#rant

#RH - контора пидорасов!
#GNOME - контора пидорасов!

У меня сломался waybar, с довольно странной ошибкой:

[2023-07-05 18:52:33.631] [warning] module sway/workspaces: Disabling module "sway/workspaces", Unable to connect to the SYSTEM Bus!...

Быстрое расследование с помощью strace показало, что программа хочет коннектиться к /run/dbus/system_bus_socket, вместо привычного /var/run/dbus/system_bus_socket

Коллеги из glib, почему-то, решили, что spec им не указ, и самовольно заменили путь по умолчанию - https://github.com/GNOME/glib/blob/main/gio/gdbusaddress.c#L1338-L1346

"While the D-Bus specification says this must be /var/run/dbus/system_bus_socket"

При этом:

* Они пишут, что для систем, где /run == /var/run, это, мол, не проблема. Гже-то написано, что это всегда так?

* Они считают, что дали возможность заменить этот путь на старый, через настройку конфигурации glib - https://github.com/GNOME/glib/blob/main/NEWS#L335

Но, конечно, они всех обманули - https://github.com/GNOME/glib/blob/main/meson.build#L130-L139

Почему? Потому что они не берут эту настройку as is, а делают вот так - glib_runstatedir = glib_prefix / get_option('runtime_dir')

То есть, по сути, они довольно жестко навязали использование /run для хранения сокета dbus.

Я не знаю, что это - долбоебизм разработчиков, или намеренное желание заставить всех хранить сокеты сервисов в /run, а не в /var/run.

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

https://github.com/0xpayne/gpt-migrate

"Easily migrate your codebase from one framework or language to another"

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

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

Мир меняется, быстро и (пока) не очень заметно, прямо сейчас, и за этим очень интересно наблюдать.

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

#rant #bootstrap

Решил я себе собрать https://github.com/openSUSE/hwinfo - это такая тулза для сбора информации про систему, развивается, судя по всему, под крылом SUSE.

Программа собирается исключительно чудом, а, точнее, двухкратным запуском make:

make[1]: *** No rule to make target 
    '.../src/libhd.a', 
    needed by 'hwinfo'.  
    Stop.
make[1]: *** Waiting for unfinished jobs....
ar: warning: creating ../src/libhd.a
make[3]: *** No rule to make target 
    'cdb/isdn_cdb.h', 
    needed by 'cdbisdn.o'.  
    Stop.
make[3]: *** Waiting for unfinished jobs....
description(enter:now): under development

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

И это, судя по беглому анализу Makefile, by design.

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

А дальше сборка зависла минут на 10, и не подавала признаков жизни. Разве что, крутила в какой-то самосборной программе 100% CPU.

Я подумал, что это все мой musl, и полез копать патчи из alpine, но, пока читал, оно как-то завершилось, выдав на экран следующее:

data written to "hd.ids"
log written to "hd.log"
statistics:
  1113 inconsistencies fixed
  20 errors, 20 resolved
  60483 items in
  45468 items out
data written to "hd_tiny.ids"
log written to "hd_tiny.log"
statistics:
  0 inconsistencies
  0 errors
  45468 items in
  377 items out
llvm-ar: warning: cre

Я воробей стреляный, говнокода на С повидал немало, и знаю, что коллеги очень редко в С изобретают хеш-таблицу, а вот квадрат операций для удаления 15000 элементов из списка длиной в 60000 они соорудить могут - https://github.com/openSUSE/hwinfo/blob/master/src/ids/check_hd.c#L2124-L2127 (собственно, проблема, что мы матчим каждый элемент с каждым, прежде чем удалить).

Про аццкий Makefile, который не знает, что такое PREFIX, и чем он отличается от DESTDIR, я вообще молчу - https://github.com/openSUSE/hwinfo/blob/master/Makefile#L105

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

Наткнулся на совершенно прекрасный текст, в котором автор libjpeg-turbo (самый популярный декодер jpeg, на его основе сделан mozjpeg - самый популярный энкодер) рассказывает, почему он не стал поддерживать новые фичи из libjpeg 9 (девятая версия референсной имплементации).

https://libjpeg-turbo.org/About/Jpeg-9

Если совсем коротко, то мейнтейнер этой самой референсной реализации сошел с ума попутал берега, и решил, что он может вкоммичивать в подведомственный ему код любую дичь, не прошедшую стандартизацию - в тексте идет речь про "Lossless SmartScale format".

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

Конечно, авторы альтернативных реализаций не хотят поддерживать эту дичь.

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

#wasm #harfbuzz

Не прошло и месяца после коммита с поддержкой wasm шейперов, как код проехал в прод - https://github.com/harfbuzz/harfbuzz/releases

(кстати, в прошлом тексте я ошибся, предположив, что код будет заниматься рендерингом - код будет заниматься исключительно шейпингом текста, то есть, расстановкой шрифтовых глиф по холсту - пример того, что было до, и после - https://github.com/simoncozens/wasm-examples)

Все это плохо пахнет, если вы понимаете, о чем я:

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

* https://github.com/harfbuzz/harfbuzz/blob/main/docs/wasm-shaper.md - поверхность взаимодействия этого кода с harfbuzz весьма широка, и я не уверен, что ее можно норм реализовать, если ты - не harfbuzz. Похоже на попытку запилить очередной vendor lock in - если хотите использовать крутой шейпер из шрифта, берите harfbuzz. И чем это пижже ситуации с интерпретатором байткода из TrueType шрифтов? Отделаться тут общими словами "ну это только незначительные улучшения шейпера" - так не выйдет, потому что вот даже тут уже показано, как таки заэмбеддить настоящий растеризатор шрифтов в такой программируемый шрифт - https://github.com/simoncozens/wasm-examples

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

* wasm target в Rust запилен много лучше, чем в других языках, хотя бы потому, что С++ в #wasm положить тяжело, так как в нем нет никакой поддержки для setjmp/longjmp/прочих способов нелокального code path (e.g. исключений)

* хайп, куда же без него

https://vole.wtf/scunthorpe-sans/

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

А какую красоту можно будет навернуть, если добавить туда программный шейпер на #wasm?

Еще я придумал мега формат для хранения и компрессии вообще всего - приложение прокидывает в wasm VM свою объектную модель, а любой сохраненный файл (документ, картинка, etc) - это просто программа на wasm, которая, дергая эту объектную модель, получает нужный результат.

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

Будни #bootstrap

Я тут собирал protobuf-c (не спрашивайте, он нужен для unbound), и во второй раз в жизни использовал хак #define private public!

Не, реально - https://github.com/pg83/ix/blob/main/pkgs/bin/protoc/c/ix.sh#L30

Зачем?

Несколько разу же писал, что, если посадить несколько очень умных людей заниматься какой-нить лютой херней, типа #protobuf (прошлый #rant был про #grpc, ну и про Тома Хуйкина с его #ncurses можно вспомнить #ball_lick), то они начинают выдумывать себе (это пофиг), и нам (а вот это уже печально) задачи на пустом месте.

https://github.com/protocolbuffers/protobuf/blob/main/src/google/protobuf/descriptor.h#L1901-L1906

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

Дело-то хорошее! Надо же загодя подготовиться к внедрению четвертой версии синтаксиса (спойлер - нет, не надо https://groups.google.com/g/protobuf/c/Xpl4mw4zM_M), поэтому надо проверять фичефлаги, а не версию. А то вдруг вся работа закончится, а ипотека еще не выплачена!

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

На "сладкое" похвастаюсь, насколько же иногда мои "процедурные" патчи проще, чем вручную накладываемые и периодически переделываемые под новые изменения в upstream diff/patch.

Вот patch в arch linux, чтобы protoc-c собирался с более свежим protobuf - https://gitlab.archlinux.org/archlinux/packaging/packages/protobuf-c/-/blob/main/66a0b0d2.patch

А вот мой процедурный - https://github.com/pg83/ix/blob/main/pkgs/bin/protoc/c/ix.sh#L13-L20

Мне кажется, он более явно (и просто) выражает мое намерение.

https://www.oracle.com/news/announcement/blog/keep-linux-open-and-free-2023-07-10/

Oracle пытается троллировать RH/IBM, и выставить себя главным другом open source вообще, и Linux в частности.

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

"Главные борцуны за свободу Linux", my ass.

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

https://www.suse.com/news/SUSE-Preserves-Choice-in-Enterprise-Linux/

Вечер перестает быть томным!

SUSE решили запилить свой клон RHEL, раз уж пошла такая пьянка!

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

Как выглядит мой код и комменты к нему

Programmer memes

https://jpegxl.info/art/2021-04_jon.html

#jpeg_xl

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

https://inai.de/projects/consoleet/

https://inai.de/projects/consoleet/terminus

Или вот вам набор шрифтов от человека, который запарился (прямо реально запарился https://inai.de/projects/consoleet/8x19 !) на том, чтобы получить хорошие векторные шрифты из их растровых эквивалентов!

Не на правах рекламы.

https://github.com/0x192/universal-android-debloater

Совершенно класнный деблоатер для Android.

Программа простая, как 5 копеек (на Rust, а как же) - есть размеченные списки того, что делает то или иное приложение на испорченном вендором ведроиде (можно почитать перед удалением), и умеет удалять всякую дичь (вызывая adb, само собой, требует включения режима разработчика, не требует root).

Если 4 года назад надо было рыскать по всяким помойкам за крохами информации, и пробовать удалять приложения почти наугад (рискуя окирпичить device), то сейчас все делается по щелчку.

Почистил свой Xiaomi, и свой Samsung - брат жив, говна на приборах стало сильно меньше.

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

Alma больше не будет клонировать #RH, а будет "максимально с ним совместима", что бы это не значило.

Что я тут имею сказать?

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

И, кажется, не имеет, из-за inline, и из-за макросов.

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

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

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

Возможно, когда-нибудь мы доживем и до стандартизации этого ABI, и программы, работающие под RHEL, перестанут сыпаться на Debian, and vice versa.

#foot

https://codeberg.org/dnkl/foot/releases

Changed
Default color theme is now starlight (#1321).

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

Пока читал changelog, натолкнулся на https://wayland.app/protocols/cursor-shape-v1 (foot его как раз поддержал).

TL;DR - в #wayland теперь можно сказать композитору, какой курсор сейчас отображать по порядковому номеру (значения которых заранее определены и известны), а не загружая кастомную текстуру каждый раз, когда мышка переезжает из окна с #gtk в окно с #QT. Курсоры (при поддержке этого протокола) теперь могут храниться в композиторе, и не загружаться каждым клиентом отдельно.

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

UPD: "Copyright 2018 The Chromium Authors Copyright 2023 Simon Ser" - ну, понятно, все #хорошее для Linux Desktop делает гагл, а не какой-то там RH.

Интересно, поддержит ли это #gtk?

#bootstrap

А я, тем временем, собрал себе npm.

https://github.com/stal-ix/ix/blob/main/pkgs/bin/npm/source/ix.sh#L20-L22

На самом деле, это был какой-то очень странный опыт, потому что официальная репа не содержит инструкций по сборке, ну или я не нашел, где. https://github.com/npm/cli

Такое ощущение, что для сборки npm предполагается, что у тебя уже есть какой-то работающий npm, что не очень хорошо.

Попытка запустить из свежескачанной git репы https://github.com/npm/cli/blob/latest/bin/npm-cli.js приводила к тому, что node не могла найти нужных модулей в системе, и отказывалась запускать этот скрпит.

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

10 симлинков решили эту проблему, и я получил "как-то" работающий npm, который смог вытянуть себя за уши - https://github.com/stal-ix/ix/blob/main/pkgs/bin/npm/source/ix.sh#L21

Потом я выяснил (чтением кода npm), что эти 10 симлинков способна вывести вот эта вот команда - https://github.com/stal-ix/ix/blob/main/pkgs/bin/npm/source/ix.sh#L20.

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

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

Короче, собрал, и пошел читать awesome js/node/npm списки - поискать, нет ли чего годного, чего у меня раньше не было, а теперь можно притащить.

И не нашел. 3 + 1/2 приложений на электроне, у которых и так есть годные нативные альтернативы.

Слабо, очень слабо, коллеги.

https://wheybags.com/blog/cow.html

"Recursive COW pages in userspace"

Картина маслом - зумеры изобретают https://www.gnu.org/software/libsigsegv/

"GNU libsigsegv is a library for handling page faults in user mode. A page fault occurs when a program tries to access to a region of memory that is currently not available. Catching and handling a page fault is a useful technique for implementing:

pageable virtual memory,
memory-mapped access to persistent databases,
generational garbage collectors,
stack overflow handlers,
distributed shared memory,
..."