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

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

Введение

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

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

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

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

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

A forwarding entity always forwards packets in per-flow order to
zero, one or more of the forwarding entity’s own transmit interfaces
and never forwards a packet to the packet’s own receive interface.
Brian Petersen. Hardware Designed Network

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

А через 10 минут он закажет такси через приложение на телефоне, и ему не придётся даже брать с собой в дорогу наличку.

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

За это время тысячи MPLS-меток будут навешаны и сняты, миллионы обращений к различным таблицам произойдут, базовые станции сотовых сетей передадут гигабайты данных, миллиарды пакетов больших и малых в виде электронов и фотонов со скоростью света понесутся в ЦОДы по всему миру.

Это ли не электрическая магия?

В своём вояже к QoS, теме обещанной многократно, мы сделаем ещё один съезд. На этот раз обратимся к жизни пакета в оборудовании связи. Вскроем этот синий ящик и распотрошим его.


Кликабельно и увеличабельно.

Сегодня:

1. Коротко о судьбе и пути пакета
2. Плоскости (они же плейны): Forwarding/Data, Control, Management
3. Кто как и зачем обрабатывает трафик
4. Типы чипов: от CPU до ASIC'ов
5. Аппаратная архитектура сетевого устройства
6. Путешествие длиною в жизнь

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "Code your own blockchain in less than 200 lines of Go!".

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

Изначально проект PUBG (просим прощения у оригинальной PUBG за использование их аббревиатуры, мы всего лишь хотим использовать эту игру для развития навыков программирования и не планируем публиковать ее в Steam в будущем) был разработан как внутренний проект нашей студии для развлечения. Затем же мы подумали, что он может быть полезен другим студиям, компаниям и образовательным учреждениям, и опубликовали его под лицензией MIT.

У этого перевода не совсем обычная история. Системы контроля версий далеки от моих профессиональных интересов. Для рабочих проектов они мне требовались нечасто, причем, разные, так что, каждый раз, когда возникала такая необходимость, я заново вспоминала, как в них делается та или иная операция. А для личных проектов мне хватало возможностей Dropbox, хранящей историю версий файлов.


^{Изображение из твиттера @girlie_mac}

Но вот однажды я на три незабываемых дня попала в роддом — это иногда случается с женщинами. Из развлечений у меня были новорожденная дочь и телефон с большим экраном. Дочь поначалу развлекала плохо (дома она быстро исправилась), а на телефоне помимо книг и фильмов обнаружился текст «Git from the bottom up», который оказался более чем годным… С тех пор прошло почти 3 года, подросшей дочке уже пора самой начинать использовать Git Git стал мейнстримом, если не сказать стандартом в современной разработке, а я с удивлением обнаружила, что перевода на русский этого чуда, полезного не только начинающим, но и продвинутым пользователям Git, до сих пор нет. Исправляю эту ситуацию.

Как все знают из новостных лент, мы живём в постоянно эволюционирующей киберпанковской антиутопии. Люди подключают туалеты к Интернету! Если этот гибсоновский мир кажется вам слишком РЕАЛЬНЫМ, то вы можете поиграть в десять лучших видеоигр о взломе, программировании и вычислениях, чтобы сбежать в мета-антиутопию. Которая, я уверен, является намного лучшим местом.

10. TIS-100

[официальный сайт]

Да-а-а, приготовьтесь к тому, что ваш мозг начнёт болеть. TIS-100 — это игра студии Zachtronics, разработчика игр-головоломок, выпустившей Infinifactory и SpaceChem. В маркетинге она позиционируется как «игра о программировании на языке ассемблера, о которой вы не просили», и хотя я обычно игнорирую маркетинговые слоганы, здесь не могу не согласиться.

Игрок получает в своё распоряжение таинственный компьютер из 70-х, найденный в вещах покойного дядюшки. Когда-то он игрался с ним, пытаясь разобраться. Теперь это ваша задача. Если вкратце, то вам нужно получить числа, чтобы провести машину из точки A в точку B, выполнив на каждом уровне «цели» (например, сначала вывести положительное число, а затем отрицательное). Для этого у вас есть список команд, изложенных в смутном руководстве пользователя. Игра советует вам распечатать это руководство в бумажном виде. В нём есть сделанные дядей примечания и пометки маркером, дающие подсказки о сущности этой машины.

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

Попробуем рассмотреть это более детально.

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

И если ошибка второго рода выражается просто:

$$

где Π — это полнота;

то вот ошибка первого рода весьма нетривиально выражается через полноту и точность (см.ниже).

Но это лирика. Самый важный вопрос:

Почему в DataScience используют полноту и точность и почти никогда не говорят об ошибках первого и второго рода?

Кто не знает или забыл — прошу под кат.

UPD: добавлен график функции.

Подобно своему создателю Карлу Вейерштрассу, это чудовище возникло из ниоткуда. Потратив четыре года учёбы в университете на кутежи и фехтование, Вейерштрасс выпустился из него с пустыми руками. В конце концов он взялся за преподавание и бо́льшую часть 1850-х был школьным учителем в Браунсберге. Ему была отвратительна жизнь в маленьком прусском городишке, он находил своё существование там одиноким. Единственной отдушиной для него стали математические задачи, над которыми он работал между уроками. Но ему не с кем было поговорить о математике, и у него не было технической библиотеки для обучения. Даже результатам его работ не удавалось покинуть пределов Браунберга. Вместо публикации в академических журналах, как это сделал бы университетский исследователь, Вейерштрасс добавлял их к школьным проспектам, пугая потенциальных учеников заумными уравнениями.

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

Предисловие

Эта статья является продолжением цикла статей про асинхронность:

1. Асинхронность: назад в будущее.
   
2. Асинхронность 2: телепортация сквозь порталы.
   

Спустя 3 года я решил расширить и обобщить имеющийся спектр асинхронного взаимодействия с использованием сопрограмм. Помимо этих статей также рекомендуется ознакомиться с универсальным адаптером:

1. Универсальный адаптер
   

Введение

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

Предисловие

Если вы создаёте игру-платформер в стиле «беги и прыгай», то, возможно, уже задумывались о добавлении в неё ИИ. Он может управлять противниками, объектами, которые игрок должен преследовать, и так далее… И слишком часто ради простоты программист реализации отказывается от умного ИИ, что в результате приводит к тому, что ИИ не может справиться с хитрыми прыжками, особо умным игроком или движущимися объектами уровня.

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

Мы рассмотрим основную идею и создадим полную реализацию. Более сложные случаи, в том числе подвижные платформы/разрушаемые стены, мы рассмотрим в другой статье.

Эта техника использована в игре Nomera, см. на www.dotstarmoney.com или в Twitter.



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

У вас есть старенький (или не очень) компьютер с двумя сетевыми картами? Вам надоела реклама и лишние телодвижения для обхода блокировок? Вы не хотите с этим мириться? Тогда добро пожаловать под кат.

Всем привет!

Сегодня мы хотели бы поделиться своим списком материалов по тематике reverse engineering (RE). Перечень этот очень обширный, ведь наш исследовательский отдел в первую очередь занимается задачами RE. На наш взгляд, подборка материалов по теме хороша для старта, при этом она может быть актуальной в течение продолжительного времени.

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

Забавный факт: нам показывали, как некоторые компании рассылают наш список материалов от себя, но только в очень старой редакции. И вот после этой публикации они, наконец, смогут использовать его обновленную версию с чистой совестью ;)

Итак, перейдем к списку материалов!

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

23 ноября 2011 года id Software поддержала собственную традицию и опубликовала исходный код своего предыдущего движка.

На сей раз настало время idTech4, который использовался в Prey, в Quake 4 и, разумеется, в Doom 3. Всего за несколько часов было создано больше 400 форков репозитория на GitHub, люди начали исследовать внутренние механизмы игры или портировать её на другие платформы. Я тоже решил поучаствовать и создал Intel-версию для Mac OS X, которую Джон Кармак любезно прорекламировал.

С точки зрения чистоты и комментариев это самый лучший релиз кода id Software со времени кодовой базы Doom iPhone (которая была выпущена позже, а потому откомментирована лучше). Крайне рекомендую каждому изучить этот движок, собрать его и поэкспериментировать.

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

Многие мои друзья и знакомые крутят пальцем у виска или задаются вопросом: не жмёт ли мне череп, когда узнают, что я пишу драйвера под Linux. Слово “драйвер” окутано каким-то почти мистическим смыслом, и постичь Дао его написания способны лишь избранные гуру.
К счастью это не так. Не знаю, как обстоят дела с написанием драйверов под другие операционные системы, в т.ч. и наиболее популярные, но под linux, вне зависимости от аппаратной архитектуры драйвера пишутся очень просто. Для написания драйвера необходимы базовые знания языка си, представление о работе ОС линукс (базовые), понимание того, что мы хотим получить, желание чтения документации и исходных кодов, ну и усидчивость. Всё.
Вы хотите посмотреть как написать драйвер для своего устройства? Тогда ныряйте под кат!

<< До этого: Дальнописец

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

Животное электричество

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

Чтобы сходу понимать материалы об инфраструктуре открытых ключей, сетевой безопасности и HTTPS, нужно знать основы криптографической теории. Один из самых быстрых способов изучить их — посмотреть или прочитать лекцию Владимира ivlad Иванова. Владимир — известный специалист по сетям и системам их защиты. Он долгое время работал в Яндексе, был одним из руководителей нашего департамента эксплуатации.


Мы впервые публикуем эту лекцию вместе с расшифровкой. Начнём с первой части. Под катом вы найдёте текст и часть слайдов.

В последнее время все чаще можно встретить обсуждение интересной, но не очень популярной парадигмы — так называемой Data Oriented Design (DOD). Если вы устраиваетесь на работу, связанную с высокопроизводительными вычислениями, будьте готовы к соответствующим вопросам. Но я был очень очень удивлен, узнав, что некоторые мои коллеги не слышали об этом подходе и после недолго обсуждения отнеслись к нему скептически. В этой статье я постараюсь сравнить традиционный OOP подход с DOD.