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

/usr/share - это жесть. Каждый тулкит, каждая графическая библиотека, содержит в себе те или иные хаки по поиску

* шрифтов
* иконок
* курсоров

Да, да, курсоров. Я был очень удивлен, узнав, что в wayland курсор отрисовывает клиент. Отсюда полная неразбериха в темах и размерах. В какой-то момент у меня получилось сделать так, что у меня были 3 разных размера курсора - в sway, foot, и в waybar.

Хорошее описание проблемы тут - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/58

Некто Simon Ser настойчиво отстаивает право авторов клиентов творить любую дичь. Наверное, потому что он автор одного из таких клиентов - wlroots/sway. Не верите? А пожалуйста!

Вот Simon героически скопировал в wlroots кусок wayland(а тот, в свою очередь, скопировал кусок из XCursor) по локации папочки с курсорами - https://gitlab.freedesktop.org/wlroots/wlroots/-/blob/master/xcursor/xcursor.c#L622 Зачем, я хз.

Конечно, это очень удобно - в одной шапочке писать правила и протоколы wayland, а в другой - разрабатывать sway.

К счастью, это open source, и то, что сломано одним долбоебом, всегда может быть исправлено другим. Я, конечно, у себя этот файлик обнуляю - https://github.com/pg83/mix/blob/main/pkgs/lib/wlroots/14/mix.sh#L52.

Я думаю, вы уже поняли, что #system0 - это "моя прелллесть" :)

В ней я, по мере сил, намерен исправить разные проблемы, с которыми я сталкивался по мере взаимодействия с Linux/Unix.

Одна из таких проблем - это свойство Unix по наследованию init-ом процессов, у которых умер родитель. Я считаю, что это треш, угар, и содомия(и одна из причин появления cgroups, кстати). Мне приятно видеть completely supervised tree, если вы понимаете, о чем я. Это удобно и для понимания, и для отладки. Долгоживущие процессы надо запускать через команду spawn сессионного супервизора.

Поэтому у меня есть https://github.com/pg83/mix/blob/main/pkgs/bin/killd/cycle.sh - демон, убивающий "залетные" процессы. Если это полетит, то я это, конечно, добавлю в свой init.

Кстати, убиение через SIGINT там исключительно потому, что, если sway убить через SIGKILL, то он регулярно вешает систему намертво. Вот такой классный графический стек в Linux.

К сожалению, тот же sway зачем-то запускает все процессы через double fork. К счастью, исправление - 3 строки кода.

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

Че-то уже третья новость про обновление uutils. Я имею сказать:

* Несмотря на все вбуханные усилия, среднестатичтический configure пока не работает(ну, ладно, на состояние 2 месяца назад).

* Размер busybox-style статического бинаря для busybox - 1.5MB, coreutils - 2.5MB, uutils - 10MB(опять же, на состояние пару месяцев назад, сейчас проверить не могу, потому что Rust у меня уже не запускается). Надо еще понимать, что в busybox в 3 раза больше утилит, там и cron, и dhcp, и util-linux, и так далее. Но они вообще упоротые, читать их код очень интересно.

* Зачем переписывать простой код, который и память-то особо не выделяет, я не понимаю. Какой от этого added value?

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

Это оказалось сложнее, чем я думал, потому что разработчик efibootmgr сошел с ума.

https://github.com/rhboot/efivar

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

https://github.com/rhboot/efivar/blob/main/src/include/workarounds.mk
Вот тут автор якобы поддерживает lld, но проваливаемся мы в not supported case.

Автор явно вызывает gcc-ar, вместо ar. Что, зачем...

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

Автор очень широко использует расширения gnu libc(я это называю горе от ума), мне ажно пришлось реализовать функцию qsort_r самому - https://github.com/pg83/mix/blob/main/pkgs/lib/qsort/r/mix.sh#L15. Я, конечно, тот еще кулхацкер и ленивая жопа, но сохранять контекст и реальный коллбек в пертредных переменных - это даже для меня мощно.

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

У чувака есть файлик safemath.h вот такого содержания - https://github.com/rhboot/efivar/blob/main/src/safemath.h

Он пишет эту простую утилиту непрерывно с 12 года, и ему явно стало скучно.

Короче, запускать получившийся grub мне было ссыкотно - там или все отработает, или попортит таблицу разделов, и я останусь с кирпичом вместо ноутбука, 50 на 50.

Все обошлось.

Сейчас форматирую освободившийся большой раздел под XFS(а вы знали, что старичок - все еще одна из лучших FS для Linux?), и переношу систему на него. #xfs

https://maskray.me/blog/2022-01-16-archives-and-start-lib #maskray

Рассказ про изобретение thin archive.

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

История изобретения:

Однажды вышел clang с поддержкой lto, и я очень захотел собрать с ней базовый поиск. LTO там было сделано на отъебись - компилятор мог родить .o файл с промежуточным представлением, и на этом все.

Эти объектные файлы нельзя было объединить в .a, нельзя было позвать clang для линковки. Единственное, что там было - это команда "opt", которая могла слинковать несколько lto .o файлов в 1, попутно применив оптимизации, была команда, которая делала asm файл из этого .o, а дальше можно было взять этот asm, руками сделать из него настоящий .o, и слинковать все это вместе с системным кодом, для которого нет lto .o файлов.

Короче, я на петончиге соорудил подобие архиватора и линкера из этих примитивов, и оно даже заработало. В тот момент мне стало понятно, что гораздо проще в .a запиклить* пути к lto .o, чем пиклить данные, а потом разпикливать их в fs, для запуска "opt". Так я изобрел thin archives.

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

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

* На HDD это приводило к бешеному росту iops, по понятным причинам. На ssd это менее релевантно.
* Даже на ssd остается проблема с readahead - мы читаем с диска существенно больше данных, чем надо.

Ладно, есть 1 случай, когда thin archives немного помогают. Если у вас до жопы памяти, и вы потребляете архивы сразу по мере изготовления(one shot build, например), некое ускорение можно наблюдать.

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

* - literally. pickle.dumps(sys.argv[2:]) - вот примерное устройство моего ar.

Я тут обратил внимание, что, после перехода с fedora на мою сборку ядра(и вообще, полностью на свой rootfs), мои configure скрипты стали на вид ощутимо быстрее. Померял,

dash + coreutils: 23s

У меня нет объяснения, кроме замены btrfs на xfs, и своим ядром без всего там лишнего. Наверное, существенное отличие - у меня full rt ядро, но это должно улучшать latency и ухудшать throughput, а мы видим другое.

UPD: подумал еще раз - у меня включены THP, и mimalloc по умолчанию(а он старается использовать THP, если они есть).

Мне, все же, кажется, что это FS. Я проверил еще и #F2FS:

dash + coreutils: 20s

BTW, мне очень импонирует идея log structured fs(я не знаю, почему, но мне кажется, что это "натуральный" способ строить FS), поэтому попробую пожить с корнем на ней.

Arch не советует - https://wiki.archlinux.org/title/F2FS, но и терять мне особо нечего, rootfs я восстанавливаю за 5 минут.

Собирал тут boost. Люди, которые меня хорошо знают, удивятся - я же известный boost hater. #gold

Не себе, для дела. Boost требуется для сборки Inkscape, а Inkscape нужен для рендера иконок в теме Adwaita(это, кстати, та еще кольцевая зависимость, потому что иконки требуются для gtk, а gtk нужен для сборки inkscape, ну да ладно). #svg

Для этого пришлось бутстрепнуть B2, оно же бывший bjam. Удивительно, но в ней нет поддержки кросс-компиляции, хотя, конечно, авторы утверждают обратное.

Давайте я поясню, что я имею в виду, когда говорю, что система сборки поддерживает кросс компиляцию: #cross #cmake

* Возможность указать компилятор и cflags - это НЕ поддержка кросс-компиляции, потому что без "раздвоения" сборочного графа это приводит к невозможности собирать проекты, которым требуется строить host тулзы во время сборки(если host != target). cmake, bjam - отличные представители.

* Кросс-компиляция начального уровня - когда сборочная система знает про HOSTCC, TARGETCC, и позволяет описать разные части сборочного графа используя разные *CC. Например, make, ninja(без надстроек над ними), autoconf.

* Кросс-компиляция второго уровня - когда можно для таргета сборки указать, host он, или target, а далее сборочная система сама правильно подставит HOSTCC, TARGETCC. meson - прекрасный представитель.

* "Высшая" кросс-компиляция - когда любым таргетом можно оперировать как в контексте host, так и target. Все будет сделано прозрачно для пользователя. ya, bazel(buck? честно, не знаю так глубоко). Кстати, Mix тоже(с поправкой на то, что не все таргеты в OSS принципиально можно кросс-компилировать).

Теперь к B2/BJAM:

* https://www.bfgroup.xyz/b2/manual/release/index.html#bbv2.tasks.crosscompile - нет разделения на target/host вообще.

* https://github.com/bfgroup/b2/blob/main/bootstrap.sh#L26 - позорище, facepalm, запуск свежесобранной target тулзы для инсталляции ея же.

#svg

С иконками, я, конечно, намучался.

* Пути к дефолтным иконкам в тулкитах.
* Какие иконки должны быть.
* Часть иконок в Adwaita лежит в png, часть - в svg, эти множества частично пересекаются. Что выберет то или иное приложение, одному (хз знает кому) известно. В svg лежат ЧБ иконки, в png - цветные.
* Загрузка svg устроена через плагин для gdk-pixbuf. Плагины для него устроены самым ненатуральным образом из всех мне известных(постараюсь написать про то, как извращенно разработчики устраивают загрузку своих плагинов). К сожалению, последняя версия этого плагина, не переписанная на Rust, не очень корректно рендерит последние иконки от Adwaita.
* Отладка "чего там реально загружается" через strace не очень помогает, так как каждая папка с иконками должна содержать индекс.

Так и живем - для качественного рендеринга в png требуется inkscape, для некачественного на лету - Rust.

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

Вся надежда на https://github.com/thepowersgang/mrustc #mrustc, чувак все ближе и ближе к тому, чтобы поддержкать 1.54. Понятное дело, что без borrow checker, но кому оно надо не в процессе разработки? У него своя реализация proc macro(по понятным причинам), не требующая подгрузки .so в компилятор.

Я сейчас остановился на svg иконках с не совсем корректным рендерингом, потому что облизывать Epiphany уже поднадоело(https://wiki.gnome.org/Apps/Web). Надо посмотреть, что ждет на пути сборки Chromium.

Кстати, я почти победил тиринг в Epiphany. Для этого я собрал webkit web process(который занимается непосредственно рендерингом) на gtk4, в котором все лучше с поддержкой opengl/vulkan канвы, а сам браузер с gtk3. Потому что Igalia уже портировала WebKIT на gkt4, а сам браузер - еще нет. Думаю, Igalia подавились бы чем-нибудь на радостях, узнав, что я так делаю. #igalia

#fontconfig #font

Ох. Шрифты. Я надеялся, что до этой темы не дойду :) Потому что могу написать раз в 5 больше, чем на страницах про fontconfig/gtk/etc у Arch и Gentoo, вместе взятых(https://wiki.archlinux.org/title/font_configuration).

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

Про то, что уже писал(например, про то, что fontconfig должен быть демоном), повторяться не буду. Про проблемы старых механизмов типа X server fonts, Xft, тоже писать не буду, в этом нет никакого смысла, да и объем бы сильно увеличило.

Казалось бы, очень простая задача - приложение хочет шрифт X, с параметрами A=a, B=b, C=c, и надо вернуть или его outline, или растеризованные картинки.

Задача сильно облегчается тем, что приложение в системе Linux может ожидать в наличии всего 4 шрифта, с именами "sans", "serif", "monospace", "system-ui"(+ алиасы к ним). Все остальные шрифты могут и не найтись, приложение(например, браузер) должно обеспечить их наличие само.

Проблема номер раз - тулкиты и их разработчики.

Тулкиты, конечно, не смогли договориться, где хранятся настройки, отображающие эти несчастные 4 алиаса в настоящие имена шрифтов. Поэтому ожидать, что в fontconfig придет какое-то нормализованное имя, типа "serif", и оно вернет шрифт для него, ожидать не приходится. Вот мое ненависное Epiphany посылает вместо "sans" -> "Cantarell". И, кстати, не потому, что так где-то зашито в gtk, а, насколько я понял, это результат разрешения какого-то цикла в резолве имен(об этом чуть позже).

Проблема номер 2 - fontconfig и его разработчики. Fontconfig, конечно, появился тогда, когда задача "поставить какой-то конкретный шрифт на машину" была принципиально неразрешима. И когда какое-то приложение просит там Arial, надо было вернуть хоть что-то, минимально похожее. Поэтому там нагородили каких-то странных циклов в резолве имен:

https://github.com/freedesktop/fontconfig/blob/master/conf.d/45-latin.conf#L281
https://github.com/freedesktop/fontconfig/blob/master/conf.d/60-latin.conf#L75

Реально же цикл, который решается тем, что какое-то из этих определений weak. Обратите внимание на слово Cantarell, и на то, что оно идет первым. Возможно, Epiphany таки и посылает "sans", но после цикла в нормализации мы получаем что-то странное.

Поэтому раздебажить, почему тупо не работает моя локальная настройка, которая говорит, что для system-ui надо вернуть Segoe UI, а оно возвращает DejaVu Sans, решительно невозможно.

В fontconfig, конечно, есть FC_DEBUG=, но, удивительный факт, оно не печатает на экран ту строку с именем шрифта, что запросило приложение. Потому что строка сначала парсится, и нормализуется(в набор алиасов) уже в процессе парсинга, а не мэтчинга.

Я попробовал убрать все дефолтные правила из fontconfig, но, с налету, так не заработало. Почему? Хер его знает. Дебажить это сложно.

Поэтому простая, с виду, задача - "написать конфиг с маппингом 4 строк на реальные шрифты" превращается в леденящий душу пиздец.

Про то, где вообще брать шрифты, и что ожидает в наличии дефолтовый Linux - в следующей серии.

Продолжение про шрифты. Если вчера было про "как", то сегодня будет про "что". #font

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

20 лет назад эта задача имела очевидное решение - нужно было украсть ttf шрифты с ближайшей инсталляции Windows, потому что шрифты, которые шли вместе с X, были ужасны. Microsoft, кстати, не только мышки классные делает, но и шрифты. Не, конечно, были шрифты от Кнута(Type1, metafont), но у дяди довольно странный вкус.

Потом в Linux появилось семейство dejavu(https://dejavu-fonts.github.io/), а потом Ubuntu нарисовала пару хороших шрифтов, и стало попроще. Уже можно было не воровать, и иметь при этом более-менее приличные шрифты.

В общем, сейчас выбор по умолчанию для любого дистрибутива - это DejaVu fonts + что-то со своим вкусом.

Обойтись совсем БЕЗ DejaVu особо не получается, потому что есть глифы, которые ни один приличный разработчик шрифтов рисовать не захочет, а люди ими зачем-то пользуются.

Чтобы далеко не ходить - вчера наткнулся на такого странного человека. https://vermaden.wordpress.com/2022/02/04/books-about-freebsd/ И у нас сегодня задачка по бутстрапу!

Определите, к какому юникодному классу символов относится текст из заголовка вышеуказанной страницы, и определите, каким шрифтом ваш браузер(или ваш WM, в моем случае) рендерит этот заголовок.

Короче, я для себя задачу дефолтных шрифтов решил так:

* DejaVu, как фоллбек для всех извращений

* Classic Microsoft Fonts(arial, helvetica, times new roman, etc) - для всяких сайтов, которые по привычке указывают эти шрифты. Вопреки расхожему мнению, эти шрифты можно использовать бесплатно, распространять только нельзя. Бывают metric compatible шрифты, но зачем мне заниматься этим скучным анализом, если доступен качественный оригинал?

* Какое-нить семейство для sans и serif шрифтов

* system-ui и monospace я решил никак не покрывать, потому что все равно каждый себе выберет что-то свое(я вот выбрал Segoe UI + Consolas)

Осталось выбрать sans и serif шрифты.

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

Мои варианты:

* Google Noto
* Google Roboto
* Неожиданно, но IBM Plex

Adobe не попало под "подходящий foundry", потому что она шрифты продает, а, значит, у их бесплатных шрифтов будут какие-то интересные strings included attached.

По совокупности причин(общий размер, покрытие языками, привлекательность) я пока остановился на IBM Plex. Noto тоже хороши, но очень уж объемны(в мегабайтах), и немного узковаты(на мой вкус).

Имею сказать, что подход IBM к разработке(поменьше творчества и побольше waterfall), конечно, очень благоприятно сказался на их шрифте - без изъебов, ничем не выделяется, просто не мешает читать текст.

Уважаемые, а правда же, что zram swap в 15% от MEM - это исключительно хорошо, и ничем не плохо(ну, кроме как для странного случая "моя программа хочет ровно 95% MEM")?

Взгляд на любимую мою тему(что провайдер #provider #law услуг не может и далее по тексту), немного с другой стороны. Мне кажется, Данила несколько черезчур оптимистичен, потому что пользователи, к сожалению, выбирают сервисы по другим критериям.

The end of the monopolistic web era?

Except maybe in totalitarian states, you cannot ever have a single publisher. Most large cities had multiple independent newspapers. In recent years, we saw a surge of concentration regarding newspaper and television ownership. However, this was accompanied by a surge of online journalism. The total number of publishers increased, if nothing else. Yet you can more easily have a single carrier/distributor than monopolistic publisher. For example, the same delivery service provides me my newspaper as well as a range of competing newspapers. The delivery man does not much care for the content of my newspaper. A few concentrated Internet providers support diverse competing services. The current giants (Facebook, Twitter and Google) were built initially as neutral distributors. Google was meant to give you access to all of the web’s information. If the search engine is neutral, there is no reason to have more than one. If twitter welcomes everyone, then there is no reason to have competing services. Newspapers have fact-checking services, but newspaper delivery services do not. Of course, countries like Russia and China often had competing services, but…

https://lemire.me/blog/2022/02/07/the-end-of-the-monopolistic-web-era/

В своих хождениях по мукам Wayland наткнулся на интересный видос. https://www.youtube.com/watch?v=cj02_UeUnGQ

Если кто не знает, то Кейт Пакард - очень крутой в прошлом чувак. Cairo, xrandr - это все был большой прорыв в OSS графике. #fontconfig - тоже он, да. Правда, в последние годы он несколько зашкварился(кстати, напомню, что это анти-SJW, и, даже, правый, блог), но это не отменяет его былых заслуг, мы же не леваки какие.

Весь видос смотреть не обязательно, но вот часть про GNU и Столлмана, со слов очевидца, очень даже прикольно(с 28 минуты).

Про python #gil.

* Оказывается, я пропустил классное интервью с автором этого мега набора патчей:
https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/

* https://github.com/microsoft/mimalloc/issues/475
Коллеги уже лезут патчить mimalloc, потому что использование аллокатора из mimalloc - часть nogil проекта. Мне прямо хочется им туда написать, что они идиоты и не лечатся совсем не подумали про static linking, но, как обычно, решил, что обойдусь парой дефайнов, а они там путь упарываются со своими symbol visibility, как хотят.

———
https://nvidianews.nvidia.com/news/nvidia-and-softbank-group-announce-termination-of-nvidias-acquisition-of-arm-limited

Big news, nvidia больше не покупает ARM. И очень жаль, потому что от этого альянса можно было бы ожидать чего-нить очень интересного.

https://www.phoronix.com/scan.php?page=news_item&px=Intel-RISC-V-International

Зато Intel вступает в RISC-V. В какой-то интересный выхлоп от Intel в плане RISC-V я верю гораздо меньше, Intel толстые, старые, и осторожные. Скорее, они участвуют везде и нигде одноврменно, для галочки, не делая ничего по существу, и проедая накопленный интеллектуальный капитал.

———
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Wayland-X11-Stats

Я чувствую, что со своей ориентацией на static linking + Wayland + clang, я, конечно, найду своего пользователя.

https://www.phoronix.com/scan.php?page=news_item&px=Chimera-Linux-2022
https://www.phoronix.com/scan.php?page=news_item&px=OpenMandriva-Lx-4.3

С удивлением узнал, что Mandriva тоже с Clang. Это, конечно, хорошо. В предыдущую мою попытку построить Clang-based дистрибутив было существенно сложнее, чем сейчас.

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

Привычка - это хорошо.

Поэтому объявляю аттракцион невиданной щедрости!

1000-ному подписчику я лично* приеду и устанвлю Mix на ноутбук!

* - выезд в пределах ТТК.

Кому что, а голому вшивому - баня. Я снова про #fontconfig

Периодически я запускаю strace на свои процессы, и смотрю, какие файлы открывают программы, чтобы:

* Они не лезли по системным путям, типа /usr

* Чтобы они не лезли в папки с установленными статическими библиотеками(если лезут, значит, я где-то забыл выделить общие данные из кода библиотек, и после gc цикла программы перестанут работать)

Почти все графические программы лезут в /usr/share/fonts, и я, наконец, решил это побороть.

Нашел пути в устанавливаемом конфиге, https://github.com/freedesktop/fontconfig/blob/master/fonts.conf.in#L28, убрал, пересобрал, проверил. Программы все равно лезут в /usr, за шрифтами.

Нашел добавление этих путей в исходниках. https://github.com/freedesktop/fontconfig/blob/master/src/fccfg.c#L2670 Ну так, на всякий случай - вдруг кто-то удалит из конфига, и не получит нужных шрифтов. Вспомнил недобрым словом Кейта Пакарда, удалил, пересобрал, проверил - все равно лезут.

Запустил греп еще раз. На этот раз увидел, что отличилась система сборки - https://github.com/freedesktop/fontconfig/blob/master/meson.build#L213 Вспомнил недобрым словом Кейта, его маму, папу, и прочих коллег по цеху X.org.

Короче, на этот раз все сработало. Больше программы в /usr не лезут.

Очень, очень надежная система.

PS: мое творчество:
https://github.com/pg83/mix/blob/main/pkgs/lib/fontconfig/data/mix.sh
https://github.com/pg83/mix/blob/main/pkgs/lib/fontconfig/t/mix.sh#L26

Обещал про динамическую линковку в OSS. #GNOME

Есть такая библиотека - #glib. И в ней типа есть возможность использовать tls. Ну, была раньше. Потом поддержку tls вынесли в отдельную либу - https://gitlab.gnome.org/GNOME/glib-networking, видимо, по лицензионным соображениям(раньше же openssl и GPL были несовместимы), но это же OSS, поэтому glib продолжает делать вид, что умеет в tls.

При попытке использования tls glib пытается загрузить glib networking, и сыпется, если это невозможно. Отделили, да.

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

Checking if "GIO has real TLS support" with
 dependencies glib-2.0, gmodule-2.0,
 gobject-2.0, gio-2.0 runs: NO (1)

Реально, вдумайтесь в происходящий цирк.

Конечно, тут же и кольцевая зависимость образовалась(потому что этот плагин продолжает зависеть от glib, а как же иначе).

К счастью, libc от проекта gnu очень хорошо умеет жить с кольцевыми зависимостями(UPD: а до последнего времени был пиздец о n^3 - https://habr.com/ru/post/451208):

"В системе динамического связывания реализован новый алгоритм сортировки DSO, использующий метод поиска в глубину (DFS) для решения проблем с производительностью при обработке зацикленных зависимостей."

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

Выскажу такую мысль - примерно треть проблем, которые можно увидеть на разных форумах про Linux(ладно, я на LOR смотрел) - это проблемы разбиения приложения на плагины. Неработающий звук - 100% посреди цепочки какой-нить pipewire не может найти плагин с alsa. Неработающее ускорение видео в браузере - 100% Mesa не может найти плагин для какого-нить vdpau. И так далее.

Обычно причины этому следующие:

* Пути не стандартизованы. Драйвер от nvidia может положить интерфейс для ускорения декодирования не туда, где его ожидает увидеть mesa.

* Не прописана зависимость, плагина просто нет на FS

* Плагин сломан(не хватает каких-то символов), не загружается.

Тестов на это все нет, и не будет.

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

https://www.youtube.com/watch?v=u9R4RoaLSIM #abi
https://habr.com/ru/company/yandex/blog/649497/

Я всегда спрашиваю, "а чо там с range-based for loop", и мне не отвечают. Комитет С++ уже много-много лет ищет пуговицу, потому что его взяли в заложники IBM(и другие компании, которым важно поддержание ABI) и несколько старых дедов(которым важно поддержать свое слабеющее влияние), и не дают решать насущные проблемы.

Пуговицу искать, конечно, очень увлекательно, но перспективы С++ сейчас, конечно, очень туманны. #cppcom

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

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

Сегодня я выступаю в роли https://ru.wikipedia.org/wiki/%D0%90%D1%80%D0%BC%D1%8F%D0%BD%D1%81%D0%BA%D0%BE%D0%B5_%D1%80%D0%B0%D0%B4%D0%B8%D0%BE

Нас спрашивают, мы отвечаем!

Q: Антон, вот ты, в который раз, пишешь, что в С++ все плохо, а что делать-то?
A:

В рамках текущей организационной структуры С++ комитета ничего сделано быть не может.

Посмотрите, сколько там голосов у американских компаний, и сколько у российских, например(спойлер - у российских 0, Антон туда ездит не как представитель Яндекса, а как представитель всей России(если я верно все понимаю)). Поэтому небольшое число голосов компаний, которым важна обратная совместимость, могут превалировать над всеми разработчиками С++ всего мира, которым ABI нафиг не всралось, они все равно и так все пересобирают, так же, как в Rust.

Ну и текущая структура комитета настроена на воспроизведение самое себя, впрочем, как и любая другая структура. Люди, которым там что-то не нравится, и они публично об этом заявляют, каким-то образом оказываются вне этой структуры, я периодически на такие coming out кидал ссылки.

Мне кажется, у MANGA(основные потребители С++) могло бы хватить сил, чтобы переломить эту ситуацию. Например, сказать, что они делают С++v2, и что clang будет его поддерживать. Если бы они сказали, что сделают в С++v2 нормальные lifetimes, и правильную обработку ошибок, я бы пошел двигать переход на их стек, думаю, как и многие другие.

Может ли кто-то, кроме MANGA? Сомневаюсь. Да нет, не сомневаюсь, не может.

А они сделают? Думаю, нет, думаю, им ОК новая волна в виде Rust. Зачем чинить С++ - это сложно, муторно, долго, и немодно, когда можно просто воспользоваться новым хайпом? Если бы не Rust, то стимул починить С++, конечно, был бы существенно выше, я был бы оптимистичнее про судьбу С++.

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