До последнего времени у меня не было weak зависимостей, потому что я нутром чую, что вот эти вот "provides xyz" - это одна из упячнейших упячек пакетных менеджеров.

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

У меня есть механизм для "рихтовки напильником" получающихся #realm. Каждый пакет может положить в папочку ${out}/fix/ какой-нибудь sh-скрипт, который система дернет при построении realm, содержащего этот пакет. Для чего это нужно:

* Некоторые пути мы знаем только в момент формирования #realm - например, путь к WebProcess для webkit браузеров.

* xdg пути. Это набор путей для широкого круга задач - для поиска шрифтов, иконок, тем курсоров, и так далее. Они не известны на момент построения пакета, который будет использовать эти assets.

* glib xml schemas. Не спрашивайте.

В итоге, я пока сделал, что weak-зависимость - это тест на наличие того или иного файла в получающимся realm.

Ну вот, реально, кладем в fix/ файлик check-xdg-open.sh, в котором написано

test -f bin/xdg-open

А дельше уже задача пользователя выбрать ту или иную реалзиацию xdg-open, подходящую его нуждам.

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

Дальше, конечно, Остапа понесло, потому что получился очень "широкий" механизм.

Например, как проверить, что пользователь установил нужный шрифт в realm?

Не нужно выдумывать новую иерархию фиктивных пакетов, достаточно просто дернуть fc-list, или что-то похожее, и посмотреть, есть ли подходящий ответ. В рамках вычислительной ноды, подготоваливающей этот realm.

Идею хуков в fix/ я подглядел в nixos, творчески ее переработав.

Выглядит это примерно так:

ENTER /mix/store/NObQBw2XIB4XeIFG-rlm-gui
+ test -d fix
+ read l
+ find fix/ -name *.sh
+ sh fix/wrap-xdg-transmission-gtk.sh
+ read l
+ sh fix/check-bin-xdg-open.sh
can not find bin/xdg-open, install 
    providing package into realm

Чем больше я про это думаю, тем больше мне нравится моя реализация:

* это тест, как я люблю

* этот тест проверяет ровно то свойство, что нужно, не больше, и не меньше

* никаких "мамой клянусь, мой пакет реализует спецификацию xdg-open!"

* нового механизма нет, а нужная функция выполняется. Это особенно ценнО, стараюсь держать свой toolbox небольшим.

#vendor

Забыл тогда написать про еще одну важную причину заниматься де-вендорингом.

Завендоренный код, чаще всего, собирается просто не так, так мне(или другому мейнтейнеру) нужно.

Происходит это в силу того, что просто очень сложно прокинуть весь ворох необходимых настроек от корня до проектов второго и ниже уровней. Поэтому они будут собираться "как-то", а именно, как позвал cmake/meson/etc оунер проекта первого уровня.

Ну, вот, например, если оунер проекта предполагает динамические связывание, то он и cmake для завендоренного проекта позовет с настройками для динамического связывания.

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

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

Примеры таких свойств, помимо типа связывания - оконная система(X11/Wayland/both), аудио стек, и так далее.

В той же телеге пришлось патчить значительный объем сборочных файлов, чтобы X11 был не нужен даже для сборки(напомню, у меня wayland only), ну и pipewire было не очень просто выкорчевать.

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

Как бы я ее не любил, Fedora - это локомотив развития десктопного Linux, поэтому решения, принятые в рамках ее развития, важны.

* fedora окончательно переходит на wayland, даже с дровами от nvidia. Это хорошо, свистопляски вокруг X11 vs. Wayland порядком надоели. Wayland, конечно, не сахар, но X11 это же вообще тихий ужас.

* #fontconfig писал как-то про выбор дефолтного шрифта для mix(выбор, фактически, у меня был между noto и ibm flex). Fedora переходит на Noto с Dejavu, и это прямо очень, очень хорошо.

* "В исполняемые файлы и библиотеки в формате ELF добавлена информация о том, к какому rpm-пакету принадлежит данный файл" Интересно, как скоро они придут к модели macos, где, по умолчанию, неподписанный external код запускать вообще нельзя.

*Судя по списку пакетов, некоторые из которых literally вышли неделю назад, fedora - это прямо bleeding edge, КМК, они даже перестают притворяться, что туда попадает хоть как-то оттестированный код.

———
https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html #vendor #npm

В crates.io попал вредонос.

crates ничем не лучше в этом отношении, чем pypi или npm, или любой другой per language repo, ничего удивительного в этом нет.

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

Это все всем давно известно, и никому не интересно.

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

Я для каждого пакета, который кладу в дистрибутив, ищу его дубликаты, нахожу обязательно "оригинал". КМК, мимо меня вот такой вредонос не прошел бы.

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

Смешных картинок в ленту!

https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1

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

Прикольно, но мало, систему на этом пока не построить.

Очень интересно, имеет ли к этому отношение давешний хак нвидии.

Я думаю, как минимум, это хорошо продвинет nouveau(напомню, что одна их основных(и нерешаемых ранее) их проблем - power management).

Нашел на просторах интернета красивое.

https://github.com/jasperla/openbsd-wip/issues/86

О судьбе форка firefox Pale Moon в OpenBSD.

TL;DR - коллеги, с точки зрения оунеров Pale Moon, криво портировали браузер, и поэтому не имеют права на официальную символику Pale Moon.

В комментарии пришел, натурально, БОЕВОЙ ДАЛЕК, и сказал, что все должны obey его rules, и obey его license. Exterminate!

Реально, я совсем не утрирую:

"You must comply with the directive or you must disable official branding for your builds."

Тред фееричный, прочитайте обязательно.

———
https://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Забавный текст про историю /bin, /sbin/, /usr/bin, /usr/sbin, /opt, /usr/local в unix.

В #mix есть только /bin, которая symlink на /mix/realm/system/bin, и /usr -> /. Потому что очень много скриптов полагается на наличие /usr/bin/env, и менять это дорого.

Кстати, в этом месте у меня довольно серьезное отличие от nix и guix, если я все верно понял.

nix, guix стараются прописать конкретные пути к выполняемым бинарям(это верно? поправьте, если я неверно понял), а я объединяю наборы пакетов в realm, и замыкаю их PATH на bin/ в этом realm. Получается, можно собрать разные realm, в которых один и тот же пакет взаимодействует с другим внешним окружением.

Cамое простое, можно набор скриптов запустить с coreutils, а можно с busybox. Или с разными версиями интерпретатора python.

Мне кажется, так более composable.

———
Короткое дополнение ко вчерашней теме, #vendor, #npm

То, как устроены per language repo, не помогает мейнтейнерам решать задачу по фильтрации всякого вредного говна.

Схема с мейнтейнерами работает, когда мейнтейнеров мало, они trusted, и дорожат своей репутацией. Если мейнтейнеров много, то они точно так же untrusted, как и оунеры кода, и увеличение числа причастных к процессу людей только увеличивает вероятность факапа.

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

Нужен какой-то компромисс, чтобы те же crates.io/npm/pypi составляли рекомендуемый набор версий, чтобы его можно было относительно легко аудировать внешними силами.

Ненавижу #cmake.

Это самая худшая система сборки ever.

* Она не умеет в кросс-компиляцию, писал об этом неоднократно #cross

* Фактически, cmake - это интерпретируемый язык с смесью синтаксиса qbasic и cobol, на которой можно как-то написать кривую и косую систему сборки, потому что язык turing complete.

Сложность скриптов на cmake ограничивается только всратостью самого языка, и ничем более.

У разработчиков QT, видимо, было очень много времени на то, чтобы разобраться с cmake, и сделать все самым ненатуральным возможным образом.

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

https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, вот она

Ее поведение можно переопределить 10 разными способами, например

https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#variable:CMAKE_SYSTEM_PREFIX_PATH

https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_IGNORE_PATH.html#variable:CMAKE_SYSTEM_IGNORE_PATH

find_package() в cmake содержит в себе 10 настроек для этих 10 переменных, https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package - искать по "NO_CMAKE_".

Каждая из которых каким-то нетривиально-всратым образом меняет семантику find_package.

Долбоебы из QT решили, что и этого им мало:

* они переопределили поведение по умолчанию, чтобы либы из QT не искались в CMAKE_PREFIX_PATH

* Они завели себе переменную QT_ADDITIONAL_PACKAGES_PREFIX_PATH, на замену CMAKE_PREFIX_PATH

* Они завели себе переменную, выключенную по умолчанию, которая возвращает поведение к "нормальному"(насколько это возможно в cmake вообще) - QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES

Я НЕНАВИЖУ, когда у программистов заканчивается работа, и они начинают маяться хуйтой.

———
Хозяйке на заметку.

Я потихоньку профилирую свой Linux, ищу, что и где плохо лежит происходит не так, как мне нравится, и починяю.

Вот, возможно, пригодится.

#foot по умолчанию запускает ncpu threads для параллельного рендеринга.

Но мы-то знаем, что дисперсия времен ответов от большого числа источников(иными словами, барьер на синхронизацию событий "мы все сделали!") штука опасная, и может быть большой. Например, потому что #scheduler в Linux - говно. Тем более, если запускать по 16 render threads. Ну и памяти под стеки они жрут прилично.

TL;DR - если убрать вообще все worker threads, и оставить только main, скорость рендеринга не меняется никак(проверяем с помощью cat на большой файл, с ansi escape codes)

Тащемта, понятно, откуда там взялся многопоток - автор foot, очевидно, испытывает комплекс перед #alacritty, и ему нужно были эти эфемерные 10% ради собственного спокойствия.

А вам я рекомендую ставить workers=0 в конфиге, работает так же, памяти жрет меньше.

Задачка на бутстрап.

pg-> cat run.sh 
while read l; do
    echo ${l}
done
echo "ЖОПА"
pg-> 
pg-> cat run.sh | bash
echo "ЖОПА"
pg-> 
pg-> cat run.sh | sh
ЖОПА
pg-> 

Что тут за WTF, и почему так?

———
Как вы все знаете, я очень уважаю процесс регулярного "better".

Поэтому я к своей пакетной базе отношусь не как к упаковке стороннего кода для кого-то, а как к полноценной монорепе.

Поэтому, конечно, ее не избежал процесс "better", и я не стесняюсь исправлять то, что сделано криво, или не работает вовсе.

Вот есть такая библиотека - https://github.com/jtanx/libclipboard.

Кросс-платформенная абстракция над clipboard, с поддержкой Linux, WinAPI, macOS.

К сожалению, в Linux поддерживается только X11, а Wayland - не поддерживается.

Не знаю, может, автору лень, а может, он просто забил.

Библиотека сделана криво.

* Если нет X11, то она просто не собирается

* А можно было бы сделать бекенд в памяти. Ну, чтобы оно собиралось, программы компилировались, и работал бы clipboard в рамках одного приложения, уже немало.

* Для души можно было бы поддержать clipboard от mc - это когда мы просто пишем в текстовый файлик в .config/mc/

А от этой библиотеки зависит https://github.com/magiblot/turbo, и он мне нравится.

Запилил https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/clipboard/fake/clip.cpp

Это не форк, это полная реимплементация существующего API. Пока я сделал в памяти, надо бы запилить в .config, ну и на wayland можно попробовать замахнуться.

"better!"

Мне иногда пеняют, что я не мержу свои изменения в trunk. А как их мержить, если trunk - это странное поделие на C, а, как знают мои читатели, в С не завезли хеш-таблицы(ладно, завезли, но использовать их запрещающе сложно).

Хочет кто-нить попробовать? Почет, слава, полезный код в OSS!

Будни бутстрапа.

Собирал себе qimgv, посмотреть, что там за чудо-скейлер на opencv(TL;DR - чуда не заметил).

qimgv падал при просмотре любой картинки, где-то в недрах exiv2.

TL;DR - кусок кода из exiv2:

#if __cplusplus >= 201103L
  #include <memory>
  #include <sys/types.h>
  #ifndef  _MSC_VER
    #include <unistd.h>
  #endif
  template <typename T>
  using auto_ptr = std::unique_ptr<T>;
#endif

У вас бывает при чтении чужого кода ощущение "взять, и уебать"? Вот это оно.

Коллега собирает либу в с++11, там используется std::auto_ptr, а клиенты используют в любом, в котором захотят. И у них часто используется std::unique_ptr.

По сути, reinterpret_cast из одного типа в другой.

Видимо, в каких-то комбинациях libstdc++/g++/etc это даже работает, а у меня вот падало.

Я напихал автору за щеку сделал так, что там всегда auto_ptr, даже когда он недоступен в том режиме сборки, в котором собирается клиент, через "#include <__memory/auto_ptr.h>"

Если кто-то хочет, то это хорошая задачка на запатчить что-нить в OSS, перейдя на std::unique_ptr в коде exiv2.

———
https://www.reddit.com/r/cpp/comments/unik91/acceptance_review_for_boostmysql_has_just_started/

Не могу не поделиться - в boost едет клиент для mysql.

Впрочем, и хер с ним, кажется, мы(как индустрия) уже пришли к консенсусу, что в новых проектах boost использовать не нужно.

———
Я решил себе собрать gnome Files, оно же nautilus. Сейчас у меня нет gui-шного file manager, а, наверное, нужно.

Список зависимостей базовой библиотеки:
https://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-desktop.html

У меня, конечно, потекла кровь из глаз, когда я увидел "GTK+-3.24.33, GTK-4.6.3"

Знаете, я, наверное, смогу собрать даже и ТАКОЕ, но что-то пока не хочется.

А #gnome пускай продолжает в глаза долбиться.

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

Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".

У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo

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

А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH

Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.

Возможно, я тут упустил какую-то интересную часть истории, расскажите.

———
Я решил устроить фичекат в своей пакетной базе. #mix

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

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

Смотрите.

Довольно часто рядом с библиотекой лежат какие-то данные.

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

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

Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14

Это будет выглядеть весьма криво в случае сборки .so файлов.

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

Короче, я пока решил это дело пофичекатить.

Мне тут в комментариях посоветовали вместо gnome files собрать https://wiki.lxde.org/ru/PCManFM #pcmanfm

Мне это показалось хорошим вариантом, часть LXDE, ни от чего не зависит(ну, почти), на вид выглядит не очень страшно.

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

Замечания по ходу процесса:

* libfm для сборки потребовало gtk-doc, причем практически неотключаемым образом.

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

Небольшое лирическое отступление. Проекты на GNU #autohell требуют для построения configure наличие dev части некоторых зависимых пакетов, даже если ты потом не захочешь использовать этот пакет, и отключишь его через —disable-XXX.

Поэтому зависимость от gtk-doc я пока решил так - у меня корректно собирается и устанавливается часть gtk-doc, нужная для генерации autohell скриптов, а вот потом, если не позвать —disable-gtk-doc в configure, все будет взрываться самым неприятным образом. Я, конечно, нужный —disable- зову.

* libfm потребовала некую libmenu-cache, которая потребовала libfm. Я тут немного прифигел, но таки да:

https://github.com/lxde/menu-cache

"Since version 0.7.0 the Libmenu-cache requires Libfm-extra for the menu-cache-gen menu cache generation binary. Since Libfm depends on Libmenu-cache, there is some hint for bootstrapers how to build those libraries together: you need create Libfm-extra first, you can easily do this by passing '--with-extra-only' option to configure script and installing Libfm-extra."

С моей точки зрения:

* коллега нагадил посреди комнаты

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

"А что подумал по этому поводу Кролик, никто так и не узнал, потому что Кролик был очень воспитанный"

(нет, Кролик был в ахуе, и выпал в осадок так-то)

* К сожалению, посреди процесса сборки уже самого pcmanfm, я обнаружил, что оно таки непосредственно зависит от X11, и я не могу это собрать и использовать.

Сначала я решил, что ну и хер с ним, но потом внимательнее посмотрел на код, и понял, что могу изящно обойти эту зависимость от X, потому что она используется только если запустить этот FM в качестве X Desktop.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/pcmanfm/mix.sh#L34

По сути, мне пришлось заменить один файлик размером 200К на несколько заглушек. Попрошу отметить, как я изящно расставил abort() в некоторых местах, чтобы быть уверенным, что мы не обсчитываем мусор. Все очень надежно!

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

Самое неприятное, конечно, в другом: #libmagic

Я успел прочитать часть кода, связанную с mime info, и с запуском приложений. Код рыхлый, неприятный, видно, что проект затащили грубой силой. Знаете, вот возникает момент, когда надо выделить функцию, а ты все равно в 10 местах вставляешь еще 1 if.

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

Пока отложил в сторону.

Я вчера написал, что не буду дочинивать #pcmanfm, но я был бы не я, если бы не взялся дочинить. Тревожный зуд что "что-то не работает" - штука такая. #debug

Прорвался сквозь сложносочиненный код для детектирования mime types, и выяснил нечто совершенно феерическое.

Если в одну программу слинковать lib/glib + lib/magic, то magic_buffer() начинает возвращать nullptr, а если без lib/glib - то "application/gzip" на данные для случайного .gz архива.

Это очень всрато, и, по сути, такое возможно только если с glib приезжают символы, которые оверрайдят какие-то weak символы в программе.

В процессе поиска я было отчаялся, но нашел флажок MAGIC_DEBUG, который выводил на экран запчасти от того, как работает #libmagic. Я там, почти случайно, понял, что:

* в libmagic есть правила на регулярках

* она их применяет линейным перебором, что, само по себе, пиздец

* libmagic ломается на первом же правиле с регулярками. Тут у меня, что называется, щелкнуло, и пазл сложился.
Вместе с glib приезжает libpcre, в составе которой есть библиотека libpcreposix.a, которая содержит в себе реализацию posix regex.x - regcomp/regexec/etc.

* (к слову, pcmanfm 4 раза дергает функцию для определения mime type для каждого файла, причем 2 раза из них реально считывает данные с диска)

Получалось так, что код собирался с определениями из musl regex.h, а линкер брал символы из pcre.

gdb) b regexec 
Breakpoint 1 at 0x2bf0cf: file src/pcreposix.c, line 328.
(gdb) b regcomp 
Breakpoint 2 at 0x2bef33: file src/pcreposix.c, line 274.

Ни к чему хорошему это не приводило, в том числе, ломался и libmagic.

Я это починил, mime types заработали.

Ура? Пьем шампанское? Ага, конечно.

После пересборки world сломался браузер(напомню, что я использую epiphany).

Уже примерно понимая, в чем дело, я поставил breakpoint, и снял вот такой трейc:

#0  0x0000000008650e70 in regexec ()
#1  0x0000000007dd061b in optConfStartElem ()
#2  0x000000000857acb7 in doContent ()
#3  0x0000000008578394 in contentProcessor ()
#4  0x0000000008573ab6 in XML_ParseBuffer ()
#5  0x0000000007dcf4fb in parseOneConfigFile ()
#6  0x0000000007dcf33b in driParseConfigFiles ()
#7  0x0000000007d117a9 in loader_get_user_preferred_fd ()
#8  0x00000000068d74c9 in dri2_initialize_wayland ()
#9  0x00000000068d266a in dri2_initialize ()
#10 0x00000000068c4d99 in eglInitialize ()

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

Потому что, когда в glib была зависимость от pcreposix, ломался разбор конфига в mesa, и поэтому #zink (мой opengl driver) работал just as planned!

А когда я починил регулярки, конфиг начал обрабатываться правильно, и #zink начал глючить c новыми настройками!

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

Что с этим делать, пока непонятно.

https://discourse.llvm.org/t/rejected-rfc-stop-defining-the-stdc-and-related-macros-in-c-mode/62468/3

Коллеги из LLVM хотят перестать дефайнить

__STDC__

в С++ коде.

В целом, понятная штука, интересным мне показалось следующее:

* llvm обнаглели, пишут, что им уже и не обязательно поддерживать совместимость с gcc на уровне препроцессора. КМК, это плохо, потому что нам больше работы, только потому, что кому-то не нравится, как пишутся два макроса.

* https://sourceware.org/pipermail/libc-alpha/2022-May/138738.html - удивительный факт, я ожидал, что glibc пошлют их в пешее эротическое с этим предложением, но нет, вроде, приняли нормально.

Баланс сил меняется.

Мне, признаться, больше нравилось, когда clang/llvm были догоняющими, было видно, что с ними легче договориться.

———
https://blog.tmm.cx/2022/05/15/the-very-weird-hewlett-packard-freedos-option/

Совершенно феерическая история про опцию "freedos на новом ноутбуке" от HP.

TL;DR - freedos запущена в VirtualBOX в Linux, а еще там рядышком 32-битный старый Linux, для запуска pdf просмотрщика с условиями лицензии.

Программисты-археологи? Привет, Вернор Винж?

———
Починял #mesa.

В итоге, я решил, что проще всего собрать mesa с заглушками regexec/regcomp, которые бы имитировали то поведение, которое было "без бага"(не буду аргументировать, что оно "правильное")

fun fact - в mesa уже есть похожий define, https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/xmlconfig.c#L46

К сожалению, он про то, чтобы все регулярки "сработали".

А мне, судя по анализу исходников(заголовок от musl + .a от pcre), нужно, чтобы все регулярки "не сработали":

https://github.com/runtimejs/musl-libc/blob/master/include/regex.h

https://github.com/luvit/pcre/blob/master/pcreposix.h#L56

Поэтому я запилил вот такую фейковую regex.h - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/fakes/mix.sh

Вроде, теперь и #pcmanfm работает, и epiphany.

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

А может, все же, STALIX? #mix

Читал тут, на ночь глядя, unixporn. Нет, это не pornhub, и не xvideos.

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

Глаз зацепился за https://www.reddit.com/r/unixporn/comments/ut0g7u/kde_catppucin_with_mac_fonts/

Там коллега, на голубом глазу, утверждал, что использует под Linux шрифты из macOS.

Я удивился, потому что думал, что эти шрифты не отчуждаемы.

Но нет, вот они, любой желающий может скачать - https://developer.apple.com/fonts/

Маленькая загвоздка - они в dmg формате, а это, по сути своей, образ HFS+, если я ничего не путаю.

Гугление подсказало, что с dmg умеет справляться 7z - https://askubuntu.com/questions/38112/how-can-i-open-a-dmg-file

Проблема в том, что с dmg умеет справляться только "большой" 7z, а 7za - не умеет. 7z у меня не был собран, потому что он в процессе работы использует две подгружаемые .so - 7z.so, и rar.so.

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

Короче, TL;DR - по моей классификации, это "всратейшая" система с #plugin, потому что там экспортируются какие-то левые символы с данными, функциями, .so при загрузке выполняет конструкторы, которые себя где-то регистрируют, и так далее.

Так же, как у меня уже было в #quake 2, обе .so и main driver пересекаются по обжам и по символам. Я и поступил так же - переименовал все символы, написал mapping для моего загрузчика, и все! https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/p7zip/z/mix.sh#L29

Забавно, по мере роста пакетной базы и развития инструментария, все это становится все проще и проще. Правда, мой идеал - по compile database вывести все нужные правила для перелинковки, пока еще далеко.

А что шрифты? А шрифты я загрузил, там, внутри dmg лежит pkg, который тоже нужно разжать с помощью 7z. А внутре лежит какой-то файл, который можно разжать только с помощью bsdtar.

Вот такая вот смерть кащея. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/aux/fonts/sf/pro/mix.sh

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

#mesa, у меня бомбит

Я как-то говорил, что mesa довольно неплохо написана.

Хочу дезавуировать это утверждение.

Она написана поверхностно хорошо, но, благодаря процессам разработки, это примерно такой же всратый кусок говна, как и ядро #linux.

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

Слабоумие и отвага!

У меня последний рабочий релиз mesa был 22.0.1, при переходе на 22.0.2 наблюдались артефакты в epiphany.

Я, наконец-то, нашел время побисектить это говно, начитался и кода, и коммитов.

Полюбуйтесь, причина поломки - https://gitlab.freedesktop.org/mesa/mesa/-/commit/bbd7f4ff9761b5a2bb5bfb4e56effe204457c3d1

Чувак разделил файл с настройками на два. При этом:

* Новый файл никто не читает. Как, Карл!?

* Поломан код от google, добавленный в 21 году, про вкомпиливание этого конфига в бинарь. Тесты, блядь, где на это? https://github.com/mesa3d/mesa/blob/main/src/util/xmlconfig.c#L39

* Самое интересное, отделенные данные, по идее, никак не должны влиять на связку zink + radv, нет там про это записей. Я предполагаю, что, из-за того, что убрали секцию про radv, там не сработал код по установке дефолтных значений, но это неточно. Второе предположение - что zink наследует настройки d3dvk, или что-то в этом роде.

Я объединил эти два файла взад, в 1 большой - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/t/merge.py

Причем не регулярками, а нормально попарсил xml! Кто молодец?

Вообще, насмотрелся в их трекере разного.

Например, tar.xz от релиза 22.0.4 появился раньше, чем был отведен релизный бранч под него. Как?!?

Стабильные бранчи бывают тупо сломаны посредине, что доставляет при бисекте.

Школота.

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

It is settled. #stalix #ix #mix

#stalix - новое название дистрибутива
#ix - новое название пакетного менеджера

Теперь OS и пакетный менеджер называются по разному, во избежание неоднозначности.

Actually, КМК, stalix объективно самое лучшее название.

Посудите сами:

* STAtically LInked LInuX - какое-то дикое пересечение акронима и того, что сокращаем.

* Звучит очень "чисто", "звонко" и "сочно".

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

Меня удивило и ободрило, что так много людей посчитало, что stalix - норм.

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

Получил два вполне подходящих мне мнения:

* Всем похуй.

* А тем, кому не похуй - они сделают хорошую рекламу на reddit. Все, что не некролог, как известно, хорошо.

"IX" - пересечение "stalIX" и "unIX", хочу, чтобы название подчеркивало цель быть пакетным менеджером не только для OS stalix, а вообще, для unix-like OS.

Ну и, конечно же, интересная история, которая со мной случилась в момент перименования.

Я сначала сделал ln -s /mix /ix, потом сделал полный ребилд всего и вся по новым путям.

А потом я сделал "./ix gc", и вот тут-то случилась жопа.

gc - это была одна из команд, которую я не перенес в граф, и она выполнялась бинарем пакетного менеджера, в котором я не переименовал mix в ix.

Поэтому он посчитал, что корней для gc нет, и снес все пакеты в /mix/trash/

А я напомню, что у меня раз в 100 секунд запускается процесс, который очищает корзину, это такая оптимизация, чтобы делать это async.

Кажется, я секунд за 10 успел:

* в открытом MC найти в trash бинарник busybox

* c помощью этого бинарника вернуть все пакеты в /ix/store/

* тут мне очень помогло, что у меня предусмотрительно на пятом tty запущена рутовая консоль без логина, для подобных аварийных случаев. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mingetty/runit/ix.sh#L9

Это был первый раз с нового года(а я под новый годе переехал на mix полностью), когда я был близок к потере установленной системы.

Но все обошлось, пути я поменял!

https://groups.io/g/simh/topic/new_license/91108560
https://github.com/simh/simh/issues/1059
https://www.reddit.com/r/linux/comments/uua97p/unix_emulator_project_maintainer_removes_foss/
https://www.reddit.com/r/emulation/comments/ut0uvn/maintainer_of_open_source_emulation_software_simh/

Читал последние несколько дней, наконец, дочитал, пишу.

Совершенно феерический тред про взаимодействие автора simh4, форка simh3 - симулятора разных древних аппаратных архитектур, типа PDP-11.

Автор симулятора запилил довольно controversal фичу - начал дописывать к raw images с образами OS свою метаинформацию в конец файла.

Спорная вещь, учитывая, что raw image это не его приватный формат, который он может менять, как ему угодно.

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

Откатывать это он отказался, люди начали форкать его поделие. Автора simh4 это возмутило до глубины души, и он поменял лицензию на свой код в этом проекте. Что, начиная с ревизии X, ты не имеешь право менять такой-то файл, функцию такую-то. А если поменял, то не имеешь права пользоваться кодом автора, начиная с ревизии X.

По ссылкам - мега-срач по этому поводу. Там все хороши.

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

ЖЫР, цирк с конями, и вообще, красивое.

Совершенно феерические рекламы 80-годов про продажу компьютеров.

Да, я сексист, мне нравится, идите в жопу.

https://rarehistoricalphotos.com/vintage-computer-ads/

(КДПВ следующим постом, телега почему-то не дала объединить)

fun fact - мои любимые NB совсем не поменялись с 85 года!