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

Никак меня не отпускает этот текст.

Там просто кладезь говна, изготовляемого #GNOME, и сопричастными.

Например:

"Когда они выпустили libxml 2.12.2, она была настолько поломана, что всё зависящее от неё не собиралось из-за отсутствующих заголовков. В том числе и больше четырёхсот приложений, не имеющих никакой связи с десктопным окружением GNOME, такие как Chromium, FFmpeg, VLC, Wayland, Xfce [23]. Неделю спустя была выпущена новая версия, устраняющая баг [22]."

Не понимаю, почему .2, наверное, раньше просто не заметили.

Оно было сломано с самой 2.12.0, и было сломано катастрофически.

https://github.com/pg83/ix/commits/main/pkgs/lib/xml/2/t/ix.sh
https://xn--r1a.website/itpgchannel/1473

Оцените, я с ноября прошлого года занимался тем, что накатывал каждую следующую версию libxml из ветки 2.12.X, а потом, матерясь, откатывал на 2.11.

Почти полгода они не могли починить одну сраную библиотеку после небольшого рефакторинга.

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

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

Появление React ребята из Facebook часто объясняют примерно вот так:

В далеком 2013 году в Facebook Chat часто появлялись фантомные сообщения: уведомление приходило, иконка загоралась, а самого сообщения не было.

Это было вызвано ужасным императивным кодом, а чтобы это починить и был придуман React.

У меня всегда были вопросы к этому объяснению. А вчера Adam Wolff причастный к разработке добавил деталей:

Да, React, был действительно создан для решения проблемы фантомных уведомлений, но эту проблему он в результате не решил, потому что проблема на самом деле была в кривых настройках DNS где-то в Индии, и когда DNS починили проблема ушла.

https://twitter.com/dmwlff/status/1762885255030259854?s=20

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

Конечно, если все делать плохо, то будет плохо, а если плохо не делать, а делать только хорошо - то все будет исключительно хорошо.

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

Вышли 6-ые кеды.

У меня их нет, и пока не будет (#kparts), а вот то, что они объявили #wayland сеанс основным, очень и очень много значит.

Это значит, что внедрение wayland сейчас станет лавинообразным, и, через год-два, будет не 15% wayland, а 15% X11. #future

Надеюсь, не откатят это, как когда-то сделали SDL.

Редкое издание

Programmer memes

Вышла новая musl, и, традиционно, она ломает то, что раньше "всегда" работало.

musl характеризуется тем, что не инклудит заголовки из ядра linux, а использует только публичные данные про ABI Linux.

С одной стороны, это хорошо, потому что меньше зависимостей и проще для #bootstrap.

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

Вот, в новом musl досыпали интерфейсов для stat* вызовов.

Конкретно, поддержали вызов statx(). Но сделали это очень неполно:

https://git.musl-libc.org/cgit/musl/tree/include/sys/stat.h#n129 - вот структура от Фелкера

https://github.com/torvalds/linux/blob/master/include/uapi/linux/stat.h?ysclid=lt8qmyswiv398996151#L99 - а вот структура от Торвальдса

Видно, что у Торвальдса в конце на 3 поля больше.

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

1) Что те программы, которые одновременно включают sys/stat.h, и linux/stat.h, перестанут компилироваться

2) Те, что включают только sys/stat.h, перестанут компилироваться, если используют вот эти 3 поля, которых нет в musl.

Проблема, понятное дело, не надуманная, у меня уже сломалась сборка приличного набора софта после upver.

Мораль?

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

epiphany  46rc-1
webkitgtk 2.43.4-1

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

А это значит скоро, свежий релиз #GNOME.

Вообще, конечно, #igalia молодцы, по сути, сами себе пишут webkitgtk, и сами же его релизят, когда им нужно.

Я, когда писал вот этот вот текст, про то, что rust с его каргой - тихий ужас, с точки зрения дистростроения, тогда еще не имел в своем #CI программ на #rust.

А теперь у меня их порядка 20 штук, и, я должен сказать, что https://xn--r1a.website/itpgchannel/337, как говорится, не "в бровь, а в глаз".

Потому что мой CI половину (половину, Карл!!!) времени занимается тем, что пересобирает эти несчастные 25 программ. Напомню, что всего у меня порядка 2000 пакетов, и вот где эти 20 программ, и где половина времени моего CI?

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

Но я выкрутился тем, что отселил CI для растопрограмм в отдельный контур, на отдельный, более слабый, хост (64 ядра vs 88 в основном контуре). Ну и оно там "как-то" бежит, не замедляя весь процесс.

Я не знаю, какой-нибудь сраный https://github.com/zed-industries/zed - это 1200 крейтов в зависимостях. 1200, Карл!!! Это больше, чем просто библиотек в среднем дистрибутиве Linux! Для сборки текстового редактора! 1200 библиотек!

Меня, признаться, знатно подбамбливает от всей этой экосистемы, так жить нельзя.

Смотрите, не прошло и года, как коллегам из ядра предложили наладить хоть какой-то CI, лишь бы они согласились:

https://patchwork.kernel.org/project/linux-kselftest/cover/20240228225527.1052240-1-helen.koike@collabora.com/

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

Но, с учетом того, что в этом замешаны RedHat и Коллабора, шансы у этого начинания есть.

Нас, кстати, уже > 1500!

Если честно, я удивлен (и обрадован), тому, что так много людей готовы читать мои бредни про open source вообще, и про ошибки сборки open source программ в частности!

Stay tuned!

Больше всего проблем с обновлением #musl (https://xn--r1a.website/itpgchannel/1721) мне доставил их отказ от эмуляции "GNU basename".

Коротенько расскажу, что это такое.

Вот basename от POSIX:

https://www.opennet.ru/man.shtml?topic=basename&category=3&russian=2

#include <libgen.h>

char *dirname(char *path);
char *basename(char *path);

Обратите внимание, что этот basename принимает mutable path, и он реально его может иногда модифицировать!

Проекту #GNU этого показалось мало, и они соорудили херобору:

https://man7.org/linux/man-pages/man3/basename.3.html

#define _GNU_SOURCE
#include <string.h>

There are two different versions of basename() - the POSIX version described above, and the GNU version, which one gets after. The GNU version never modifies its argument, and returns the empty string when path has a trailing slash, and in particular also when it is "/". There is no GNU version of dirname(). With glibc, one gets the POSIX version of basename() when <libgen.h> is included, and the GNU version otherwise.

Подумайте над следующим:

* Как это, блядь, вообще работает?

* Как работают configure скрипты, которые пытаются понять, какой же basename будет реально вызван?

* Что будет, если какой-то проект забудет у себя принудительно выставить _GNU_SOURCE, и (если!) сконпелируется с POSIX вариантом?

* Наоборот, случайно выставит _GNU_SOURCE, когда он не ожидается?

Ну, вот, musl убрал из string.h эту магию, и, ВНЕЗАПНО, это сломало сборку какого-то количества софта.

На самом деле, изменение так-то неплохое, потому что фанаты Alpine набигут на upstream проекты, и пофиксят их, чтобы в них выбор реализации не зависел от libc/всратых макросов/порядка включения заголовков.

V2:

У канала есть флудилка, там можно обсудить мои тексты, и просто пообщаться на разные темы - https://xn--r1a.website/it_pg_talks

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

Мама, я мейнтейнер:

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

- https://xn--r1a.website/itpgchannel/376
- https://xn--r1a.website/itpgchannel/377
- https://xn--r1a.website/itpgchannel/379
- https://xn--r1a.website/itpgchannel/467
- https://xn--r1a.website/itpgchannel/545
- https://xn--r1a.website/itpgchannel/572
- https://xn--r1a.website/itpgchannel/757
- https://xn--r1a.website/itpgchannel/824
- https://xn--r1a.website/itpgchannel/1261
- https://xn--r1a.website/itpgchannel/1608

Как настроить зеркало stal/IX:

- https://xn--r1a.website/itpgchannel/1371

#ix как пакетник для разработки:

- https://xn--r1a.website/itpgchannel/882
- https://xn--r1a.website/itpgchannel/898
- https://xn--r1a.website/itpgchannel/965
- https://xn--r1a.website/itpgchannel/1422

https://en.m.wikipedia.org/wiki/Bootstrappable_builds:

- https://xn--r1a.website/itpgchannel/20
- https://xn--r1a.website/itpgchannel/207
- https://xn--r1a.website/itpgchannel/221

Эстетика статической линковки:

- https://xn--r1a.website/itpgchannel/705
- https://xn--r1a.website/itpgchannel/709

Rant & wisdom:

- https://xn--r1a.website/itpgchannel/660
- https://xn--r1a.website/itpgchannel/710
- https://xn--r1a.website/itpgchannel/1572
- https://xn--r1a.website/itpgchannel/1279
- https://xn--r1a.website/itpgchannel/1639

Я как-то писал, что одно из самых больших удовольствий, которое доставляет наш род занятий, это "соединить несоединимое" - https://xn--r1a.website/itpgchannel/1000.

Вот, взять какие-то разнородные штуки, грубо подогнать их друг к другу, и получить какое-то новое value, от соединения их в единое целое.

У меня есть три текста на эту тему, я их решил объединить в цикл, и назвал его "История о трех херОборах" #herobora. #gold

История первая, или "альтернативный patch".

Недавно рассказывал про то, как интересно у меня сломался #GNU patch, при сборке keepassxc - https://xn--r1a.website/itpgchannel/1692

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

В общем-то, у нас есть следующие альтернативы:

* gnu patch (он сломан)

* оригинальный patch от Larry Wall (https://en.wikipedia.org/wiki/Patch_(Unix)), от которого пошли все остальные патчи

* git apply patch (про эту команду я ничего не знаю, и даже не смотрел, что у нее под капотом)

Я решил, что, а давайте соберем patch от Larry Wall, и попробуем заиспользовать его!

Какой вариант этого кода взять? patch от Larry Wall раскидан примерно по всем *BSD системам, с какими-то доработками, улучшениями, ухудшениями, немного разной сборкой, и так далее.

Тащить его из FreeBSD мне не захотелось, потому что он идет вместе со всей монорепкой FreeBSD, поэтому я решил стащить его из https://github.com/apple-oss-distributions/patch_cmds/tree/main/patch

В целом, хорошая альтернатива, тем более, macOS - один из немногих сертифицированных UNIX.

Понятное дело, что он никогда не собирался под Linux, его исходники были заточены на Darwin (и ранее на FreeBSD).

Возникло 2 проблемы:

* Как собрать исходник с наименьшими правками

* Как не переписывать родную сборочную систему - https://github.com/apple-oss-distributions/patch_cmds/blob/main/patch/Makefile - это Makefile, но довольно необычный Makefile, если кому интересно - читайте про то, как собирается *BSD мир.

Собственно, для решения первой задачи я соорудил первую херОбору из списка - linux libc + https://libbsd.freedesktop.org/wiki/ (набор библиотек, которые делают Linux немного более похожим на BSD) + некоторе количество доработок напильником поверх (https://github.com/pg83/ix/blob/main/pkgs/bin/patch/darwin/unwrap/ix.sh#L26-L36). Удивительно, но, в сумме, это позволило собрать darwin patch.

Вторая проблема была несколько сложнее.

Традиционно, для сборки BSD систем используется утилита make, которая похожа на gnu make, но не совсем gnu make. Их, конечно, тоже можно насобирать по разным репозиториям с BSD системами (NetBSD, OpenBSD), и так далее, но можно взять готовый https://www.crufty.net/help/sjg/bmake.html, который основан на коде из NetBSD

"As noted above; bmake is derived from NetBSD's make(1), its goal is to be a portable version of same, so new features are added via imports of NetBSD's make (I'm one of the contributors to NetBSD). Thus bmake is kept in sync with NetBSD's make."

И так же используется во FreeBSD:

"FreeBSD 10.0 and later also use bmake (I'm a FreeBSD committer as well)."

bmake - это полдела.

Нужно еще где-то найти .mk файлы - https://github.com/apple-oss-distributions/patch_cmds/blob/main/patch/Makefile#L13 , собственно, в них и содержится вся мякотка сборки.

Как вы уже поняли, в какждой BSD системе есть свои mk файлы, они похожи, но все равно, разные. С bmake идут mk файлы от NetBSD, и они нам не подходят - https://www.crufty.net/help/sjg/mk-files.htm

Беглый взгляд на Makefile показал, что в patch используются либо цельнотянутые из FreeBSD mk файлы, либо очень близкие к ним. Родных для Darwin я так и не нашел.

В этот момент я соорудил вторую херОбору (на сегодня):

* bmake

* https://github.com/pg83/ix/blob/main/pkgs/bin/pmake/mk/ix.sh - скачал всю монорепу FreeBSD, и потырил из нее mk файлы

* pmake - wrapper, который объединяет первые два пункта в одну команду - https://github.com/pg83/ix/blob/main/pkgs/bin/pmake/script/ix.sh

(продолжаю https://xn--r1a.website/itpgchannel/1730)

Собственно, с помощью этой херОборы я вполне успешно собрал darwin patch.

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

Настойчивый читатель спросит, а нафига все это нужно, если результат уже был получен?

* Это интересно!

* Мне всегда казалось, что миру не хватает "FreeBSD с content addressable package manager", если вы понимаете, о чем я (#ix). Вот, теперь я могу поэкспериментировать и в эту сторону тоже.

И, с учетом того, что я уже не влез в размер одного поста в телеге, продолжение цикла историй о трех херОборах - в следующих сериях!

https://news.ycombinator.com/item?id=39593647
https://www.opennet.ru/opennews/art.shtml?num=60721

Меня тут спрашивают, почему я не пишу про эти две истории.

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

Я считаю, что можно делать clean room reimplementation. https://en.wikipedia.org/wiki/Clean_room_design

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

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

Ну, то есть, если ты купил видеокарту nvidia, скачал себе CUDA, согласился с EULA, в которой написано, что нельзя декомпилировать результат, то все, ты не можешь это использовать для производства конкурирующего продукта. Тебя за руку никто не тянул, мог не соглашаться, и не использовать тогда этот hard & soft. А если согласился и нарушил договор, то все, результат труда "испорчен".

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