Pull to refresh
0
0
Send message
Но все же мы обсуждаем карту построенную на статистических данных, за один год. И насколько я понял, вы заявили, что такой низкий показатель у нас из-за того что «детей просто нечем кормить». Ниже я привел ссылку на статистику только по России, из которой видно, что в центральных регионах (которые исключение, там детей наверно есть чем кормить) рождаемость не лучше, а даже хуже чем в среднем по России. Т.е. на основе этих и мировых данных, я считаю, что ваше подозрение не верно.
Еще могут дать вот такую ссылку (правда у меня она долго открывается). На карте хорошо видно, в каких регионах этот коэффициент высокий. И опять же это как-то не очень вяжется с фразой про центральный регион России, т.к. в европейской части ситуация с рождаемостью хуже, чем в среднем по стране.
А вы на карту то смотрели? Получается что в Африке еды очень много… Корреляция этого показателя и уровня жизни скорее обратная (точнее начиная с некоторого уровня влияние оказывают уже другие факторы). Вот еще картинка en.wikipedia.org/wiki/File:TFR_vs_PPP_2009.svg Ну и статью в той же википедии можно почитать. Еще можно вот эту табличку посмотреть www.cia.gov/library/publications/the-world-factbook/rankorder/2127rank.html В Германии тоже детей нечем кормить?
Как альтернатива, какой-нибудь продвинутый спутниковый ресивер вроде дримбокса. Китайские клоны с доставкой стоят в районе 200-300$, т.е. примерно как билайновская приставка, если ее сразу выкупать. По возможностям, если конечно есть желание копаться в прошивках и т.п. ее превосходят. Появились они не 1,5 года назад, а раньше, хотя и цены со временем снижаются. Единственное цены на подписку у НТВ+ вроде все же по больше будут.
В ядре часть открытых драйверов. Для nvidia они получены реверсиженериногом, а у ATI спеки открыты. Хотя поддержка местами не полная, но все же эти драйвера в некоторых случая могут оказаться вполне приемлемыми. К тому же они поддерживают некоторые фитчи, которые закрытые драйвера не поддерживают, например KMS или работу внутри Xen. Работают из коробки и как правило не ломаются с выходом новой версии ядра/xorg, т.к. вместе с ними идут и их новые версии.
Пару раз получал вторичное извещение без первичного. Один раз вообще без вопросов было, получал сразу несколько посылок, в т.ч. по первичному (в один день в ящике появились сразу несколько извещений, причем на некоторые посылки вторичное и первичное, а на одну только вторичное, похоже какой-то затор с разносом был). В другой раз попросили написать что-то вроде, «первичного извещения не получал, число, подпись». Что бы совсем извещения не приносили, пока такого не было.
Я сказал только про первые два битовых поля, но далее то там есть еще, для флагов и смещения…
В коде лишний пробел случайно поставил :)
А так вывод 0х4. Платформа например x86_64, компилятор gcc version 4.6.3 (Debian 4.6.3-1). Или специально проверил на под Windows x86, компилятор «Microsoft ® 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86» (правда пришлось stdint.h отсюда подсунуть msinttypes.googlecode.com/svn/trunk/stdint.h). Результаты идентичные. Да и собственно я же не просто так про это написал, выше уже писал про netinet/ip.h. В моем дистрибутиве в нем есть такие строчки:
struct iphdr
  {
#if __BYTE_ORDER == __LITTLE_ENDIAN
    unsigned int ihl:4;
    unsigned int version:4;
#elif __BYTE_ORDER == __BIG_ENDIAN
    unsigned int version:4;
    unsigned int ihl:4;
#else
# error "Please fix <bits/endian.h>"
#endif

Под другими ОС, которые поддерживают как LE так и BE платформы, и где такой файл в наличии, так же присутствует нечто подобное.
И какой же результат будет у этого кода?
IpHeader iphdr = {0};
iphdr.version = 4;
std::cou t<< std::hex << std::showbase << (int)*(uint8_t *)&iphdr << std::endl;

Почему в последних 4х битах первого байта вдруг оказалась версия IP протокола, когда она должна быть в первых 4х?
Для начало надо будет посмотреть, как оно заработает на x86 :) Т.к. описанная в статье структура IP пакета соответствует IP протоколу как раз на процессорах с big endian, а на LE будет отличаться.
В разделе «Порядок байт» в коде скорее всего будут проблемы на LE :) Т.е. на в т.ч. x86… в старших битах первого байта там будет header_length, а в младших ver. Тогда как на BE наоборот, т.е. так же как и должно быть в IP пакете.
Собственно во многих ОС можно посмотреть netinet/ip.h, как там описан заголовок IP пакета. Так что битовые поля тоже достаточно платформозависимые (об этом правда уже написали выше), в отличии кстати от логических операторов ;) Конечно если для них изначально подготовить данные.
В C можно объявлять переменные в начале любого блока, а не только функции. А в С99 их можно объявлять в любом месте, так же как и в C++, в т.ч. и условиях.
Далее, конструкция for(int i=0; i<10; i++) {… } все же объявляет i только в пределах цикла.
Я про 802.1Q и соответственно ядерный модуль 8021q, а так же утилиту vconfig. Тут подробнее xgu.ru/wiki/VLAN_%D0%B2_Linux И не понимаю, про какие alias в данном контексте идет речь.
2. Тут конечно «отношение полной мощности к активной».
Еще как влияет. Фактора влияния два:
1. При работе импульсного БП с диодным мостом ток это совсем не синусоида, а измерительный прибор вроде не true rms, т.е. на токе далеком от синусоиды он может показывать что угодно.
2. Power factor, т.е. отношение активной к реактивной мощности у импульсных БП без PFC (Power Factor Correction) далек от единицы. Не зря же в современные БП (к noname это не относиться) ставят этот самый PFC. www.nix.ru/support/faq/show_articles.php?number=616&faq_topics=PFC
В Linux vlan'ы будут работать почти с любой сетевухой ;)
Так в том то и дело, что ваттметр тоже не учитывает. А если умножать напряжение и ток, вернее их среднеквадратичные значения, как не смещай их относительно друг друга (предположим, что напряжение и ток это идеальные синусоиды, что для импульсных БП уже не верно, и не каждый мультиметр дает среднеквадратичное значение не для синусоиды, т.е. уже одна из измеряемых величин непонятно что), циферки будут одинаковые, а вот активная и реактивная мощность будут разными.
Такие вещи все-таки стоит мерить ваттметром, а не умножать напряжение на ток, при том, что они переменные и нагрузка имеет реактивную составляющую.
МСВС это Linux. Что не мешает ему работать на SPARC ;)
Причем тут вообще призыв? МО не сами строят РЛС и не пишут софт для них. Этим занимаются соответствующие НИИ. Тут скорее зря убрали возможность предоставление отсрочки для работников этих НИИ.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Registered
Activity