PEP-484 (mypy) - расширение для gradual typing в CPython и PyPy.

PEP-484 (mypy) давно поддерживается не только официальным интерпретатором, но сторонними реализациями Python, такими как PyPy и Jython.
Но даёт ли статическая аннотация типа до фазы run-time значительно ощутимый прирост производительности исполнения байт-кода в run-time благодаря отсечению лишних проверок вывода типа и более быстрому динамическому связыванию объекта с типом? Или данный механизм помогает только в отладке сложных ситуаций преобразования типов обектов (type casting)?
Больше полугода, как мы стали масштабно использовать это расширение в разработке, вопрос оставался открытым.
Сейчас, спустя время, по метрикам мониторинга сервисов под реальной нагрузкой и на основе имеющегося опыта применения расширения можно делать определённые выводы.

В общем, как я и полагал PEP-484 позволяет только отлавливать сложные run-time ошибки типов статически определяя тип через аннотацию в run-time без необходимости его вывода в run-time.
Прироста производительности при интерпретации кода это не даёт, т.к. проверки соответствия связываемого с аннотируемым объектом приходящего типа всё равно происходят и без этого никак не обойтись, т.к. тип аннотированного объекта задан заранее и вписан в байт-код и в случае несоответствия приходящего типа аннотируемому будет вызвано run-time исключение, которое впрочем можно обработать, что упрощает отладку сужая окно выбора типов и указывая на корректность входящего принимаемого объектом типа.

Более того возможны также дополнительные задержки при исполнении кода на различных платформах из-за сопоставления и преобразования типов к размеру машинного слова, что сам интерпретатор без аннотаций типов выполняет быстрее и оптимальнее и аннотация в этом случае только помеха для оптимизированного механизма type casting в интерпретаторе.
Поэтому расширение PEP-484 (оно же mypy) стоит использовать в основном в отладочных целях.

http://doc.pypy.org/en/latest/faq.html#would-type-annotations-help-pypy-s-performance

https://bugs.jython.org/issue23973
https://bugs.jython.org/issue32227

Так же расширение помогает в выявлении логических ошибок типов в режиме flow-sensitive typing в IDE, например в PyCharm крайних версий.

Ранее, чем в Python, технология gradual typing была реализована в TypeScript и далее в Dart 1.xx (Dart 2 полностью статически типизированный язык с выводом типов в compile-time) и statical type checker'е Flow от Facebook для реализации gradual typing, как надстройки из дополнительных run-time проверок (диспетчеризации) типов, в языке JavaScript, поддержка flow sensitive typing была внедрена в Visual Studio Code и Atom IDE.

Интересный доклад по данной теме:
https://www.youtube.com/watch?v=_PPQLeimyOM

Предыдущий пост по теме:
https://xn--r1a.website/technologique/1214

#digging
#compilers

Google I/O 2018

Сейчас начинается открытие конференции Google I/O 2018

https://www.youtube.com/watch?v=ogfYd705cRs&list=PLOU2XLYxmsIIjoHFYLtwS-_dKrtLhhk_D&index=1

Полный плэйлист лайв-стримов трансляций со всех залов конференции:
https://www.youtube.com/playlist?list=PLOU2XLYxmsIIjoHFYLtwS-_dKrtLhhk_D

Полный плэйлист записей трансляций всех докладов:
https://www.youtube.com/watch?v=ogfYd705cRs&list=PLOU2XLYxmsIInFRc3M44HUTQc3b_YJ4-Y

Google IO 2018 пройдёт с 8 по 10 мая

https://events.google.com/io/

Лично мы ждём пресс-релиза Dart 2 и Flutter для Android и iOS, а также возможного анонса OS Fuchsia, статистики применения и распространения Kotlin в сообществе Android за год с предыдущей конференции, больше информации о развитии и стратегии продвижения платформы Android Things для IoT экосистемы, применении WebAssembly в веб-приложениях.

https://events.google.com/io/schedule?section=may-10&sid=7387180b-b1dd-49c3-bddf-de3f87ae1990 - сессия с Андреем Бреславом о #Kotlin

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

https://events.google.com/io/schedule

https://events.google.com/io/live

Dart 2.0 уже можно поставить из dev (unastable) репозитория Google

https://www.dartlang.org/tools/sdk

https://storage.googleapis.com/dart-archive/channels/dev/release/latest/linux_packages/dart_2.0.0-dev.53.0-1_amd64.deb

Киллер фича Dart 2 это даже не статический вывод типов и повышение скорости исполнения кода
Главное - AoT компиляция на всех платформах, включая стандартную библиотеку, созданные приложения и пакеты из PUB репозитория (https://pub.dartlang.org)
Итоговый бинарник имеет только run-time код для управления потоками и автоматического управления памятью, т.е. виртуальная машина и JIT компиляция элиминируются из процесса исполнения кода полностью
Это то чего пока что в Java 9 не достигли в полной мере с GraalVM - AoT компиляция невозможна для многих классов даже в стандартной библиотеке, не говоря уже про сторонние библиотеки и приложения.
Я впечатлён - новый Dart 2 получился на редкость годным и конкурентоспособным!

#GoogleIO
#Dart
#Flutter
#Fuchsia

Будущее Intel

Джим Келлер, знаковая и во многом судьбоносная фигура в разработке современных процессорных архитектур, работавший ранее в подразделении Tesla Autopilot над архитектурой бортового компьютера для автопилота автомобилей Tesla, а также до этого дважды в AMD в разные годы (разработал набор инструкций x86-64, архитектуры K7/K8/Zen/Zen-2/Zen-3/K12, шину HyperTransport) и в Apple (разработал архитектуры A4 и A5) - перешёл на работу в Intel!

https://newsroom.intel.com/news-releases/jim-keller-joins-intel-lead-silicon-engineering/

https://www.anandtech.com/show/12689/cpu-design-guru-jim-keller-joins-intel

https://medium.com/syncedreview/chip-guru-jim-keller-leaves-tesla-for-intel-34affc4a6490

Можно в уверенностью утверждать, что суперскалярная конвейерная (pipeline) архитектура исполнительных ядер процессоров себя уже изжила (при наличии более быстрых параллельных архитектур, применяемых в GPU и для вычислений с технологией NVidia CUDA) и во многом была дискредитирована уязвимостями упреждающего предсказания ветвлений в конвейере процессора при исполнении кода (нашумевшие ещё в начале года Meltdown и Spectre).

Поэтому можно ожидать как новых GPU от Intel, новых ультрамобильных (Atom) и embedded процессоров (например для IoT и single board компьютеров), так и при нынешней ситуации, аппаратной уязвимости архитектур предыдущих поколений и сложности перехода c 14 нм на 10 нм фотолитографический техпроцесс в глубоком ультрафиолете (EUV, extreme ultraviolet lithography), нужно ожидать новых технологических прорывов и улучшений в архитектурах и технологических процессах производства основной линейки серверных, десктопных и мобильных процессоров Intel.

Ссылки по теме:
https://xn--r1a.website/technologique/1102
https://xn--r1a.website/technologique/772
https://xn--r1a.website/technologique/28

О будущей архитектуре Intel Tinsley (процессор Sapphire Rapids):
https://xn--r1a.website/technologique/1242
https://xn--r1a.website/technologique/1244
https://xn--r1a.website/technologique/1245

О сути уязвимостей суперскалярной конвейерной архитектуры и найденных решениях для их фиксации:
https://xn--r1a.website/technologique/1246
https://xn--r1a.website/technologique/1235

Поддержка групповых звонков в Telegram

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

https://github.com/grishka/libtgvoip/search?l=C%2B%2B&q=group&type=

https://github.com/grishka/libtgvoip/blob/public/VoIPController.cpp

https://github.com/grishka/libtgvoip/blob/public/VoIPController.h

https://github.com/grishka/libtgvoip/blob/public/client/android/tg_voip_jni.cpp

Наш регулярный листинг рекомендаций IT каналов в Telegram.

@MicrosoftRus - Авторские заметки для ITPro & Dev о Microsoft, Windows Server, System Center, Azure, Office 365, OMS, SQL, облаках и не только.

@mustreat - Mustreadы технологий и значимых событий.

@sea_plus_plus - Материалы и заметки из мира C/C++, Python, Go, Linux и не только.

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

@msdnru - Официальный канал сообщества Microsoft Developer для разработчиков и всех, кто интересуется новыми технологиям.

#channels
#telegram
#advices
#рекомендации

И ещё один небольшой список замечательных и очень интересных каналов о программировании, DevOps практиках и администрировании, о технологиях и немного о сарказме в IT. =)

@SysadminNotes - Заметки практикующего сисадмина о Linux и администрировании серверов.

@theaftertimes - Несерьезный дайджест IT. Ежедневно. Цитаты, паста, картинки.

@w20to - Настоящее и будущее технологий. Future, Science, Tech, Trands, Robotics, AI, IoT, VR, and more.

@dncuug - Канал посвящён вопросам разработки под .NET Core: новые фичи C#, .NET разработка под macOS X и Linux, микросервисы и HighLoad. Вот это вот все и даже больше.

@ITBroadcast - Канал для тех, кто хочет быть в теме и познавать новое в области IT. Входим в Top 1 каналов Telegram о технологиях.

#channels
#telegram
#advices
#рекомендации

GitHub поглощён корпорацией Microsoft

Сегодня была официально подтверждена сделка о поглощении git хостинга open source проектов GitHub компанией Microsoft за $7.5G.

https://blog.github.com/2018-06-04-github-microsoft/

https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-developers/

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

Все мы помним к чему приводят поглощения Microsoft open source компаний - достаточно вспомнить проекты открытых мобильных ОС Maemo и Meego (ныне проект Jolla Sailfish) также поглощённой в своё время компании Nokia.

С моей точки зрения это такая стратегия конкурентной борьбы корпорации с открытым и свободным программным обеспечением.

Поэтому с трудом верится в bright future for GitHub and developers - это скорее светлое будущее для создателей и светлая память прекрасному сервису для коллаборации миллионов разработчиков по всему миру.

С другой стороны нельзя не признать что Microsoft меняется на гразах и очень быстро - компания вошла в Linux Foundation, был портирован гипервизор HyperV для ядра Linux, создан слой WSL (Windows Subsystem for Linux, https://github.com/Microsoft/WSL) для изоляции Linux окружений (файловых систем и процессов) на ядре Windows, и их интеграции с Windows окружением, открыт исходный код платформы .Net, компиляторов C# и F#, SQL Server, JS движка Chakra Core браузера Microsoft Edge, активно разрабатываются свободные и открытые проекты .Net/Roslyn и .Net Core, LSP (Language Server Protocol, http://langserver.org), редактор кода Visual Studio Code и инструментарий языка TypeScript.

https://github.com/Microsoft

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

Тем временем сообщество стало активнее бэкапить проекты на сторонние сервисы хостинга git репозиториев - GitLab и Bitbucket сегодня испытывают всплеск нагрузки по импортированию репозиториев с сервиса GitHub:

https://monitor.gitlab.net/dashboard/db/github-importer?orgId=1&from=1527811200000&to=1528156800000

Самое печальное в этой ситуации то, что очень много зависимостей в проектах на Go до сих пор сильно завязаны на хостинг GitHub, не смотря на наличие сервиса https://gopkg.in для проксирования адресов зависимостей.

All about Node

Откровенный рассказ Райана Дала, автора платформы Node.js, о недочётах в концепциях, положенных в основу дизайна при проектировании платформы Node.js на конференции JSConf.EU 2018

https://youtu.be/M3BM9TB-8yA

Ссылки:
https://xn--r1a.website/technologique/1071

Rust Traits

Прекрасная статья с подробным объяснением различий всех видов трейтов (тайп-классов - &Trait, Box<Trait>, impl Trait, dyn Trait), их обектов (экземпляров) и особенностей реализаций/имплементаций в языке #Rust.

https://joshleeb.com/posts/rust-traits-and-trait-objects/

Framework Benchmarks - Round 16

Шестнадцатый раунд нагрузочного тестирования производительности фреймворков - Framework Benchmarks от TechEmpower.

https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=plaintext&a=2

https://www.techempower.com/blog/2018/06/06/framework-benchmarks-round-16/

Тестовые наборы TechEmpower интересны разносторонним подходом к тестированию производительности и выявлением таким образом узких мест фреймворков.

Тестовые наборы находятся в открытом доступе для их open-source community разработки (https://github.com/TechEmpower/FrameworkBenchmarks).

Производительность фреймворков тестируется по различным параметрам и подсистемам, что формирует разные модели нагрузки - сериализация JSON и неформатированные plain-text запросы (для оценки производительности контроллеров и роутеров API запросов согласно идеоме фреймворка), одиночные и множественные (многопоточные) запросы к БД на чтение данных (оценка производительности коннекторов к различным БД и raw подключений к БД), количество операций записи данных в БД (через коннектор либо raw подключение к БД), запрос всех строк и полей таблицы с данными (fortunes) с их последующей шаблонизацией и отсылкой клиенту (комплексная оценка скорости операций чтения данных и производительности шаблонизации данных в формат сериализации для отдачи клиенту или стороннему API).

Dockerificationization!!! [Докерификэйшенизэйшн!!!]

Было обновлено серверное железо (Citrine - triple homogeneous Dell R440), ширина канала связи до серверов увеличена до 10 Гбит/с.

Самое же главное нововведение в данном раунде - контейнеризация тестовых окружений с помощью Docker.
Ранее использовался home-brew sandboxing - 1, 2, 3, 4.
Переход на Docker был произведён для улучшения процесса непрерывного нагрузочного тестирования (continuous benchmarking - https://tfb-status.techempower.com).
Прогон всех тестовых наборов для получения новых показателей занимает сейчас в среднем 67 часов.

Главное, что было проверено под большими нагрузками, что сам движок dockerd, библиотека libvirt и тем более изоляция окружений на базе системных вызовов ядра Linux не дают хоть сколько нибудь ощутимого оверхэда и торможения тестовых наборов в контейнерах - 67 часов прогона всех тестовых наборов без Docker при использовании Docker замедляются всего лишь в пределах минуты. Такой результат находится на уровне погрешности измерений при нескольких прогонах тестовых наборов!

Across the board, our sanity checking of performance metrics has indicated Docker's overhead is immeasurably minute. It's lost in the noise. And in any event, whatever overhead Docker incurs is uniformly applicable as all test implementations are required to be Dockered.

Это весьма сильный аргумент для до сих пор сомневающихся компаний и инженеров в пользу применения Docker в серверной инфраструктуре проектов.

В нагрузочном тестировании stateless контейнеры улучшили сам процесс непрерывного тестирования и воспроизводимость тестовых окружений (reproducibility of builds), что повысило согласованность данных (consistency) при множественных прогонах тестовых наборов в процессе непрерывного тестирования (continuous benchmarking).

Most importantly, thanks to Dockerizing, the reproducibility and consistency of our measurements is considerably better than previous rounds. Combined with our continuous benchmarking, we now see much lower variability between each run of the full suite.

И главное напутствие данного раунда тестов - медленные платформы и их приверженцы, разработчики, пытаясь преодолеть платформенные ограничения, плодят ужасные, некрасивые и неэлегантные архитектурные решения, которые не всегда необходимы, для масштабирования таких платформ под высокой нагрузкой (вспомните опыт инженеров Instagram - https://xn--r1a.website/technologique/1214).

Стремитесь к красоте и элегантным решениям!

Developers on slower platforms often have so thoroughly internalized the limitations of their platform that they don't even recognize the resulting pathologies: Slow platforms yield premature architectural complexity as the weapons of “high-scale” such as message queues, caches, job queues, worker clusters, and beyond are introduced at load levels that simply should not warrant the complexity.

Предыдущие посты по теме:
https://xn--r1a.website/technologique/1263
https://xn--r1a.website/technologique/970
https://xn--r1a.website/technologique/609
https://xn--r1a.website/technologique/59

Яндекс.Такси проводит соревнование для бэкенд разработчиков.
Главный приз — 300 тысяч рублей.
В качестве заданий — реальные задачи разработчиков Яндекс.Такси.
Писать можно на C++, Python или Java.

Регистрация открыта до 13 июля:
https://taxi.yandex.ru/action/ytcf/coding_fest

#challenge

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

https://www.webstack.de/blog/e/cloud-hosting-provider-comparison-2017/

https://www.vpsbenchmarks.com/compare/scaleway_vs_vultr
https://www.vpsbenchmarks.com/plans

Ссылки:
https://www.scaleway.com/pricing/
https://www.online.net/en

https://www.vultr.com/pricing/

https://www.ovh.com/world/vps/

https://www.digitalocean.com/pricing/

https://www.linode.com/pricing

https://www.heroku.com/pricing

https://www.hetzner.com/cloud?country=us

#vps #vds #asp

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

https://www.youtube.com/watch?v=jsGhJ2pKKYY

Ссылки на материалы по теме:
https://xn--r1a.website/technologique/1054
https://xn--r1a.website/technologique/1052
https://xn--r1a.website/technologique/1051

The big short

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

https://neilpatel.com/blog/speed-is-a-killer/

И занимательная аналитика на эту же тему:

https://blog.hubspot.com/marketing/page-load-time-conversion-rates

В условиях микро и нано-сервисных облачных (cloud native, FaaS) инфраструктур - оптимизация по расходу памяти (memory footprint) и времени отклика (decrease latency) это уже устойчивый тренд, при том не только для крупных компаний, который имеет более важное практическое значение, чем синтетические нагрузочные бенчмарки с замерами значений RPS (requests per second) к различным программным подсистемам софта.

OOMd - user space daemon for killing processes by out of memory exception raises.

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

Буквально на днях коллеги из группы Facebook Open Source Team опубликовали исходники демона oomd работающего в пространстве привилегий пользователя для завершения процессов при срабатывании исключения out of memory (OOM), при чрезмерном расходе памяти приложениями и сервисами.

https://code.fb.com/production-engineering/open-sourcing-oomd-a-new-approach-to-handling-ooms/

https://github.com/facebookincubator/oomd

Также для более раннего обнаружения (до срабатывания исключения OOM Killer в ядре) паразитических процессов и нагрузки создаваемой ими и чтобы не потерять контроль над уже нестабильной системой (а также для повышения стабильности и отзывчивости системы) в момент срабатывания OOM Killer механизма ядра, для включения в ядро был предложен механизм Pressure Stall Information — pressure metrics, метрики, подобные load average, по таймфреймам, для создания и определения модели нагрузки и определения livelocks состояний (взаимоблокировки процессов при попытке завладения доступом к ограниченным ресурсам) по подсистемам cpu, memory и io, и по отдельным процессам, как для отслеживания "качества жизни" отдельных процессов и их окружений cgroups, так и нагрузки по подсистемам ресурсов в целом — для предоставления информации ядру и для более раннего обнаружения процессов слишком активно требующих выделения ресурсов системы и потребляющих их:

https://lkml.org/lkml/2018/7/12/661

Данный механизм ядра совместно с демоном oomd позволяет более точно отслеживать состояние процессов и выделение ресурсов в системе, более точно локализовать проблемные места (bottle-necks) для дальнейшей оптимизации сервисов по потреблению ресурсов, а также повысить отзывчивость (время реакции, задержки, latency), стабильность и надёжность (fault tolerance) работы системы, особенно в условиях мультиконтейнерных stateless окружений микро и нано сервисов, повысить эффективность утилизации ресурсов кластерных систем и масштабируемость приложений при миграции процессов в пределах кластерной системы.

Следующий большой шаг, над которым ведётся работа - разработка и интеграция новых решений для систем инициации (systemd, а также upstart и sysVinit для более старых систем) по отслеживанию состояний потребления ресурсов процессами резидентных приложений (демонов), с высоким постоянным невыгружаемым пулом памяти (memory footprint).

Существующие механизмы в текущих системах инициализации в ОС GNU/Linux не дают необходимой гибкости управления процессами, особенно у условиях состояний ограниченных или исчерпывающихся ресурсов в системе.

https://www.freedesktop.org/software/systemd/man/systemd.exec.html#OOMScoreAdjust=

http://upstart.ubuntu.com/cookbook/#oom-score
http://upstart.ubuntu.com/cookbook/#respawn
http://upstart.ubuntu.com/cookbook/#respawn-limit

Хочу выразить благодарность Артёму, автору канала @SysadminNotes, за публикацию данной информации (https://xn--r1a.website/SysadminNotes/877) и за прекрасный и очень интересный канал (подписывайтесь, читайте - рекомендую! 😉)

PS: На самом деле очень приятно видеть, когда то, над чем работали для конторы уходит в open source - труды не пропадают даром и подобные проекты будут полезны всему сообществу. Жаль что не столь оперативно происходит открытие исходников подобных интересных проектов.

Материалы по теме:
https://xn--r1a.website/technologique/1253
https://xn--r1a.website/technologique/1254 - в данной статье я упоминал также про подобное уже существовавшее на тот момент решение проблемы ранней упреждающей обработки OOM исключений в user space, EarlyOOM (https://github.com/rfjakob/earlyoom)
https://xn--r1a.website/technologique/1255
https://xn--r1a.website/technologique/1256
https://xn--r1a.website/technologique/1258

Daemonization for JVM

Есть ещё одна неприятная известная проблема с Java приложениями которая требует освещения.
На Java невозможно написать нормальное резидентное stateless приложение демона, коими являются любые сетевые демоны, обеспечивающие работу сетевых протоколов, да и вообще любые приложения относящиеся к server-side cloud infrastructure software.

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

На скриптовых языках такое написать более возможно поэтому они широко используется как системные демоны для управления различными подсистемами в Linux (пример - OpenStack, комплексная система автоматизации управления облачными инфраструктурами) и используются в мультиконтейнерных приложениях и микро/нано сервисных серверных инфраструктурах для украшения ими.

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

В общем, стояла недавно такая задача...
Управлять стартом/рестартом Java приложений после их краха, убийства процесса приложения ядром при переполнении памяти (по out of memory exception) при помощи системы инициализации (Upstart в Ubuntu LTS, systemd на Debian) в Линуксе внутри контейнера или без контейнера в самой системе (для старых монолитных систем).

Сделать это непросто, т.к. Java машина, особенно если на ней исполняется сервер приложений с несколькими сервлет-контейнерами, имеет множество системных потоков (тред-пулов, spawned fork-join thread-pools) и может ответвлять отдельные процессы (fork-join process pools) для запуска сторонних приложений (например инициировать запуск sms демона для обслуживания SMS шлюза).
Состояние и PID (process id) процессов при этом отслеживать системой инициализации демонов в Linux очень сложно технически и не представляется возможным, т.к. система инициализации умеет отслеживать либо один форк процесса (expect fork stanza), либо двойной форк процесса (expect daemon stanza) при запуске и работе управления приложением, его автоматическим запуском и перезапуском, но не процесс пулы, где сложно отследить корневое приложение иницирующее ветвления, форки процессов в пуле.

Для этого приходится писать обёртки (wrappers), чаще на скриптовых языках или использовать готовые типа start-stop-daemon, для демонизации Java приложений и ортогонального управления ими.

Благо по системам инициализации есть прекрасная документация.

http://upstart.ubuntu.com/cookbook/#stanzas-by-category

http://upstart.ubuntu.com/cookbook/#initctl-commands-summary

http://upstart.ubuntu.com/cookbook/#expect

http://upstart.ubuntu.com/cookbook/#run-a-java-application

http://upstart.ubuntu.com/cookbook/#alternative-method

https://wiki.ubuntu.com/Upstart

https://www.freedesktop.org/software/systemd/man/systemd.exec.html

И пара классных статей от Digital Ocean по различиям систем инициализации и управления процессами в Linux системах.

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-1-practical-examples

https://www.digitalocean.com/community/tutorials/how-to-configure-a-linux-service-to-start-automatically-after-a-crash-or-reboot-part-2-reference

#Linux
#Ubuntu
#Upstart
#systemd

Rust concurrency in a nutshell

https://www.youtube.com/watch?v=SiUBdUE7xnA

Отличная лекция Алекса Крайтона, разработчика библиотечных решений для использования паттернов многопоточности в языке Rust и знаменитого фреймворка Tokio для разработки приложений, использующих многопоточный асинхронный неблокирующий ввод-вывод (concurrent event loop for asynchronous non-blocking IO) — о подходах, моделях и парадигмах использованных в языке Rust для разработки безопасного многопоточного кода более простыми и понятными методами (closures, corourines, continuations, message passing and channels, actors, futures, promises и их использование в контексте концепций языка, системы типов и компилятора языка Rust — владения и заимствования для контроля использования указателей и время жизни для областей видимости в контексте вызова и исполнения функций).

#Rust

Ещё несколько классных статей одного автора на тему паттернов многопоточности в Rust:

https://medium.com/@polyglot_factotum/rust-concurrency-patterns-no-context-no-cancel-no-leak-b6c1ec2dafa5

https://medium.com/@polyglot_factotum/rust-concurrency-patterns-natural-born-pipelines-4d599e7612fc

https://medium.com/@polyglot_factotum/rust-concurrency-patterns-communicate-by-sharing-your-sender-11a496ce7791