https://blog.tenstral.net/2024/01/wayland-really-breaks-things-just-for-now.html

Классный текст про #wayland.

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

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/269

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247

Хочу подробнее остановиться на

"Desktop environments of course have a design philosophy that they want to push, and want applications to integrate as much as possible (same as macOS and Windows!). However, there are many applications out there, and pushing a design via protocol limitations will likely just result in fewer apps"

Здесь аккуратно написано про следующий факт - люди, которые могут закоммитить новый протокол в wayland (например, позволяющий точно позиционировать окна), по странному стечению обстоятельств, являются стейкхолдерами (в том или ином виде) в kwin(KDE)/gnome shell/wlroots.

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

Вот, например, зачем человеку, который отвечает за все tiling композиторы принимать proposal, в котором можно разрешить приложению управлять своим положением на экране?

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

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

Собственно, это все описано вот тут - https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D1%81%D0%B5%D0%BD%D1%81%D1%83%D1%81#%D0%9A%D1%80%D0%B8%D1%82%D0%B8%D0%BA%D0%B0

Что с этим делать - непонятно, потому что у владельцев репы с wayland-protocols нет никаких стимулов что-то менять (https://cyclowiki.org/wiki/%D0%9F%D1%87%D1%91%D0%BB%D1%8B_%D0%BF%D1%80%D0%BE%D1%82%D0%B8%D0%B2_%D0%BC%D1%91%D0%B4%D0%B0 ), а всем остальным договориться о том, чтобы брать эти протоколы из другого места, кажется нереалистичным.

https://asahilinux.org/2024/01/fedora-asahi-new/ #asahi

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

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

Печалит то, что, для того, чтобы достигать приемлемого уровня качества сервиса, коллегам приходится распихивать по всему стеку Linux подпорки для оборудования от Apple, что-то типа "классной психоакустической модели для встроенных в ноутбук колонок в виде plugin к pipewire", и написано оно все на Rust - https://github.com/chadmed/bankstown, то есть, повторить (в #stal/ix) это будет совсем не просто.

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

Я или переоцениваю сложность этой задачи (например, потому что ничего в этом не понимаю), или там какое-то совершенно дикое количество энтузиастов, среди которых есть и такие специалисты. Кода там не очень много, но он весьма специфичный - https://github.com/chadmed/bankstown/blob/main/src/lib.rs

#gnome moment

https://discourse.gnome.org/t/dealing-with-glib-and-gobject-introspection-circular-dependency/18701

В полку сумасшедших прибыло - теперь у нас официально есть кольцевая зависимость glib <-> gobject-introspection (вдобавок к https://xn--r1a.website/itpgchannel/202).

Нормальные люди (оценочное суждение) кольцевые зависимости рвут, ненормальные - документируют, и потом, втихую, наслаждаются страданиями package maintainers.

Иииии rust наносит ответный удар!

https://www.phoronix.com/news/GCC-Rust-Developer-Discussion
https://lore.kernel.org/git/CALNs47s3tUQoOD4ejdoTn6y12ywjL0j5hWU-fUnBLe_o3vV5SQ@mail.gmail.com/T/

Будни #bootstrap

Все же знают историю про то, что размер спейсшаттлов является прямой функцией от ширины задницы лошади?

Вот, в паре скриптов в пакете с gzip нашел прекрасное:

# WARNING: the first line of this file must be either : or #!/ix/store/gF4xURAJ
as4kd5vU-bin-dash-sh/bin/sh
# The : is required for some old versions of csh.
# On Ultrix, /ix/store/gF4xURAJas4kd5vU-bin-dash-sh/bin/sh is too buggy, change
 the first line to: #!/ix/store/gF4xURAJas4kd5vU-bin-dash-sh/bin/sh5

Что тут написано?

Что когда-то, очень давно, в этом скрипте стояли прямые ссылки на /bin/sh, и вот про них было написан комментарий людям, которые бы редактировали этот shell script - мол, под каким-то там Ultrix (что это?) /bin/sh может не работать, берите /bin/sh5.

Но, после серии рефакторингов, и, насколько я понимаю, замены прямой ссылки на /bin/sh на ссылку на shell, найденный в момент выполнения ./configure, случился такой странный казус.

Получается, что мой dash, лежащий в /ix/store, может так себе работать под какой-то несуществующей OS.

https://lobste.rs/s/lgwcpb/statement_regarding_ongoing_sourcehut#c_zz1to9

Из обсуждения этой темы на lobste.rs узнал, что #ddv (ну и еще парочка его коллег) был там забанен пару лет назад, за слишком агрессивный маркетинг sr.ht, https://en.wikipedia.org/wiki/Rage_farming.

Это, конечно, немного в другом свете освещает историю про нападки #ddv на #hyprland https://xn--r1a.website/itpgchannel/1337

#gnu, невменяемые мейнтейнеры

Я как-то рассказывал, что слежу за свежими апдейтами через repology.org. И там, довольно регулярно, настолько, что я обратил на эту странность внимание, ровно про две программы, приходит новая версия, в довольно странном формате - readline 8.2_p10, bash 5.2_p26.

Довольно долго не понимал, что же это за _pX, в "гнусном" ftp/http лежат вот ровно эта версия - 8.2 - https://ftp.gnu.org/pub/gnu/readline/

Оказывается, _p10 - это вот патчи из https://ftp.gnu.org/pub/gnu/readline/readline-8.2-patches/, которые нужно скачать отдельно, и наложить на основные исходники.

То есть, вместо того, чтобы сформировать очередной минорный релиз, upstream просто выкладывает все патчи с багфиксами, а ты ебись, как хочешь. А я-то всегда думал, почему readline так редко релизится...

https://github.com/pg83/ix/blob/main/pkgs/lib/readline/ix.sh#L3-L26

Мягко говоря, не очень удобно, надо вручную прописывать url, sha, и накладывать патч.

В первый раз такое вижу.

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

#linux #kernel #ci

https://www.phoronix.com/news/Linux-6.8-Sched-Regression

TL;DR - в процессе слияния ядра 6.8 Линус заметил, что, когда он собирает свежее ядро, будучи загруженным в это свежее ядро (#bootstrap), то у него это ядро собирается в 2 раза медленнее.

Тут, конечно, интересна не причина регрессии, а процесс.

Даже до Миши с фороникса начинает доходить, что что-то в консерватории не так, если такие валенки на пульте находит не автоматизированный CI, а лично Линус в процессе мержа:

"For regressing a workload like code compilation speeds being halved is rather surprising as while the Linux kernel lacks common and robust continuous integration (CI), it seems like kernel developers responsible for the changes would notice such a dramatic change... Especially if the code has been through linux-next and the like"

Все, буквально все (кроме старых линуксхакеров - https://xn--r1a.website/itpgchannel/264), уже понимают, что одна из самых важных программ в индустрии не может разрабатываться ТАК. Ну, то есть, может, но только в 10 раз медленнее, или дороже, чем могла бы.

Треш, угар, содомия.

Особенно смешно на этом фоне смотрится, как Линус материт Intel за то, что они не тестируют свой код перед мержем - https://www.phoronix.com/news/Torvalds-Unhappy-Linux-6.8-DRM

Будни #bootstrap, #stal/ix

Тут вот коллеги подкинули ссылку на смешной способ сделать Dockerfile исполняемым. https://gist.github.com/adtac/595b5823ef73b329167b815757bbce9f

Ничего особо интересного, просто "волшебный" шебанг, который сделает всю работу:

#!/usr/bin/env -S bash -c "docker run...

Я тут сразу вспомнил, что это не будет работать в Alpine Linux, ну только если они не стали специально патчить busybox. Руками я это предположение не проверял, но патчи от Alpine на busybox прогрепал - https://git.alpinelinux.org/aports/tree/main/busybox?h=master

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

Вот, смотрите, его разбор command line аргументов: https://elixir.bootlin.com/busybox/latest/source/coreutils/env.c#L60

Все остальные /usr/bin/env, до которых я дотянулся, опцию -S поддерживают. В том числе, *BSD, Darwin, GNU coreutils, и прочая, и прочая.

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

Поэтому я взял, и спиздил env из bsdutils https://github.com/dcantrell/bsdutils (цельнопижженные из FreeBSD утилиты):

* Размер их статически слинкованного env всего 50k. В coreutils в несколько раз больше, у gnu очень bloated софт.

* Не хочу иметь ничего от #GNU в базовой системе

* Так уж случилось, что я однажды уже опакетил bsdutils - https://xn--r1a.website/itpgchannel/65, поэтому это был наиболее быстрый способ.

Вот, у меня env из bsdutils - https://github.com/pg83/ix/blob/main/pkgs/set/system/0/unwrap/ix.sh#L36, у меня такой скрипт имеет шанс запуститься:

pg# /usr/bin/env -h
/usr/bin/env: unrecognized option: h
usage: env [-0iv] [-L|-U user[/class]] 
    [-P utilpath] [-S string] 
    [-u name]
    [name=value ...] 
    [utility [argument ...]]

Мораль?

* В хозяйстве все сгодится, рано или поздно.

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

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

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

TIL новое слово - Еггогология.

https://ru.wikipedia.org/wiki/%D0%95%D0%B3%D0%B3%D0%BE%D0%B3%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F

New comic
https://stonetoss.com/comic/iron-crossed/

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

Пакеты в nix/guix в своих шебангах имеют абсолютные пути, которые ведут в другие пакеты. То есть, питонячий скрипт в пакете A будет вести в абсолютный путь к питону из пакета B, и будет жесткая зависимость A -> B.

У меня это устроено иначе. Я перепахаю такой шебанг в виде #!/usr/bin/env python3, и пакет будет зависеть от "какого-то" питона. Связывание с конкретным питоном случится в момент формирования #realm - какой питон ты туда поставишь, такой и будет использоваться.

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

* первый более надежно фиксирует окружение
* второй гибче, хотя может иногда подламываться
* второй мне было проще имплементировать (например, чтобы указать явный путь, нужно уметь делать зависимость на пакет B под определенный target, совпадающий с target A, но, чаще всего, все системы сборки пропишут зависимость на host B, потому что задетектят его при сборке)

В целом, я довольно часто пользуюсь тем, что build python/perl/sh != target python/perl/sh, и связывание происходит в моменте построения полного #realm, в рамках которого все и будет запускаться.

Так вот, когда я только запилил процедуру подмены шебангов с #!/a/b/c/prog -> #!/usr/bin/env prog, то столкнулся с тем, что такая подмена не всегда работает.

Скажем, #/a/b/c/perl -w нужно заменить на #!/usr/bin/env -S perl -w, а не на #!/usr/bin/env perl -w, потому что второй способ не будет работать по причинам, которые я излагал в предыдущем тексте.

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

Будни #bootstrap, #gold

Проснулся сегодня с мыслью, что именно сегодня, хоть тушкой, хоть чучелом, хоть вызовом https://play.rust-lang.org/?version=stable&mode=debug&edition=2021 по http, но я затащу Rust в #ix.

Потому что ну сколько можно? И потому что мне нужно было обрести уверенность, что выбранный мной способ #bootstrap, рано или поздно, но приведет к работающему результату.

В #stal/ix теперь есть #rust!

Пока не #bootstrap, пока просто сборка с оффсайта, творчески перепаханная, чтобы уметь работать в full static environment:

* https://github.com/pg83/ix/blob/main/pkgs/bld/musl/ix.sh - сборка shared musl, с динамическим загрузчиком. Особое внимание стоит обратить на мою великолепную реализацию динамических исключений (libgcc_s.so.1) - https://github.com/pg83/ix/blob/main/pkgs/bld/musl/ix.sh#L22-L69

* С помощью patchelf перепахиваем скачанный дистрибутив, чтобы он использовал мой ld.so - https://github.com/pg83/ix/blob/main/pkgs/bld/rust/linux/unwrap/ix.sh#L20-L23

* Цимес, мякотка, соль всего процесса - https://github.com/pg83/ix/blob/main/pkgs/die/rust/cargo.sh#L30-L65 - хрень, которую я подсовываю в rustc в качестве С/С++ компилятора (и линкера). Она решает творческую задачу по редактированию строки вызова компилятора так, чтобы, когда надо, это была динлинковка с моим musl (для последующей загрузки получившейся .so компилятором rustc), а, когда надо, статлинковка финального артефакта.

Заняло это всего час времени.

Нет, реально, все оказалось проще, чем я изначально предполагал, оно просто взяло, и заработало.

Это не финальный результат, но:

* Уже можно использовать какие-то полезные программы на rust, хотя они еще не bootstrapped.

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

Проект #carbon продолжает нас радовать кодом лулзами своими transparency reportами - https://github.com/carbon-language/carbon-lang/discussions/3615

Ждем, надеемся.