https://nixcademy.com/2023/10/31/cpp-with-nix-in-2023-part-1-shell/

Продолжение темы про использование #ix/nix/guix в качестве dev окружений. #dev_shell #ix_run

Мне мой "ix run", конечно, кажется более простым и лаконичным, чем то, что по ссылке, но, все равно, и то, и другое, - много лучше альтернатив.

Важное отличие #ix от nix/guix - мои артефакты можно невозбранно использовать в любом Linux, а не только там, где есть подходящий store с сотней .so-шек.

#bug12309

Слушайте, а вы обратили внимание, что, "тихо и незаметно", 12309 таки починили?

Я это связываю с внедрением MGLRU - https://www.kernel.org/doc/html/next/admin-guide/mm/multigen_lru.html

Вообще, удивительно, механизм делали чтобы починить 12309, и он его таки и чинит - довольно необычно в kernel community. Наверное, потому что это запилил Google, а не какой-нить рандомный васян.

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

https://www.phoronix.com/review/bcachefs-linux-67 #Kent

А вот подоспели бенчмарки #bcachefs от Михаила.

(напомню, что его бенчмаркам веры нет - https://xn--r1a.website/itpgchannel/1402, но, думаю, для троллинга автора bcachefs они сойдут)

Спойлер - у bcachefs все не очень, как с перфом (последние места на почти всех нагрузках), и с надежностью (не любой ssd можно под нее отформатировать).

Зато этот бенчмарк подтверждает мой старый тезис - "#xfs - лучшая FS в Linux". Вот, реально, не знаешь, что выбрать - выбери #xfs.

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

"Опубликован репозиторий OpenELA для создания дистрибутивов, совместимых с RHEL"

А вот это, КМК, знаковое событие.

Потому что чем сильна RHEL, и centos (ранее)?

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

Понятное дело, что на все там Генты и прочие #stal/IX сил у вендора не хватит, и он выдаст его на два самых популярных дистрибутива (догадайтесь, каких).

Теперь же ситуация может радикально поменяться - будут выдавать сертификат на вот этот вот OpenELA (or compatible), с которым будет совместим много кто.

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

https://mjg59.dreamwidth.org/68350.html

Хороший текст про ACPI, зачем это, и с чем его едят.

TL;DR - это набор хуков на некотором интерпретируемом байткоде, которые может дернуть OS, чтобы firmware сделало что-то для OS.

В целом, ACPI очень позитивно сказалась на портабельности Linux на новое железо.

КМК, это хорошо коррелирует с темой, которую я загонял в цитируемом посте (https://xn--r1a.website/itpgchannel/218), что, мол, Linux-у отведена роль реализации POSIX API поверх черного ящика, которое обеспечивает настоящая, bare metal, OS (firmware), которую Linux будет дергать вот такими вот "ACPI"-подобными хуками.

Будни #bootstrap, #rant

Вышла новая elfutils - https://sourceware.org/elfutils/.

Ну вышла и вышла, с кем не бывает.

Как обычно, авторы гнутых тулчейнов делают вид, что, кроме gnu, в этом мире ничего и нет:

checking for __cxa_demangle in -lstdc++... no
configure: error: __cxa_demangle not found 
    in libstdc++, use --disable-demangler 
    to disable demangler support.

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

И не рассказывайте мне, что они там про это не знают, или что более хороший тест на проверку наличия написать сложнее. Знают, не сложнее, просто им наличие альтернативы в мире open source - как кость в горле.

Конечно, приятнее быть the open source toolchain, а не одними из многих, с которыми нужно договариваться.

Починил я это так - https://github.com/pg83/ix/blob/main/pkgs/lib/elfutils/t/ix.sh#L23 Я уже давно перестал патчить исходники про такое. Ну вот хотят люди libstdc++ - ну получат они пустую фейковую библиотеку, а функция появится из другого места.

elfutils эти, кстати, сломанные, с ними не собирается ядро Linux, пришлось откатить.

https://lwn.net/Articles/947941/

TL;DR - groff (это штука типа tex, только в реальной жизни ее используют для форматирования man pages), однажды очень давно сделали очень правильную вещь - The specified behavior of groff is that an ASCII "-" (Hyphen-Minus) in the input becomes a Hyphen in the output. Это не соответствует поведению оригинальной программы, с которой слизали groff.

Но вот ее текущему мейнтейнеру пришло в голову взять, и отменить это поведение.

Это, очевидно, поломало кучу man pages, потому что вы копируете оттуда "--help" в терминал, и у вас ничего не работает.

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

Автор изменения, конечно, редкостный #errogant мудила, потому что сделал это он, мол, потому, что хотел, чтобы в groff корректно рендерилось какое-то говно мамонта - https://github.com/g-branden-robinson/retypesetting-mathematics, а на то, что это изменение literally ломает тысячи man страниц, ему аще похуй.

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

Думаете, преувеличиваю?

Нет, все ровно так:

"If a person sits down to write a man page from scratch in a text editor, they will have things to learn, and in my opinion the hyphen/minus distinction is one of them. (As the original article suggested, there are in fact four other "ASCII" glyph distinctions to learn about.)
The theme of audience is also applicable to why I made this change in groff upstream. The GNU Project generally releases source archives, not binary packages. The primary consumers of groff releases from GNU are therefore, I would expect, people who already know of the package and desire to obtain it"

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

Короче, в комментах ЖЫР, не упустите!

https://blog.vaxry.net/articles/2023-inclusiveActivists #gold

Совершенно крутой текст от Vaxry.

TL;DR - коллега написал, что настоящая инклюзивность - это когда, если Адольф Гитлер пишет нормальный код на С++, то его вкладу могут быть рады в open source проекте. Его за это, конечно, назвали фашистом, и он в ответ накатал этот текст.

Inclusive communities, in the eyes of such advocates, are often the opposite of inclusive. They will try and find things that you do outside of your proffessional persona, or often infer, guess, meddle with, or lie about what you say and stand for. Then, once they have the "ammo", they will ostracize you. Ban, kick, call for removal, censorship.

...

I firmly believe that FOSS is literally for everyone. Unlike those people, I stand by my stance that even if you are something that the country I live in disagrees with, you still are free to use, contribute to, and be a part of the greater FOSS community.

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

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

Будни #bootstrap

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

Я этот "кубик" оформил в удобном для применения виде:

pg@...:~/ix ./ix build bld/python/frozen \
    --python_ver=12 \
    --py_extra_modules=lib/py/wayland
pg@...:~/ix /ix/store/.../bin/python3
Python 3.12.0 (main, Nov 6 2023) ...
>>> import pywayland
>>>

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

Это мне позволило замахнуться на модули, использующие cffi модуль!

Вообще говоря, cffi - страшная жесть: https://github.com/flacjacket/pywayland/blob/main/pywayland/ffi_build.py Разработчики "pure python" модуля копипастят к себе определения нужных им C функций, после чего модуль cffi парсит это говно, вызывает конпелятор, и дает на выходе .so-шку, которую можно загрузить в python, и дергать функции какой-то внешней (оборачиваемой таким образом) .so-шки.

Собственно, мне нужно было научиться собирать в статику оба этих "уровня абстракции".

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

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

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

https://github.com/pg83/ix/blob/main/pkgs/lib/py/wlroots/t/ix.sh#L17 - например, для сборки pywlroots мы готовим питон, в котором есть модуль cffi, и уже заранее собранный модуль pywayland.

Короче, получился очень удобный кубик.

Зачем я ебался со всеми этими сложностями?

Мне очень нужен был https://qtile.org/! И он у меня теперь есть!

А вот зачем он мне нужен - в следующей серии.

#qtile

Собственно, в https://xn--r1a.website/itpgchannel/374 я как-то обмолвился, что очень хочу запилить нечто под названием "scrollable tiling wm".

Мысли этой не первый год, в первый раз я про это задумался лет 5 назад. Но, как я уже писал выше, ничего подходящего для этого не было и нет, если не рассматривать JS plugin к mutter. А я не рассматриваю, потому что этот всратый JS в mutter я буду запускать дольше, чем запилить новый кленовый wlroots.

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

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

Собственно, я потихоньку пилил инструменты, чтобы собрать static qtile, и недавно у меня это получилось.

А теперь самая мякотка!

BayanWM (от слова "аккордеон", а не то, что вы подумали) я запилил, как кастомный layout engine для qtile, за один вечер - https://github.com/pg83/bayanwm/blob/main/config.py#L49-L134 Работает оно превосходно, даже лучше, чем я ожидал. Попробуйте, скопипастить это в свой конфиг qtile займет 5 минут.

Респект и уважуха проекту за подход к конфигурированию, когда конфиг - это, по сути, плагин, которому доступна вся внутренняя механика проекта.

Мораль?

Любую задачу можно запилить за 15 минут и 100 строк кода, если знать, куда тюкнуть!

(технический пост, не думаю, что это особо интересно, скорее, запись для себя)

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

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

https://github.com/pg83/ix/tree/main/pkgs/bin/kitty/prev - вот тут я прикопал старую сборку
https://github.com/pg83/ix/tree/main/pkgs/bin/kitty/next - а вот тут новую

Отдельных папочек (целей) стало больше, каждая цель стала описываться проще.

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

Новый вариант - это, по сути, 10 раз запустить родную сборку (это быстро), взять маленький ее кусочек, поработать с ним, и подготовить его к тому, чтобы моя generic машинерия могла с ним работать:

* https://github.com/pg83/ix/blob/main/pkgs/bin/kitty/next/modules/glfw/ix.sh - вот так я готовлю какой-то произвольный .so от родной сборки kitty
* https://github.com/pg83/ix/blob/main/pkgs/bin/kitty/next/modules/fdt/ix.sh - или другой. По папочке на каждый модуль, но там и код не очень обобщаем
* https://github.com/pg83/ix/blob/main/pkgs/bin/kitty/next/py/ix.sh - а вот так готовлю его питонячку, чтобы дальше мочь ее заморозить своим generic механизмом
* https://github.com/pg83/ix/blob/main/pkgs/bin/kitty/next/unwrap/ix.sh#L21 - а вот так выглядит переписанный entry point для kitty, в котором я его манкипатчу на предмет wayland, no x11, другой способ подморозки произвольных ресурсов, и так далее

В общем, оно получилось гораздо более composable, и переживет следующие upver существенно проще.

Первый способ у меня занял в 5 - 10 раз больше чистого времени.

Мораль?

Некоторые вещи нужно делать не когда очень хочется, а когда ты к этому готов!

Fun fact - #Ковид начала переписывать kitty на Go, я бы на его место тоже так сделал, потому что сейчас kitty - это unmanageable mess.

началось?