https://www.neversaw.us/2023/06/30/understanding-wasm/part2/whence-wasm/

#wasm

Классный экскурс в историю WebAssembly.

Очень понятно объясняется, почему WebAssembly именно такой, и как так получилось.

КМК, ключевой абзац этого текста:

"WebAssembly pulled the same magic trick C did: it extracted an existing, useful abstract machine definition from several concrete implementations, like finding David in the block of marble. Rather than requiring that browser vendors implement a second virtual machine, WebAssembly support could be added incrementally, sharing code between the JS and WASM runtimes. WebAssembly machine definition supports C's abstract machine — C, C++, Golang, and Rust can compile to this target — acting as a virtual instruction set architecture"

WebAssembly - это такие "кишки наружу" от уже существующих оптимизирующих JavaScript JIT, типа V8/TraceMonkey, позволяющих эффективно таргетировать WEB как платформу для быстрого выполнения кода на разных компилируемых языках, типа C++/Rust/etc, без прослойки вида JavaScript/Emscripten/asm.js.

#wasm #bootstrap

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

Изначально WASM - это песочница для безопасного исполнения кода в браузере, чуть более лучшая (накладывающая меньше ограничений), чем java апплеты.

Но, с появлением таких штук, как #wasi, и как биндинги в WebGL, на WASM можно довольно удобно смотреть как на API boundary.

Что это значит?

Для кода, исполняющегося в песочнице WASM, вызывающая сторона может четко описать, какие внешние вызовы ей доступны:

* https://wasi.dev/ - набор API для кросс-пдатформенных вызовов в OS.

* https://wasix.org/ - POSIX API

* Браузеры, например, предоставляют WASM коду возможность дергать WebGL функции, то есть, к аппаратному ускорению графики.

* Аппаратное декодирование видео

* ...

Возникает очень простая мысль: а зачем линковаться с реализацией opengl (статически или динамически), если тебе ее может предоставить WASM runtime?

Картина маслом - все GUI приложения в системе компилируются в WASM, можно сразу в AOT представление, а различия в аппаратной начинке систем скрыты в WASM runtime, который, единственный в системе, линкуется с настоящей реализацией opengl.

Что туда было бы хорошо засунуть, кроме opengl?

* vulkan
* multimedia api, типа кодеков, микширования звука
* dbus
* алгоритмические ошметки сетевых стеков (кодеки bluetooth и прочее)

Короче, все, что:

* имеет стабильный и слабо меняющийся ABI (поэтому библиотеки виджетов и прочие freetype/harfbuzz под это не попадает)
* используется много кем

Дальше Остапа понесло:

* FUSE, VFS(?), mount namespaces
* какие-то другие запчасти от контейнеризации

Понятное дело, что мы пока очень далеко от этого, потому что даже WASIX есть только в одном рантайме, но, я надеюсь, однажды это можно будет сделать "просто".

#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).

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