What am I supposed to do and how to survive:

— Не покупайте пока новомодные лэптопы на Skylake с контроллером памяти DDR4 и не берите сервера с этими процессорами, пока Intel не придумает как защитить протокол отладки.
Уязвимость пока опробована не на всех степпингах ядер процессоров, поэтому нужно считать что уязвимо всё семейство ядер микроархитектуры Skylake.

— На процессорах Skylake не включайте при сборке ядра Linux модули гипервизоров Xen и KVM, без острой необходимости, отключайте поддержку VT-x и VT-d при сборке ядра и в BIOS.

— Используйте готовые сборки с патчами и патч-сетами для ядра, сборка ядра Linux должна быть с поддержкой nx-bit и security модулями (SELinux, AppArmor) и патчами grsecurity и PaX - в этом случае лучше юзать микро-дистрибутив Alpine Linux (возможно даже в Docker контейнере) для создания безопасного окружения для вашего проекта в удалённом дата-центре.

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

— Отключите в Android (в разделе Securuty меню настроек) установку приложений из неизвестных источников. Отключите режим разработчика, отладку через USB и ADB на смартфоне. Отключите MTP, PTP, DMS, DLNA и любые другие поддерживаемые протоколы передачи данных между смартфоном и компьютером. Активируйте любую передачу данных только по необходимости и после отключайте.

— Заряжайтесь только обычной зарядкой (dumb charger).

— Think securely - keep safety!

Всем добра!

Лучшие дистрибутивы на этот год по версии Linux.com

Лучший дистрибутив для IoT - Snappy Ubuntu Core

https://www.linux.com/news/learn/sysadmin/best-linux-distributions-2017

Страшный сказ о том как программер (сотрудник проекта) в ночь с 31 января на 1 февраля по неосторожности дропнул продакшн БД сервиса GitLab.
Хранилище репозиториев не было затронуто - только сам сервис GitLab для управления кодовой базой проектов.
Из бэкапов (репликаций postgresql) восстановить ничего не получается, востанавливают с образа LVM тома с разделом ФС, содержащим копию БД, сделанного как раз на случай неудачи за несколько часов до инцидента - весьма показательный случай, когда у сервиса нет нормальной политики партицирования и постоянной репликации данных, и разумной политики доступа к данным на запись и изменение.

Нормальной реализации партицирования (шардинга) в PostgreSQL пока нет (будет реализовано в будущих версиях) - только через наследование таблиц и контроль записи в них через триггеры, что весьма не элегантно и не удобно в обслуживании. Поэтому PostgreSQL не очень удобен для распределённого хранения партиций (шардов) БД и их репликации (бэкапов), т.е. вообще для проектов использующих распределённые данные и кластерное хранение. Недавно Uber по этим причинам перешёл с PostgreSQL на MySQL.

Вся информация в одном документе:
https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

Лучше конечно свои репозитории и движок GitLab поднимать локально, и нести всю ответственность за свои данные самому.

Ребята даже live stream сделали для большей прозрачности процесса восстановления данных, отслеживания ситуации и снятия социального напряжения - на заметку всем кто хочет превращать минусы в плюсы, а факапы в шоу. Хотя ребятам сейчас адреналина хватает и без шоу. :)

https://youtu.be/nc0hPGerSd4

https://opennet.ru/opennews/art.shtml?num=45957

Официальная статья с полным изложением ситуации по данному инциденту в блоге уже восстановленного GitLab

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

Ребята пытались защититься и снять нагрузку от DDoS с БД, но пошли не путём маршрутизации трафика запросов, а путём самого слабого места PostgreSQL, её репликации.

Это ещё раз доказывает что PostgreSQL неудачное решение для распределения данных - она плохо масштабируется в распределённых системах и для неё реально мало качественных сторонних решений и инструментов для удобной работы с данными и управления БД, в сравнении с MySQL и тем более MariaDB, в которой все возможности шардинга, репликации и in-memory кэширования горячих данных встроены в движок или реализованы множеством сторонних инструментов.

Тем не менее с помощью OpenStack компонентов Cinder (с использованием платформ-хранилищ и файловых систем Ceph и GlusterFS), компонентов Manila, Swift и Trove можно настроить масштабирование и кластеризацию практически любой БД, но это всё внешние примочки и clusterfuck science - все возможности должны идти из коробки встроенными в движок БД.

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

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

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

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

Обычно не публикую такое, извините, но это ооочень смешно https://twitter.com/thepracticaldev/status/826820232278847490 По ссылке видео.

Kernel.org отключит доступ по протоколу FTP к репозиторию версий исходного кода ядра Linux ftp://ftp.kernel.org 1 марта и к зеркалам других Open Source проектов ftp://mirrors.kernel.org 1 декабря этого года.
Останется доступ только по http/https.

https://kernel.org/shutting-down-ftp-services.html

https://opennet.ru/opennews/art.shtml?num=45935

Распределённые параллельные вычисления наступают со всех сторон!

Если у вас есть код на Go, Rust или любом другом современном языке, поддерживающем какую-либо модель многопоточности и есть желание опробовать ваш код на кластере с процессорами Intel Xeon Phi - теперь такая возможность есть, вэлкам!

https://habrahabr.ru/company/intel/blog/320972/

https://youtu.be/MYxgfpWW5Q8

Недавнее испытание скоростной капсулы выполненной по технологии Hyperloop, двигающейся в туннеле и разгоняемой реактивным двигателем, разработанным в SpaceX.
Заметьте внутреннюю нарезку трубы туннеля - как у ствола винтовки. Это для улучшения вихревой аэродинамики и уменьшения сопротивления воздуха.
Можно почувствовать себя пулей в таком стволе - видео снято в формате VR 3D, всю прелесть которого вы можете уже сейчас прочувствовать на вашем смартфоне (и в очках CardBoard, если есть), открыв видео в официальном приложении YouTube (используйте смартфон как перископ) или плейере JauntVR - http://jntvr.co/Hyperloop (https://play.google.com/store/apps/details?id=com.jauntvr.android.player.cardboard).
Такого формата видео появляются уже довольно часто.

Собрались как-то раз на конференции Lang Next 2014 авторы и соавторы C++, Rust, D, Go поговорить о жизни и будущем системных языков программирования.

https://youtu.be/BBbv1ej0fFo

Там не хватало только Криса Лэттнера, автора Swift и LLVM, где-нибудь посередине группы.

Удивительно, Бьярн Страуструп и Роб Пайк на одной сессии одной конференции! Это как две рок-звезды на одной сцене одного концерта. Наверно их специально рассадили подальше друг от друга - слишком сильна гравитация вокруг них. 😆

https://youtu.be/BBbv1ej0fFo?t=6m45s - примечательно, что Роб Пайк говорит про позиционирование Go, больше как "server (i.e. network daemon) writing language... and now Go is a server-side cloud infrastructure language", и это очень верное определение.

Подкаст Scalalaz #14 о языке Scala и всему, что с ним связано

http://scalalaz.ru/series-14.html

Гость - Дмитрий Петрашко (Scala Team at EPFL, https://github.com/darkdimius), разработчик платформы Dotty.

Аудиопоток:
http://scalalaz.ru/mp3/scalalaz-podcast-14.mp3

Дмитрий рассказал про проект Dotty, основанный на DOT (Dependent Object Types), платформе для опробования новых высокоуровневых возможностей языка Scala и низкоуровневых технологий будущего компилятора.

https://github.com/lampepfl/dotty

http://dotty.epfl.ch

Ещё одна из интересных тем подкаста - сопрограммы и модель CSP (Go, Kotlin) versus модель акторов (Scala, Akka, Quasar).

Недавно в Kotlin сделали сопрограммы, что весьма интересно, т.к. сопрограммы на низком уровне не поддерживаются байт-кодом JVM (и поэтому в JRuby отсутствует класс потоков Fibers, основанный на сопрограммах, т.к. JVM поддерживает только M:N маппинг на нативные треды):

https://github.com/Kotlin/kotlinx.coroutines

https://github.com/fboldog/async-under8

Go 1.8 будет выпущен в этом феврале.

Общемировая пати по этому случаю намечена на 16 февраля.

Как изменился Go и к чему пришли:
https://talks.golang.org/2017/state-of-go.slide

В Go 1.8 очень серьёзно поработали над runtime и алгоритмами GC - добились субмиллисекундных задержек на многогигабайтной куче (heap) в памяти!
Это очень ощутимо повысило производительность программ скомпилированных Go 1.8 Release Candidate.

https://twitter.com/brianhatfield/status/804355831080751104

Репозиторий с тестами:
https://github.com/bmhatfield/go-runtime-metrics

И отличная статья в блоге разработчиков шикарного сервиса Pusher, о том как работает алгоритм GC и как добились мягкого реального времени в GC для Go:
https://blog.pusher.com/golangs-real-time-gc-in-theory-and-practice/

Безудержного пятничного веселья пост!

От улыбки станет всем светлей! 😄😂👍

Классный бот, который превратит все ваши grumpy photos в smiley photos.

@MagicSmileBot - просто киньте ему фото и нейросеть заставит улыбнуться и вас и ваше фото

Улыбайтесь чаще друзья! 😁

#thismademyday
#madeit

Many thanks to @Luger_08!

PS:
Нейросетку обучали на наборах данных, парах фото в анфас, где человек улыбается и где не улыбается.
На фото в профиль не обучали, поэтому реконструкция улыбки получается кривая.

Производится именно реконструкция улыбки на лице - нейросеть использует накопленные в тензорных полях данные, шаблоны и отношения между полями, для реконструкции улыбки (губ, зубов, формы, цвета, света-тени/освещения) на конкретном лице и его области.

DropBox прекращает развитие Pyston, эффективного многопоточного JIT компилятора Python на базе LLVM и полностью передаёт его разработку open-source сообществу.

Чего и следовало ожидать.

Тем более недавно Google опубликовал проект AST транс-компилятора Python в Go - Grumpy (https://github.com/google/grumpy).

Большую часть бэкэнда DropBox уже переписали на Go и Rust с меньшими трудозатратами, что получилось даже быстрее по времени и производительнее по нагрузке.

Проанализировав состояние проекта компания пришла к выводу, что на поддержание совместимости с CPython и обеспечение приемлемого потребления памяти требуется значительно больше ресурсов и затрат, чем ожидалось. Но решающим фактором отказа от проекта Pyston стали не оправдавшиеся завышенные надежды на производительность Pyston.

Go эффективнее Python по исполнению кода.
Оба языка поддерживают FFI - Go через cgo, Python через ctypes.
Но видимо в DropBox не хотели увеличивать количество Си кода в ходе роста нагрузок и выбрали золотую середину - Go.
Хотя от экспертизы Гвидо Ван Россума, как автора языка, автора эталонного интерпретатора и главного специалиста в Python, вроде пока не отказались.

Теперь разработку компилятора Pyston отдали в руки сообщества, которое будет развивать его, что возможно не очень хорошо для проекта потому, что таким образом он будет развиваться не так динамично, как в самой компании - комьюнити проекты JIT компиляторов Python, PyPy и Jython, традиционно не очень активны и развиваются крайне медленно, во многом из-за наличия эталонного CPython и PEP стандартизации нововведений со стороны сообщества. По этой причине все реализации Python кроме эталонной выступают в роли догоняющих проектов.

Но Pyston должен был быть эффективнее PyPy, т.к. использует LLVM в качестве бэкэнд компилятора, который реализует регистровую машину, в отличие от PyPy и CPython, которые реализуют стековую машину (http://doc.pypy.org/en/latest/interpreter.html#introduction-and-overview).

Регистровая машина имеет другую модель памяти - для трансляции байт-кода активно используются регистры и регистровые операции процессора, и соответственно для размещения структур данных используется быстрый процессорный кэш (которого в современных процессорах немало - мегабайты).
Поэтому регистровая машина работает быстрее и лучше подходит для языка Python и реализации всех его концепций (сопрограмм, итераторов, генераторов), как языка с динамической системой типов, для реализации в байт-коде более быстрого динамического определения типов объектов в runtime через dynamic dispatch (динамическую диспетчеризацию типов).
Более того выделение памяти в кэше процессора ускоряет обмен данными и работу с ними, и позволяет разместить в нём кучу (binary heap, которая обычно размещается в намного более медленной RAM), содержащую кадры стека вызовов сопрограмм (parent pointer tree with cactus stack), для более быстрой работы с ней, что в свою очередь нивелирует проблему funarg (как восходящего, так и нисходящего funarg) для сопрограмм - проблему сложности быстрой работы на низком уровне с более комплексными структурами данных типа дерева, хранящими стэки вызова сопрограм и подпрограмм, из-за отсутствия широкой поддержки таких структур данных машинной архитектурой для их размещения в более быстрой памяти.
Поэтому регистровая машина (LLVM) эффективна для реализации сопрограмм и многопоточности по модели CSP, основанной на их использовании, таким образом Pyston имеет реализацию многопоточности, не ограниченную GIL, которая базируется на сопрограммах и их асинхронных вызовах (async/await).

https://github.com/dropbox/pyston

https://blog.pyston.org

http://speed.pyston.org/comparison/

https://blogs.dropbox.com/tech/2014/04/introducing-pyston-an-upcoming-jit-based-python-implementation/

Ранее, выше я уже писал о непростой судьбе интерпретируемых языков Python, Ruby и сложности реализации эффективных JIT компиляторов для этих языков, что ограничивает их развитие и применение, во многом из их динамической природы и концепций, основанных на динамизме типов данных.
Сложности в дальнейшем развитии проекта Pyston это лишний раз подтверждают.

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

Переданный параметр может быть указателем на код функции и тогда это first class function, и если это указатель на вложенную функцию, которая возвращает данные в эту же функцию, то это closure/замыкание.
Либо параметр может иметь указатель на код функции, возвращающей другой кадр стэка и соответственно контекст в эту же функцию, или даже вызывать другую функцию, возвращая ей этот контекст, которая в свою очередь уже возвращает стэк/контекст вызова или уже финальные данные в эту начальную функцию.
Такая передача контекстов через параметры функций называется continuation passing style, а передающие контекст функции называются продолжениями (continuations).
Таким образом происходит вызов функций по цепочке с сохранением контекста каждого вызова.
В цепочку вызовов функций (рутин, routine) с сохранением контекста раскладываются вложенные и рекурсивные вызовы функций и вызовы сопрограмм (корутин, coroutine).
Это и происходит на низком уровне при вызове сопрограмм - итераторов, генераторов, горутин, файберов, потоков/нитей, etc., т.е. многопоточных и асинхронных высокоуровневых конструкций, которые переводятся в итоге на низком уровне в сопрограммы.
Это увеличивает сложность компилятора, потому что требуется отследить все вызовы, чтобы выстроить всю цепочку вызовов и отследить время существания всех кадров стэка и контекстов вызова для последующего освобождения памяти.
Сложность рекурсивного вызова выше чем вложенного.
Рекурсивный циклический вызов может быть бесконечным и его цепочку отследить сложнее.
Для этого компилятор должен уметь выполнять оптимизацию циклов и оптимизацию хвостовой рекурсии (tail recursion optimization), т.е. оптимизацию вызовов при возврате из одной функции и передаче контекста вызова в другую.
В итоге стэк может быть переполнен, т.к. заранее неизвестно сколько памяти нужно выделить под стэк, потому что неизвестно сколько циклов вызовов будет прежде, чем произойдёт возврат данных в начальную функцию, т.е. количество вызовов и длина всей цепочки вызовов изначально неизвестна компилятору.
Также учитывая многосвязность вызовов через указатели и кадров стэка, хранящих контекст вызова, очевидно, что структура данных типа стэк (буфер first-in last-out) уже не подходит для хранения контекста всех вызовов, т.к. такая многосвязность множественных кадров стэка через указатели порождает структуру данных cactus stack (parent pointer tree) типа in-tree дерево или многосвязный граф, для хранения которого используется структура данных типа куча (binary heap), под которую происходит динамическое выделение памяти ядром ОС уже в более медленной основной RAM, тогда как для выделения стэка, благодаря его заранее известному и ограниченному размеру, используются регистры процессора и более быстрая регистровая кэш память процессора.
Плюс структура данных типа стэк, благодаря своей упорядоченности, проще и быстрее в работе, обработке и обращении с ней
Это и есть проблема funarg, аргументов/параметров функций, которая сводится в итоге к фундаментальным ограничениям машинной архитектуры и задержкам динамической оперативной памяти.

#сложновато

Evan Shaw в интервью весьма верно отметил, что компилятор Go и его GC достаточно умно спроектированы, чтобы в зависимости от ситуации выбрать размещение контекста гоурутин и функций в стэке или в куче и грядущий релиз Go 1.8 с субмиллисекундными! задержками работы GC с памятью прекрасно это доказывает. (1)
При каждом обращении к куче увеличиваются задержки из-за её размещения в более медленной RAM памяти.
Задержка может происходить при размещении контекста вызова в куче либо при извлечении контекста вызова из неё, отсюда различают проблему восходящих и низходящих аргументов/параметров функций (funarg).

Недавно нашёл толковое и простое определение проблемы funarg:

Nested functions may in certain situations (and languages) lead to the creation of a closure. If it is possible for the nested function to escape the enclosing function, for example if functions are first class objects and a nested function is passed to another function or returned from the enclosing function, then a closure is created and calls to this function can access the environment of the original function. The frame of the immediately enclosing function must continue to be alive until the last referencing closure dies and non-local automatic variables referenced in closures can therefore not be stack allocated. This is known as the funarg problem and is a key reason why nested functions was not implemented in some simpler languages as it significantly complicates code generation and analysis, especially when functions are nested to various levels, sharing different parts of their environment.

Funarg problem

Continuation

Continuation-passing style (CPS)

Call with current continuation (call/cc)

Parent pointer tree