https://github.com/terraform-aws-modules/terraform-aws-eks/pull/1937#issuecomment-1070958276

Антон таки внял голосу разума, и убрал некорректное изменение в лицензии Apache. Теперь тот самый текст - просто комментарий в README.md, без юридических требований. https://github.com/terraform-aws-modules/terraform-aws-eks#additional-information-for-users-from-russia-and-belarus

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

Сегодня ссылочный блог, звиняйте.

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

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

В современном мире компания, которая делает браузер в качестве основного продукта, не жилец.

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

———
https://lkml.org/lkml/2022/3/17/964

Rust в Linux, v5. #linux_kernel_rust

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

Но сейчас Линус уже старый и сытый, и не хочет кусать руку, которая его кормит, поэтому послать в жопу то, что не осилил понять(речь про С++ и Rust, а я смею заверить, что критика тогдашним, молодым, Линусом, C++ - ну так себе) уже не выйдет.

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

Вот такой вот я злобный и злопамятный С++ программист.

https://www.cnews.ru/news/top/2022-03-18_razrabotchik_samoj_populyarnoj

Пиздец, 5000 человек будут дистр Линукса клепать... Даже мне будет сложно с ними конкурировать.

https://asahilinux.org/2022/03/asahi-linux-alpha-release/ #asahi

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

———
Новости бутстрапа.

Мне понадобилось собрать yasm.

* У него есть две системы сборки - новая, на cmake, и старая, на autohell. Как я уже говорил, cmake не умеет в кросс-компиляцию, а yasmу нужно в процессе сборки себя построить парочку хостовых инструментов. Сборка на autohell про это знает и поддерживает, поэтому we are stuck с autohell.

* yasm вендорит очень старый re2c, родом из 2003 года. Я так понимаю, потому что это одна из последних версий до перехода re2c на С++. Этот re2c падает в процессе сборки:

  GEN      genmacro
  GEN      genversion
  GEN      genstring
  GEN      genperf
  GEN      re2c
make: *** [Makefile:4426:
    gas-token.c] Segmentation fault
make: *** Deleting file 'gas-token.c'
make: *** Waiting for unfinished jobs....
make: *** [Makefile:4429:
    nasm-token.c] Segmentation fault
make: *** Deleting file 'nasm-token.c'

причем каким-то очень всратым образом(за 15 минут я не раздебажил). Я решил, какого хрена, и собрал самый старый доступный re2c из реп - https://github.com/skvadrik/re2c/tags?after=0.13.7.2

После небольшой магии с патчингом сборочных файлов(https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/yasm/mix.sh#L21), оно собралось и заработало. Замечу, re2c 2013 года отработал грамматику 2003 года, good, good.

* Я решил на этом не останавливаться, и собрал современный re2c. Он тоже корректно отработал грамматику 2003 года выпуска, поэтому промежуточный re2c я выпилил.

Отдельно хочу рассказать про re2c:

2003 год - 10 файлов на C.
2013 год - 5 файлов на С++.
2022 год - 250!!! объектных файлов из исходников на С++. Сука, 250!!! Они там написали свое вообще все, что можно - регулярки, парсера, utf8, все.

Я уже как-то, когда рассказывал про #ncurses #Хуйкин, писал, что, когда проект, по сути, завершен, и программисту нечего делать, то он начинает вылизывать себе яйца этот проект возможными и невозможными способами.

Ничего хорошего тут нет, это code bloat, и отсюда стремление вменяемых людей запилить что-то типа suckless.org, или вот мой mix.

Веселых картинок в ленту

Про лицензии.

https://news.ycombinator.com/item?id=30710032

Мое первое появление на Hacker News. Не ожидал, что оно будет именно таким.

https://beny23.github.io/posts/on_weaponisation_of_open_source/

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

https://lwn.net/Articles/888453/

Связь всего этого УГ с #GPL.

———
https://www.undeadly.org/cgi?action=article;sid=20220320115932

Без всякой помпы анонсирован порт OpenBSD на Apple M1. On par с #asahi Linux, судя по тексту.

———
https://philippegroarke.com/posts/2018/c++_ui_solutions/

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

К сожалению, идеальной библиотеки виджетов я для себя пока не нашел :)

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

Включил p-states на своем ноуте, получил систему, близкую к freeze. Все работало раз в 10 медленнее, чем полагается. Возможно, все ядра были в режиме глубокого энергосбережения, непонятно только, почему

———
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/sdl/2/mix.sh#L26

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

Как вы думаете, что делают эти странные настройки *_SHARED=OFF?

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

Они отключают очень странный механизм в SDL - загрузку внешних зависимостей через dlopen/dlsym.

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

Потому что в системе появляется новая, более приоритеная .so для загрузки.

#mesa, свет моей жизни, искры на кончиках пальцев. Грех мой, любовь моя. Me-sa.

Для ее сборки была разработана ныне очень популярная система сборки - #meson, и, на самом деле, это очень печально, потому что разработчики Mesa слишком хорошо знают meson, и пользуются любыми всратыми ее фичами.

Фактичеси, Mesa состоит из 2 частей - загрузчика плагинов, который поверх интерфейса плагина реализует всякие там state tracker типа opengl, vulkan, и, собственно, плагинов.

Так как авторы Mesa слишком хорошо знают meson, то сборка Mesa выглядит примерно так:

* собирается K объектных файлов
* из них собирается N архивов, причем, что важно, есть пересечения - один и тот же .o может попасть в несколько архивов
* из этих K + N артефактов собирается M конечных .so. Тоже с произвольным пересечением по .a/.o файлам!

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

Пока это все собирается в .so, со скрытыми символами, это не представляет собой проблемы, кроме увеличения объема конечного кода и времени компиляции(потому что некоторые исходники таки переcобираются по нескольку раз).

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

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

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

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

Я подходил к задаче распила раз 5:

* попилить по .o конечный артефакт руками. Ломается о комбинаторный взрыв различных способов собрать драйвера.
* сделать так, чтобы все собиралось в несколько полностью независимых .a файлов - все упиралось в дефекты сборочный системы meson и сособенности сборочных файлов mesa - тут я пытался руками править сборочные скрипты mesa(не масштабируется на апдейты), и саму meson(тут я был ближе всего к победе, но не срослось)

Короче, пока я эту проблему решил так:

* написал generic процедуру вычитания одного .a из другого. По именам .o файлов это сделать нельзя, по причинам что я уже описал выше, поэтому все делается посимвольно. https://github.com/pg83/mix/blob/main/pkgs/lib/mesa/t/sep/substr.py

* последовательным вычитанием привел в порядок загрузчик и библиотеку с драйверами. https://github.com/pg83/mix/blob/main/pkgs/lib/mesa/t/sep/mix.sh#L29

Это гораздо эстетичнее, чем предыдущая идея с мешком обжей, и работает достаточно хорошо(по крайней мере, решает исходную задачу).

В догонку предыдущему посту про #mesa.

Забыл рассказать, что мне пришлось хачить сборочную систему mesa, потому что собрать loader с пустым списком драйверов оно не умело. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mesa/t/nodrv/mix.sh

И действительно, кому в своем уме это может понадобиться?

(кстати, я негодую, что никто не оценил эпиграф к предыдущей записи, он классный)

———
https://www.phoronix.com/scan.php?page=article&item=apple-m1-linux-perf&num=1

Первые бенчмарки Asahi Linux, в сравнении с MacOS. Я бы сказал, что там нет ничего удивительного.

1) Linux пишут жадные капиталисты для датацентров

2) MacOS - в ожидании, что там что-то выполняется редко, но метко, и важнее отзывчивость.

3) В Asahi нет управления питанием, то есть, оно шпарит всегда на максимум.

Поэтому на CPU-bound задачах Asahi несколько лучше, что хорошо заметно на моем любимом примере компиляции. Думаю, что Mac Mini M1 с Asahi на борту - это самое cost effective решение для CI сейчас.

———
LLVM weekly

Вышел clang/llvm 14! Я уже перешел на него в Mix. Впрочем, я перешел сразу на rc1, у clang хорошие тесты.

https://reviews.llvm.org/rG827575a7f853 - libc от LLVM наращивает мускулы. Она будет непригодна для bootstrap, потому что написана на C++, но вот для сборки основного дистрибутива - будет очень интересно.

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

Писать интерфейсы на C/GTK - это пиздец как сложно, там получаются просто тонны и километры boilerplate кода. Я, если честно, совершенно не понимаю людей, которые в 21 веке пишут GUI на C.

Вот, вместо того, чтобы перейти на C++/Rust, был запилен специальный язык для разработки на GTK.

Как и все от проекта #GNOME - всратое говно.

скорее бы уже

Ну и чтобы вы не думали, что автономные робаты это только Терминаторы и Дроны-убийцы...
Двойное назначение никто не отменял.

"А по вечерам я работаю в клубе".

https://www.cnews.ru/news/line/2022-03-24_bazalt_spo_predlozhila

Все же знают, почему и Альт, и Астра - упыри, не надо лишний раз рассказывать, да? #altlinux

#linux - это embedded. #scheduler

Что такое embedded? Это когда вам дают какой-то заранее собранный и преднастроенный программно-аппаратный комплекс, который выполняет какую-то функцию, и вы его используете, как черный ящик.

Я хочу аргументировать, что все известные и выстрелившие использования ядра Linux - это embedded.

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

* ядро Linux на реальных железках настраивают и эксплуатируют специально обученные люди

* вендоры предоставляют образа для запуска Linux в своих облаках

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

Можно было бы привести в пример Android, как пример "открытой" системы, но и там:

* Прошивку вылизывает вендор

* Приложения сильно ограничены VM sandbox, которая делает много магии, чтобы они все вместе работали "плавно"

Поэтому "Linux на десктопе" - это оксюморон, он последние лет 10 точится совсем в другом напрявлении. Linux - давно не "OS общего назначения".

Правда, тут стоит отметить еще следующие факты:

* macOS - это что-то типа Android по своим свойствам, потому что Apple тюнит свою OS под ограниченный набор устройств, и очень сильно ограничивает приложения

* Если поставить современную винду на современный ноут же, и поставить драйвера из интернета, а не от вендора этого ноутбука, тоже могут быть сюрпризы.

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

Удивления это не вызывает, системы становятся все сложнее, и, кажется, вот эта стадия "пуско-наладки" тоже будет все сложнее и сложнее, и без специально обученных людей будет не обойтись.

https://lwn.net/Articles/889025/#Comments
https://www.opennet.ru/opennews/art.shtml?num=56902

Вышел новый #gnome GNOME. Много недовольных.

Кто-то недоволен тем, что убрали градиенты на кнопках(я из них) - https://blog.brixit.nl/the-end-of-the-nice-gtk-button/ . Лично мне кажется, что политика "все кликабельное имеет градиент" - это очень классно, и упрощает работу с GUI.

Кто-то - процессами разработки. https://informatique-libre.be/swilmet/articles/gnome-gedit-dev-feedback.pdf

Я, как обычно, недоволен пиздежом.

"В число приложений, рекомендуемых для включения по умолчанию в установки GNOME, добавлено два новых приложения - текстовый редактор Text Editor и эмулятор терминала Console. Данные приложения используют GTK 4"

UPD: то, что console использует gtk4 - ошибка перевода новости с https://release.gnome.org/42/

Полез собрать эти чудеса, потому что в живую не видел приложений на gtk4 + libadwaita.

gnome-text-editor собирается из тега, который не прошел CI тесты. https://gitlab.gnome.org/GNOME/gnome-text-editor/-/tags

gnome-console, судя по скриншоту, собрался вообще с gtk3. Я таки попробовал собрать его с gtk4, но:

* #libvte, которая нужна для console, собирается с gtk4 только в транке, тега и релиза про это еще не было вовсе

* сам код console не рассчитан на gtk4

Ну и, куда же без этого, наткнулся на очередной errogance от разрабов GNOME: https://gitlab.gnome.org/GNOME/vte/-/issues/72

Чуваки, как обычно, форсят свою повестку - "API Linux определяет glibc"(по ссылке офигенный комментарий от автора musl, Ричарда Фелкера, про это), "мы не поддерживаем musl", etc. Технически дело в том, чтобы не использовать 1 нестандартный макрос из #glibc, все musl-based дистрибутивы патчат это место - https://git.alpinelinux.org/aports/tree/community/vte3/fix-W_EXITCODE.patch.

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

Мое мнение о разрабах GNOME падают все ниже и ниже плинтуса. Половина из них - #errogant(я тут не могу написать предлагаемый перевод "высокомерный" для этого слова, потому что IMHO значение немного другое) мудаки, имеющие свою нетехническую повестку(реально это воспринимается именно так - "мы тут знаем что API Linux - это glibc, и не дадим вам про это забывать, минорной проблемой, которую просто откажемся чинить, потому что можем").

https://lobste.rs/s/zlanqi/end_nice_gtk_button#c_usyuo5

gnome-text-editor, кстати, ничо так, чистенько, опрятненько, ничего лишнего.

Поддержку перехода на libadwaita(и "1 theme to rule them all"), кстати, я поддерживаю. Жалко только, что libadwaita пока - так себе закос под macOS, надо лучше.

История одного бутстрапа.

Решил я себе собрать какой-нить не-tiling wm. Выбор пал на wayfire, потому что картинки в интернете красивые. Похоже на compiz, если вы понимаете, о чем я.

https://github.com/WayfireWM/wayfire/blob/master/src/api/wayfire/plugin.hpp#L187 #plugins - первая проблема. Все плагины имеют одинаковую точку входа. И, к сожалению, в данном конкретном случае не получается модифицировать определение этого макроса, потому что его могут вызывать так - https://github.com/WayfireWM/wayfire/blob/master/plugins/single_plugins/autostart.cpp#L55 (нет законченного С токена, к которому можно привязаться).

Поэтому я испробовал новую для себя технику - переименование символов в готовых артефактах. В объектных файлах. https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/mix.sh#L51 В этом цикле мы пользуемся тем, что имя плагина совпадает с именем .cpp файла.

Потом по получившимся .o файлам строим структуры данных для моего "динамического" загрузчика - https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/mix.sh#L62

Ну и перелинковываем программу вместе с плагинами - https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/mix.sh#L71 Тут можно отметить вызов cc без -I/-L/-l, потому что моя система готовит враппер для компилятора со всеми нужными агрументами.

Казалось бы, все?

Нет, при старте программа начала кидаться исключением из какого-то глобального конструктора: https://github.com/WayfireWM/wayfire/blob/master/plugins/wobbly/wobbly.cpp#L152 У чувака таким странным образом сделан разбор аргументов командной строки. Плагин загружается уже после обработки конфига, и это как-то работает.

Ну, если уж начинать жестить - то зачем останаливаться? Я написал ленивый класс для обработки параметров конфига - https://github.com/pg83/mix/blob/main/pkgs/bin/wayfire/opts.h

Все тут же заработало? Какое там.

В логах и в strace это выглядит так - мы читаем конфиг, а дальше ничего не происходит. Потратил на это пару часов, чтобы выяснить, что автор этого кода конкретно сошел с ума - он пересекает множество запрошенных плагинов с множеством реальных файлов в папке с плагинами, чтобы отфильтровать несуществующие. Без записи об этом в лог, просто кидая на пол. https://github.com/WayfireWM/wayfire/blob/master/src/output/plugin-loader.cpp#L200 - в транке логгирование уже есть. Нормальные люди просто пытаются открыть файл по запросу, и пишут ошибку, если не получилось.

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

just random thoughts:

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

* У автора плагиноз головного мозга. Все сделано через плагин. Даже загрузка конфига через плагин. Кольцевая зависимость? Ничего страшного - передадим имя плагина для загрузки конфига через command line!

* Примерно половина кода проекта - поддержка перечитывания конфигурации при изменении файла с конфигом. Ну, ладно, треть. Хотя умные люди давно все придумали - общение с dbus в основном event loop.

* Для wayfire нужно было собрать https://github.com/g-truc/glm Эти упыри не только не стали делать install таргет для своей либы, но и убрали .pc файл для discover этой библиотеки, репозитариям приходится это делать вручную - https://github.com/archlinux/svntogit-community/tree/packages/glm/trunk https://github.com/archlinux/svntogit-community/blob/packages/glm/trunk/PKGBUILD#L30 Надо бы ворваться к ним в тикет, но пока нет. UPD: вломиться не получится, тикет отменили - https://github.com/g-truc/glm/issues/947

>Ну, если уж начинать жестить - то зачем останаливаться?

fun fact - я, когда страдаю "пожестить в коде", всегда вспоминаю вот эту вот сценку из Футурамы - https://www.youtube.com/watch?v=JdH3jo-A2Uw

Во внутреннем монологе это звучит как "пора обмазаться шоколадом" 😁

#обмазаться_шоколадом

llvm weekly

https://discourse.llvm.org/t/rfc-lifting-include-cleaner-missing-unused-include-detection-out-of-clangd/61228

Рефакторинг кода по очистке заголовков из clangd в отдельный инструмент. Пишут, что работает немного не так, как линтер из clang-tidy.

———
#mesa

У меня тут случилось странное - "вдруг" перестали работать приложения на Vulkan, а на OpenGL продолжали работать, хотя у меня #zink в качестве реализации OpenGL.

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

Очень удобно, когда состояние всей системы привязано к hash коммита в репозитории, и сборочные артефакты лежат в content addressable cache - bisect я запустил на неделю назад, заняло это полчаса времени(так долго, потому что нужно вручную перезапустить WM и запустить тест).

Оказалось, что дело в минорном обновлении Mesa, с 21.3.7 на 21.3.8. https://docs.mesa3d.org/relnotes/21.3.8.html

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

Это к давнему спору о том, можно ли доверять апстриму и всей технологии #semver. Нет, нельзя.

———
https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-On-Direct3D-12-Dzn-Merge

Еще новостей про Mesa. На этот раз от Collabora + Microsoft. Реализация Vulkan поверх Direct3D, для WSL. Само по себе мне это не очень интересно, но вот то, что MS последнее время серьезно коммитит в Mesa - факт.

https://www.collabora.com/news-and-blog/blog/2022/03/23/how-to-write-vulkan-driver-in-2022/ - текст от Collabora про разработку драйвера Vulkan.

———
https://old.reddit.com/r/linux/comments/thsrcp/this_was_the_first_step_in_the_interview_process/

Классный текст про собеседования в Canonical. TL;DR - они там совсем упоролись, как будто к ним очередь стоит. Ну или они нанимают для вида.

Починил таки кольцевую зависимость #harfbuzz - freetype.

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

https://git.sr.ht/~pg/mix/commit/338a5028686dd448442f796faac6bff0d0c10e75

———
В каждом увлечении есть свой священный грааль. #nvidia

(кстати, если не смотрели "Monty Python and the Holy Grail" - обязательно посмотрите)

Для меня это - статическая сборка libGL.so от Nvidia в свои программы, собранные с musl.

Если рассказать про эту задачу широкими мазками:

* https://github.com/endrazine/wcc

"WCC is a collection of compilation tools to perform binary black magic on the GNU/Linux and other POSIX platforms."

С помощью wcc можно превратить libGL.so в релоцируемую libGL.o. Вообще, сходите по ссылке, и почитайте, что умеет wcc, это действительно похоже на черную магию.

Как работает восстановление relocations, например, через таблицу plt, я не очень понимаю. Это, получается, нужно найти такие адреса, по которым записано число, совпадающее с расстоянием в этом .so от этого адреса до таблицы plt? И чтобы при дизассемблировании это оказалась jmp инструкция? Ох.

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

* Переименовать все входящие в libGL.o символы, применив к ним какой-то префикс, например, gnu_.

* Далее написать кучу boilerplate кода, который бы делал примерно следующее:

GNUFILE* gnu_fopen(const char* p, const char* m) {
    FILE* f = fopen(p, m);
    GNUFILE* gf;
    // construct GNUFILE* from FILE*
    return gf;
}

Короче, реализовать все нужные символы из glibc поверх musl, сохранив layout структур из glibc.

После этого все это добро можно слинковать в один большой бинарь, все, как я люблю.

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

В следующей серии рассказ про мою скромную коллекцию бинарных хаков, с помощью которых я постепенно приближаюсь к решению этой задачи - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bld/scripts/librarian.

https://lwn.net/Articles/889444/

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

------
https://wiki.musl-libc.org/alternatives.html

Список альтернатив mainstream software, от авторов musl(что само по себе символично). Я довольно много из этого списка использую для bootstrap, потому что оно все сильно проще в сборке.

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

Хочется иметь софт, который ты понимаешь, как работает.

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

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

В продолжении темы минимализма:

"БД пакетного менеджера RPM перенесены из каталога /var/lib/rpm в /usr/lib/sysimage/rpm с заменой /var/lib/rpm на символическую ссылку. Подобное размещение уже применяется в сборках на базе rpm-ostree и в дистрибутивах SUSE/openSUSE. В качестве причины переноса называется неразделимость БД RPM с содержимым раздела /usr, в котором фактически находятся RPM-пакеты (например, размещение в разных разделах усложняет управление снапшотами ФС и откат изменений, а в случае переноса /usr теряется информация о связи с установленными пакетами)."

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

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

Такая кривая и косая статическая линковка поверх динамической, со всеми недостатками этих подходов.

#evince #gold

Я, когда собирал evince, узнал, что в последние годы случился какой-то разумный конкурент для poppler - mupdf. Это еще один open source pdf renderer.

Это довольно удивительно, потому что xpdf/poppler сообщество пишет последние лет 30. Это не суперсложная, но довольно муторная задача. Особенно учитывая, чего adobe наворотила в pdf(там и js, и хождение по сети, да вообще все).

Библиотека называется mupdf, просмотрщик - zathura.

zathura примечательна тем, что у нее плагины живут out of tree, поэтому мои обычные техники статической линковки тут не годились.

Я вышел из положения так. Собрал zathura 1 раз, оставил от сборки только заголовки. С этими заголовками собрал кучу .a файлов, для каждого плагина. После этого собрал zathura во второй раз, имея все собранные плагины под рукой.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/zathura - вот тут можно посмотреть на все таргеты для сборки.

Конечно, дело не обошлось без треша, куда уж там.

* mupdf имеет встроенный просмотрщик, помимо библиотеки. Он использует opengl + freeglut. Какое же было мое удивление, когда я увидел в консоли вот такое:

https://github.com/swaywm/wlroots/issues/1799

Великий и ужасный(нет) Simon Ser, конечно же, послал страждущего нахуй.

Я посмотрел, что там дальше случилось в репозитории freeglut:

https://github.com/FreeGLUTProject/freeglut/issues/72

Чувак с бородой, называющий себя "I'm a hacker", ничего сделать не смог, и вообще, сказал, что вертел он этот наш Wayland, и ему на остаток жизни и X11 хватит.

Короче, c 19 года как не работало, так и не работает. Я, может, даже и взялся бы починить freeglut, но нести это в "I am a hacker" не очень хочется, он явно не заинтересован.

Зато он заинтересован в том, чтобы написать еще один freeglut - точно такой же, но только в 1 файле, потому что нормальных систем сборок в мире нет. https://github.com/jtsiomb/miniglut

* Как вы понимаете, я сразу же вбил в google "evince mudpf".

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

https://mail.gnome.org/archives/evince-list/2016-October/msg00007.html

Ну, конечно, зачем им там нужен конкурент там выстраданному poppler, поэтому, most definitely, нахуй mupdf в evince не нужен. #GNOME, чего с них взять.

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

Потом это уже нафиг никому не нужно.

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

Как, кстати, однажды произошло с проектом #GNU, потому что они считали, что пишут THE libc #glibc, и THE compiler #gcc. Про то, что они вот только недавно разрешили не подписывать бумажное CLA для разработчиков, я тут пару раз писал.

Вывод - в проекты нужно приходить на ранней стадии, и если вам интересно попилить какой-нить дистр, приходите ко мне, а не в arch/nix/fedora!

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

This site can’t be reached
gitlab.gnome.org refused to connect.
Try:

Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_REFUSED

Совпадение?