Будни #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://t.me/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://t.me/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://t.me/itpgchannel/133
https://t.me/itpgchannel/119
https://t.me/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 продукты пилятся и будут пилиться совершенно бесплатно. Если, конечно, у тебя не очень хорошо подвешен язык, и ты не сумел уболтать несколько спонсоров.

https://lobste.rs/s/fkzcja/ditching_github#c_ie3hfq

Утащу из обсуждения этой темы на lobste.rs:

"I think I am the maintainer of the only GNU project hosted on GitHub. Richard Stallman periodically emails me to tell me I’m evil, but since I moved it to GitHub the number of external contributors has gone from zero to several highly motivated people. Most recently, a student found it and did RISC-V and PowerPC ports (some bits need to be in platform-specific assembly). Being on GitHub increased the amount of Free Software in the world.

I don’t like GitHub’s monopoly position. I refused to even create an account for many years but at the end of the day you have to pick your battles. Given a choice between using a non-Free platform and having fewer contributors, I regard the non-Free platform as the lesser evil. Particularly since there is nothing intrinsic to GitHub that we need, so we can always move to a better alternative if one exists. I’d love to see a truly distributed revision control system, with a mechanism for members to contribute the ability to run isolated VMs for other people’s CI, for example"

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

Собственно, посмотрел, https://github.com/YaLTeR/niri классный, визуально приятный, с ненавязчивой анимацией.

Решил поиспользовать вместо #qtile, потому что его разработка в коме, и не подает признаков жизни.

#niri

Скажите, а есть в природе легковесный мультисессионный display manager?

Это когда он запускается, скажем, на vt1, а сессии запускает на vt2 - vt5, и из сессии можно вернуться на vt1 (через ctrl-alt-f1), и запустить еще одну сессию?

Я попробовал greetd/ly/*getty/emptty, но они все - login manager, то есть, в каком vt ты их запустил, в том же они и запускают сессию, есть отображение 1 к 1 между количеством инстансов login manager и числа возможных сессий.

https://blog.polybdenum.com/2024/01/17/identifying-the-collect-vec-memory-leak-footgun.html #perf

Текст про то, как стандартная библиотека #rust оказалось слишком умной, и переиспользовала память Vec после того, как этот Vec был превращен в range, а из этого range снова в Vec.

Насколько я понял, там случилось ажно две смешных штуки оптимизации:

1) into_iter().collect() переиспользовало тот же самый вектор, хотя можно было бы ожидать, что это будет похоже на shrink_to_fit()

2) into_iter().map().collect() переиспользовало старую выделенную память исходного вектора, если размер нового элемента <= размера старого элемента. Поэтому, если размер нового элемента был раз в 10 меньше, чем исходного элемента, то происходил дикий пережор памяти.

Оптимизации, конечно, семантически корректные, но спорные.