Начнем с того, что разделение на физиков и лириков придумали в 60ые для смеха, типа западников и славянофилов, или патриотов и либералов, спартак или динамо — классическая “двухпартийная система” наглядно показанная в серии Южного Парка про клизму и бутерброд. Еще древние римляне называли этот принцип “разделяй и властвуй”.

В итоге разным командам дали разные книжки, а про чужие говорили «скучно, вам не понять, да и понимать НЕ НАДО», а понять меж тем легко, главное посмотреть сквозь другие очки, сменить парадигму. Ведь ни одна из парадигм не истина, а вот бинокулярное зрение сильно облегчает жизнь. А тут, дали людям разные очки, одним плюс, другим минус, гуманитариям шестеренок в часах не рассмотреть, а для технарей через 200 метров вся природа абстракция.

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

Java — очень распространённая платформа, на ней пишут очень разные вещи, начиная от Big Data, заканчивая микросервисами, монолитами, enterprise и прочим. И, как правило, всё это развёртывают на Linux серверах. При этом, соответственно, те люди, которые пишут на Java, зачастую делают это совсем на других операционных системах. Там они:

• пишут код;
  
• отлаживают, тестируют;
  
• после этого упаковывают в jar;
  
• отправляют на Linux, и оно работает.
  

В том, что оно работает, нет особой магии. Но это приводит к тому, что такие разработчики немножечко «засахариваются» в своём мире кроссплатформенности и не очень хотят разбираться, а как оно на самом деле работает в реальной операционной системе.



С другой стороны, есть те, кто занимается администрированием серверов, на их сервера устанавливают JVM, отправляют jar и war-файлы, а с точки зрения мира Linux все это:

• чужеродное;
  
• проприетарное;
  
• собирается не из исходников;
  
• поставляется какими-то jar-архивами;
  
• «отъедает» всю память на сервере;
  
• вообще, ведёт себя не по-человечески.
  

Цель доклада Алексея Рагозина на Highload++, расшифровка которого идет далее, была в том, чтобы рассказать особенности Java для «линуксоидов» и, соответственно, Linux — Java-разработчикам.

Ну ладно, про «полюбил» — это преувеличение. Скорее «смог сосуществовать с».

Как вы все знаете, с 16 апреля 2018 года Роскомнадзор крайне широкими мазками блокирует доступ к ресурсам в сети, добавляя в "Единый реестр доменных имен, указателей страниц сайтов в сети «Интернет» и сетевых адресов, позволяющих идентифицировать сайты в сети «Интернет», содержащие информацию, распространение которой в Российской Федерации запрещено" (по тексту — просто реестр) по /10 иногда. В результате граждане Российской Федерации и бизнес страдают, потеряв доступ к необходимым им совершенно легальным ресурсам.

После того, как в комментариях к одной из статей на Хабре я сказал, что готов помочь пострадавшим с настройкой схемы обхода, ко мне обратились несколько человек с просьбой о такой помощи. Когда у них всё заработало, один из них порекомендовал описать методику в статье. Поразмыслив, решил нарушить свое молчание на сайте и попробовать в кои-то веки написать что-то промежуточное между проектом и постом в Facebook, т.е. хабрапост. Результат — перед вами.

Недавно мы рассказали о способе наглядного представления однокубитных состояний — сфере Блоха. Всем чистым состояниям соответствуют точки на поверхности сферы Блоха, а смешанным — точки внутри нее. В этой публикации мы постараемся объяснить, что на самом деле представляют собой чистые и смешанные состояния.

Приходилось ли вам отслеживать зависимости системных процессов, «кто чей папка», найти императора и убить его, чтобы рабы не респаунились? Можно ps'ать и grep'ать, можно lsof погонять, ведь это так увлекательно ;) Но любые связи, как мне кажется, всегда проще анализировать в визуальной форме, консольные утилиты рисуют хорошие таблички, но из них не всегда можно быстро понять, что с чем связано и в какой последовательности, а для диагностики это очень важно.

Об авторе. Алекс Ирпан — разработчик из группы Brain Robotics в Google, до этого работал в лаборатории Berkeley Artificial Intelligence Research (BAIR).

Здесь в основном цитируются статьи из Беркли, Google Brain, DeepMind и OpenAI за последние несколько лет, потому что их работы наиболее заметны с моей точки зрения. Почти наверняка я что-то упустил из более старой литературы и от других организаций, так что прошу прощения — я всего лишь один человек, в конце концов.

Введение

Однажды в Facebook я заявил следующее.

Когда кто-то спрашивает, может ли обучение с подкреплением (RL) решить их проблему, я сразу отвечаю, что не может. Думаю, что это верно как минимум в 70% случаев.

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

К сожалению, в реальности эта штука пока не работает.

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

Мне довелось программировать на ассемблерах разных процессоров. Последний в списке – это Xilinx MicroBlaze. Решил выложить некоторые свои наблюдения за особенностями этих почти волшебных железок, которые как волшебный ключик Буратино открыли нам двери в волшебную страну виртуальной реальности и массовой креативности. Об особенностях современных систем x86, x86-64, ARM, ARM-64 и т.п. писать не буду, может быть в другой раз – тема очень большая и сложная. Поэтому планирую закончить на Intel 80486 и Motorola 68040. Хотелось ещё включить в обзор IBM/370, с которыми имел дело. Эти системы были довольно далеки от широких масс пользователей, но оказали при этом огромное влияние на компьютерные технологии. На них просто не хватило выделенного на тему времени, они не использовали процессоры-чипы и самих их вроде бы почему-то не осталось совсем. Очень надеюсь, что мои материалы привлекут внимание и знатоков, которые смогут добавить что-нибудь из того, о чем не подумал или не знал.

В качестве иллюстративного материала прикрепляю свой небольшой камень из Розетты – программки для расчета числа π на разных процессорах и системах по алгоритму-затвору, претендующие на звание самых быстрых его реализаций. Похожий "камень" есть и для алгоритма для быстрого расчета множеств Мандельброта.

В 1979 году сразу две страны — Западная Германия и СССР — запустили экспериментальные образцы пассажирских маглевов. Маглев (magnetic levitation) — поезд на магнитной подушке, который при движении парит в воздухе, не касаясь никакой опоры. Немцы сделали из этого настоящую рекламу — маглев по коротенькой трассе возил посетителей Международной транспортной выставки IVA. У нас же с рекламой всегда было плохо, поэтому первый советский маглев ТП-01 ездил по заводской 36-метровой трассе.

И почему вы (не) захотите стать одним из нас

Радиолюбители-связисты (HAM radio operators) – отдельная каста в мире энтузиастов электроники (electronics), о тайной жизни которых среднестатистическому паяльщику и ардуиностроителю известно мало. Далее по тексту словами «радиолюбитель», «радиоаматор» будут называться именно радиолюбители-связисты.



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

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

Я не большой любитель задавать технические вопросы на собеседованиях: по мне так лучше посидеть с кандидатом (или кандидаткой) за клавиатурой над каким-то реальным кодом, реальной проблемой — и целый день заниматься парным программированием, желательно поочерёдно с остальными членами команды. Но я считаю, что некоторые технические вопросы могут быть хорошей отправной точкой для начала увлекательного и приятного разговора и позволят глубже узнать друг друга.

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

Ядро Linux широко распространено во всем мире как на серверах, так и на пользовательских машинах, на мобильных платформах (ОС Android) и на различных «умных» устройствах. За время существования в ядре Linux появилось множество различных механизмов защиты от эксплуатации уязвимостей, которые могут существовать как в самом ядре, так и в приложениях пользователей. Такими механизмами является, в частности, ASLR и stack canary, противодействующие эксплуатации уязвимостей в приложениях.

Насколько трудно может быть измерить производительность простой функции, вроде вот этой?

// func.cpp
void benchmark_func(int* a)
{
	for (int i = 0; i < 32; ++i)
		a[i] += 1;
}

Ну, давайте просто завернём её в какой-нибудь микробенчмарк, вызовем её много-много раз (для усреднения результатов) и посмотрим, что получится, да? Ну ладно, мы можем ещё посмотреть на сгенерированные инструкции просто чтобы убедиться, что компилятор чего-то там не «наоптимизировал». Мы можем также провести несколько разных тестов, чтобы убедиться, что именно цикл является узким местом. Ну и всё. Мы понимаем, что мы измеряем, да?

Давайте представим, что в нашем файле есть ещё одна функция, скорость работы который вы тоже замеряете, но в отдельных тестах. Т.е. файл выглядит как-то так:

// func.cpp
void foo(int* a)
{
	for (int i = 0; i < 32; ++i)
		a[i] += 1;
}

void benchmark_func(int* a)
{
	for (int i = 0; i < 32; ++i)
		a[i] += 1;
}

И вот однажды ваш менеджер приходит к вам и показывает претензию от пользователя вашей библиотеки, которая заключается в том, что она не работает настолько быстро, как вы обещали. Но постойте, мы ведь хорошо измерили производительность и обещали ровно то, что получили по результатам тестов. Что же пошло не так?

Введение

Мы занимаемся разработкой глубоких нейронных сетей для анализа фото, видео и текстов. В прошлом месяце мы купили для одного из проектов очень интересную штуковину:
Intel Movidius Neural Compute Stick.


Это специализированное устройство для нейросетевых вычислений. По сути, внешняя видеокарточка, заточенная под нейронные сети, очень компактная и недорогая (~$83). Первыми впечатлениями от работы с Movidius’ом мы и хотим поделиться. Всех заинтересовавшихся прошу под кат.

Недавно коллега задал привычные уже вопросы про «зачем ходить на конференции» и «зачем смотреть записи на YouTube». Так как это друг, а не просто какой-то произвольный человек, захотелось ответить более обстоятельно, детально и по чесноку. К сожалению, в режиме онлайн, при живом общении, сделать это сложно: просто не упомнишь всех подробностей. С другой стороны, это отличная тема для хабрапоста: можно один раз написать развёрнутый обзор и потом, как истинный социофоб, отвечать на все вопросы ссылками на Хабр.

Идея проста: надо взять наиболее популярные доклады с JPoint 2017, кратенько пересказать, о чём там речь, почему это круто и зачем нужно лично мне. Каждый из этих докладов заслуживает отдельного разбора, но вначале — краткий обзор первой десятки. Поехали!

Мой инструментарий социального архитектора состоит из 20 инструментов, каждый из которых соответствует какому-либо аспекту сообщества или группы. Их можно использовать двумя способами.

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

Во-вторых, вы можете использовать их для создания сообщества, при этом прилагая усилия там, где они наиболее необходимы.

• Четкая миссия – заявленная причина существования группы.
• Свободное участие – насколько легко люди могут присоединиться к группе.
• Прозрачность – насколько открыто и публично принимаются решения.
• Бесплатные участники – как много можно платить людям за участие.
• Свобода работы с материалами (ремиксабельность) – насколько свободно участники могут использовать работу друг друга.
• Четкость протокола – насколько хорошо прописаны правила.
• Компетентность власти – насколько хорошо следят за соблюдением правил.
• Нон-трайбализм – насколько далеко распространяются права группы над своими участниками.
• Самоорганизация – насколько свободно могут участники определять свои задачи.
• Толерантность – как группа разбирается с конфликтами.
• Измеримый успех – как хорошо группа может отслеживать свой прогресс.
• Высокое награждение – как группа вознаграждает своих участников.
• Децентрализация – насколько широко распределены участники группы.
• Свободная рабочая среда – насколько легко создавать новые проекты.
• Стандартная структура – насколько общая структура стабильна и предсказуема.
• Плавность обучения – насколько легко начать и продолжить учиться.
• Позитивность – насколько группа движима позитивными целями.
• Чувство юмора – насколько серьезно группа себя воспринимает.
• Минимализм – сколько лишней работы делает группа.
• Разумное финансирование – как группа борется за выживание в экономическом плане.

Спасибо Сергею Даньшину за помощь с переводом.

Немного лирики

В те давние времена, когда трава была зеленее и деревья были выше, я твёрдо верил, что такие страшные слова, как дивергенция потоков, cache missing, coalescing global memory accesses и прочие не позволяют эффективно реализовать задачу множественного поиска на GPU. Годы шли, уверенность не исчезала, но в один прекрасный момент я наткнулся на библиотеку PFAC. Если интересно, на что она способна — добро пожаловать под кат.

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

Но у меня нет сторонних проектов. У меня нет аккаунта на GitHub. У меня нет open-source проектов, которые я строгаю по вечерам. У меня ровно ноль пулл-реквестов в любой из последних модных проектов, в которых участвуют все крутые кодеры. Я не вожусь с упражнениями в Haskel. И я ненавижу хакатоны.

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

Space Quest. Day of the Tentacle. Gabriel Knight. Monkey Island. У игроков определённого возраста простое упоминание этих названий вызывает воспоминания о целом мире игр, теперь почти утерянном.

На современном рынке графические адвенчуры с трудом борются за место под солнцем, но когда-то они год за годом были на вершине списков бестселлеров. Жанр взлетел на пик компьютерного гейминга во второй половине 1980-х, и испытал столь же резкое падение десятком лет позже. Он определил печальную судьбу крупнейших компаний в индустрии игр, даже несмотря на то, что примитивная графика игр стала фоном миллионов детских воспоминаний. Адвенчуры дали нам Роджера Вилко, Сэма и Макса, а также целый мир Myst. Но сегодня только немногие геймеры знают историю жанра целиком, или о том, как классические игры Sierra и LucasArts конца 1980-х и начала 1990-х исчезли под натиском шутеров от первого лица.

Я расскажу, как мы добрались от King's Quest до The Longest Journey и о том, почему это важно. Чтобы добраться до конца этой истории, вам не потребуется использовать текстовый парсер, объединять два загадочных предмета из инвентаря для решения безумной головоломки или заниматься пиксель-хантингом по всему экрану.

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

На этой неделе заканчивается формирование программы третьей международной конференции Linux Piter, проходящей при поддержке Dell EMC.

Это два полных дня, 3 и 4 ноября, пятница и суббота в Питере, заполненные не всякой шелухой, а полноценными докладами про сеть, системные ресурсы, контейнеры и внутренности ядра Linux. Сугубо техническая тематика интересна всем тем, кто каждый день использует open source продукты и топовые технологии вокруг Linux в своей работе и в своих проектах.



Если кратко, то у нас 3 доклада про сетку, 5 про контейнеры, 4 про ядро, пара про производительность и еще много разного. Чтобы был понятен уровень выступлений: среди спикеров из Штатов, Германии, Швеции, Австрии и конечно же России к нам приедут Lennart Poettering (мантейнер systemd) и Christoph Hellwig (мантейнер XFS и NVM Express драйвера) – это реально круто. Будут доклады инженеров, работающих в Redhat, Intel, Microsoft (!), Ericsson, Docker и Canonical. Будут два параллельных потока с десяти утра до вечера: язык выступлений первого потока — английский (с синхронным переводом на русский для тех, кто не успевает), второго — русский (с синхронном на английский для наших иностранных гостей).
Ниже несколько анонсов выступлений в разных разделах конференции.

Приятная особенность Linux Piter #3 в том, что параллельно на этой же площадке будет проходить ещё одна наша техническая конференция — Piter Py #4, и участники смогут свободно посещать доклады любой из этих двух конференций.