В чем отличие маршрута пакета от его пути?
Стандартный механизм маршрутизации пакетов в интернете — per hop behavior — то есть каждый узел в сети принимает решение куда ему отправить пакет на основе информации, полученной от протоколов динамической маршрутизации и статически указанных администраторами маршрутов.

Маршрут — это интерфейс, в который нам надо послать пакет для достижения какого то узла назначения и адрес следующего маршрутизатора (next-hop):

R1#sh ip rou | i 40.  
	 40.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
O        40.0.0.0/31 [110/3] via 20.0.0.0, 00:01:54, FastEthernet0/0
O        40.1.1.1/32 [110/4] via 20.0.0.0, 00:00:05, FastEthernet0/0

Что такое путь? Путь — это список узлов, через которые прошел (пройдет) пакет:

 1  10.0.0.1  16.616 ms  16.270 ms  15.929 ms
 2  20.0.0.0  15.678 ms  15.157 ms  15.071 ms
 3  30.0.0.1  26.423 ms  26.081 ms  26.744 ms
 4  40.0.0.0  48.979 ms  48.674 ms  48.384 ms
 5  100.0.0.2  58.707 ms  58.773 ms  58.536 ms

Путь пакета можно посмотреть с помощью утилит tracert в OC Windows и traceroute в GNU/Linux и Unix-подобных системах. (другие команды, типа tracepath мы не рассматриваем).
Многие считают что этих утилит один и тот же принцип работы, но это не так. Давайте разберемся.

Качаете и раздаете торренты на высокой скорости, но из-за этого прыгает пинг в онлайн-играх, и играть становится невозможно? Сожитель совершает видеозвонок по скайпу, а вы не хотите ему мешать? Держите файлопомойку, которая занимает весь канал, а QoS настраивать лень? Заливаете видео на youtube с телефона, скорость ограничить не можете?

fq_codel — планировщик пакетов (qdisc) с активным управлением очередью, который решит все ваши проблемы!
Все еще не верите? Посмотрите видео!

На видео видно, что компьютер слева, подключенный через обычный домашний роутер с прошивкой cerowrt (измененный OpenWRT), открывает сайты значительно быстрее, чем правый компьютер с тем же роутером, но со стандартной прошивкой.

Предлагаю читателям «Хабрахабра» перевод поста «Rust Once, Run Everywhere» из блога Rust за авторством Alex Crichton. Сам я некоторое время уже интересуюсь этим языком, а в связи со скорым релизом версии 1.0 хотел бы продвигать его по своим скромным возможностям. Ничего своего, к сожалению, сейчас у меня написать не получается, но когда-то я занимался переводами, так что решил вспомнить давнее дело. Перевод этого поста на Хабре я не нашёл, так что решил сделать свой.
Некоторые термины, которые обозначают уникальные для Rust-а концепции (ownership, borrowing, lifetime parameter), я не знал, как лучше перевести на русский, так что постарался подобрать наиболее подходящие по смыслу и более-менее понятные для русскоязычной аудитории слова. Любые предложения-улучшения принимаются.

Никогда не было планов добиться мирового господства Rust-а за одну ночь, так что есть большая потребность в способности взаимодействовать с уже сущестующим кодом так же легко, как и с нативный кодом на самом Rust-е. Именно поэтому Rust даёт возможность очень просто использовать C API без накладных расходов, и при этом гарантирует строгую безопасность управления памятью, благодаря своей системе управления владением и заимствованием указателей.

Сегодня, как и обещала, я продолжу тему планирования легких сущностей, которую уже начала в своем цикле статей. В нем я рассказала о внутреннем устройстве tasklet, workqueue и protothread. Конечно, тема не ограничивается лишь этими примерами: есть еще FreeRTOS с ее coroutine, или GNU Portable threads; или можно отойти от структур и библиотек, применяющихся в ОС, и вспомнить различные green threads, которых становится все больше и больше.

На этот раз я хочу поделиться тем, как мы реализовали легкие потоки в проекте Embox. С одной стороны мы постарались учесть опыт предыдущих разработок, с другой — привнести что-то новое.

Недавно руководитель проекта Perezvoni.com Виталий Ягодкин пообщался с известным российским бизнес-тренером, который проводит тренинги по лидерству, мотивации и харизме Радиславом Гандапасом.

Радислав рассказал как нужно мотивировать себя и сотрудников для достижения целей. Также речь шла о том, почему большинство предпринимателей терпит неудачу на начальном этапе своего пути и дал несколько полезных советов о том, как этого избежать.

Образы Docker могуть быть очень большими. Многие превышают 1 Гб в размере. Как они становятся такими? Должны ли они быть такими? Можем ли мы сделать их меньше, не жертвуя функциональностью?

В CenturyLink Lab мы много работали над сборкой различных docker-образов в последнее время. Когда мы начали экспериментировать с их созданием, мы обнаружили, что наши сборки очень быстро раздуваются в объеме (обычным делом было собрать образ, который весит 1 Гб или больше). Размер, конечно, не столь важен, если мы говорим про образы по два гига, лежащие на локальной машине. Но это становится проблемой, когда вы начинаете постоянно скачивать/отправлять эти образы через интернет.

Я решил, что стоит копнуть поглубже и разобраться с тем, как работает процесс создания docker-образов, чтобы понять, что можно сделать для уменьшения размера наших сборок.

Ранее мы рассматривали этапы разработки торговых систем и изучали способы проверки работоспособности робота с помощью исторических данных, но не уделили внимание еще одному важному аспекту — созданию самой стратегии работы на рынке. Сегодня мы восполним этот пробел и поговорим о том, что нужно учитывать при разработке стратегии для торгового робота.

Еще одна статья о CUDA — зачем?

На Хабре было уже немало хороших статей по CUDA — раз, два и другие. Однако, поиск комбинации «CUDA scan» выдал всего 2 статьи никак не связанные с, собственно, алгоритмом scan на GPU — а это один из самых базовых алгоритмов. Поэтому, вдохновившись только что просмотренным курсом на Udacity — Intro to Parallel Programming, я и решился написать более полную серию статей о CUDA. Сразу скажу, что серия будет основываться именно на этом курсе, и если у вас есть время — намного полезнее будет пройти его.

Со времени предыдущего поста из жизни lock-free контейнеров прошло немало времени. Я рассчитывал быстро написать продолжение трактата об очередях, но вышла заминка: о чем писать, я знал, но реализации на C++ этих подходов у меня не было. «Не годится писать о том, что сам не попробовал», — подумал я, и в результате я попытался реализовать в libcds новые алгоритмы очередей.
Сейчас настал момент, когда я могу аргументированно продолжить свой цикл. В данной статье закончим с очередями.

Кратко напомню, на чем я остановился. Были рассмотрены несколько интересных алгоритмов lock-free очередей, а под занавес приведены результаты их работы на некоторых синтетических тестах. Главный вывод — всё плохо! Надежды на то, что lock-free подход на магическом compare-and-swap (CAS) даст нам пусть не линейный, но хотя бы какой-то рост производительности с увеличением числа потоков, не оправдались. Очереди не масштабируются. В чем причина?..

Digital Ocean — лоукостер на рынке облачных VPS провайдеров. Пользуется технологией виртуализации KVM. Хорош по соотношению цена/качество и бла-бла-бла, вы сами всё это знаете.

Но есть в нём и несколько минусов, одним из которых является ограничение в поддерживаемых операционных системах. Официальная позиция хостера состоит в том, что место на дисках в дроплетах (образах виртуальных машин) может быть расширено из панели управления без необходимости переустановки системы, поэтому загрузчик туда лучше не ставить. В связи с этим, libvirt не читает загрузчик внутри образа, а использует предустановленное в панели управления ядро с хостовой машины.

Поддержку загрузки пользовательских ядер они обещают сделать со дня на день… уже чуть больше года.

Мы ждать и клянчить не будем.

В предыдущей своей статье я затронула тему многопоточности. В ней речь шла о базовых понятиях: о типах многозадачности, планировщике, стратегиях планирования, машине состояний потока и прочем.

На этот раз я хочу подойти к вопросу планирования с другой стороны. А именно, теперь я постараюсь рассказать про планирование не потоков, а их “младших братьев”. Так как статья получилась довольно объемной, в последний момент я решила разбить ее на несколько частей:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

В третьей части я также попробую сравнить все эти, на первый взгляд, разные сущности и извлечь какие-нибудь полезные идеи. А через некоторое время я расскажу про то, как нам удалось применить эти идеи на практике в проекте Embox, и про то, как мы запускали на маленькой платке нашу ОС с почти полноценной многозадачностью.

Рассказывать я постараюсь подробно, описывая основное API и иногда углубляясь в особенности реализации, особо заостряя внимание на задаче планирования.

Сегодня наше приложение Диктовка для интерактивного написания и редактирования текста голосом появилось в AppStore и Google Play. Его главная задача — продемонстрировать часть новых возможностей комплекса речевых технологий Яндекса. Именно о том, чем интересны и уникальны наши технологии распознавания и синтеза речи, я хочу рассказать в этом посте.



Пара слов, чтобы вы понимали, о чём пойдёт речь. Яндекс уже давно предоставляет бесплатное мобильное API, которое можно использовать, например, для распознавания адресов и голосовых запросов к поиску. За этот год мы смогли довести его качество почти до того же уровня, на котором такие запросы и реплики понимают сами люди. И теперь мы делаем следующий шаг — модель для распознавания свободной речи на любую тему.

Кроме этого, наш синтез речи поддерживает эмоции в голосе. И, насколько нам известно, это пока первый коммерчески доступный синтез речи с такой возможностью.

Обо всём этом, а также о некоторых других возможностях SpeechKit: об активации голосом, автоматической расстановке пунктуационных знаков и распознавании смысловых объектов в тексте — читайте ниже.

Жестокими законы окружающей нас природы можно назвать только в переносном смысле. Мы создали машины, способные освободить нас от уз, удерживающих в гравитационном колодце всё человечество, но управление некоторыми из их аспектов остаётся вне наших сил. Если мы хотим начать наше путешествие по Солнечной системе, то эти ограничения придётся как-то обходить.

Современные ракеты отбрасывают часть собственной массы в виде газа из сопел двигателей, что даёт им возможность двигаться в противоположном направлении. Это реально благодаря третьему закону Ньютона, который был сформулирован в 1687 году. Всему нашему ракетному движению мы обязаны формуле Циолковского 1903 года.


В формуле всего четыре переменных (слева направо): конечная скорость летательного аппарата, удельный импульс ракетного двигателя (отношение тяги двигателя к секундному расходу массы топлива), начальная масса летательного аппарата (полезная нагрузка, конструкция и топливо) и его конечная масса (полезная нагрузка и конструкция).

Как можно изменить одну из переменных, если три другие уже заданы? Это просто невозможно, никакая форма желания, хотения или просьб здесь не поможет.

Именно потери на гравитацию определяют пределы человеческого исследования космоса, и мы вынуждены их учитывать, когда мы выбираем место, куда мы хотим отправиться. Сегодня таких мест не так уж и много. С земной поверхности мы можем оказаться на орбите Земли, с орбиты Земли можно отправиться на поверхность Луны, или на поверхность Марса, или в пространство между Луной и Землёй. Возможны различные комбинации, но с текущим развитием технологий это самые вероятные точки назначения.

Представленные ниже значения не учитывают никакие потери на, к примеру, сопротивление атмосферы, но значения достаточно близки для иллюстрации того, что нужно принять как должное. Это в некотором роде стоимость полёта.

Quotient filter — это вероятностная структура данных, позволяющая проверить принадлежность элемента множеству. Она описана в 2011 г. как замена фильтру Блума. Ответ может быть:
— элемент точно не принадлежит множеству;
— элемент возможно принадлежит множеству.

Скотт Мейерс — один из самых известных и признанных экспертов по C++, автор серии книг «Эффективное использование C++», которые читал почти каждый профессиональный разработчик на C++ и которые оказали заметное влияние на всю экосистему и качество использование языка.

Лично я стал почти его фанатом ещё студентом, когда в начале 2000-х читал статьи Скотта, лежащие в основе его книг (сами книги на тот момент в России ещё не были переведены, а на английские с Амазона у меня, как бедного студента, денег не было).

Поэтому, когда он некоторое время назад приехал в Яндекс, чтобы провести тренинг для наших разработчиков, я не мог не воспользоваться этим шансом, чтобы поговорить с ним. Разговор получился о том, каким он видит будущее C++ и программирования вообще, как отличаются разработчики в разных странах и в разных индустриях, и о нём самом.

Некоторые новинки очень настораживают. Это то открытый ноутбук без клавиатуры и без диска за $1'995 на базе слабого ARM процессора, то «универсальный» и «мощный» ПК Tango размером со смартфон за $350, фактически совершенно бесполезный без второй док-станции, которая стоит как половина этого ПК, в том случае если всё-таки носить вычислительный модуль между работой и домом.

Я давно присматриваюсь заменить свой ноутбук на что-то, причём ноутбуки с момента появления планшета меня как таковые интересовать совершенно перестали.
Хотелось что-то совсем компактное, и я начал копать в сторону форм-фактора nano-ITX и pico-ITX, но ничего достаточно производительного за разумные деньги так и не нашлось.

Зато нашлась вот такая буквально поллитровка, несущая в себе 4е поколение Intel Core, Haswell.



Если по картинке не понятно, то этот ПК всё же чуть меньше, чем уже упоминавшаяся док-станция для Tango (108mm x 115mm x 30mm vs 135mm x 135mm x 27mm).

Поставляется с вмонтированным в материнскую плату процессором. Линейка процессоров:

— Intel® Core™ i7-4500U 1.8 GHz – 3.0GHz (turbo), Intel HD 4400
— Intel® Core™ i5-4200U 1.6 GHz – 2.6GHz (turbo), Intel HD 4400
— Intel® Core™ i3-4010U 1.7 GHz, Intel HD 4400
— Intel® Celeron™ 2955U 1.4 GHz, Intel HD

Существует также и модель на базе AMD A8-5545M 1.7G/2.7GHz.

Продаётся такое чудо как модель для сборки, для полной комплектации которой необходима память (можно вставить до 16ГБ, осторожно, подходит только DDR3 на 1.35В, не 1.5В) и диск mSATA.
Стоимость в зависимости от процессора колеблется на зарубежных сайтах от $250 до $500. Комплект из двух планок памяти общим объёмом 8ГБ можно приобрести приблизительно за $100, примерно столько же обойдётся и mSATA SDD на 128ГБ. WiFi b/g/n и Bluetooth 4.0/3.0 уже на борту, занимают единственный PCIe порт.

Взявшись за этот пост, автор полностью отдает себе отчет. И в том что «набило оскомину». И что «только ленивый не кинул камень». И про то что «хватит уже, достали». Однако, вдоволь начитавшись доморощенных и не очень аналитиков, автор решил все-таки выразить собственное мнение, которое отличается от того общепринятого, что с некоей мазохистской истомой доселе перепечатывалось здесь и тут различными авторами, интерпретаторами и переводчиками. Вероятно кому-то будет интересно его прочитать.

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

«Цель: получить работу в IBM»
— пишет какой-то идиот-соискатель в Amazon.com.

---

ВНИМАНИЕ: это мое собственное, *персональное*, мнение, не Google, не Amazon или кого-либо еще. Я думаю вы обнаружите, что большинство рекрутеров, оценивающих анкеты в технических компаниях — особенно в технических компаниях, которые производят собственное программное обеспечение сами, такие как Yahoo!, Ebay, Amazon.com, Microsoft или Google — в целом, согласятся со многим из перечисленного. Но опытные рекрутеры расходятся во мнениях касательно многих мелких деталей, и, в конце-концов, это всего лишь мое собственное мнение. Эти советы не гарантируют получения Вами сколь-нибудь лучших результатов. Возможно, у вас будет другой опыт. Не используйте эти советы в ванной или стоя в луже. Не стучите по стеклу, это раздражает советы. Советы не кормить! И т.д.

---

Мозг подопытной мыши в процессе сна. Красные «полосы» на снимке — потоки спинномозговой жидкости в процессе очистки от отходов.

Сон очищает мозг от лишней информации, накопившейся во время бодрствования — утверждение, знакомое, наверное, каждому еще со школьной скамьи. В 2013-м году появилось несколько более существенное пояснение по поводу роли сна в жизни человека.

Привет, Хабр!

Наткнулся на интересное интервью с сооснователем Google Ларри Пейджем. Мне оно показалось очень занимательным, и я старался как мог переводя его на русский язык, чтобы поделиться им с вами. Перевод может быть не очень точным, прошу за это прощения. Для свободно англо-читающей аудитории в конце поста ссылка на источник, в оригинале естественно можно получить больше удовольствия от прочтения. Если что-то из интервью вам придётся не по вкусу или вы не согласны с тем что говорит Ларри — не спешите минусовать, подумайте о том, что я всего лишь перевел это для вас. Tim — это интервьюер. Ну, поехали:



Tim: Google известна тем что поощряет своих сотрудников решать амбициозные задачи и делать большие ставки. Почему это так важно?
Larry Page: Я волнуюсь о том, что что-то серьёзно пошло не так с тем как мы управляем компаниями. Если вы читаете то что средства массовой информации пишут о нашей компании, или вообще о всей технологической индустрии — речь всегда идёт о конкуренции. Всё преподносится так как будто речь идёт о спортивном событии. Не легко найти примеры действительно впечатляющих вещей, которые были сделаны исключительно за счет конкуренции. Многие компании приходят в упадок со временем, потому что они имеют тенденцию делать в точности тоже что они делали раньше, всего лишь внося небольшие изменения. Это естественно для людей — заниматься чем-то в чем они точно уверены что не потерпят неудачу. Но просто постепенного улучшения недостаточно.
Таким образом огромная часть моей работы это сфокусировать людей на вещах, работая над которыми можно добиться чего-то более значимого чем просто постепенного улучшения существующего. Возьмём например Gmail. Когда мы выпустили её, мы были поисковой компанией — это был большой скачёк для нас выпустить почтовый сервис, не говоря уже о том что мы дали пользователям в сотню раз больше свободного места чем они могли получить где-либо еще. Это не что-то что могло бы произойти само собой если бы мы просто сосредоточились на постепенном улучшении.
Tim: Но вы же должны улучшать и ваши существующие продукты, верно?
Larry Page: Конечно. Но периодически, каждые несколько лет, вам следует работать над чем-то новым, что на ваш взгляд является поистине удивительным.
Tim: Теперь у вас есть отдельное подразделение называемое Google X, предназначенное для таких «moon-shot» проектов (прим. автора: не знал как это точно перевести поэтому так и оставил, здесь имеются ввиду революционные проекты вроде полётов на луну и т.п.), как например самоуправляемые автомобили. Почему вы решили что нужно учредить целый департамент для этого?
Larry Page: Я думаю нам необходимо делать прорывные вещи, а не просто улучшать то что есть и это касается всего нашего бизнеса. Но сейчас Google X делает вещи которые могут быть сделаны более независимо.
Знаете, у нас всегда есть такие споры: У нас есть все эти деньги, у нас есть все эти люди, так почему же мы просто не производим больше? Вы можете сказать что Apple делает очень небольшое кол-во вещей, и это довольно хорошо работает для них. Но я нахожу это неудовлетворительным. Я чувствую как много возможностей использования технологий для улучшения жизни людей сейчас существует в мире. В Google мы нацелены лишь на 0,1% от этих возможностей. А все вместе взятые технологические компании охватывают лишь около 1%. Это означает что 99% это возможности которые упускаются. Инвесторы всегда беспокоятся: «Ах, вы ребята собираетесь потратить слишком много денег на эти сумасшедшие вещи.» Но это как раз сейчас те самые захватывающие вещи — YouTube, Chrome, Android. Если вы не делаете что-то сумасшедшее значит то что вы делаете неправильно!
Tim: Но с другой стороны — первопроходцам всегда приходится не легко. Посмотрите что было с Xerox PARK, не похоже чтобы их фантастические инновации особо помогли самой корпорации.
Larry Page: PARC имела впечатляющую исследовательскую организацию и они внесли большой вклад в современные вычислительные технологии. Но они не были сосредоточены на получении прибыли от своих изобретений. А этого упускать нельзя. Возьмём к примеру компанию Tesla, которой я восхищаюсь. Они не просто сделали действительно инновационный автомобиль, а вероятно около 99% своих усилий потратили выясняя как сделать чтобы их продукт стал массовым и популярным и чтобы им действительно начали пользоваться. Когда я еще только рос, я хотел быть изобретателем. Но потом я понял что есть слишком много печальных историй о изобретателях, таких как Никола Тесла к примеру. Это удивительные люди, которые не имели большого влияния, по причине того что не превращали свои изобретения в бизнес.