Задачка на #bootstrap:

pg# strace 2>&1 | wc -l
2
pg# strace strace 2>&1 | wc -l
24
pg# strace strace strace 2>&1 | wc -l
696
pg# strace strace strace strace 2>&1 | wc -l
24551
pg# strace strace strace strace strace 2>&1 | wc -l
921491

По какой закономерности растет это число, и почему?

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

https://gist.github.com/pg83/d5ce2f6b27458aa84f16e0d9368a1f38

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

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

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

Меня так и тянет сделать fallback на distfiles от gentoo, но насколько это ОК?

А если я сделаю fallback на какой-нибудь из бесчисленных зеркал distfiles, например, ну, чтобы не ходить далеко, https://mirror.yandex.ru/gentoo-distfiles/ ?

Какой QoS можно ожидать?

Хорошо иметь много пользователей!

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

Вот, например, мои пользователи часто жаловались на негерметичность первоначальной стадии #bootstrap - если в систему были установлены те или иные библиотеки, то системы сборки часто их находили в системе, вместо моих. С моментальной ошибкой сборки, потому что они несовместимы по ABI.

Я достаточно неплохо выкосил это в autohell скриптах - https://github.com/pg83/ix/blob/main/pkgs/die/c/autohell.sh#L38-L46

Недавно выкосил в #meson, через обертку над clang, которая убирает /usr из search path - https://github.com/pg83/ix/blob/main/pkgs/bld/wrapcc/kuroko/wrapcc.krk#L118

Вот, настала очередь #cmake. Он принудительно добавляет эти пути в пути для поиска библиотек вот тут - https://github.com/Kitware/CMake/blob/master/Modules/Platform/UnixPaths.cmake#L33

Сначала я изящно занулял этот файл при установке cmake, но потом нашел более "изящное" решение. Этот файл имеет include guard, чтобы не включаться повторно - https://github.com/Kitware/CMake/blob/master/Modules/Platform/UnixPaths.cmake#L10

Ну я и обманул cmake, чтобы он думал, что уже включил этот файл - https://github.com/pg83/ix/blob/main/pkgs/die/c/cmake.sh#L66-L67

А зачем там UNIX=1, спросит дотошный читатель?

Ну потому что выставить в cmake флаг про то, что мы собираем под unix, конечно, лучше всего именно в файле, который настраивает юниксовые пути поиска библиотек - https://github.com/Kitware/CMake/blob/master/Modules/Platform/UnixPaths.cmake#L18

(Что?? Да!!)

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

Причиной остановки всех 14 заводов Toyota в Японии стал недостаток места на диске базы данных, сообщил автоконцерн на своем сайте.

Совет от дядюшки ПЖ.

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

Почему?

Потому что, если вы делаете иначе, то вы регулярно будете расходиться в трактовках всяких мелочей, и, при замене компилятора, да и даже при простом upver своего компилятора, вы рискуете столкнуться с:

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

Если вы не разработчик компилятора, то не надо спать со стандартом под подушкой, и пытаться заюзать любую новую фичу, которую добавили во вчерашний релиз (стандарта и/или компилятора).

Выработайте в себе здоровый скептицизм, вот.

А вот как великие доебываются до стайлгайда на code review - https://www.phoronix.com/news/Linus-Comments-Bcachefs-6.6 #bcachefs #Kent

"А теперь ты приходишь и говоришь: Дон Корлеоне, мне нужна справедливость. Но ты не просишь с уважением, не предлагаешь дружбу, даже не думаешь обратиться ко мне — крёстный. Нет, ты приходишь ко мне в дом в день свадьбы моей дочери и просишь убивать за деньги"

"I need to know that you understand that if you actually want this upstream, you need to work with upstream.

That very much means *NOT* continuing this "I'll just do it my way". You need to show that you can work with others, that you can work within the framework of upstream, and that not every single thread you get into becomes an argument"

В целом, я не очень уважаю мейнтейнеров open source софта за их #errogant поведение, но тут сложно не согласиться с Линусом, и выглядит это все странно.

Тут вот lobste.rs принес ссылку на очередной мини-шедевр от Гугла.

https://github.com/google/minijail

Это, знаете ли, ровно та контейнеризация, которая нужна для системы сборки - не делает ничего лишнего, и потому работает полностью rootless, без #suid бинарников и прочей нечести.

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

Маленькая, компактная, шик, блеск, красота. И, кстати, тоже из ChromiumOS

Интересно, сколько у Гугла еще таких полезных мелочей, в их огромных закромах? Я как-то, ради интереса, пробовал пролистать их org на github, там просто залежи полезного кода. Но вот как там искать то, что нужно здесь и сейчас - совершенно непонятно.

Я вот так спокойно пишу, что "обкостылил все популярные системы сборки".

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

Вот, например, есть такой проект - https://github.com/Genivia/ugrep

Хороший, быстрый, современный grep (наверное, мне пофиг, я сам не использую)

И, вообще говоря, когда я его тащил к себе, то еще удивился, что вот, мол, новый проект, а сборка у него на gnu autohell. Ну не может же быть такого в 21 веке?

Но мне, ВНЕЗАПНО, все стало понятно, когда я увидел, что этот проект сопротивляется моим стандартным попыткам запретить ему лезть в /usr.

Чувак настолько любит (я не знаю, какие тут еще могут быть эмоции) gnu autohell, да и M4, что накостылял своих костыльных макросов для поиска внешних библиотек, https://github.com/Genivia/ugrep/tree/master/m4

Которые, ничего не стесняясь, лезут в систему - https://github.com/Genivia/ugrep/blob/master/m4/ax_check_bzlib.m4#L67

Это не копипаста, это реально его самодел - https://github.com/Genivia/ugrep/blob/master/m4/ax_check_bzlib.m4#L32

Я, честно говоря, такое вижу в первый раз в жизни.

Если вы хотите помочь проекту, но не хотите ставить его себе на машину, то теперь есть такая возможность!

Вам нужно всего лишь отправить sms на короткий номер запустить скрипт примерно следующего содержания на машине с linux, на которую можно попасть извне - https://gist.github.com/pg83/4bdb11a2ca3602d949db26b4b2a66781, на регулярной основе (например, пару раз в день из cron)

Дальше нужно расшарить содержимое output dir по протоколу http, ну и написать мне про это.

Скрипт скачает все используемые в #IX исходники в content addressable store, и будет обновлять их по мере поступления новых версий пакетов. Пока там порядка 6GB данных.

IPFS? Ну мы тут с коллегой провели серию экспериментов, IPFS - неработоспосбное говно, с постоянно разваленным DHT.

Торренты? Может быть, когда-нибудь, но пока нет.

#mirror

#ix #mirror

Тем временем, у нас появилось первое полноценное зеркало - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/mirrors.txt - http://ix-eparo-mirror.duckdns.org/

Если вы готовы запилить такое же, сразу шлите PR в этот файл. А я, eventually, сделаю его поддержку в фетчере, например, через aria2 - https://aria2.github.io/

Так же один из наших товарищей запилил нам немного мерча - футболки с символикой #stal/ix, фото будут чуть позже, когда я разберусь с деталями и логистикой.

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

Stay tuned!

У меня, кстати, есть немного поучительных подробностей про этот мой простой скрипт, который строит зеркало исходников для #IX. #gold

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

* https://github.com/pg83/ix/blob/main/pkgs/die/scripts/prefetch - это первый вариант скрипта, он весьма дуболомный, потому что он по шагам делает ровно то, что я хочу получить в результате - скрупулезно проверяет, не сделан ли был этот шаг на прошлой итерации, пропускает, что уже было сделано, переделывает то, что завершилось с ошибкой. Мерзкая лапша. Этот вариант я выкинул, после того, как получил работающую папку с кешем.

* https://github.com/pg83/ix/blob/main/pkgs/die/scripts/recache - а это второй вариант. Он, вместо того, чтобы делать что-то, описывает построение Makefile, который, будучи запущенным, сделает то, что мне нужно. На мой взгляд, он гораздо понятнее, потому что в 2 раза короче, и, вместо того, чтобы описать действия, описывает то, что нужно получить. Да, все, как я люблю - разложил задачу в граф вычислений, написал метапрограмму, которая описывает этот граф для какого-то движка выполнения графов, и выполняет его. Ну и, в целом, если вы описали свою задачу как программу, которая пишет другую программу, то вы существенно выиграли. А у меня тут аж целых два уровня - python, который генерирует Makefile, который выполняет shell. Заодно я получил распараллеливание закачек, совершенно бесплатно!

* мне несколько человек (кстати, у нас уже целых 5 зеркал!) написали, что, мол, моя программа падает с ошибкой. Да, падает, потому что не все файлы получается скачать - каких-то просто нет, какие-то недоступны в данный момент времени, и так далее. Мне это кажется очень разумным, и отражающим суть решаемой задачи - если нельзя скачать все файлы, то код ошибки должен отличаться от 0. Данную семантику мне обеcпечивает gnu make, даже буде запущенным с -k.

* https://gist.github.com/pg83/7a52dc5569e09102e341f55686fc3333 - выхлоп программы кажется "грязным", потому что перепутан output от разных паралллельных wget, и stack trace в конце. Это тоже важная тема - я очень не люблю причесывать торчащие наружу кишки в процессе разработки и серьезных доработок, потому что все такие "причесывания" ухудшают observability. Вот, реально, скрыл стектрейс - потом, в самый ненужный момент, будешь ебаться с тем, чтобы как-то его получить, потому что без него ничего не понятно. Всякого рода "причесываниями" стоит заниматься, когда код, по сути, завершен, и вы понимаете, что решаемая задача меняться не будет. Вот тогда можно сказать, что, если 1000 раз записал этот stack trace, и он не пригодился - ну и хрен с ним, можно скрыть.

* кто-то заметил, что у меня есть урлы, которые не ведут на исходники, а вообще ведут на динамический html контент - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/urls.txt#L330. Да, есть, да, ведут. Код устроен так, что такой урл на хосте будет скачан 1 раз, переименутеся в ничего не значащий $(sha256sum) от этого html, и на этом все, про него можно забыть. А если бы я занялся выфильтровыванием всех "некрасивых" url из общего файла, я бы обязательно удалил бы что-то лишнее, и потом долго разбирался с багрепортами, что в кеше нет чего-то важного. Фильтрацией этого списка, опять же, можно заняться в будущем, когда будет доказана полезность этих 5 зеркал, когда будут починены и отлажены реальные баги, приводящие к реальным ошибкам у пользователя.

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

Красоту я, конечно, наведу. И url пофильтрую, и ошибку прикопаю, но когда-нибудь "потом".

#llvmweekly принес прекрасное

https://discourse.llvm.org/t/hand-written-in-assembly-in-libc-setjmp-longjmp/73249

Оказывается, у них там есть прекрасная policy - в исходниках llvm libc не должно быть файлов на ассемблере. Дело хорошее, нужно это, чтобы хорошо работали санитайзеры, фаззеры, и так далее.

Но случилась маленькая проблемка - setjmp/longjmp очень сложно написать на inline assembly (он, насколько я понял, таки разрешен), по разным интересным причинам.

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

Помяните мои слова, они этот код напишут как

__attribute__((section, '.text'))
char setjmp[] = {
    // и тут просто байтовое представление
}

Или что-то в этом роде.

https://go.dev/blog/wasi

Вот, в продолжение темы "#WASI as api boundary".

Go поддержал компиляцию в #WASI.

Я, в связи с этим, хочу поспекулировать на тему "WebAssembly as language boundary".

Получается, что программа, однажды скомпилированная в WebAssembly, может использовать рантаймы очень разной природы - на Rust, C/C++, JS, whatever.

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

Это, в целом, заманчиво, потому что пляски с ffi и системным ABI, которые, сами по себе, являются локальными оптимизациями под процессорные архитектуры 80-90х годов прошлого века, утомили. Нужно задавать передаваемые типы, а не исполнять 1000-страничные мануалы, где написано, когда и как что может быть передано в EAX.

https://www.neversaw.us/2023/09/04/understanding-wasm/part3/you-are-here/

А вот еще один, довольно водянистый, текст про WebAssembly/#WASI.

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

Но вот еще одна забавная мысль, которую я оттуда почерпнул - "WebAssembly as security boundary".

Что это значит? Это значит, что достаточно продвинутая WASM VM может эмулировать fork(), и процессы, без поддержки операционной системы, и без переключения контекстов, соответственно.

Идея это не очень новая (кто сказал https://en.wikipedia.org/wiki/Singularity_(operating_system) ?), но, кажется, в случае WebAssembly, мы близки к этому, как никогда ранее.

Вот, опять, ровно те же круги по воде - новая libadwaita, новая версия webkitgtk. Значит, скоро 45-ый #GNOME.

Вот вам соображение - libadwaita и webkitgtk пишет, в основном, #igalia, в первую переносят запчасти из epiphany, а вторую - в ней же и используют.

UPD: вон, даже релиз уже отвели - https://github.com/GNOME/epiphany/tags!