It is settled. #stalix #ix #mix

#stalix - новое название дистрибутива
#ix - новое название пакетного менеджера

Теперь OS и пакетный менеджер называются по разному, во избежание неоднозначности.

Actually, КМК, stalix объективно самое лучшее название.

Посудите сами:

* STAtically LInked LInuX - какое-то дикое пересечение акронима и того, что сокращаем.

* Звучит очень "чисто", "звонко" и "сочно".

Если бы не коннотация со Сталиным, у меня не было бы никаких сомнений, и я бы даже не стал устраивать опрос.

Меня удивило и ободрило, что так много людей посчитало, что stalix - норм.

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

Получил два вполне подходящих мне мнения:

* Всем похуй.

* А тем, кому не похуй - они сделают хорошую рекламу на reddit. Все, что не некролог, как известно, хорошо.

"IX" - пересечение "stalIX" и "unIX", хочу, чтобы название подчеркивало цель быть пакетным менеджером не только для OS stalix, а вообще, для unix-like OS.

Ну и, конечно же, интересная история, которая со мной случилась в момент перименования.

Я сначала сделал ln -s /mix /ix, потом сделал полный ребилд всего и вся по новым путям.

А потом я сделал "./ix gc", и вот тут-то случилась жопа.

gc - это была одна из команд, которую я не перенес в граф, и она выполнялась бинарем пакетного менеджера, в котором я не переименовал mix в ix.

Поэтому он посчитал, что корней для gc нет, и снес все пакеты в /mix/trash/

А я напомню, что у меня раз в 100 секунд запускается процесс, который очищает корзину, это такая оптимизация, чтобы делать это async.

Кажется, я секунд за 10 успел:

* в открытом MC найти в trash бинарник busybox

* c помощью этого бинарника вернуть все пакеты в /ix/store/

* тут мне очень помогло, что у меня предусмотрительно на пятом tty запущена рутовая консоль без логина, для подобных аварийных случаев. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mingetty/runit/ix.sh#L9

Это был первый раз с нового года(а я под новый годе переехал на mix полностью), когда я был близок к потере установленной системы.

Но все обошлось, пути я поменял!

https://groups.io/g/simh/topic/new_license/91108560
https://github.com/simh/simh/issues/1059
https://www.reddit.com/r/linux/comments/uua97p/unix_emulator_project_maintainer_removes_foss/
https://www.reddit.com/r/emulation/comments/ut0uvn/maintainer_of_open_source_emulation_software_simh/

Читал последние несколько дней, наконец, дочитал, пишу.

Совершенно феерический тред про взаимодействие автора simh4, форка simh3 - симулятора разных древних аппаратных архитектур, типа PDP-11.

Автор симулятора запилил довольно controversal фичу - начал дописывать к raw images с образами OS свою метаинформацию в конец файла.

Спорная вещь, учитывая, что raw image это не его приватный формат, который он может менять, как ему угодно.

Короче, запилил, к нему посыпались возмущенные пользователи с "какого хера твоя программа попортила мои образа".

Откатывать это он отказался, люди начали форкать его поделие. Автора simh4 это возмутило до глубины души, и он поменял лицензию на свой код в этом проекте. Что, начиная с ревизии X, ты не имеешь право менять такой-то файл, функцию такую-то. А если поменял, то не имеешь права пользоваться кодом автора, начиная с ревизии X.

По ссылкам - мега-срач по этому поводу. Там все хороши.

И поехавший автор, и community, которое вообще не понимает, что такое лицензии, и собирает петиции, чтобы отобрать на гитхабе владение организацией simh у этого чувака.

ЖЫР, цирк с конями, и вообще, красивое.

Совершенно феерические рекламы 80-годов про продажу компьютеров.

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

https://rarehistoricalphotos.com/vintage-computer-ads/

(КДПВ следующим постом, телега почему-то не дала объединить)

fun fact - мои любимые NB совсем не поменялись с 85 года!

#allocator #tcmalloc #mimalloc

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

Короче, я привел свои эмоции в соответствие реальности, и перешел на tcmalloc по дефолту.

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/c/alloc/ix.sh#L5 - по сути, это изменение 1 строчки кода, после чего весь репозиторий будет линковаться с tcmalloc, если не указано обратное

* конечно, реальное изменение было несколько больше, потому что, я напомню, цепочка #bootstrap у меня теперь строится автоматически, и теперь tcmalloc может использоваться раньше в этой цепочке, когда мой инструментарий был недостаточен, чтобы собрать его полную версию. Самое простое - не готов perl, для запуска GNU autohell скриптов. Поэтому я взял более свежую версию gperftools, где есть поддержка cmake. Сборка cmake там пока молодая, немного кривая, за ней приходится подрихтовывать сборочные артефакты руками - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/cmake/ix.sh#L52

(кстати, пользуясь случаем - полайкайте, чтоли, https://github.com/google/tcmalloc/issues/126 - прошу G-word company, чтобы они поддержали сборку каноничного tcmalloc без Bazel)

* Число пересборок библиотек стало меньше. Потому что раньше я принудительно собирал некоторые гуевые приложения с tcmalloc, а остальные - с mimalloc, а сейчас все получается с tcmalloc. Поэтому всякие mesa + gtk + qt раньше собирались по 2 раза, а теперь 1.

* у tcmalloc очень большой footprint - размер на диске 600Kb. 400Kb сам tcmalloc + 200Kb c++ runtime. Это довольно дофига, сильно вырос объем дискового пространства, занимаемого базовыми утилитами OS.

Я, наконец-то, нашел время это все подрихтовать, теперь базовые утилиты собираются с другим набором флагов - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/set/system/0/ix.sh#L4 :

* curses=netbsd говорит нам, что не нужно использовать ncurses для этих утилит. На минус куча лишних terminfo в базовом образе.

* intl_ver=no говорит нам, что не надо использовать gnu gettext для интернационализации, не нужно это в утилитах, которые не видит пользователь. Вообще, предполагается, что каждый пользователь сам, в своем #realm, решает, какие утилиты использовать

* purec=musl/unwrap говорит нам, что мы используем libc musl без переопределения аллокатора. Встроенный в musl аллокатор как раз хорош для такого рода использования.

Ну и, раз я уж этим занялся, то я аккуратно:

* почикал из системных пакетов неиспользуемые тулзы. Например, https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/dbus/sys/ix.sh#L5 - Действительно, зачем в системном пакете что-то, отличное от dbus-daemon? Клиента, если надо, пользователь поставит в свой #realm.

* Редко запускаемые, one-shot программы пожал с помощью upx. busybox не пожал, нефиг разжимать при каждом запуске cp/rm/mv/etc. Демоны тоже жать не стал, им нужен backing store за замапленной программой в памяти. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/iwd/sys/ix.sh#L12 Кстати, fun fact - upx почти не имеет смысла с динамической линковкой, но хорошо помогает в случае статической. В копилку примеров решений, которые по разному работают в разных мирах.

После всех этих действий объем базового #realm упал с 40 мегабайт до 17 - https://pastebin.com/raw/6b9Xtg5n (причем 7Mb из них - сжатая в 1 файл питонячка бинаря ix - graph executor моего пакетного менеджера, который надо переписать на С++/Rust).

Напомню, что мой базовый #realm позволяет поднять OS с настроенной сетью и серверной частью seat/input/sound/etc.

https://keunwoo.com/notes/rebooting/ #reboot

Хороший, только очень длинный текст, в котором написаны 2 простых мысли:

* В любой системе нарастает энтропия. По другому - в системе есть https://ru.wikipedia.org/wiki/Гейзенбаг.

* Перезагрузка(VM, хоста, программы) - это простой способ вернуть систему из состояния с накопившейся ошибкой в состояние без такой ошибки.

Люди, которые меня знают поближе, знают, что я люблю давать пару странных архитектурных советов:

* Периодически рестартовать свои программы на кластере. Обычно достаточно обновления версий, если оно регулярное.

* Несколько более странный совет - вставлять в свою программу abort() в случайные места. В проде, именно в проде.

Попробуйте пофантазировать, почему это хорошо и правильно, и от каких проблем защитит вас.

———
https://hpdevone.com/

Какой-то странный forced mem от HP и ноутбук на PopOS. Написали про это поделие на 5 форумах, которые читал сегодня.

Расскажу вам такую историю.

Я очень странно отношусь к своей технике. Например, экран и клавиатуру ноутбука я могу не протирать по несколько месяцев, потому что зачем? И потому что лень.

Однажды я ехал на переднем сиденье такси, с ноутбуком. Водитель половину поездки пялился на мой ноут, потом достал из бардачка спиртовую салфетку, протянул мне, и сказал: "Протирай!". Больше за всю поездку мы не перемолвились ни словом.

К чему я клоню?

Я, с полгода назад, рассказывал, какой охуенный ноут я купил - #Xiaomi, Ryzen, OLED, 4K. https://aliexpress.ru/item/1005002697829975.html?sku_id=12000027107974063&spm=a2g0o.search.0.0.4f227153dK0TN4

Стоит дешевле, чем собрат от HP, начинка лучше, и просто божественный OLED экран!

Он настолько крутой, что я завел себе привычку вытирать его 3 раза в неделю спиртовой салфеткой! Никогда в жизни такого не делал, а тут делаю.

Это не реклама, ноут реально офигенный. Stal/IX я разрабатываю на нем, его 8/16 ядер не простаивают ни секунды.

#alsa #gold

Победил проблему со звуком. Как? Что было?

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

* Как я уже рассказывал, система у меня определяла 2(на самом деле 3, но это неважно) аудиокарточки - hdmi выход в видеокарте, и встройку. alsa выбрала в качестве карты по умолчанию hdmi выход, поэтому звук, даже если и шел куда-то, то, явно, не туда.

* libalsa silently fail, если в системе нет группы audio. Конечно, нам в протокол общения с ядром обязательно надо указать эту информацию, даже если пользователю не нужен доступ к этой группе(у меня пользователи напрямую не ходят в alsa, а ходят в мультиплексор sndiod). Повторю - наличие пользователя в этой группе не нужно, важно наличие этой группы на машине. PZDS.

* В alsa все выходы по умолчанию mute. Это не было бы проблемой, если бы я знал/помнил, как это выглядит в "графическом" alsamixer. Выглядит оно... незаметно, скажем так. То, что каналы замучены, я нашел в полном большом выхлопе какой-то отладочной тулзы.

Наверное, стоит упомянуть, что, прежде чем чинить alsa, я попробовал вывести звук через alsa oss emulation, но у меня, с ходу, не получилось, потому что oss сейчас, конечно, уже так себе поддерживается в клиентах. Например, я нигде не смогу указать, что нужна именно вторая карта(к этому моменту я уже понимал, что звуковые карты перепутаны).

Все заработало? Нет!

Но сначала история из прошлого.

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

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

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

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

* there is no such thing as "protaskivanie"! #protaskivanie

и

* what the hell code are your writing?

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

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

К чему это я?

Авторы #sndiod решили позаниматься "protaskivanie" - они погрузили формат описания звукового устройства в какой-то свой формат, и мне понадобилось еще полчаса чтения кода, чтобы понять, что нужно запускать не "sndiod -f 1", а "sndiod -f rsnd/1". Что такое этот rsnd, и зачем он там нужен, я не понял.

С другой стороны, я пытаюсь делать так, чтобы "protaskivanie" не было нужно, поэтому я сделал так, что номер карты можно указать параметром ко всему #realm, и он попадет прямо в самый скрипт настройки sndiod:

pg-> ./ix list system
{'flags': {'alsa_device': '1', 'failsafe': '1'}, 
 'name': 'set/system/0'}

Этот флажочек сам пробулькивается до конечного скрипта:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sndio/runit/scripts/ix.sh#L8

После этого все заработало, звук появился сразу и везде, кроме epiphany, потому что там аццкий gstreamer, с которым я еще вообще не разбирался.

веселых картинок в ленту!

Долго думал, откуда целых три блевотных смайлика на прошлое сообщение.

И я все понял!

Все верно, "./configure; make; make install" без указания —prefix превращает любую систему в slackware, виноват, обещаю исправиться.

https://www.reddit.com/r/wayland/comments/uva3os/scrollable_tiling_wm_alternative/

Знаете, обнять и плакать, что называется, как будто сам писал.

scrollable tiling wm, КМК, очень годная тема для ноутбуков.

Это, представьте себе, бесконечная лента окошек в 1 ряд, которую можно скролить влево и вправо, и в каждый момент времени экран ноутбука отображает 2 или 3 сопряженных окна из всей ленты. Новое окно всегда открывается или слева, или справа от текущего.

Проблема в том, что одна из двух существующих альтернатив - это какой-то говнокод на JS для GNOME, и ломается через релиз Clutter, а вторая - заброшенное поделие на wlroots.

———
Из 5 секунд загрузки OS на моем компе:

1 секунду занимает sleep в драйвере amdgpu:

[    0.338250] amdgpu 0000:03:00.0: 
    amdgpu: Will use PSP to load 
    VCN firmware
[    1.225631] [drm] reserve 0x400000 
    from 0xf43f800000 for PSP TMR

И еще одну секунду занимает нечто в нечто, делающее нечто:

[    3.473944] random: fast init done
[    4.363383]  (null): enodev DEV ADDR = 0x00

По меркам загрузки винды, наверное, не так уж и много, но зачем?

Кстати, загрузка от начала userspace до логина у меня занимает 0 времени.

———
Я занялся энергосбережением для #stal/IX, до сего момента у меня работал "performance" гувернер.

В связи с этим у меня два вопроса - как кошерно настраивать acpi(открытие и закрытие крышки ноутбука, вот это вот все)?

У меня сейчас 2 примитивных скрипта, но, такое ощущение, посреди ночи бывает spurious wakeup, и дальше ноутбук жарит вовсю весь остаток ночи, с закрытой крышкой.

Где взять правильные скрипты для acpid? Или acpid вообще неправильно?

И второй вопрос - cpu frequency scaling.

По идее, политика для ноутбука с большим числом ядер должна быть примерно такой - если есть активные в данный момент времени задачи, то число ядер на full scale должно быть == min(ncpu, числу активных задач), все остальные ядра надо отправлять на low scale. Шедулер должен шедулить задачи на ядра с высокой частотой.

Как настроить linux так, я пока не понял. Не думаю, что это вообще возможно.

Как сейчас принято делать?

2 руководителя службы, в перерывах между встречами по планированию следующего полугодия

Много раз обещал написать, зачем свой дистрибутив Linux, и почему он так устроен. #stal/IX #gold

Часть первая, "зачем".

Мне в современных OS очень много чего не нравится.

* Мне не нравится шедулер Linux. #scheduler

* Мне не нравится закрытые части в macos, ее политика по отношению к приложениям, и, особенно, к инструментам разработчика(профилирование, отладка - все это перестает работать "из коробки")

* Мне, для примера, очень не нравится, что в Unix orphane process прибивается к init'у, я хочу, чтобы все мои процессозапускалки не делали double fork, чтобы видеть completely supervised tree

* Мне не нравится сложность, которую RedHat привносит в Linux, например, systemd - это универсальный(и очень плохой!) запускатор динамического графа задач, система управления загрузкой там вообще сбоку. (правильно, кстати, сделано в macos, там отдельно начальный загрузчик, отдельно socket activation, и так далее) PipeWire - универсальный обработчик графа мультимедия потоков, и нахер он никому не нужен в таком качестве, все вменяемые(да-да, "ни один истинный шотландец") плееры берут дубовый ffmpeg, без вот этой вот всратой динамики и резолве зависимостей плагинов в runtime.

* Мне не нравится наслоение говен на говны в современных LFS/LSB дистрибутивах. Ах, динамическая линковка ведет к dll hell, ну, мы ее оставим, но приделаем ostree и контейнеры для деплоя приложений. Знаете, это решение из серии "сохранить лицо", а не перепридумать, как было бы правильно сделать с самого начала.

Этот список можно продолжать бесконечно, но, я думаю, суть вы уловили.

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

Написать свою OS? Меня этим троллят примерно раз в месяц, и, кстати, я бы запилил неплохую OS(как-нить надо написать, как бы она была устроена). Проблема только в том, что современное(на данный момент времени) графическое приложение я там запущу лет через 15, и то, если сильно не объебусь с архитектурой и инструментами.

Я себе это представляю довольно точно, можно просто посмотреть на динамику развития Linux, и экстраполировать ее исходя из:

* взять нормальный язык, чтобы писать раз в 10 быстрее, чем это делают разрабы Linux

* взяв нормальные архитектурные принципы построения ядра

https://www.opennet.ru/opennews/art.shtml?num=57260 - цифры про размер ядра.

Я так примерно понимаю, что Linux стало норм где-то в районе 2.6, 5 - 10 MLOC. Если взять нормальный язык, надо настругать где-то 0.5 - 1 MLOC.

В общем-то, все предсказуемо, и очень грустно.

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

Например, запилив демон, который прибивает все прибившиеся к init orphane process, постепенно и инкрементально.

Например, отказавшись от динамической линковки и от dll hell, как КЛАССА проблем.

Как это запилить в той же Fedora - это убиться же можно.

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

Из всего вышесказанного следует:

* совершенно бессмысленно меня спрашивать, "почему не systemd"

* "почему не ostree"

* "почему ...

Я пытаюсь как-то по другому решить известные мне проблемы, это исследовательский hobby дистрибутив, а не конкурент для RHEL на его поле.

Если меня устраивает systemd и dll hell, я возьму Fedora, и не буду париться.

Мне же интересно "а как, вообще, можно иначе".

#stal/IX, часть вторая, почему я делаю так, а не иначе. #gold

* Структура директорий.

Тут все довольно просто, я не понимаю, как сейчас можно пилить новый дистрибутив по LSB/FHS https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Это какое-то жуткое legacy, оставшееся с времен начала Unix, с кучей слабо решаемых проблем(dll hell, атомарные обновления(ostree - это хак, и не уговаривайте в обратном)).

FS должна представлять из себя content adressable storage, по типу git/nix/guix.

Так мы получаем почти бесплатно, just to name a few:

- мультиверсионность

- быстрые накаты и откаты

- атомарные апдейты(переключение всей конфигурации - переключение 1 symlink)

- бесплатное кеширование сборочных артефактов в пакетной системе

- non-root/user package management. Это прямое следствие из content adressable storage.

* Функциональное управление конфигурацией.

Речь идет про то, что, фактически, содержимое etc/ определяется рядом настроек #realm, и описанием пакетной базы.

Руками в etc/ лезть нельзя, оно генерится скриптами подготовки #realm, и вообще, read-only.

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

* Static linking

https://gavinhoward.com/2021/10/static-linking-considered-harmful-considered-harmful/ - хороший текст с summary, почему основные предъявы к статической линковке не выдерживают серьезной критики.

https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/ - я думаю, что вы уже поняли, что я считаю Линуса еще тем упырем, но враг моего врага - мой друг.

- tooling для нее все еще лучше, потому что она простая, как 5 копеек

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

- получившиеся бинари, несмотря на некоторое дублирование объектного кода, быстрее.

- FS чище, нет лишнего мусора, я про каждый файл могу сказать, что он у меня делает. В том же nix/guix могут быть десятки вариантов одной и той же библиотеки, это ungrepable лапша.

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

- личный фактор

Я последние лет 15 насаждаю статическую линковку в Я, и, в целом, преуспел в этом.

Я имею амбицию показать миру, что на основе этой модели можно получить полноценный, не игрушечный, дистрибутив. Игрушечные, типа stali, oasis, и так далее - это, простите, школьная поделка на фоне того, что уже сделал я.

* Здоровый минимализм. Я хочу иметь возможность обозреть всю систему.

No code bloat, no systemd, no pipewire(?), etc

In general, no vendor lock on RedHat/IBM software.

Красношляпые очень хотят залочить экосистему Linux на себя. На systemd, на gstreamer, как на часть pipewire, etc.

Не вижу в этом ничего хорошего, да и возможности понимать, как работает система, весь этот софт мешает.

Я тут совсем коротенько отмечу, что я не против, если кто-то сделает вариант stal/IX поверх systemd, я этому не мешаю, и даже готов помочь.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/dbus - поштырьте на эту папку, у меня даже runit скрипты не являются частью основного пакета, чтобы можно было параллельно иметь systemd/s6/etc юниты.

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-1.21-Alpha

Красивое про wayland.

"Two years after the merge request was originally opened, the upcoming Wayland 1.21 release is adding high resolution scroll wheel support for mice to match the work carried out for X.Org and within the Linux kernel drivers. "

Two years.

Не помню, писал ли я это уже, но, КМК, в open source вовсю цветет "трагедия маленького человека, получившего небольшую власть", он же "синдром вахтера".

———
https://lwn.net/Articles/896153/

Это статья про сложность разработки ядра Linux.

Напомню, что есть два вида сложности - inherent complexity, и incidental complexity.

inherent complexity вот этой вот задачки из текста статьи - добавить pure virtual function в интерфейс к FS. Казалось бы, на пару дней для стажера.

Но incidental complexity, которая появилась в этой задаче благодаря нескольким идефиксам Линуса(С вместо С++, очень редкие рефакторинги ядра), потребовала встречи большого количества людей на какой-то конфе.

И эти большие и важные люди целый час обсуждали, как половчее добавить pure virtual function в интерфейс FS.

Текущая модель разработки ядра #linux зашла в тупик, она требует кратных усилий для решения простых задач.

———
https://bethesignal.org/blog/2011/03/12/the-libappindicator-story/

Интересный исторический текст про взаимодействие canonical и redhat(GNOME), в контексте панели уведомлений.

И почему я не удивлен? GNOME во всей своей красе.

———
https://formulae.brew.sh/formula/argp-standalone

Я, давеча, писал, что одна из задач дистростроителя - найти каноничное место с исходником, и использовать его.

У библиотечки arg-standalone(это кусок glibc для парсинга command line options, для non-glibc linux) их ажно целых три:

1) https://www.lysator.liu.se/~nisse/misc/ - оригинал

2) https://github.com/ericonr/argp-standalone - форк, продолжение

3) https://github.com/argp-standalone/argp-standalone - коллеги из freebsd устали, что автор 2) поклал хер на библиотеку, форкнули ее, и продолжают патчить

Все 3 используются, в разных контекстах, разными дистрибутивами.

Кто прав, кто виноват, на кого положиться - непонятно. Я взял версию от freebsd, они ребята чоткие.

Про #stal/IX, часть третья. #gold

Про устройство пакетного менеджера.

У меня, по большому счету, было 3 итерации к устройству пакетного менеджера.

* Пекеты представляли из себя описание на языке Python, выполнитель графа для каждой ноды запускал python, который выполнял этот код. Примерно так же устроен homebrew, только там ruby.

Очень быстро я понял, что python совершенно не подходит для этой задачи:

- Он абсолютно не composable, нельзя сконкатенировать 2 скрипта, и получить работающий скрипт, из-за того, что в python важно выравнивание и индентация. Поэтому задача "а вот возьми этот скрипт, и замени там build фазу на вот такую" была совершенно нерабочей.

- Вторая причина общая как для ruby, так для python, так и для всего, кроме posix sh. В этих языках приходится изобретать какой-то dsl, для описания простых действий, которые в shell деллаются простыми командами:

os.setcwd('xxx')
a = os.environ['yyy'] + '/zzz'
os.setcwd(a)

vs

cd xxx
cd ${yyy}/zzz

Короче, этот DSL выглядел всрато, и я совершенно точно не хотел отдавать пользователю это.

* Вторая итерация - сборочные скрипты в стиле Arch, с метаинформацией в комментариях:

# url https://a.b/c.tgz
# dep lib/c lib/c++
# bld bin/make

build() {
    make -j 8
    ...
}

...

Это было уже лучше, но:

- Задача "возьми вот этот сборочный скрипт, и немношк поменяй в нем build() или список зависимостей" все еще не решалась разумным образом, поэтому цепочка bootstrap содержала в себе много лишнего кода. Ну, типа, приходилось копировать сборочное описание для сборки cmake на самых ранних стадиях, когда еще ничего нет, или уже для более поздних стадий, когда доступен предыдущий cmake и библиотеки.

- Тут меня уже начинало напрягать, что приходется повторять один и тот же boilerplate для вызова meson/cmake/etc. Надо сказать, что, тот же Arch, может звать cmake напрямую. А мне нужно передать 100500 параметров, для того, чтобы обеспечить статическую сборку, и nix-style пути в файловой системе(короче, DESTDIR и PREFIX не по умолчанию)

* В этот момент у меня появилась jinja - язык для описания и подстановки шаблонов, и пакеты стали выглядеть так, как они выглядят сейчас.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/kitty - посмотрите, в t/ лежит шаблон, который специализирует общий шаблон для какой-то сборочной системы, и два его наследника - linux/, darwin/. Посмотрите их перед чтением следующих пунктов.

Тут важно понять, что из этого шаблона строится не shell script, а json, в котором лежат кусочки шелл скриптов для разных фаз(build, configure, etc) сборки, и списки зависимостей.

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

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

Примеры:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/brotli/ix.sh#L7 - а собери-ка мне brotli, но с расширенным списком библиотек, потому что я собираю не либу, а бинарники.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/curl/bleed/ix.sh - а собери-ка мне curl, но с другой http3 библиотекой, и исходниками посвежее.

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/gdbm/ix.sh - а собери-ка мне бинарник от libgdbm, и добавь к нему readline(обратите внимание, расширяем не только список библиотек, но и configure флагов)

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/cmake.sh#L43 - базовый шаблон для cmake, посмотрите, сколько я там делаю приседаний, от передачи путей к компилятору, до замены SHARED на STATIC в CMakeLists.txt - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/cmake.sh#L81 Благодаря этому, мои сборочные файлы, которые видит пользователь, lean and mean, там только информация по сути вещей(зависимости), а все эти приседания скрыты от пользователя.

Лиха беда начало, в какой-то момент времени мне стало понятно, что шаблонизатор очень легко решает задачу произвольной настройки сборки того или иного таргета.

./ix build bin/xxx --allocator=mimalloc 
    --nostrip --buildtype=debug --opt=O0

Вот тут нет НИ ОДНОГО флага, который бы обрабатывался самой системой сборки, это все флаги, которые напрямую пробрасываются во все шаблоны*, и настраивают их поведение:

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/c/alloc/ix.sh#L4 - —allocator=

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/build/opt/ix.sh - —opt=

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/die/std/postinstall.sh#L34 - —nostrip

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

* - на самом деле, не на все собираемое дерево, а по хитрому алгоритму - на все зависимые библиотеки, и на все зависимые бинари, ЕСЛИ у таргета нет build script. По сути, всегда все прокидываем для hub-целей.

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

И не пришлось изобретать никакого всратого языка, как там в nix, или не пришлось застрять в модели шелл-скрипта, как в Arch.

#gold

Много раз жаловался, какой же в Linux херовый #scheduler, что он не может нормально пошедулить браузер во время фоновой нагрузки.

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

Я добавил в систему #ananicy, чтобы можно было регулировать всякими интересными настройками для выполняющихся программ - rt prio, nice, etc.

Я настроил параметры для самых важных программ в меру своего разумения, что такое RTOS, и как должен работать RT scheduler.

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

Задача RTOS - не в том, чтобы выполнить вашу задачу максимально быстро, а в том, чтобы выполнить ее за предсказуемое время. Это значит, что, обладая доступом к исходникам, вы можете заранее рассчитать, сколько времени будет занимать тот или иной блок кода.

Задача эта часто противоречит задаче "выполнить заданный код наиболее быстро в среднем"(собственно, это то, что хотят от OS жадные капиталисты в датацентре), и поэтому RTOS и просто OS - это, обычно, разные продукты.

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

Решается эта задача, если очень грубо:

* Очень простой шедулер. У каждого процесса/треда есть свой приоритет, если в очереди на выполнение есть процесс с бОльшим приоритетом, чем тот, что сейчас выполняется, то выполняемый процесс вытесняется в пользу более приоритетного. В целом, этого уже почти достаточно, чтобы код работал предсказуемо.

* Некоторое расширение модели выше - когда OS делает асинхронную задачу в рамках ядра для какого-то процесса, она должна эту задачу во все свои внутренние очереди тоже класть с приоритетом процесса, которой ее заспаунил. Короче, таска в io queue должна иметь приоритет своего процесса, чтобы io тоже был приоритезированным.

* Priority inversion, priority inheritance. Тут все просто - если процесс с бОльшим приоритетом залочился на mutex, которым владеет процесс с меньшим приоритетом, то надо на время забустить приоритет этого процесса до максимального значения из приоритетов всех процессов, кто хочет этот mutex. Вроде, примерно понятно, зачем это надо, не буду вдаваться в подробности.

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

Короче говоря, я разметил все процессы в системе, имея вот это свое понимание, что такое RTOS, и как оно должно работать:

* Композитор имеет класс FIFO, потому что композитор - эта такая штука, которая ничего сама не делает, и только диспатчит сообщения через pipe. Я, опять, долго объяснять не буду, просто подумайте, нужно ли вообще такому процессу иметь возможность быть rescheduled посреди акта своей работы. Мой ответ - нет, не может, это приведет к увеличению latency всей системы, без влияния на throughput.

* По тем же причинам я поставил FIFO для звукового демона, и для dbus брокера.

so long, so good.

Так же я выставил RR класс для web process и gui process браузера epiphany.

* FIFO - это очень простая и понятная штука, тред с FIFO классом выполняется строго по правилам, которые я описал выше.

* RR - это какое-то не до конца мне понятное изобретение в теме, потому что RR класс говорит нам, что RT задачи с одинаковым приоритетом будут обрабатываться через round robin subscheduler. Я думаю, что вы уже поняли, что я считаю такую трактовку RT несколько легкомысленной, потому что что это за херня - задачи с одинаковым приоритетом в RT системе?

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

(продолжение)

И, знаете, эта система приоритетов работала настолько хорошо, что я уже было собрался писать победный пост, как я загнул #scheduler, и у меня все работает плавнее, чем в macos. Кстати, похвастаюсь, что, без нагрузки это УЖЕ так, помогли все мои облизывания и политик шедулинга, и тюнинг аллокатора, и так далее.

Но, конечно, Linux и тут себя показал в своей красе, и это какой-то леденящий душу пиздец.

Я не буду утомлять подробностями #debug, просто расскажу, что происходило.

- я запускал сборку чего-то тяжелого, оно насыщало все CPU.

- в этот момент заходил на сайт с зависшим JS, процесс браузера(который, напомню, RR) начинал жрать 100% CPU.

В этот момент начинал срабатывать какой-то сраный код в ядре, который позволял загруженному на 100% RR треду периодически прерывать выполнение FIFO треда от композитора. Даже на самом деле слегка не так, система ограничила сверху время для FIFO + RR задач в какой-то процент от CPU, что привело к тому, что FIFO задача иногда reschedule посредине своей работы.

В этот момент появлялась какая-та всратая фраза в dmesg, про включение тротлинга, погуглив которую я и узнал, что это just as planned. Ну, то есть, долбоебы-разработчики позаботились о том, чтобы FIFO тред не мог съесть весь CPU, несмотря на то, что я попросил именно это.

Ссылку не дам, потому что затерялась, а восстанавливать весь setup сейчас лениво. Самое близкое, что нашел - https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/tuning_guide/real_time_throttling

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

Если вы внимательно прочли мое описание RTOS, то должны согласиться, что такое поведение неприемлемо для RT системы, и, если бы система вела так, как заявлено, то такого эффекта бы не возникало.

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

Короче, TL;DR - выставил я nice для браузера вместо RR, оно, конечно, лучше, чем без nice, но даже и рядом не стояло с правильным, нужным мне, поведением.

#scheduler я пока не победил, но все еще не отчаиваюсь!

Я думал, что больше всего на свете я ненавижу людей, которые включают -Werror в своем проекте. #werror

Но, вдруг, оказалось, что есть грех и посерьезнее, а именно, включить -Werror в configure скрипта своего проекта:

checking for boost/spirit/
    include/classic.hpp... no

Причина:

:216:64: error: declaration shadows 
    a field of 'subrule_parser<ID, DefT, 
    ContextT>' [-Werror,-Wshadow]
    operator,(subrule_parser<ID2, DefT2, 
    ContextT2> const& rhs) const

/mix/store/EXZAWbJZCAHZ5qTY-lib-boost/
    include/boost/spirit/home/classic/
    core/non_terminal/subrule.hpp:229:32:
    note: previous declaration is here

typename DefT::embed_t rhs;

———
https://mazzo.li/posts/fast-pipes.html

Интересный текст про передачу большого объема данных через пайпы.

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

———
Интересное наблюдение - просмотрщики картинок редко когда зависят от imagemagick/graphicsmagic/freeimage/etc.

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

90% кода просмотрщика изображений - это фабрика, врапающая загрузку разных форматов в вектор rgb значений.

Моя теория заключается в том, что "так не интересно".

Люди любят OSS, потому что люди любят низковисящие фрукты(в прямом и переносном смысле), а в OSS легко заняться именно низковисящими фруктами.

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

А тут написал вечером загрузку png вдобавок к jpg - у тебя сразу программа в 2 раза лучше стала!

А если добавить поддержку IM, то поле для вкусных и недорогих улучшений сразу и пропадет.

Кстати, КМК, это одна из причин популярности новых языков типа Rust/Go. Они, конечно, лучше, чем старые, а еще там непаханое поле по разработке http сервера.

Это же круто - запилить сотую aio библиотеку, и получить 100500 звезд на гитхабе!

Я тут ничем не лучше, потому что вкусные фрукты вида "написал 5 строк кода, и у тебя в шедулере графа поддержка памяти и CPU ограничений" манят сильно.

https://discourse.llvm.org/t/upcoming-project-policy-changes/62637

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

* https://discourse.llvm.org/t/upcoming-project-policy-changes/62637/4

"Users may not be a convicted sex offender or listed on any US state or federal sex offender registry (or other country equivalent)"

ЖЫР, LLVM решили взять на себя функцию суда.

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

Пока они не решили обсудить фуррей, и не стоит ли их тоже забанить. Нет, really.

https://discourse.llvm.org/t/upcoming-project-policy-changes/62637/14

Я из этого топика узнал, что FurryCon - это такое место, куда съезжаются все фурри, и, на afterparty, снимают все ближайшие отели, и чпокаются там в свое удовольствие.

Но в программе это не объявлено, потому что туда приезжают родители с детьми.

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

Кстати, движение furry мне в чем-то близкО, потому что я(как, я уверен, и ты, аноним!), конечно, в молодости фапал на Гаечку, и у меня даже был соответствующий плакат, с Гайкой, Чипом, и Дейлом, если вы понимаете, о чем я.

Тот факт, что, по версии Диснея, Гайка родила 42 ребенка от Вжика, конечно, разбил мне сердце.

https://daily.afisha.ru/infoporn/23121-urodlivyy-sonik-i-42-rebenka-gayki-i-vzhika-fanatov-shokirovalo-prodolzhenie-chipa-i-deyla/