https://pythoninsider.blogspot.com/2021/12/python-3110a3-is-available.html

Пишут, что Python 3.11 уже на 20% быстрее, чем 3.10. Не знаю, у меня, кажется, медленнее, будет время - проведу пару тестов.

———
https://habr.com/ru/post/596193/

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

———
https://www.brian.jp/2021/12/24/exiled-from-the-metaverse-before-it-even-started-the-dangers-of-relying-on-facebook/

Писал, пишу, и буду писать, что это(отключение от услуги) не должно быть в компетенции провайдера услуги. #law #provider #yeswecan

———
https://lwn.net/Articles/879739/
Вышел юбилейный systemd.

https://www.opennet.ru/opennews/art.shtml?num=56393
И не столь юбилейный s6.

Из этих двух, я, конечно, выбрал бы s6, а так - ни тот, ни другой.

Я еще сильно не думал про систему инициализации в MixOS, мне, если честно, пофиг, или, как сейчас модно говорить, unopinionated. Скорее всего, это будет божественный runit, потому что он реализует ровно ту модель запуска сервисов, которую я считаю правильной.

Про #systemd:

* Он слишком сложный. Если я бы хотел не знать, как работает моя система, я бы взял систему с launchd, если вы понимаете, о чем я.

* Он слишком всеобъемлющий. Я не верю, что такой комбайн может работать хорошо, и это, простите, не unix-way. Я предпочту набор хорошо сопрягаемых независимых компонент(в каждом из которых можно разобраться по отдельности).

* Он не решает ни одной моей задачи. В облаках сервисами управляет, условно говоря, снаружи K*, внутри или ничего, или что-то очень простое, типа runit. На десктопе модель systemd слишком сложна. Redhat, скорее всего, пилит systemd для отдельно стоящего сервера с apache/mysql/1c, ну так я не целевая аудитория.

* Мне никто так и не сумел ответить, как systemd должен поднять систему, в которой написано, что B поднимается после A, и должен работать только если работает А, но A находится в состоянии "10 секунд работает, 10 секунд упал".

Я считаю, что зависимости в системе управления локальными сервисами - зло. Управлялка должна оперировать bag of services, и просто пытаться поднять их все, возможно, с exponential backoff(потому что сервисы, в момент запуска, часто жрут больше CPU, чем в процессе работы).

Если вы пытаетесь перенести часть логики по обеспечению надежности своего сервиса в systemd("апач не должен отвечать на запросы, если не поднят mysql"), то вы попали, и мне даже лень подробно объяснять, почему.

Собственно, поэтому это и будет runit, возможно, с несколькими кастомными скриптами(для обеспечения exponential backoff, для управления cgroup, etc).

А, совсем забыл, за что глаз зацепился-то в релизе #systemd:

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

То есть, "анимированный индикатор" запилили раньше, чем вывод сведений о состоянии. Такие дела.

Небольшое продолжение про #systemd, конкретно, про #udev(который какого-то хера стал частью systemd).

https://github.com/illiliti/libudev-zero

"Another udev problem is non-portable home-grown language called "udev rules". Udev authors definitely don't know(or care) why it's better to avoid reinventing the wheel. Strictly speaking, I think they did that on purpose to overcomplicate udev as much as possible. Why? So that only authors(RedHat/IBM) can rule and dictate the future of udev. The recent eudev death only proves that it's really hard to support such unmaintainable mess."

Забавно, но я пришел к таким же выводам, весь этот ваш systemd - это классический vendor lock-in, со стороны IBM/RedHat.

———
https://lists.llvm.org/pipermail/llvm-dev/2021-December/154371.html #loongson

В #LLVM приземляют поддержку loongarch. Это ОЧЕНЬ странно. LLVM, на моей памяти, отказали почти ВСЕМ, в их желании поддержать новую архитектуру в LLVM. Их позиция - лучше меньше, но лучше. Почему этот принцип не сработал в данном случае, и кому занесли китайские товарищи(или на кого собрали компромат, хотя какой в современном западном обществе возможен компромат, когда все можно и все, что можно, - хорошо)?

———
https://justine.lol/sectorlisp2/

Lisp, на этот раз с GC, за 436 байта.

Еще ссылок от #Justine:

https://justinetunney.com/dox/unicode.html
https://justinetunney.com/endian.html

Хотел на ее примере написать что-то типа "вот есть же нормальные тетки-программисты, и без всяких этих ваших SJW-конференций https://www.youtube.com/watch?v=xOmQFBirbOg", а потом передумал.

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

Вышла новая версия busybox. Почему-то очень часто, рядом с информацией про релиз busybox, пишут вот такую ересь:

"В то же время автор BusyBox всячески возражает против такой защиты - считая что она ломает ему бизнес."

Брюс Перенс, конечно, является автором закрывающих скобочек в коде, но вообще, он склочный мудак:

https://lists.busybox.net/pipermail/busybox/2006-September/058617.html

Это переписка тогдашнего мейнтейнера Busybox(он, после этого, стал автором Toybox), с Брюсом.

Мейнтейнер, конечно, тогда тоже был не прав, потому что удалил авторство Брюса вот над этими "закрывающими скобочками", но Брюс, конечно, очень плохой человек - он настаивает на том, что он является автором busybox, даже если там не осталось его кода. Очень интересная идея, конечно.

GNU, кстати, согласно с такой трактовкой - один раз автор - всегда автор. Поэтому GNU/Linux, даже если кода GNU у тебя сейчас уже нет(не верите? А попробуйте собрать какую-нибудь #autohell приблуду с gnu triplet, содержащим linux, но не содержащим gnu).

Зачем издания форсят этот унылый мем, что "автору busybox" там кто-то мешает вести бизнес, я не понимаю. Он уже давно не автор.

———
Busybox или Toybox?

Мне, конечно, ближе идея toybox(https://www.landley.net/toybox/faq.html#why_toybox).

Я не верю в деньги или славу от OSS, это примерно как рассчитывать на деньги и славу от профессионального спорта - ну вот сколько вы знаете известных программистов? 100? 1000? Наверное, примерно столько же, сколько и спортсменов.

Я верю в патчи и фидбек от OSS, а они достигаются широтой использования твоего кода. Даже если кто-то решит закрыть твой код, патчи ему будет выгоднее держать в upstream.

Поэтому toybox почти в каждом телефоне, а busybox на рутерах, и его оттуда постоянно выпиливают, потому что разработчики - склочные #GPL задроты.

Ну и на закуску - busybox про #systemd. https://busybox.net/kill_it_with_fire.txt

———
https://reviews.llvm.org/rG37e6bd8bc8da

К НГ новости совсем закончились, вот, llvm weekly предлагает, в качестве новости, вот такой вот коммит про очередной scope guard.

———
Пишут, что Линусу сегодня 52. Это, конечно, очень важно, и вот вам ссылка на запись одного из его самых первых выступлений на конференциях. Я не слушал, не фанат. https://www.facebook.com/maddoghall/posts/10159125354012025

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

Вот и ответ про clang. Сравнение с прошлой версией не очень хорошо получается сделать, но я насчитал где-то 8% преимущества над GCC.

———
https://blog.darknedgy.net/technology/2020/05/02/0/

Фундаментальный текст про systemd.

* Я понял, что не совсем верно понимал позиционирование systemd. Авторы его больше продавали как замену xinetd, то есть, хотели все сделать на socket activation. Ну, то есть, systemd еще более overengineered, чем я думал.

* launchd, с которого списывали #systemd, сделал многие вещи существенно более правильно - отдельная система для dependency management, отдельная - для socket(port, в случае Mach) activation.

* Текст лично для меня оказался очень вкусный. Знаете же это ощущение, что на одной волне с автором? Читаешь такой, и думаешь, "а вот сейчас бы упомянуть про ...", и вот оно. Например, https://www.winestockwebdesign.com/Essays/Eternal_Mainframe.html. Или вот - "and the general trend of eBPF turning Linux into an extensible hybrid kernel of sorts."

* Недостаток текста - автор зачем-то слишком много цепляется к личности Поттеринга. Насрать же на Поттеринга, важно то, что хочет делать RedHat, а потом IBM(кроме как попыткой враждебного захвата Linux это и не назвать IMHO).

* Поворотный момент - когда разработчики ядра(спасибо им за это!) послали всю эту гоп-компанию с kdbus. Сейчас systemd не представляет экзистенциальной угрозы.

———
https://github.com/2point21/lba2-classic

Совершенно случайно наткнулся на исходники LBA2. В детстве всегда хотелось посмотреть, как она сделана внутри, вот, смотрю. Интересное вечернее занятие :) Удивительно, насколько оно все сделано странно, и, фактически, затащено "грубой силой".

К слову, был у меня период, когда я, в течении нескольких месяцев, воскресное утро начинал с того, что проходил LBA2. А какой там был саундтрек!

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

Классная штука, я туда даже пару коммитов сделал.

———
https://habr.com/ru/news/t/645097/

А расскажите, кто в теме, кто в данной ситуации негодяй и редиска?

———
https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/ #gold

Хороший текст про важность времени сборки.

For example here (Unity), we had a joke that “adding Boost into the codebase is a fireable offense”

Мои 5 копеек:

* Header-only библиотеки - это зло, которое возникло от того, что старперы в стандарте заняты поддержкой сохранения ABI, вместо того, чтобы сказать, что приложение на С++ должно пересобираться целиком, как в Rust. Поэтому люди вынуждены эмулировать вот это вот "целиком" подручными средствами. #abi

* В своем личном коде на C++ я стараюсь допускать как можно меньше inline, у меня даже pushBack() в Vector в .cpp лежит. LTO разберется(и, по факту, no inline + LTO разбирается быстрее, чем инстанциировать километры шаблонов в каждом исходнике).

* Если бы все согласились разово замедлить весь код на 20%, но чтобы он собирался в 10 раз быстрее, я(ну, условный я) за освободившееся время бы алгоритмически ускорил бы подведомственный код больше, чем на 20%. Кажется, тут уместно вспомнить, что оптимум по Парето не всегда совпадает с равновесием Неша.

* Использование компиляторных intrinsics в 100 раз быстрее, чем использование их, но обернутых в std::. Поэтому у меня есть https://github.com/pg83/std/blob/master/std/typ/intrin.h

———
https://blog.robsayers.com/on-learning-smalltalk

Тут вот господин рассказывает, почему Smalltalk хорошо, но мне почему-то кажется, что любой image-based Lisp(а это почти все современные Lisp) обладает такими же свойствами.

———
Флеймообразующий вопрос к аудитории!

А почему, например, GNU/FSF не считает файл с образом для QEMU, в котором лежит образ Linux и другие динамические библиотеки, вариантом статической линковки?

———
>Сейчас #systemd не представляет экзистенциальной угрозы.

Хочу немного пояснить этот speech. Речь идет про small linux, hobby linux, про мой личный Linux.

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

Читал тут исходники pulse audio. Осознал, что Поттеринг всю жизнь пишет одну и ту же программу - граф обработки каких-нить событий в realtime, и обязательно чтобы граф связывался в runtime, и без проверок на то, что этот граф может выполниться в реальной жизни. Ну не дает покоя человеку эта идея.

Бывает, чо. Некоторые вот уже 5-ую систему сборки пишут.

———
#gold, #security

Сначала небольшая вводная, для тех, кто с нами недавно.

Mix - это пакетный менеджер для linux/macos, и дистрибутив Linux на основе.

Я очень хочу, чтобы пакетным менеджером пользовалось как можно больше народу(не прямо сейчас, а вообще), потому что 1 человек потянет 500 пакетов(у меня сейчас 300), а больше уже нужно больше людей.

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

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

Поэтому я предполагаю, что у меня будет несколько "пресетов" - наборов пакетов, которые формируюут законченную идею(вид линковки + libc + DE + whatever).

Далее, когда я говорю, что "у меня в Mix вот так-то", я имею в виду вот этот вот пресет - https://github.com/pg83/mix/blob/main/pkgs/set/system/0/mix.sh, или System/0 #system0. Все, что я делаю в нем, может и не относиться к потенциальному Mix на #systemd + gnome.

Я повторю, что мне все равно, кто и как использует пакетную базу, лишь бы помогали обновлять пакеты.

Так, вводная закончилась. Далее про то, как будет устроен System/0(а точнее, про один из аспектов устройства).

Мне очень хочется, чтобы пакетный менеджер не работал от root, и чтобы в нем не было postinstall скриптов. А точнее, я хочу, чтобы пакет можно было установить, распаковав папку с его содержимым, и все. Это здорово облегчает реализацию, и упрощает модель безопасности. Скажем, как в Android.

Я решил почти все проблемы, связанные с этим:

* заведение пользователей/групп
* резолвер
* динамическая настройка сети

Да даже попакетные настройки ядра.

Но вот одна проблема оставалась для меня сложной. Как эскалировать привилегии? Да, sudo. Если пакетный менеджер не работает от root, нет postinstall скриптов, то как получить #suid бинарник в системе?

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

На днях придумал элегантное решение, и спешу им поделиться.

На хосте запущен(скажем, через socket activation) ssh демон, от рута. И sudo - это простой скрипт, который делает ssh root@localhost. ssh поднят на unix domain socket, чтобы не светить в сеть. Базово эта схема уже работает.

Чем больше думаю, тем больше мне эта схема нравится.

* Эскалация привилегий в ssh, я думаю, отлажена даже лучше, чем в sudo. Потому что так мы привилегии эскалируем IMHO чаще.

* Вход не по паролю, а по ключу, 1 на пользователя, а не одному на host.

* Парольный/беспарольный вход остается на стороне пользователя(пароль на приватной части ключа), без fragile вмешательства в /etc.

Схема работает очень годно - у меня нет ни одного #suid бинаря.

#unbound #musl #dns #dnsmasq

Перешел с unbound на dnsmasq, по советам коллег.

(да, я понимаю, что это продукты несколько разных масштабов, потому что unbound - настоящий рекурсивный dns resolver, а dnsmasq - "просто" кеширующая прокся (+dhcp +говна самовар), я их использовал для одного и того же)

pg# ls -la /ix/.../bin/unbound 
... 5683992 unbound
pg# ls -al /ix/.../bin/dnsmasq
... 2948464 dnsmasq

dnsmasq (вроде) не виснет, и весит меньше.

Заодно сделал использование локального кешера обязательным, потому что musl без этого так себе работает - https://wiki.musl-libc.org/functional-differences-from-glibc.html#Name-Resolver/DNS, а люди потом жалуются на alpine - https://martinheinz.dev/blog/92

Коллеги посоветовали посмотреть в сторону #systemd-resolvd, но, КМК, они так шутят, потому что, будучи статически слинкованным, он будет под сотню мегабайт весить, наверное.

https://www.phoronix.com/news/Red-Hat-Layoffs

Пишут, что в RH сокращения.

Мне сразу пришел в голову вопрос, что будет, если у RH кончатся деньги на развитие #systemd - что будет? Реально, community не потянет развивать это УГ, хватит ли сил у организации?

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1384350-red-hat-begins-cutting-hundreds-of-jobs?p=1384370#post1384370 - забавно, но один из первых комментариев на форониксе ровно про то же самое.

Да и на opennet тоже - https://www.opennet.ru/openforum/vsluhforumID3/130300.html#2

#dbus #systemd

https://www.phoronix.com/news/Ubuntu-23.10-Dbus-Broker-Plan

dbus-broker - это замена dbus-daemon, но:

* linux-only
* https://github.com/bus1/dbus-broker/blob/main/meson.build#L76 довольно безальтернативно зависит от libsystemd, без нее глючит в плане запуска процессов
* зависит от каких-то велосипедных библиотек для С - https://github.com/c-util, https://github.com/bus1/dbus-broker/blob/main/meson.build#L24 Факт того, что уже есть безальтернативная зависимость от #glib, никого не волнует - это не +-1, это +1 велосипедная либа

И все это для чего? Для того, чтобы показать эфемерный выигрыш в производительности. Ага, для десктопной шины, которая должна тумбнейлеры запускать, это, конечно, очень важно.

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

Мораль? Да какая мораль, все равно нас всех скоро заменит AI, пусть кожаные порезвятся напоследок.

https://www.phoronix.com/news/systemd-255-rc1

Я просто оставлю это здесь - в #systemd появилась поддержка BSOD. Нет чтобы что-то хорошее из винды притащить, а?

https://www.phoronix.com/news/Systemd-Varlink-D-Bus-Future

Я чет ору.

D-Bus уже не годится для #systemd, теперь там будет https://varlink.org/ #varlink.

С одной стороны, в качестве транспорта там JSON, что хорошо, потому что легко отлаживать.

С другой - очередной велосипиздизм:

* \0-delimited, вместо всем привычного jsonlines (https://jsonlines.org/).

* очередной велосипедный IDL. Старые, очевидно, обладают фатальным недостатком (их придумал не Поттеринг (когда же он уже уймется?), ага)

Linux Kernel module included (https://github.com/varlink/linux-varlink/), видимо, очередная попытка pown ядра.

Приятно осознавать себя на острие прогресса!

Вот, я недавно (ну как "недавно", в первый раз так-то в 22 году, когда я только начал этот quest) писал про #TMPDIR, и тут, внезапно:

https://dotat.at/@/2024-10-22-tmp.html

Годный, очень созвучный моим мыслям текст, почему общая TMPDIR - плохо.

https://systemd.io/TEMPORARY_DIRECTORIES/

А потом и авторы #systemd подтянулись (они вообще горазды пиздить у меня годные идеи, типа https://t.iss.one/itpgchannel/1871 #suid). Чуть менее годный, но тоже неплохой, текст, на эту тему. Решение проблемы, которое озвучивается там, мне не нравится.

К сожалению, оба текста недостаточно радикальны.

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