https://github.com/jaor/xmobar#were-using-github-under-protest

Тем временем, наткнулся на первого мамкиного съезжатора с github. #sfc #gnu #gpl #charity

Кстати, я сам, лично, выкладывал что-то под GPL, только когда был literallly голодным студентом. Ну, посудите сами, мне тут жрать нечего, а кто-то, НА ХАЛЯВУ, воспользуется моим бесценным кодом.

После того, как:

* Заработал первые деньги

* На собственной шкуре убедился, что copyleft делит весь софт на 2 плохо связанные части(я тут намеренно не указал OSS, потому что корпорации довольно охотно отдают код под permissive license, да и сами используют тоже). Произошло это примерно так - я, вдруг, понял, что я, Антон, могу использовать кусок GPL2 библиотеки base64 во внешнем проекте, но я, Антон, не могу же использовать ее внутри Я, а, значит, Столлман не за меня, а против корпораций. И это не моя война, так как я хочу иметь возможность использовать OSS софт в любом контексте. Сумасшедшие фанатики тут делают вывод, что все должно быть под GPL, я же сделал вывод, что надо делиться, и не требовать ничего взамен, чтобы не создавать проблем какому-нибудь другому Anton, где-нить совершенно в другом месте.

, я ни строчки не отдавал под copyleft лицензиями.

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

Простите за моралофажество, но это не по-христиански.

#busybox, #GNU

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

10 лет назад я считал, что это какая-то интересная игрушка, в стиле "засунь дистрибутив Linux на floppy", и что там невозможно "жить" всерьез.

3 года назад я сделал его переоценку, и решил, что busybox вполне себе годится для #realm system, для загрузки системы, ну, и... всё.

Сейчас я уже где-то полгода использую busybox, как основную реализацию posix утилит, да и, в общем-то, как замену grep/sed/find/etc, coreutils, util-linux(!!, набор linux-специфичных системных утилит), и так далее. Даже awk я использую из busybox, он там куцый, но чтобы выбрать строку по значению поля - вполне подходит.

Я даже какое-то время использовал shell из busybox(ash), но, в конце-концов, вернулся на bash(причем 3-ий, в районе четвертого они что-то сильно для меня поломали). По довольно странной причине - у ash плохо работает интеграция с mc. Если бы не это, так бы и использовал.

Ну, ладно, less у них кривой, но кому нужен less в наше время?

Короче, я так скажу - в настоящее время я не вижу смысла строить Linux систему на основе утилит от GNU(косое, кривое, совместимое только с собой, да и то, не всегда, нечто), потому что а зачем? Вам, правда, нужна одна из 1000 этих опций, длиной от 20 символов, которые невозможно запомнить?

Да, тут еще, конечно, важно за это поблагодарить сообщество alpine linux, которое, насколько я понимаю, следит, чтобы всякие говноскрипты были с busybox совместимы. Может, еще openwrt, но это не точно.

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

Тут вот пишут, что вышла новая версия #GNU shepherd.

Важная новая фича:

"Клиентские соединения теперь обрабатываются в неблокирующем режиме, что позволяет исключить зависание shepherd при отправке неполной команды"

Хорошо, что я это не стал использовать.

А на вид, если не считать того, что конфиги к ней надо писать на диалекте lisp/scheme, выглядело оно вполне ничего так.

(kinda) #GNU hate speech

https://catgirl.ai/log/elegy-gnu/

Небольшой текст, дополняющий мою большую нелюбовь к проекту GNU. Конкретно, с претензией к RMS, что он, мол, плохой руководитель.

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

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

Мои основные соображения:

* Не был накоплен "опыт", "культурный слой", "инженерные практики", "инструменты", как хотите. Кстати, fun fact(ну, ладно, серьезный фактчекинг я ему не устраивал) - у наших предков мозг был больше, поэтому, вполне возможно, они были умнее, но умели при этом меньше, потому что опыт не был накоплен. https://trv-science.ru/2021/09/glupeet-li-chelovechestvo/ Поэтому, например, мне в обертке над libmagic пришлось вставить блокировку - https://github.com/pg83/ix/blob/main/pkgs/lib/mimetype/mt.cpp#L37 Ну потому что автору кода 40 лет назад не был известен простой факт, что read only данные стоит отделять от модифицируемого состояния.

* Потому что программированием занимались не профессионалы, а те, кому "очень надо" - математики, физики, химики, и так далее. Ну и софт мы имели соответствующий.

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

Уф, написал)

Меня тут (опять) спрашивают, почему я не люблю проект #GNU. #gold

Расскажу сегодня другую часть этой истории.

Все из-за очень большого разочарования! От любви до ненависти, как известно, не очень далеко.

Я пришел в Linux и в OSS примерно в 2000 году, еще будучи студентом. Знаете, довольно сообразительным, но не очень опытным, знающим. В целом, могу сказать про тогдашнего себя - легко велся на красивые идеи.

Проект GNU, конечно, тогда мне показался чем-то очень волшебным - могучие мейнтейнеры, великий провидец Столлман, Линус, гениальный kernel hacker, вот это вот все.

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

Я, помнится, тогда напридумывал себе много очень правдоподобных идей, почему OSS будет рулить миром, например: "в отличие от корпораций, которые склонны переизобретать все снова и снова, чтобы заработать деньги на одной и той же идее, в OSS проекты аддитивны - то есть, ты не пилишь новый Office, а дописываешь кусочек в общее здание".

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

И что, наоборот, коммерческие компании заинтересованы в том, чтобы было меньше бардака, и что новые xml(тогда еще)-парсеры плодятся в open source, а не в компаниях.

И что если ты придешь в какое-то такое "общее здание", то, за очень небольшим числом исключений, тебя пошлют из-за какой-то ЧСВ-шной херни того или иного мейнтейнера(тут можно вспомнить историю того же gcc и его ast).

В этот момент я понял, что OSS (ну вот даже лично мне) полезен довольно в ограниченном наборе софта*, и что RMS воюет не за что-то общеполезное, а потому что его в детстве обидели, не дав исходники от его любимой lisp машины.

Собственно, GNU я не люблю потому, что они до сих пор вербуют программистов на эту бессмысленную войну, и, тем самым, сегментируют OSS софт на пустом месте.

*: в основном, инфраструктурный софт, протоколы взаимодействия(не только TCP, а еще документооборот, например), и так далее.

Писал, что Столлман и его проект GNU, на самом деле, очень похожи на Гейтса, и MS. #gnu hate speech

Только MS жаден до ваших денег, а GNU - до вашего кода. (я лично считаю, что любая жадность - это плохо, потому что все, в итоге - время, и я уважаю open source, который #charity)

Вот вам интересный факт - GNU переняла тактику MS, которая https://ru.wikipedia.org/wiki/Embrace,_Extend,_and_Extinguish

У них, на самом деле, есть целый проект про это, называется #gnulib (!= glibc, != glib) (это такая попытка привязать софт к API несуществующей OS, да так, чтобы невозможно было выпилить), но про него надо написать отдельно.

Сегодня - вот про такой забавный #EEE, от гнутого линкера.

https://cgit.freedesktop.org/libbsd/tree/src/setproctitle_ctor.c#n51

Что здесь написано?

Здесь написано, что произвольная so может получить доступ к argc и argv процесса в момент инициализации, для этого достаточно положить указатель на функцию в секцию .init_array. Может ли она их творчески модифицировать, или линкер передает туда RO копию, я хз.

https://maskray.me/blog/2021-11-07-init-ctors-init-array

#maskray пишет, что эту дырень придумали в HP, потом GNU скопировала к себе, а потом разошлось по другим free unix.

"glibc and BSD implementations call the constructors with argc, argv, environ while musl's calls the constructors with no argument"

Классический EEE - запилили странную фичу, а потом конкуренты вынуждены это повторять, для совместимости: "FreeBSD added support in 2012-03. OpenBSD added support in 2016-08. NetBSD made DT_INIT_ARRAY available for all ports in 2018-12"

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

Будни #bootstrap.

Я тут, знаете ли, немножко прихуел, и хочу с вами немедленно поделиться.

Думаю, все сталкивались с сообщением от gnu make "clock skew detected", и про то, что сборка может быть не очень хорошей. Происходит это от того, что какие-то файлы оказываются в будущем, и возникает ситуация, что, как не перестраивай цель, она не станет младше, чем ее зависимости.

Обычно это связано с неполадками в системном времени, или в использовании сетевых FS - https://stackoverflow.com/questions/3824500/compiling-c-on-remote-linux-machine-clock-skew-detected-warning

У меня, внезапно, такая ошибка стала случаться очень часто, практически, в любой сборке, использующей gnu make, вот с такой вот диагностикой: https://gist.github.com/pg83/081189d9140288ce21291d88152ce6d2

Это не совсем обычный случай для clock skew - make пишет, что проблема не в том, что файл в будущем, а в том, что его mtime не попадает в некий диапазон. При этом #gnu make пытается быть святее папы римского, а именно, выставляет синтетическое время модификации этого файла куда-то далеко в будущее.

А у меня это не будущее, а самое дальнее прошлое - нулевой timestamp. Я его принудительно выставляю для всех сборочных артефактов, чтобы потом системные timestamp не попадали в зависимые сборки, и не портили бы воспроизводимость - https://github.com/stal-ix/ix/blob/main/pkgs/die/sh.sh#L69-L73.

Все это леденящий душу пиздец очень удивительно, потому что в какой такой range не попадет 0?

Не буду вас томить скучными подробностями #debug, но вот его результат:

https://git.savannah.gnu.org/cgit/make.git/tree/src/filedef.h#n200, копипаста - https://gist.github.com/pg83/4e54f757ce838ba6aaf746b6b9a2b8b3

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

Тут написано, что make резервирует первые три timestamp (0, 1, 2) под какие-то свои нужды. Вот, реально, сука, make считает, что файлов с timestamp < 3 в системе нет, и быть не может.

Задачка со звездочкой - что на выходе получил автор этого текста, когда попытался выставить своим файлам timestamp 1, и 2, и какими словами он обозвал разработчиков этого кода, когда во всем разобрался.

Будни #bootstrap

Есть такая библиотека - libidn2.

На своем сайте, https://gitlab.com/libidn/libidn2, они утверждают, что могут (и что это предпочтительно) использовать системную libunistring (про эту всратую либу надо как-нибудь написать отдельно):

"The Libidn2 library may use GNU libunistring for Unicode processing and GNU libiconv for character set conversion. It is recommended to install them before building and installing libidn2. ... When the recommended libunistring is not available, libidn2 uses internal replacement functionality which increases the size of the library. To use the internal libunistring-replacement rather than the system libunistring (even when deemed to be sufficient) you may use..."

Но вот год назад они стали линковать в себя кусок этой самой libunistring статически (вкомпиливать в libunistring.so) - https://gitlab.com/libidn/libidn2/-/commit/c691cdf09c8c172ebaa5926348b8d41f5fadca4c

Что, зачем, а главное - нахера?

https://gitlab.com/libidn/libidn2/-/issues/104

Судя по всему, у них сломался ubsan на libunistring (это еще одна вечная проблема конвенциональных пакетных менеджеров, что собрать всю приложуху с санитайзером примерно невозможно), и они решили это подкостылить у себя, потому что апстрим (как это принято у проекта #GNU) - #errogant упыри, и не хотят сделать у себя лишний каст по какой-то надуманной причине (а на самом деле, потому что это значило бы признать свою неправоту, что, конечно, невозможно) - https://lists.gnu.org/archive/html/bug-gnulib/2022-03/msg00011.html #gnulib

Мораль?

Ее, как обычно, нет.

#gnulib #rant

gnulib - это такая библиотека от #GNU, которая якобы должна приводить интерфейс системной библиотеки libc, к богоугодному столлманоугодному виду.

У нее есть ряд проблем, которые, в основном, вызваны тем, что у проекта GNU все принято делать через жопу:

* ее не существует в виде отдельной либы. Нельзя собрать libgnulib.a и установить ее к себе на хост

* она поставляется (и разрабатывается) в виде M4 макросов, которые, по странным правилам, генерируют исходники на машине, где собирается то или иное приложение от GNU

* эти псевдоисходники вендорятся каждым проектом от GNU, с патчами от этих проектов

Для этих исходников генерируются (в процессе configure, ага), заголовки, мимикрирующие заголовки несуществующей libc от несуществующей gnu os (!= linux, потому что на linux непустое множество кода, добавляющегося в эти заголовки).

Там куча ifdef, которые либо что-то скрывают из системной libc, либо что-то добавляют (например, функции, которых нет в системе).

Как это работает? Хуево это работает!

Все это барахло очень хрупкО по отношению ко входным параметрам (способам autodetect в configure скриптах фич компилятора и наличия определенных функций в libc), не cross-friendly (например, фишка этой библиотеки - переопределять malloc/realloc, когда системные реализации могут вернуть 0(что разрешено стандартом!), а для этого нужно код реально запустить под target платформу).

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

https://gist.github.com/pg83/55712a369912405fcf9c4063533722eb

Вот вам мой сегодняшний пример, который стриггерил эту волну хейта.

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

configure скрипты вывели несовместимые определение для эмуляции inline в С, и определение для пометки чего-то, как потенциально неиспользуемое.

Вот так выглядит их склейка:

# define _GL_INLINE static _GL_UNUSED

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

Самое безумие этой ситуации - что исправить это невозможно (а, точнее, запретительно дорого), потому что, даже если прийти в gnulib, и исправить это там, то по проектам это говно будет растекаться несколько лет!

Мораль?

Держитесь как можно дальше от проекта GNU, если у вас есть такая возможность.

Продолжаю рассказ про #MinGW #windows

Пожалуй, самая дичайшая дичь, с которой я столкнулся, это то, что #GNU #autohell позволяет настроить расширение для собранной статической библиотеки.

Настройка эта доступна не тому, кто запускает готовый configure, а запрятана где-то глубоко в настройках libtool/libtoolize (не спрашивайте, всратые гнутые скрипты, призванные облегчить линковку динамических библиотек под разные платформы). И, что самое удивительное, мейнтейнеры этой настройкой активно пользовались - у кого-то это lib, а у кого-то - a.

Поэтому я не могу пойти и параметризировать свои обвязки этим расширением, потому что его надо настраивать per project, а потом переделывать кучу моих скриптов, которые везде (до этого времени), полагали, что работают с .a файлами.

Я сделал несколько подходов к снаряду:

* Попробовал руками запатчить все проекты, чтобы свести все к .a файлам. Быстро задолбался и прекратил.

* Попробовал указать в качестве libtool стороннюю реализацию - https://github.com/midipix-project/slibtool Это работало удивительно хорошо, кроме тех случаев, когда не работало вовсе. Ну, например, у libtool есть режим "перелинковки" программ при их установке (наверное, для систем, в которых нет rpath). Зачем этот режим иногда срабатывал в случае статлинковки - неизвестно. Как отключить - неизвестно. А сторонняя реализация (совершенно справедливо!) это говно мамонта не поддерживает.

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

Комбинация 2) и 3) позволила вообще не патчить исходные сборочные скрипты, и обойтись настройкой того, какой libtool использовать в проекте.

https://blog.opensource.org/the-most-popular-licenses-for-each-language-2023/
https://www.opennet.ru/opennews/art.shtml?num=60252

А вот классное исследование про распространение тех или иных лицензий в той или иной экосистеме.

* Нет C/C++, видимо, потому что у С++ нет хорошо формализованного поставщика пакетов, с понятной политикой управления лицензиями, как в других экосистемах.

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

* Особую радость вызывает факт, что там почти нет #GNU, и почти нет copyleft кода. Очень, очень хорошо, что #GPL остается уделом маргиналов, которые зачем-то гоняют C/C++ код на платформе GNU/Linux.

#rant

https://www.phoronix.com/news/GNU-Hurd-x86_64-2023-Progress

Не понимаю, зачем кто-то вообще пишет новости про #gnu #hurd. Пациент, совершенно точно, мертв.

Вот, например, цитата от его разраба:

"Building packages is not very stable. I have been trying to build gcc-13 for a couple of weeks, without success so far. There are various failures, most often odd errors in the libtool script, which are a sign that the system itself is not behaving correctly. A way to reproduce the issue is to just repeatedly build a package that is using libtool, sooner or later that will fail very oddly.

This means that while the buildd will be ready, I'm really not at ease with letting it start, knowing that it can behave erratically. When I built the initial set of packages for debian-ports (~100 packages), I got something like 5-10 such failures, that's quite high of a rate :/"

Курам на смех, конпелятор пересобирается через раз, рандомные bash скрипты падают со странными ошибками, и оно не может пересобрать себя из под себя (то есть, не self hosted).

#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, вместо нового снепшота, потому что ты платишь за каждый мегабайт.

Будни #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.iss.one/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 ...]]

Мораль?

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

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

#cross

Сегодня я узнал, что help2man (от проекта #GNU) запускает только что скомпилированную программу, чтобы превратить ее --help в man file.

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

И это, конечно, совершенно никак не ложится на кросс-компиляцию.

https://forums.gentoo.org/viewtopic-t-1141876.html

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

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

Что я с этим сделал?

А нахуй послал.

Я как-то рассказывал, что у меня есть скрипт - "универсальная" замена любому codegen. Он анализирует свои аргументы, находит подходящий кандидат на output, и просто пишет в него 0 байт. (https://t.iss.one/itpgchannel/927, https://github.com/pg83/ix/blob/main/pkgs/bld/fake/er/ix.sh)

Ну я и заменил оригинальный help2man на затычку - https://github.com/pg83/ix/blob/main/pkgs/bld/help2man/ix.sh

Инструментарий от проекта #GNU - всратое, забагованное, говно. #gold

Его единственное достоинство - что оно было (ну, то есть, существовало) в тот момент, когда больше ничего другого и не было.

Я уже несколько раз про это писал, соберу все ссылки в одном месте:

https://t.iss.one/itpgchannel/585 - свежий awk ломает сборку ядра

https://t.iss.one/itpgchannel/1133 - свежий grep ломает вообще все, до чего дотягивается

https://t.iss.one/itpgchannel/220 - ed от проекта GNU не может собрать bc от проекта GNU, а bc от проекта GNU не работает для сборки ядра Linux

https://t.iss.one/itpgchannel/1432 - groff от проекта GNU ....

https://t.iss.one/itpgchannel/1233 - make от проекта GNU ...

(еще у меня была история про sort от проекта GNU, но я не могу ее найти в бездне)

Вот, у меня пополнение историй успеха сборочного инструментария от проекта GNU, назовем эту серию "patch от проекта GNU".

Наткнулся я на нее, когда собирал патченый под QT6 KeePassXC (https://t.iss.one/itpgchannel/1643)

Там коллега учудил, и, вместо github branch, оформил все в виде одного большого patch.

Собственно, при наложении этого патча у меня и случилось красивое:

patch: **** Can't rename file \
    HibpDownloader.cpp.oq4YS9V to \
    HibpDownloader.cpp \
    : No file descriptors available

Не знаю, что тут еще можно добавить. При наложении каких-то больших diff, GNU patch утекает по файловым дескрипторам.

Имея опыт взаимодействия с GNU toolchain, я это дело творчески закостылял - сам распилил diff на кусочки, и применил их с помощью того же patch, но по одному:

https://github.com/pg83/ix/blob/main/pkgs/bld/patch/patcher.py#L26-L27

Мораль?

По возможности, держитесь от кода от проекта GNU как можно дальше.

Больше всего проблем с обновлением #musl (https://t.iss.one/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/всратых макросов/порядка включения заголовков.

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

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

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

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

Недавно рассказывал про то, как интересно у меня сломался #GNU patch, при сборке keepassxc - https://t.iss.one/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

Будни #bootstrap

https://t.iss.one/itpgchannel/1640
https://t.iss.one/itpgchannel/2210
https://t.iss.one/itpgchannel/471

Вот, кстати, вспомнилось, в продолжение этих трех (!) тем.

(Меня, кстати, иногда удивляет своя последовательность в этом безумии, год от года ничего не меняется, пилю граф площе и площе, отрывая лишнее маленькими кусочками, но это так, в сторону)

Недавно вышла новая версия makeinfo, от проекта GNU, и я решил, что не хочу пересобирать world еще и из-за этого, и, вместо makeinfo, начал подсовывать в сборки свою заглушку - https://github.com/pg83/ix/blob/main/pkgs/bld/texinfo/ix.sh

Тем более что документацию в формате texinfo пишут только сумасшедшие #GNU фанатики, ну и, как я уже однажды писал, она всегда доступна в веб, а если надо, то можно собрать нужный таргет и с настоящими makeinfo.

Будни #bootstrap

Клал я новую версию libunistring (это такое оверинжиниренное говно для работы с unicode, от проекта #GNU), и там что-то сломалось под aarch64.

Что именно, для рассказа неважно, там в тестах заюзали непортабельную хрень, решил я это, как обычно, грубо и эффективно - https://github.com/pg83/ix/blob/main/pkgs/lib/unistring/ix.sh#L26-L27

Пока я с этим разбирался, наткнулся на смешной комментарий в коде:

/* Work around clang bug <https://github.com/llvm/llvm-project/issues/104670> */

"clang bug" от сумасшедших GNU мейнтейнеров - это должно быть очень весело, подумал я!

https://github.com/llvm/llvm-project/issues/104670

Там, действительно, какое-то несоответствие между тем, как работает gcc, и как работает clang (macro expansion в pragma - должно или не должно случаться?)

Мне очень понравилось, как коллега аргументирует, что это именно баг в clang:

"I claim that this is a bug, because

* With "gcc" instead of "clang", it works fine.
* The documentation at https://gcc.gnu.org/onlinedocs/gcc/Weak-Pragmas.html does not mention effects of macro definitions"

Сука, в этот момент я, конечно, взорнул, да.

Правда, там чуть ниже есть настоящая причина, почему это баг (standalone пропроцессор в clang работает не так, как если бы он был встроен):

"* If I preprocess main.c before compiling it, it works fine as well"

Наверное, у коллеги просто такое специфическое чувство юмора.

Еще забавно, что в этот тикет набижал главный мейнтейнер gcc, и рассказал эту печальную историю, откуда пошло такое поведение - https://github.com/llvm/llvm-project/issues/104670#issuecomment-2294994641 (спойлер - все грустно).

Оказалось, что https://github.com/pinskia регулярно набигает в багтрекер llvm, и рассказывает, где clang и gcc не совпадают, очень хорошее дело, я считаю.

А пока я вспоминал, кто же такое pinskia, наткнулся на замечательный срачик Тео Де Раадта с мейнтейнерами gcc, про его скорость - https://gcc.gnu.org/legacy-ml/gcc/2004-03/msg00011.html