https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Kopper-Merged

"Zink with Kopper now provides native Vulkan windowing system integration (WSI), proper Vulkan swapchain handling"

"This moves Zink closer to being able to run with a Wayland compositor and other features previously only dreamed about for this generic but performant OpenGL implementation for running on Vulkan drivers. Mike Blumenkrantz continues working on Zink/Mesa thanks to employment from Valve" (Все #хорошее в графическом стеке Linux делают корпорации!) #zink #mesa

Интересно, а как у меня так получается уже гонять весь opengl stack через связку wayland + zink + vulkan? В том числе, и композитор.

Ну и непонятно, зачем этот самый WSI нужен. EGL вполне справляется с настройкой контекста, и, кроме слова GL, там от opengl нет ничего особо.

Тут вот пишут, что профессия художника уже закончилась. Интересно, когда придут за IT? 5 лет? 10?

Мысли ниже:

Я тут собирал #kitty под Linux, прост потому что мне не нравится, когда в репозитории есть сломанные таргеты. Так-то я использую #foot

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

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

* Мое любимое занятие(на самом деле нет) - делать так, чтобы эмуляторы терминала выглядели одинаково. Для этого при размере шрифта в foot 12pt мне пришлось выставить в kitty 11.8pt(на тот же шрифт). Не могу доказать, но чую, что автор kitty где-то что-то умножил на константу или сложил, потому что у него там границы символов не сходились, ну или просто так больше нравилось. Да, это prejustice prejudice.

* В kitty какое-то безумное чило настроек. Такое ощущение, что автор бездумно вместо терма X везде писал (X + X1) * X2, ну чтобы можно было настроить что угодно и как угодно, иначе я все эти бессмысленные настройки объяснить не могу.

* Я решил проверить kitty и foot на performance. Для этого я, конечно(MAD SKILZ detected), сделал cat some_big.pdf прямо в терминал. Kitty тупо завис(не, прямо реально завис), foot отработал неважно с какой скоростью. Лог kitty перед смертью:

[097 21:55:06.343874] [PARSE ERROR] 
Unknown char after ESC: 0x24
[097 21:55:06.343883] [PARSE ERROR] 
Unknown char after ESC: 0x65
[097 21:55:06.347035] [PARSE ERROR] 
Unrecognized APC code: 0x1a

* После этого я вывел 20 мегабайт случайного текста.

foot:

real 0m0.642s
user 0m0.000s
sys 0m0.198s
pg->

kitty:

real 0m0.644s
user 0m0.000s
sys 0m0.207s
pg->

Казалось бы, одинаковая скорость, что у GPU-accel kitty, что у CPU foot? Какое там, это только потребление CPU! Kitty еще съел невозбранно дофига GPU, которое я не умею измерять!

* Kitty весит 51MB, foot - 8. Помним, что у меня статическая линковка. Чем меньше кода, тем меньше багов.

* Вишенка на торте - размер https://github.com/kovidgoyal/kitty/blob/master/setup.py в Kitty 50KB. Чувак там реально запилил сборку .c и .py кода(херовую, конечно). Размер всего ядра MIX - 45KB. А я уже собрал 550 пакетов, у меня супер крутая сборка с декартовым произведением флагов и кросс-компиляцией.

* Еще хочу похвастаться, как у меня круто устроено наследование шаблонов и диспатч между таргетами. Для тех, кто не знает шаблоны ruby/jinja2/etc, {{super()}} - это "взять текст базового блока и подставить в это место".

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/t/mix.sh - базовый шаблон
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/linux/mix.sh - надстройка для linux
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/darwin/mix.sh - для darwin
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/mix.sh - диспатч между ними

Я все мог бы сделать в одном файле через if darwin, if linux, но так намного читаемее.

TL:DR; - не ведитесь, когда вам продают GPU accelerated что-то, чаще всего это хайп ни о чем.

https://github.com/libarchive/libarchive/releases/tag/v3.6.1

Вышла минорная версия libarchive.

Меня заинтересовала строчка в changelog:

ZIP reader: fix possible out 
of bounds read (OSS-Fuzz 38766 #1672)

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38764&q=libarchive (там несколько однотипных ссылок, которые нашел фаззер, я даю только одну из них)

TL;DR - 16 сентября нашли багу, 16 декабря открыли ее публично(grace period в 3 месяца). В марте оунеры проекта зашевелились, и таки починили.

OSS такой OSS

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

"Из других изменений отмечается прекращение установки утилиты zless на системы без утилиты less"

https://www.youtube.com/watch?v=CF166bieJ-k

У меня, после очередного обновления, стал падать браузер, а, точнее, его WebKitWebProcess, вот с таким вот стектрейсом:

#0  0x000000000852cfb0 in strcmp ()
#1  0x0000000004a937b9 in 
_ZNK3PAL12Text...CUConverterEv ()
#2  0x0000000004a938b4 in 
_ZN3PAL12TextCodecICU6decodeEPKcmbbRb ()
#3  0x00000000040fc431 in 
_ZN7WebCore19T...er6decodeEPKcm ()
#4  0x00000000040fd227 in 
_ZN7WebCore19T...ushEPKcm ()
#5  0x00000000041413ee in 
_ZN7WebCore12CachedScript6scriptEv ()

Падает вот тут:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/PAL/pal/text/TextCodecICU.cpp#L181

Предыдущий вызов из ICU стал возвращать nullptr.

https://github.com/unicode-org/icu/releases/ - тут написано, что был минорный релиз, ничо не меняли, "мамой клянусь".

semver такой #semver. Верить нельзя никому, только своим тестам.

https://github.com/kovidgoyal/kitty/issues/606

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

Это ПИЗДЕЦ как странно, от OS нужно получать либо сканкоды, и самому превращать их в юникодные символы для программы внутри терминала, либо получать готовый текст(и иметь те проблемы, которые он имеет в kitty с настройкой шорткатов).

https://github.com/microsoft/msquic

Портабельная реализация QUIC, от MS.

Альтернативная реализация от Google обладает каким-то странным свойством, что для ее работоспособности надо написать 100К привязок к платформе. In the wild оно есть только в Chromium, с привязкой к его кодовой базе. И, по слухам, в envoy, но про там я ничего не знаю.

UPD: вспомнил, еще есть quiche от Cloudflare, на Rust. Бардачная ситуация, потому что разобраться где quiche от Google, а где от cloudflare, решительно невозможно.

Признаться, я в восторге!

Новости одной строкой: #mrustc https://github.com/thepowersgang/mrustc умеет в rust 1.54.0.

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

https://xanmod.org/ - скажите, а кто-нибудь пробовал? Какие результаты?
Ну и, пользуясь случаем - кого бы мне подергать про ручки шедулера Linux? Хочу понять, как уменьшить цену миграции процесса с одного ядра на другое.

Пробую собирать #mrustc, https://github.com/thepowersgang/mrustc

Автор этого проекта, очевидно, разбирается в компиляторах, но совершенно не разбирается в системах сборки.

Его система сборки - это 4 Makefile, котрые рекурсивно вызывают друг друга, модифицируя аргументы и переменные среды.

https://github.com/thepowersgang/mrustc/blob/master/build-1.54.0.sh - главный драйвер сборки, вызывает make 7 раз, с разными Makefile, и аргументами(и каждый из этих вызовов еще рекурсивно дергает make!)

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

Пока получилось:

* собрать компилятор
* собрать minicargo
* с их помощью собрать cargo(1) из mainstream исходников

Дальше цепочка bootstrap предполагает:

* mrustc + minicargo -> rustc(1)
* minicargo + rustc(1) -> std(2)
* std(2) + cargo(1) + rustc(1) -> rustc(2), cargo(2)

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

То есть, получить rustc(1), cargo(1) я могу, а вот дальше с ними сделать ничего не выйдет.

Я, как и собирался, попробовал собрать какой-нить сторонний софт с помощью mrustc + minicargo, но, увы, пока он заточен только на сборку самого rust.

Что я могу заметить по процессу?

Разработчики rust, конечно, пионеры, с завышенным ЧСВ. Иначе я никак не могу объяснить вот это вот говно - https://github.com/rust-lang/libc/tree/master/src/unix/linux_like/linux

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

Нормальный человек нагенерил бы кучу setter/getter для структур, типа:

int struct_stat_get_inode(struct stat* s) {
    return s->st_ino;
}

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

Но это же не по пацански, и вообще, у нас комплексы лапки, и нужно сделать вид, что C тут и рядом не стояло, поэтому мы построим все на Rust: https://github.com/rust-lang/libc/blob/master/src/unix/linux_like/linux/musl/b64/aarch64/mod.rs#L10 Копипаста под все платформы и возможность разъехаться - не, не слышали.

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

True story, я искал, в качестве фикса mrustc у меня принудительно собирает под musl, потому что куда это в нем передать, я не нашел.https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mrustc/mix.sh#L41

Ну и вендоринг C/C++ исходников(openssl, git2, curl, etc) - я про это уже писал, и повторю еще раз. Код эти пионеры вендорят, данные - нет. Потому что вендорить корневые сертификаты - это сложна, одной системой сборки не обойтись. Поэтому, конечно, найти в системе корневые сертификаты свежеиспеченный cargo не умеет.

#bs #vendor #gold

Почему дистрибутивы не любят контрибы:

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

* В случае использования конвенциональных дистрибутивов(dynamic linking + LSB FHS, в противовес nix/guix/mix/static linking) это еще и технически сложно - динамеческая либа и ее данные хотят жить по одному и тому же файловому пути, для разных версий этой либы.

* Например, нужно, чтобы freetype/fontconfig/harfbuzz/ca-certs у всех пакетов были общие. Потому что кто, в своем уме, хочет разный рендеринг шрифтов в разных приложениях? Это частный случай первого пункта, но хочу подчеркнуть его отдельно.

Для меня, как яркого представителя content-based addressing distro(пути - это https://en.wikipedia.org/wiki/Merkle_tree), и дистрибутива со статической линковкой, часть этих проблем - не проблемы вовсе.

Поэтому я не всегда занимаюсь де-вендорингом(если вы понимаете, о чем я), но иногда приходится:

* freetype/etc case

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

* Так называемый "всратый" vendoring. Что это такое? Это очень разнообразный класс ситуаций, когда мейнтейнер пакета сошел с ума, и приходится его готовить, и приходится за ним подчищать. Например: кто-то сделал у себя в проектах submodules, но не делает git clone --recursive в момент изготовления пакета. В такой ситуации у тебя в пакете пустые папки вместо submodules, и делай с ними, чо хош. Странно? И не такое бывает.

Де-вендорингом можно заниматься по разному.

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

* Ковровые бомбометания. Например, в meson все такие штуки описываются с помощью wrap файлов, и достаточно их просто удалить. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/meson.sh#L87 NB: рассказать, как я злодейски поступаю с разными системами сборки, не церемонясь ни с их авторами, ни с разработчиками пакетов.

Вот, вчера так поступил с Rust.

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

Поэтому я поступил по рабоче-крестьянски, и просто обнулил сборочные файлы неугодных мне таргетов, благо, их названия вполне вписываются в регулярку: https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mrustc/cargo/unwrap/mix.sh#L14 Кстати, вполне возможно, что это таки моя первая строчка кода на Rust! (которую я реально скомпилировал и запустил)

Короче, если там какие-то сумасшедние авторы пакетов и систем сборок думают, что я буду разбираться с тем, как они предоставили ту или иную фичу(де-вендоринг, сборка с разными флагами компилятора, санитайзеры, static/dynamic linking, etc) - да щаз.

"Мы не можем ждать милостей от природы, взять их у нее – наша задача"

https://www.qt.io/blog/qt-6.3-released

Вышла новая версия QT. #ball_lick

Когда программисту нечего делать - он начинает вылизывать себе яйца код. В целом, задача построения gui библиотек уже завершена, поэтому теперь их авторы соревнуются в том, кто сделает побольше QtPDF, css/html/qml врапперов, чтобы даже макака могла строить GUI, и так далее.

Code bloat, который я ненавижу.

А хорошей gui библиотеки:

* VK/GL в качестве канвы, без прослоек.

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

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

* IM/RM - хз, мне кажется, круто иметь один и тот же набор виджетов под обе парадигмы.

как не было, так и нет. Наверное, ближе всего к этому ImGUI?

Еще нужно сказать, что гномовцы, конечно, правы, и GTK - это таки платформенный Linux toolkit, и все из-за дурацкой политики QT.

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

Ну как так?

И это очень печально, потому что, чем больше я погружаюсь в Linux графику, тем более невменяемыми мне кажутся гномовцы.

https://www.reddit.com/r/wayland/comments/r8t7pe/where_are_we_at_for_working_autotype_protocols/

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

Все, абсолютно все, согласны, что это должен быть протокол в Wayland. И только упоротые гномовцы считают, что нет, и изобретают очередной костыль по типу libdecor #GNOME, который там что-то должен делать через dbus и загрузку плагинов.

https://gitlab.freedesktop.org/libinput/libei

Вот их всратое изобретение.

https://gitlab.freedesktop.org/libinput/libei#why-not-foo

"The only connection to Wayland is merely that input events are received
through the Wayland protocol. So a Wayland protocol for emulating input is
not a great fit, it merely ticks the convenient box of "we already have IPC
through the wayland protocol, why not just do it there"."

Уровень аргументации - бог.

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

Посмотрите, какие шедевральные архитектурные картинки они там рисуют.

Я тут решил, из интереса, завести #http3 хоть где-нибудь, раз уж в моих руках оказалась msquic. https://github.com/microsoft/msquic

Что я имею вам сказать, дорогие радиослушатели?

* Что msquic, что связка ngtcp2 + nghttp3, что chromium quic, используют патченый openssl. https://github.com/quictls/openssl. Причем обе стороны, что вендоры, что openssl - дико извиняются, что ну вот никак-никак не смержат все это дело, а openssl еще и намекает, что, может, они и сами наговнякают реализацию quic. https://www.openssl.org/blog/blog/2020/02/17/QUIC-and-OpenSSL/

"We believe that the inclusion of QUIC support in OpenSSL is extremely important and there is an intention to provide it in a future version of OpenSSL. This may be in the form of an API to enable TLS integration into 3rd party QUIC products, or it may be in the form of a complete QUIC transport protocol implementation."

Я решил еще +1 openssl не класть, и заменил общий на патченый, благо, вендоры обещают не затягивать с обновлениями. Патч там, если убрать мусор, строк на 500 кода, но выглядит реально всрато.

* ms stack сырой донельзя, поддержка в curl появилась пару дней назад. https://daniel.haxx.se/blog/2022/04/10/msh3-as-the-third-h3-backend/ Причем оно использует какой-то всратый клей между msquic и нормальным миром, msh3 https://github.com/nibanks/msh3, которая, в свою очередь, полагается на приватные запчасти от msquic - https://github.com/nibanks/msh3/blob/main/lib/msh3.hpp#L43. Короче, обычному пользователю проще умереть, чем это попробовать.

* Но я попробовал, и имею вам сказать!

Как вы понимаете, я не стал ходить nghttp3 в nghttp3, и msquic в msquic, потому что зачем, а стал ходить ровно наоборот:

nghttp3 -> msquic:

pg-> /mix/store/KKTWnNVKMRCbB5Lq-bin-curl/bin/curl 
    --http3 https://quic.westus.cloudapp.azure.com
curl: (56) Failed to connect to 
    quic.westus.cloudapp.azure.com 
    port 443 after 5446 ms: Failure when receiving 
    data from the peer

msquic -> nghttp3:

pg-> /mix/store/BHNhnDCyQ4HIZUFO-bin
    -curl-bleed/bin/curl 
    --http3 https://nghttp2.org:4433/
Connection shutdown by transport, 0xbebc300
curl: (7) failed to connect, state=1

В свои родные сервера оно ходит норм, я, конечно, проверил.

Выводы? HTTP3 пока нет, по крайней мере, в том виде, чтобы все были согласны, что это оно.

#mold раньше всех - https://github.com/rui314/mold/releases/tag/v1.2, вышла новая версия супер-быстрого линкера. Попробую на выходных, подходит ли он на то, чтобы слинковать всю систему.

———
https://www.vedomosti.ru/technology/articles/2022/04/13/918008-times-new-roman-zablokirovali

Звучит как плохая первоапрельская шутка. Really, я на дату на часах посмотрел, когда прочел эту новость.

———
В поисках нормальной библиотеки виджетов.

Думал, нашел подходящий вариант - https://lvgl.io/

Компактная, без изъебов, есть все, что надо.

Но, как обычно, меня подвела привычка смотреть внутрь того, что я использую: https://github.com/lvgl/lv_drivers/blob/master/sdl/sdl_gpu.c#L79 Поддержка 2 мониторов, my ass.

Вот так вот, просто, без изысков(ну там типа "вектора мониторов"). 2 - это таки 2.

———
https://go.dev/blog/when-generics

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

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

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

Каждый язык, видимо, взрослеет(и умирает) вместе со своей аудиторией.

#mix digest

* Число пакетов:

pg-> find . | grep mix.sh | wc -l
1097

Надо понимать, что тут содержатся и всякие пакеты для bootstrap, которые пользователю никак не нужны и не интересны. Полезных пакетов около 700. Напомню, что база Arch Linux - 2700 пакетов.

* Постепенно полирую и доделываю всякое. Например, чтобы было понятно:

- до недавнего времени у меня и на пользователя, и на root, были пустые пароли. Ну просто потому что привсунуть их через useradd - не вариант, у нас же "чистое" управление системой, и это нужно было прокинуть через настройки #realm до конкретных пакетов. Выглядит это у меня вот так:

{
    "flags": {
        "failsafe": "1"
    },
    "name": "set/system/0"
},
{
    "flags": {
        "hash": "uz.......c",
        "pubkey": "ssh-rsa AAAh...j2M= pg@mix",
        "user": "pg"
    },
    "name": "etc/user/0"
},
{
    "flags": {},
    "name": "etc/zram/0"
}

пользователям nix/guix подобная схема может показаться знакомой, а остальные могут пофантазировать, как эти flags могут превращаться в конкретные записи в /etc/passwd, в /etc/authorized_keys, etc

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

- Сегодня у меня был день date time. До этого я жил в UTC, выставленным руками. Сейчас я наладил синхронизацию времени через ntp, save/restore времени при reboot, и собрал пакет с таймзонами для musl. Все это несложно, но довольно муторно, и приходится вспоминать вещи, которые никому не нужны и не интересны.

* Фактически, из нерешенных задач у меня осталось две:

- bluetooth stack. Разобраться, чего там нахуевертили в Linux, выбрать реализацию, отполировать. https://www.bluez.org/

- Звук. #alsa

Пожалуй, самая серьезная моя проблема. Я уже выбрал и собрал 2 звуковых сервера на выбор(https://jackaudio.org/, https://sndio.org/). Мне лично симпатичнее всего #sndiod, маленькая, компактная запчасть из openbsd.

Проблема в том, что звука-то я пока ни разу и не услышал, хотя совершенно точно уверен, что до ядра данные идут. А как в этом месте отладить alsa - у меня пока затык. Дрова видны, они подцепляют устройство, микшер их видит, данные текут в канал. Звука нет, в dmsg пусто :( Если загрузиться в Fedora Live CD, звук есть. Дрова подцепляются все те же самые, микшер видит все те же самые устройства.

fun fact - я в какой-то момент времени офигел, узнав, что у меня 2 аудиокрты, и одна из них интегрирована в AMD GPU. Прежде чем я понял, что это такое представление для системы hdmi audio output, я был "слегка" озадачен.

Божечки-божечки-божечки, НАЧАЛОСЬ! #linux_kernel_rust

https://lwn.net/ml/rust-for-linux/CAHkG_ewRo5uPOue3ZMAAPAc+eP7MNNU5iVym-JVG1jN7HD+XMg@mail.gmail.com/
https://lwn.net/ml/rust-for-linux/CAKfU0DLS5icaFn0Mve6+y9Tn1vL+eLKqfquvXbX4oCpYH+VapQ@mail.gmail.com/

Какие-то школьники интересуются, когда можно будет использовать crates.io и cargo в разработке Linux. С патчами про Rust все было и так понятно, но надо же иметь хоть немного совести, и подождать, пока поддержка Rust попадет в mainline.

Парсера json им не хватает в ведре, да.

———
https://github.com/microsoft/mimalloc/issues/574

Нашел багу в свежем mimalloc. Как? Очень просто, пересобрал с ним мир, и увидел в логах красивое:

pg-> /mix/store/mAZUHwYPOIGAPJOH-bin
    -coreutils-9-0/bin/sort 
sort: memory exhausted

gnu sort начал так ругаться на пустом вводе.

Стандартов на эту функцию нет, кто формально виноват, непонятно, но есть мнение, что reallocarray(a, n, m) == realloc(a, n * m) для всех n, m, которые можно безопасно перемножить.

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

———
https://github.com/WebPlatformForEmbedded/libwpe/commit/064bd78c534d18f9422ddbfe4ca762a42290531c

#igalia lia никак не уймется, и они запилили для WebKit еще один порт, для embedded. Он устроен хитро - есть loader, libwpe, который загружает конкретную имплементацию, которая уже и реализует настройку графического контекста для рендеринга. И есть конкретная референсная реализация для freedesktop проектов, wpe-fdo.

Сделано это всрато:

* loader зависит от libxkbcommon, то есть, наружу протекла абстракция ввода-вывода(от конкретной реализации)

* абстракция, насколько я понял, абстрагирует не только графику, но и звук. Через что они гоняют звук, я пока не понял, как бы не через wayland :D

На днях коллеги из Igalia решили, что, раз уж есть всего одна реализация плагина, то можно ее и не через dlopen открывать. Кстати, придумали элегантное(без шуток) решение - статический loader просто содержит в себе extern на символ из плагина, после чего с ним можно линковаться, как с обычной .so

https://github.com/WebPlatformForEmbedded/libwpe/blob/master/src/loader-static.c#L32

А теперь то же самое, в конкретном плагине:

https://github.com/Igalia/WPEBackend-fdo/blob/master/src/fdo.cpp#L33

Мне понадобился gdb, чтобы найти тут ошибку.

Очевидно, что этот статический loader никто никогда в реальной жизни даже не запускал. Я этим пидарасам так и написал - https://github.com/WebPlatformForEmbedded/libwpe/commit/064bd78c534d18f9422ddbfe4ca762a42290531c#r71375192

Вот моя реализация: https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/wpe/loader/loader.c

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

#musl

https://lobste.rs/s/osfunr/musl_preprocessor_debate
https://catfox.life/2022/04/16/the-musl-preprocessor-debate/
https://www.openwall.com/lists/musl/2013/03/29/13

Я уже как-то писал про сумасшедших авторов Musl, которые никак не хотят запилить

#define __MUSL__

Как ни странно, я немного поменял свое мнение, хотя и мои новые аргументы не подкрепляют точку зрения Ричарда Фелкера.

Мои аргументы:

* мало кто использует musl с аллокатором из musl, потому что аллокатор из musl сосет.

* стандарты на аллокатор - очень размытое понятие, потому что они менялись со временем, и некоторые функции тупо не стандартизированы(reallocarray, о которой я писал в прошлом посте).

* mimalloc(который я использую вместе с musl) недавно поменял свое поведение(оба поведения имеют право на существование) - конкретно, malloc(0) возвращал уникальный указатель, а теперь может возвращать nullptr.

* исходя из всего этого, потребители не могут пользоваться

__MUSL__

, для того, чтобы проверить свойство аллокатора - нужен configure-time тест.

Дело, конечно, усложняется кросс-компиляцией, и невозможностью получить нужную информацию через configure-time test, но что тут поделать.

Отдельно отмечу, от смены версии mimalloc сломалось прямо очень много configure-time тестов, и я предлагаю из этого сделать такие выводы:

- #semver не работает. Только тесты, только хардкор.

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

Кажется, совсем иделаьное решение - подставлять все нужные флажки в configure/cmake/meson/etc в системе построения пакетов, но, кажется, это утопично.

Конечным потребителям musl вполне можно продолжать иметь свой

#define __MUSL__

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