Например, 2 разных подхода к оценке реализации асинхронности(вторая ссылка не про C++, но она точно так же применима к С++, или к Python):

https://habr.com/ru/company/yandex/blog/575062/
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ (названия каждой новой главы доставляет)

Или, например, как сдизайнен async API в jinja2:
https://jinja.palletsprojects.com/en/3.0.x/api/

Казалось бы, где jinja2, и где async? Но нет, мы же можем передать в нее контекст, который загружает шаблоны по сети.

Я, скорее, согласен со вторым автором. Пока будет такое разделение на 2 мира, и поддержку async придется добавлять руками, дублируя код, async популярным не станет.

Кстати, зачем Python ушел от yield from к async/await - я не понимаю. По сути, как раз в Python не было(вернее, она была еще раньше - обычные функции vs. генераторы, но никогда не было проблем звать функции из одного мира в другом) этой проблемы разделения на 2 мира, и ее добавили искуственно.

PS: как сделать call/cc(очень похожая на корутины тема) в С++, с помощью fork() http://mainisusuallyafunction.blogspot.com/2012/02/continuations-in-c-with-fork.html Осторожно, по ночам будут кошмары.

Оказывается, G уже запилила fuzzer для Linux:
https://github.com/google/syzkaller

С внушительным послужным списком:
https://github.com/google/syzkaller/blob/master/docs/linux/found_bugs.md

Это прекрасно. Интересно, используется ли это в процессах разработки ядра, или работает сбоку?

Фаззить системные вызовы - это хорошо, но мало.

Мне нравится использовать контейнеры, но я не люблю docker.

Нужно понимать, что docker - это не то, что реально выполняет код в контейнере. Это очень простой CLI над несколькими системами Linux. Фактически, задача docker - скачать tar.gz с файлами образа, и запустить какой-то OCI compatible runtime над разархивированной папочкой. Docker - самый старый такой CLI для Linux(если не вспоминать LXC). Поэтому он накопил довольно большой груз проблем.

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

Например, процессы контейнера запускаются этим демоном. Лично меня беспокоит соседство внешнего кода и root демона. Я понимаю, что демон сбрасывает привилегии, но когда это кому мешало? Код может сбежать из контейнера, и наличие некоего демона, который обеспечивает какие-то важные функции для этого контейнера(то есть, обрабатывает запросы от него!), и работает под root - ну такое.

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

Поэтому docker'у я предпочитаю daemonless, rootless решения:

1) Podman. Работает daemonless, умеет работать rootless. Обеспечивает CLI такой же, как у docker. А теперь и под macOS! https://davegallant.ca/blog/2021/10/11/replacing-docker-with-podman-on-macos-and-linux/

2) Семейство udocker. https://github.com/indigo-dc/udocker. Вообще не требует ничего от системы, даже USER_NS. Работает с помощью тулзы под названием proot(https://proot-me.github.io/), которая перехватывает системные вызовы от управляемого процесса с помощью ptrace(считайте, API для отладчика). Написан на python, что для меня глоток свежего воздуха, после засилья Go во всяких CLI для контейнеризации.

3) Таки звать OCI runtime напрямую! Это не rocket science - скачать tgz, распаковать ее, и запустить 1 бинарь:

pg@:~/bundle mkdir rootfs
pg@:~/bundle docker export $(docker create busybox) | tar -C rootfs -xvf - > /dev/null # тут можно позвать curl
pg@:~/bundle runc spec --rootless # создаем config.json, почитайте его, там тоже никакой магии
pg@:~/bundle runc --root /tmp/runc run qw
/ #

Actually, это мой любимый способ. Такой chroot на стероидах, со всеми вытекающими удобствами. Во первых, он совершенно не оставляет за собой "следов" в виде висящих процессов, во вторых, очень гибкий(например, попробуйте под docker build заменить содержимое /etc/hosts - https://stackoverflow.com/questions/38302867/how-to-update-etc-hosts-file-in-docker-image-during-docker-build, и не работает для ipv6), это важно для всяких CI/CD pipeline.

Вместо runc(это OCI runtime от docker) можно взять любой другой - https://github.com/containers/crun, тысячи их!

И вторая важная тема!

Контейнеры под Linux - это не способ изоляции! Контейнеры имеют полный доступ к ядру Linux, и могут произвольно эксплуатировать уязвимости в нем! Поэтому, желательно, использовать какую-то прослойку между ядром Linux, и пользовательским кодом контейнера. Например, для этой цели можно ипользовать gVisor. https://github.com/google/gvisor Это такой эмулятор ядра Linux, написанный поверх ядра Linux. У него есть некоторые недостатки:

* Написан на Go, И требует bazel для сборки - это аццкое сочетание, trust me.
* Пока не умеет в rootless :(

Если приходится использовать docker безальтернативно, я крайне рекомендую посмотреть на gvisor, для более лучшей изоляции.

Интересных ссылок в последние дни нет.

Разве что:

* Новая Зеландия отменила контракт со штатным колдуном. https://boingboing.net/2021/10/13/official-city-wizard-fired-from-new-zealand-city-after-over-20-years-of-public-service.html Оригинальная ссылка недоступна, возможно, происки колдуна.

* Вышла совершенно ничем не примечательная OpenBSD 7.0 Ссылку на changelog не кидаю, там ничего нет. Зато, как обычно, с каждым новым релизом OpenBSD разработчики выкладывают какую-то графоманскую мелодию, которой можно насладиться тут - https://www.openbsd.org/lyrics.html#70 Треш, угар, содомия.

* Российская Государственная Открытая Лицензия - https://habr.com/ru/news/t/583156/ Сейчас запилят православный github, тогда заживем.

* Переписка про удаление GIL из Python - https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/

Вот что пишет г-н Гвидо про nogil: #gil #fast_python

"To be clear, Sam’s basic approach is a bit slower for single-threaded code, and he admits that. But to sweeten the pot he has also applied a bunch of unrelated speedups that make it faster in general, so that overall it’s always a win. But presumably we could upstream the latter easily, separately from the GIL-freeing part."

"Я с удовольствием использую идеи автора в своем проекте по ускорению Python"

Осталось понять, PRO, или MAX?

Заявления Apple про скорость звучат, как чудо, но M1 они же доставили?

https://www.apple.com/ru/shop/buy-mac/macbook-pro/14-%D0%B4%D1%8E%D0%B9%D0%BC%D0%BE%D0%B2

https://news.ycombinator.com/item?id=28908383 - 1800 коментов, давненько на HN такого не видел.

Очень мне нравится новый экран. 2560x мне было маловато(например, после Asus ROG Flow X13 с его 3840x). Я вижу отдельные пиксели в шрифтах :( Интересно, почему в этой области Apple не пытается быть впереди планеты всей?

Свои процессоры сегодня не делает только ленивый!

https://www.ixbt.com/news/2021/10/19/128-ddr5-pcie-5-5-alibaba.html

В догонку - хороший текст на хабре про стоимость процессоростроения, между прочим, от автора epic battle Ядра vs. Elbrus! https://habr.com/ru/post/583780/

Доразбирал прошлый дайджест llvmweekly.org

1) Неплохая заметка про то, как работает линкер - https://blog.llvm.org/posts/2021-10-01-generating-relocatable-code-for-arm-processors/

Первая половина - годное введение в проблему(например, становится понятно, почему способ линковки зависит от конечной системы).

Вторая половина - на мой взгляд, какое-то очень невнятное решение понятной проблемы, которую линкеры уже давно умеют решать(relocatable static binary, c 2 секциями - .text, .data). Так же авторы, IMHO, периодически сваливаются с темы "relocatable" на тему "position independant". pi code является relocatable, но не наоборот, и делать его сложнее.

2) А кто-нибудь понимает, зачем LLVM продолжает пилить свою libc? https://reviews.llvm.org/rGdb8a88fef87e

3) Мы же теперь живем в мире, где участие женщин в IT надо как-то специально, не на общих основаниях, подсвечивать, да? Вот, llvmweekly дает ссылку на "Women in Compilers and Tools meetup" - https://www.youtube.com/watch?v=1-H8RTwCpwA Я тоже даю, я хороший. Cлушать там не о чем.

https://lwn.net/ml/linux-next/20211008113116.4bdd7b6c@canb.auug.org.au/

Например, история, как посрались 2 мейнтенера ядра Linux - разработчик драйвера AMD GPU Simon Ser, и Christoph Hellwig. Второй удалил из интерфейса ядра для модулей функцию, которую использовал первый.

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

Но kernel hackers такие kernel hackers.

PS: посрались знатно, практически с матюгами, и жалобами маме Линусу.

Написал тут AGPL в поиске в русской расскладке, и понял, что пора бы уже написать, почему я не люблю GNU/FSF/GPL.

#GPL

Если совсем коротко:

1) Слух о их полезности для дела бутстрапа OSS "несколько" преувеличен
2) Сейчас они индустрии больше вредят, чем помогают
3) С этической точки зрения они сильно похожи на движение SJW(которое я искренне ненавижу)

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

Поехали, часть первая!

Есть такой тулчейн, под названием LLVM. В него входит дебаггер LLDB, основной конкурент GDB. Я тут, на днях, собирал его для своего дистрибутива MIX, и нарвался на красивое.

Есть такая библиотека - readline. https://tiswww.case.edu/php/chet/readline/rltop.html Она распространяется по лицензии GPL3 (даже не LGPL!). Библиотека решает очень простую задачу - позволяет делать удобный пользовательский ввод, с редактированием, и историей. Понятно, что эта библиотека используется в куче софта - bash, python, gdb, везде, где нужен пользовательский ввод. К сожалению, лицензия библиотеки не позволяет ее использовать в бОльшей части OSS софта, из-за лицензии. Поэтому проект BSD запилил свою реализацию API readline - libedit. http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libedit/?sortby=date#dirlist Реализация, как обычно в мире OSS, неполная, но более-менее работает.

В чем прикол?

1) LLDB содержит в себе интерпретатор питона, для расширения
2) LLDB, как настоящее свободное программное обеспечение, использует libedit
3) Python под Linux настаивает(ну, до недавнего времени) на readline.

Это выливается в ошибки линковки, а если их "починить", то в падения в runtime - несмотря на то, что функции в libedit называются так же, как в readline, структуры данных имеют разный layout.

Очевидное решение - собирать python с libedit для LLDB. Ага, щас, вот феерический тикет про интеграцию libedit в python - https://bugs.python.org/issue13501

long story short - собрать python с libedit стало возможным совсем недавно, заняло это несколько ЛЕТ согласований.

"LLDB is a bit of a special case: LLDB links against libedit, but the Python libedit module is built as if readline is in use. It turns out this "magically" works out, presumably due to the runtime workaround detection. As far as I know this issue would affect Linux as well, but perhaps the version of libedit on common Linux distributions is one with the 0-based vs 1-based history fix?"

Почему так? Потому что какие-то долбоебы решили, что нижележащая инфраструктурная библиотека в Linux должна идти под copyleft лицензией. Извините, но инфраструктурная библиотека под GPL - это леденящий душу п№%дец. Это привело к фрагментации OSS мира, и к потере огромного количества человеко-лет. Что получила GNU/FSF от этого, кроме чувства огромного морального удовлетворения? Ничего. Libedit успешно существует, собака лает, караван идет. Страдают пользователи, исключительно из-за политики FSF.

Причем за развитие libedit "платят" пользователи OSS, те самые, о благе которых, якобы, беспокоится FSF, а не корпорации, от которых нас FSF "защищает". "платят", потому что ресурсы на эту мышиную возню можно было потратить иначе.

Перечитал текст, и задумался - а имеет ли вообще модуль readline в Python право на существование? Очевидно, сам модуль должен быть под GPL3, раз он линкуется с libreadline. При этом, интерпретатор питона загружает его в runtime. Какой, в итоге, должна быть лицензия конечного продукта? Имеет ли право не-gpl программа загружать gpl .so в runtime?

Таким вопросом задавался не только я:

https://python-list.python.narkive.com/ZktLTSUV/gnu-readline-licensing
https://www.b-list.org/weblog/2009/jul/14/licensing/ - очень интересная тема про то, как могут в одном питоне жить ssl и readline(раньше openssl была несовместима с GPL). А если учесть, что REPL Питона принудительно загружает модуль readline...
https://yarchive.net/comp/linux/gpl_modules.html (про загрузку проприетарных модулей ядра в Linux)

Напишу-ка я в FSF.

Например, блог разработчиков RedHat, с описанием того чудесного мира, куда RedHat собирается тащить десктопный Linux:

https://blogs.gnome.org/uraeus/2021/09/24/fedora-workstation-our-vision-for-linux-desktop/

Что я могу сказать? Я могу сказать, что RedHat тщательно игнорирует тренды современных языков, которые, по умолчанию, делают статическую линковку(Go, Zig, Rust, Swift, etc), навязывая дурацкий FlatPak(https://flatpak.org/) для дистрибуции приложений для Linux. К счастью, ничего они с этими трендами сделать не cмогут, и FlatPak будет постепенно умирать с остатками кода на С/С++. Может быть, трансформируется во что-то более удобное, типа бандлов в MacOS, для более удобного доступа к ресурсам приложения.

PS: flatpak, конечно, строго лучше того dll hell, что есть во всех мажорных дистрибутивах Linux, но "будущее" - вряд ли.

Новости из мира GNU. SFC подала иск за нарушение GPL на компанию #Vizio. https://lwn.net/Articles/873338/

Я прочитал публичную часть иска - https://shoestring.agency/wp-content/uploads/2021/10/SFC_PressKit_10-19-2021_v1.pdf

Все в лучших традициях GNU/FSF:

1) 20 страниц самореламы, без конкретных претензий к компании
2) Передергивания на передергивании. Just to name a few:
"… that you, as the consumer, have specific rights to modify, improve, repair and fix the software in your Linux-based products?"

Вот, из моего третьего пункта следует, что они настаивают на моем праве пофиксить bash в телевизоре. Но вот из их текста кажется, что я имею право лезть в саму прошивку Vizio.

"Vizio has a long history of violating copyleft, furthermore:
Vizio has already been subject to a large class-action suit that alleged that Vizio was misusing its customers’ private information"

Дооо, из того, что на Vizio уже подавали за что-то в суд, следует, что она нарушает copyleft.

3) Actually, на 20 страницах ровно 1 строчка претензий по существу. Что мы из нее узнаем?

"Smartcast is a Linux-based operating system. That means that not only do multiple copies of the Linux kernel appear in the firmware, other GPL’d and LGPL’d programs were found, including U-Boot, bash, gawk, tar, glibc, and ffmpeg."

Вы понимаете, к чему прикопалась эта пиявка? К тому, что в телевизоре есть bash && ffmpeg. bash/ffmpeg/прочее из этого списка, позволю себе напомнить, не идет под AGPL, поэтому требовать на этой основе открытия исходников софта Vizio под GPL нельзя. Можно требовать открытия патчей на bash, но если патчей нет, то и требовать нечего. Есть ли патчи на bash, или нет - иск стыдливо умалчивает.

4) Самая мякотка, которая показывает, насколько GPL защищает права пользователей на самом деле:

"that what makes this litigation unique and historic in terms of defending consumer rights is the fact that it is the first case that focuses on the rights of individual consumers as third-party beneficiaries of the #GPL. "

Сцуко, это ПЕРВЫЙ иск за всю историю #GPL, который подан не от лица разработчика! "Права пользователя на модификацию кода" my ass, ага.

GPL/FSF - это рак индустрии. Чем они вот отличаются от патентных троллей, с такими исками?

Отличный текст от Google, про оптимизацию memcpy: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/4f7c3da72d557ed418828823a8e59942859d677f.pdf #perf

Сравниваются 2 подхода - вручную написанный ассемблер, и автоматически настроенный(под нагрузку) код на С++. Второй способ побеждает(1% перфа Google). Я прямо ОЧЕНЬ советую прочесть хотя бы первую половину статьи, про использование SAT solver для автоматического построения алгоритма из базовых кубиков, это прямо огонь.

Так же дается описание того, как можно настроить memcpy под свою нагрузку.

На мой взгляд, конечно, оптимизацией memcpy должны авторы CPU(кто сказал "rep movsb"?):

1) Не нужно иметь сложный код от архитектуры к архитектуре(поэтому такой memcpy можно всегда инлайнить по месту)
2) Memcpy в процессоре имеет больше доступа к состоянию CPU, и может делать какие-то архитектурные оптимизации. Например, если поспекулировать, то memcpy может работать на уровне протокола синхронизации кешей - CPU читает cache line, и, вместо того, чтобы "прокачивать" его через регистры в output cache line, сразу пишет этот cache line по нужному адресу в свой cache, чтобы протокол синхронизации кешей сбросил этот cache line по нужному адресу в памяти. memcpy в CPU может игнорить write ordering.
3) Профит получит не только Google(не у всех есть 10 студентов, которых можно пустить на решение такой проблемы).

Тут, конечно, есть некоторые сложности(например, взаимодействие такой сложной инструкции и прерываний, взаимодействие с page cache), но они, кажется, решаемы. К сожалению, в x86 rep movsb проигрывает другим реализациям:

https://stackoverflow.com/questions/43343231/enhanced-rep-movsb-for-memcpy

Почему? Почему Intel оптимизирует AES, который не виден cluster wide, но не оптимизирует memcpy, который виден?

Для ARM у меня пока нет данных, но инструкции уже завезли:

https://news.ycombinator.com/item?id=28601386

Текст про то, как проект gnutls разводился с проектом GNU:
https://lwn.net/Articles/529522/

Как ушел мейнтейнер sed && grep, из-за политики FSF и Столлмана:
https://lists.gnu.org/archive/html/bug-gnu-utils/2012-12/msg00011.html

Ульрих Дреппер(один из авторов glibc) о RMS:
https://sourceware.org/legacy-ml/libc-announce/2001/msg00000.html

"Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC). The SC is different from the SC in projects like gcc in that it does not make decisions. On this front nothing changed. The only difference is that Stallman now has no right to complain anymore since the SC he wanted acknowledged the status quo. I hope he will now shut up forever.

The morale of this is that people will hopefully realize what a control freak and raging manic Stallman is. Don't trust him. As soon as something isn't in line with his view he'll stab you in the back. *NEVER* voluntarily put a project you work on under the GNU umbrella since this means in Stallman's opinion that he has the right to make decisions for the project."

Каких же потрясающих срачей в интернете нас лишила эта ваша политкорректность!

Как натянуть сову на глобус семантику Rust на C++:
https://docs.google.com/document/d/e/2PACX-1vSt2VB1zQAJ6JDMaIA9PlmEgBxz2K5Tx6w2JqJNeYCy0gU4aoubdTxlENSKNSrQ2TXqPWcuwtXe6PlO/pub

Спойлер: увы.

RedHat планомерно сворачивает "бесплатный RedHat Linux", во всех его проявлениях. Интересно, ждет ли ее судьба ELK && MongoDB? https://www.opennet.ru/opennews/art.shtml?num=54219

Microsoft колбасит .NET:
https://www.opennet.ru/opennews/art.shtml?num=56027
https://www.opennet.ru/opennews/art.shtml?num=56020

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

———
Я как-то обещал написать про то, как #eBPF && #io_uring поменяют Linux, но так и не написал. Давайте я совсем коротко обозначу свою мысль, а раскрою ее позже.

Благодаря тому, что syscall станут бесплатными(io_uring), и станет возможным безопасно выполнять пользовательский код в контексте ядра(eBPF), ядро станет мигрировать в область микроядра - сервисы в пространстве (kernel-user)space(кто сказал "Microsoft Singularity?!" - https://ru.wikipedia.org/wiki/Microsoft_Singularity), c реализацией ядерной функциональности.

Это не просто спекуляция - сеть уже едет вовсю в (kernel-user)space, а вот теперь и шедулер: https://lwn.net/ml/linux-kernel/20210916162451.709260-1-guro@fb.com/ (патчи от нашего бывшего коллеги!) #sched

Тесты производительности новых M1 - https://www.anandtech.com/show/17024/apple-m1-max-performance-review/5

Очень впечатляет, и я могу только понудеть, что так мало от площади кристалла отдано целочисленным задачам CPU. https://architosh.com/wp-content/uploads/2021/10/M1-pro-max.jpg - меньше 1/10 части кристалла. А вот 1/2, отданная под GPU, у меня будет простаивать.

А мне начинает нравиться llvm-libc!

https://reviews.llvm.org/rG87c016078ad7 - имплементация https://lemire.me/blog/2020/03/10/fast-float-parsing-in-practice/

Если коллеги будут и дальше пушить туда state of the art алгоритмы, это же просто праздник какой-то!

1) Проект GNOME всегда славился тем, что "слизывал" дизайн и концепцию GUI с macOS. Но тут GNOME впереди планеты всей - если вам не терпится попробовать новую "челку" в действии, то это уже можно сделать в GNOME! https://github.com/AlynxZhou/gnome-shell-extension-inotch/

2) Адовейший ад с samsung - https://www.cnews.ru/news/top/2021-10-21_samsung_zapretili_prodavat

3) Заметка про то, что можно сделать неправильно вообще все, но если ваш продукт востребован - то пользователей это не остановит. https://www.quastor.org/p/how-whatsapp-scaled-to-1-billion

4) Продолжаем hate цикл про GNU - https://blogs.gnome.org/aklapper/2009/12/13/to-gnu-or-not-to-gnu/

https://habr.com/ru/news/t/585682/

Ну, TG я еще понимаю, но LJ-то за что?

1) Чот читаю, и ржу, какие девиации бывают у людей на собеседованиях. https://www.linux.org.ru/forum/development/16592727

2) Вот тут раздают serverless cockroarchdb. https://www.cockroachlabs.com/blog/announcing-cockroachdb-serverless/ Мне интересно, cockroarch смогли доставить то, что обещали много лет назад? В частности:
* не нужно админить
* горизонтальное масштабирование
* sql
* open source

Или, как обычно, take any N-1?

3) Хороший текст про http3/quic - https://www.smashingmagazine.com/2021/08/http3-performance-improvements-part2/
Long story short - ну, такое, непонятно, чем quic лучше, чем tcp(кроме того, что в нем проще экспериментировать)

Bonus: про TCP BBR от нашего коллеги! https://www.youtube.com/watch?v=hOr9GP_czFs

4) Какая-то непонятная(но, наверняка, позитивная!) новость про то, что YADRO присоединилось к OIN. https://www.opennet.ru/opennews/art.shtml?num=56046 У YADRO есть какой-то значимый пул патентов, чтобы это имело смысл?