#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

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

Продолжаем развенчивать мифы про 3D ускорение терминала. #terminal

Раз уж я заполучил #rust (https://xn--r1a.website/itpgchannel/1605), то теперь у меня есть работающий #alacritty!

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

#alacritty:

real  0m1.039s
user  0m0.000s
sys  0m0.396s

#foot:

real  0m0.597s
user  0m0.000s
sys  0m0.362s

Что это значит?

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

Ссылки:
https://xn--r1a.website/itpgchannel/133
https://xn--r1a.website/itpgchannel/119
https://xn--r1a.website/itpgchannel/39

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

Вот, вывод на экран 150 мегабайт текста:

alacritty:

real  0m2.920s
user  0m0.000s
sys  0m1.456s

foot:

real  0m2.059s
user  0m0.000s
sys  0m1.534s

https://www.opennet.ru/opennews/art.shtml?num=60467, чего бы это не значило.

А как вам такая мысль: chrome - это обуза для Google, чемодан без ручки, который и тащить не хочется (потому что, по сути, денег он не приносит, несмотря на почти монополию, и все попытки его монетизировать, AFAIK, обломались, да и пользоваться положением монополиста не очень получается), но и бросить жалко, потому что его тут же подберет консорциум из пары десятков заинтересованных компаний, и будет развивать без Google?

#jpeg_xl #fork

https://davidben.net/2024/01/15/empty-slices.html

Забавный текст про представление пустого диапазона значений(slice, span, array_ref, etc) в разных языках.

Базово это всегда [start_ptr, count), но есть нюансы, связанные с обработкой пустого диапазона. Потому что их много разных, но какие-то валидны в одном языке, но сломаны (UB) в другом:

* [nullptr, 0) - OK в C++, сломан в Rust, отвратительно сломан в С. Когда автор текста написал, что, мол, тот факт, что нельзя позвать memcpy(nullptr, 0), долго мешало включить ubsan в chrome, мне захотелось обнять его и заплакать.

* [alignof(T), 0) - валидно в Rust, сломано в C++, статус в C я не очень понял.

Помимо этого, утверждается, что в Rust, по причине устройства его пустого slice, сломаны (несогласованы) итераторы по slice.

Ну и, на самом деле, это все ведет к тому, что interop/ffi между Rust и C/C++ может быть фундаментально сломан, потому что никто не занимается корректной конвертацией диапазонов при передече их между языками, и в код на C++, который ожидает [nullptr, 0), может приехать [alignof(T), 0), и наоборот.

А если сделать корректно, то он будет не zero cost.

Такие дела.

Полез за обновлениями zutty, увидел, что автор мигрировал с gihub:

https://tomscii.sig7.se/2024/01/Ditching-GitHub

Перешел на email based git workflow, my ass. Это в 21 веке-то.

Как увидеть все фичи, которые можно включить на #rust crate?

Никак, пук-среньк.

https://www.reddit.com/r/rust/comments/pwpuas/is_there_anyway_i_can_see_all_the_features_a/

#money

https://lobste.rs/s/sm3t1o/open_source_sustainability_crisis

Опять какой-то зумер жалуется, что в open source нет денег.

Нет, и вряд ли будет:

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

* Для любого популряного open source проекта верно утверждение, что следующий в очереди готов сделать эту работу за "спасибо". Ты только отдай пароль от своей репы, или заархивируй ее и дай ссылку на официальный fork.

Отсюда простой и понятный вывод - все популярные open source продукты пилятся и будут пилиться совершенно бесплатно. Если, конечно, у тебя не очень хорошо подвешен язык, и ты не сумел уболтать несколько спонсоров.