https://lxqt-project.org/blog/2024/02/15/qt-6-and-wayland/
https://www.opennet.ru/opennews/art.shtml?num=60625

Ня какая новость!

LXQT едет на QT6, и быстрыми темпами собирается переезжать на Wayland.

Это, конечно, хорошо, потому что LXQT - самый вменяемый из "младших" линуксовых DE. Без изысков с #kparts, из-за которых я не кочу тянуть KDE, и без глобальных идей о том, как мне пользоваться моим компьютером (привет, #GNOME).

Полноценной DE у меня пока нет, потому что затащить целиком GNOME, или KDE, я пока не представляю возможным (не потому что сложно или лень, а потому что, например, много запчастей от GNOME не могут собраться без Xorg), но, надеюсь, масштаб LXQT позволит ей отказаться от наследия X чуть быстрее, чем старшим товарищам.

Инструментарий от проекта #GNU - всратое, забагованное, говно. #gold

Его единственное достоинство - что оно было (ну, то есть, существовало) в тот момент, когда больше ничего другого и не было.

Я уже несколько раз про это писал, соберу все ссылки в одном месте:

https://xn--r1a.website/itpgchannel/585 - свежий awk ломает сборку ядра

https://xn--r1a.website/itpgchannel/1133 - свежий grep ломает вообще все, до чего дотягивается

https://xn--r1a.website/itpgchannel/220 - ed от проекта GNU не может собрать bc от проекта GNU, а bc от проекта GNU не работает для сборки ядра Linux

https://xn--r1a.website/itpgchannel/1432 - groff от проекта GNU ....

https://xn--r1a.website/itpgchannel/1233 - make от проекта GNU ...

(еще у меня была история про sort от проекта GNU, но я не могу ее найти в бездне)

Вот, у меня пополнение историй успеха сборочного инструментария от проекта GNU, назовем эту серию "patch от проекта GNU".

Наткнулся я на нее, когда собирал патченый под QT6 KeePassXC (https://xn--r1a.website/itpgchannel/1643)

Там коллега учудил, и, вместо github branch, оформил все в виде одного большого patch.

Собственно, при наложении этого патча у меня и случилось красивое:

patch: **** Can't rename file \
    HibpDownloader.cpp.oq4YS9V to \
    HibpDownloader.cpp \
    : No file descriptors available

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

Имея опыт взаимодействия с GNU toolchain, я это дело творчески закостылял - сам распилил diff на кусочки, и применил их с помощью того же patch, но по одному:

https://github.com/pg83/ix/blob/main/pkgs/bld/patch/patcher.py#L26-L27

Мораль?

По возможности, держитесь от кода от проекта GNU как можно дальше.

Продолжаю тему "rust всего лишь немного более memory safe, чем С++" (https://xn--r1a.website/itpgchannel/1641)

https://github.com/Speykious/cve-rs

#безопастный_rust

cve-rs has safe implementations \
  of the following bugs:
  Use after free
  Buffer overflow
  Segmentation fault

Лицензия тоже доставляет:

https://github.com/Speykious/cve-rs/blob/main/LICENSE

https://www.phoronix.com/news/Zink-NVK-For-NVIDIA-OpenGL #NVK

собственно, в копилочку наблюдений про #zink как основной драйвер для #opengl

https://ardour.org/whatsnew.html
https://www.opennet.ru/opennews/art.shtml?num=60638

Тут вот проект ardour пишет, что они завендорили себе gtk2.

Ссылка в новости ведет в https://github.com/Ardour/ardour/tree/master/gtk2_ardour, но там кода gtk2 нет, а есть он в https://github.com/Ardour/ardour/tree/master/libs/tk - они его еще и переименовали.

Поддержки wayland в gtk2 не было, и не будет.

Поэтому, конечно, интересно, о чем думали разработчики, и что они собираются делать long term.

Впрочем, понять их можно, потому что gimp вон до сих пор мигрирует с gtk2 на gtk3 (https://www.gimp.org/news/2024/02/21/gimp-2-99-18-released/). А inkscape, видимо, навсегда застрянет на gtk3.

Потому что авторы основных тулкитов для Linux - упыри, и вообще не понимают, что такое обратная совместимость.

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1445064-ardour-8-4-digital-audio-workstation-still-relying-on-gtk2-adds-aaf-import?p=1445108#post1445108

Оказывается, разработчики хорошо подумали головой, и:

* с gtk они съезжают

* большинство их виджетов и так самопальные, и к gtk отношения не имеют

Q: "Does this mean native Wayland support will come in the future?"

A: No plans for Wayland support. Doing the work will get our users nothing, more or less.

Такие дела.

Довольно техническая тема сегодня.

Я уже как-то рассказывал, как я из "грязных" входных данных делаю "чистые".

Грязный ввод - это, скажем, git checkout, или cargo vendor, или что-то в этом роде. Короче, куча файлов, которые скачиваются по сети, и, в общем, ты для них заранее ничего не можешь сказать.

Грязные данные нельзя делать вводом "чистого" алгоритма, потому что его результат - непредсказуем, невоспроизводим.

Поэтому я все такие данные кладу в один большой архив, в определенном формате, считаю его хеш, и, после этого, данные становятс "чистыми". Потому что если я заранее знаю хеш от полного git checkout/cargo vendor/etc, то, значит, я зафиксировал результат работы "грязного" кода. Если же хеш не совпал, то сборка останавливается.

И я, если честно, задолбался с форматом этого архива.

Потому что мне не захотелось велосипедить, и я решил, что у меня получится файлы после сырого git clone/cargo vendor/etc привести к такому состоянию, что tar.gz от них на разных хостах будет одинаковый.

Я прошел несколько итераций улучшений этого процесса:

* umask на разных машинах разный, поэтому после закачки надо приводить его к общему виду

* timestamp у всех файлов, очевидно, надо выставлять в одно и то же число

* gid/uid файлов сохрнанять нельзя, потому что он зависит от пользователя, от которого ты все запустил

* все rw права надо переделывать в ro, а после распаковки - снова не забыть в rw, потому что можем захотеть пропатчить результат

Но больше всего проблем мне доставили симлинки.

Симлинки для воспроизводимого сохранения в tgz - это какой-то звиздец. Потому что:

* Просто так удалить все симлинки из дерева - не вариант. Чаще всего они не нужны, но не всегда.

* А они могут вести на dangling file, и tar может выкинуть их к хуям во время компресии, если не знать про правильные ключи. А еще у тебя на одном хосте это будет dangling link, а на другом - нет.

* Права доступа к симлинкам vs файлам, на которые они указывают.

* Влияние umask при их создании. Я, кстати, так и не понял логику за этим процессом, и это стало последней каплей, когда я решил свести задачу к существующей.

Я сам сериализую все симлинки в отдельный файл перед запаковкой, удаляю их из упаковываемого дерева, и восстанавливаю после распаковки:

https://github.com/pg83/ix/blob/main/pkgs/bld/stable/pack/store_links
https://github.com/pg83/ix/blob/main/pkgs/bld/stable/unpack/restore_links

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

Любители nix меня спросят, почему не взять готовый nar (https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-nar)?

Давайте я вам просто покажу код по сериализации в nar:

https://github.com/ebkalderon/libnar/blob/master/src/ser.rs#L31-L71

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

Так, я нашел время обновиться на #mesa v. 24, перейти на использование ACO вместо LLVM, для компиляции шейдеров, и даже замерил экономию в размере получающихся программ:

llvm:

pg# ls -la .../bin/imhex
157265936 Jan 1 2000 imhex

aco:

pg# ls -la .../bin/imhex
88756648 Jan 1 2000 imhex

Очень и очень немало, почти 70 мегабайт разницы, вот столько весит используемый оптимизатор из LLVM.

Программисты В С Ё, во всяком случае так считает глава NVIDIA Дженсен Хуанг.

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

Скинь тому самому 300к-сеньору

О чем я тут пишу:

https://stal-ix.github.io/

https://xn--r1a.website/itpgchannel/20
https://xn--r1a.website/itpgchannel/376
https://xn--r1a.website/itpgchannel/377
https://xn--r1a.website/itpgchannel/379

А я, тем временем, занялся автоматизацией своей home #lab.

Моя home lab - это 3 сервера, в которых примерно 200 ядер, + 3 - 4 небольших нод, которые сделаны из всякого хлама, скопившегося за несколько лет.

Понятно дело, что все это и так крутится под #stal/ix, но, до сего момента, все это выглядело так - я руками ставил OS на машину, а дальше заходил на нее через ssh, и руками вводил какие-то команды, которые что-то делали с этой машиной.

Конечно, можно было бы взять что-то готовое, но:

* нужно есть свою собачью еду.

* https://en.wikipedia.org/wiki/Content-addressable_storage - очень хорошая основа для всякого там IaC, и мне хочется сделать еще один подход к этому снаряду.

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

* Ручная наливка хоста заканчивается тем, что мы удаляем set/stalix из system #realm, и ставим туда почти то же самое, но с автоапдейтом.

* Автоапдейт занимается тем, что "приводит систему к состоянию", которое указано в каком-то заранее определенном репозитории.

Состояние - это набор пакетов, заданное состояние - это набор пакетов, который описан в какой-то конкретной версии репозитория.

https://github.com/pg83/lab - вот код, который полностью описывает состояние моей home lab.

Он состоит:

* Fork stal/IX, который я периодически сливаю с upstream.

* Одна точка входа, тот самый пакет, который содержит ссылку на auto updater, и на пакеты, которые должны стоять в системе - https://github.com/pg83/lab/tree/master/pkgs/lab https://github.com/pg83/lab/blob/master/pkgs/lab/ix.sh#L7

Я его устанавливаю на каждый хост, он ставит:

* сам auto updater. https://github.com/pg83/lab/blob/master/pkgs/lab/services/autoupdate/scripts/ix.sh - простой скрипт, который в цикле забирает новое состояние с github, и приводит систему в соответствие этому состоянию.

* пакеты, которые должны быть на каждом хосте

* и диспетчер, который ведет на список пакетов, уникальный для хоста - https://github.com/pg83/lab/blob/master/pkgs/lab/ix.sh#L6

Вот, например, список пакетов для "host1" - https://github.com/pg83/lab/blob/master/pkgs/lab/hosts/host1/ix.sh. Видно, что он крутит мой ci, и какую-то ерунду, про которую расскажу в другой раз.

Так, я на вас вывалил некоторый "framework", в рамках которого потом буду рассказывать про свой home lab.

Вот ровно так на меня смотрят наши джуны, когда я предлагаю все переписать!

https://a.exozy.me/posts/pulseaudiodb/

Текст про то, что KV база данных может быть устроена из чего угодно. В данном случае - из настроек громкости в PulseAudio.

Доставляет то, что получившийся KV поверх PulseAudio - очень медленный:

"and only takes 15.14 seconds to run for an amazing 200 reads and 200 writes"

Наверное, потому что кто-то очень любит программировать на sleep, а то как же это еще объяснить?

Раз уж я занялся автоматизацией своего home #lab, то расскажите мне за DNS.

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

А дальше мне бы хотелось, что, когда dhcp раздаст всем по IP, каждый хост "куда-то" рассказал про свой IP, в виде пары (hostname, IP), например, через broadcast, и это самое "куда-то" начало обрабатывать DNS запросы.

У меня в голове крутятся следующие ключевые слова: gossip, zeroconf, avahi, bonjour, но ничего конкретного я из этого стека вспомнить не могу, и вообще, я не настоящий сварщик.

Пока я сделал по рабоче-крестьянски: привязал в dhcp IP к mac, и прописал все хосты в /etc/hosts на каждом хосте, но это как-то не очень спортивно.

https://habr.com/ru/companies/ruvds/articles/796345/

Годный текст (перевод, оригинал там же, по ссылке) про #GNOME.

Из него я узнал, что в GNOME появился аж третий терминал "по умолчанию", о как.

От автора патчей, ускорявших vte (да, да, все три терминала построены вокруг одной и той же библиотеки, #libvte, только вот у кого-то она тормозит, а у кого-то нет).

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

https://gitlab.gnome.org/sungsphinx/ptyxis

#ptyxis

Правда, автор пока не договорился с libvte про свои патчи, и носит их с собой:

https://gitlab.gnome.org/sungsphinx/ptyxis/-/tree/main/build-aux

Поэтому он не может быть собран с системной libvte, и вынужден предлагать всем попробовать свое поделие через flathub - https://gitlab.gnome.org/sungsphinx/ptyxis#installation.

Я когда-то писал про libvte, и про gnome-console, удивительно, но вот этот косяк с W_EXITCODE (https://xn--r1a.website/itpgchannel/282) люди тащат из проекта в проект.