https://www.redhat.com/en/blog/red-hats-commitment-open-source-response-gitcentosorg-changes

Мерзотный текст от RH, с "объяснением" происходящего.

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

* "Нам нужны деньги, чтобы платить ЗП разрабам" (а еще акционерам, но про это не сказано), "поэтому нам приходится делать так, чтобы нашу работу было сложно повторить".

* "Нуачотакова? Вот исходники, все выложено, делайте с ними, чо хотите". И опять же, четко не сказано, что собрать из этих исходников RHEL, не зная конкретные ревизии, невозможно, потому что смотри предыдущий параграф.

#wasm

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

https://wasix.org/

https://github.com/wasix-org/wasix-libc

Вот, почти полный POSIX wasm runtime. К сожалению, пока работает только в https://wasmer.io/

#wasm #perf

Разобрался с отставанием wasmedge.

Чтобы все работало быстро, нужно пройтись по wasm с помощью его AOT компилятора, и тогда получается вот такой результат:

real  0m 0.62s
user  0m 0.57s
sys  0m 0.03s

Это уже довольно близко к нативной скорости выполнения того же бинаря.

Впрочем, скорость его AOT не впечатляет:

pg# time .../bin/wasmedgec \
    --optimize 3 \
    --enable-threads \
    .../brotli brotli
[2023-06-29 01:55:52.636] [info] compile start
[2023-06-29 01:55:52.669] [info] verify start
[2023-06-29 01:55:52.710] [info] optimize start
[2023-06-29 01:55:56.632] [info] codegen start
[2023-06-29 01:56:01.680] [info] output start
[2023-06-29 01:56:01.682] [info] compile done
[2023-06-29 01:56:01.686] [info] output start

real  0m9.117s
user  0m9.063s
sys  0m0.041s

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

Oracle запилили автоматический оптимизатор настроек ядра Linux, о как.

На моей памяти это уже вторая (а то и третья) такая попытка.

(быстрым грепом не нашел эту историю в интернете, если у вас есть под рукой - киньте ссылкой)

Но, насколько я помню, тогда оно не полетело, потому что:

* Linux был еще глючнее, чем сейчас.
* Многие комбинации параметров приводили к тому, что система просто вставала колом, с невозможностью тюнить ее дальше. С учетом первого пункта это было бомбически.
* Шум.

Интересно, как Oracle решили эти проблемы.

https://rockylinux.org/news/keeping-open-source-open/

Не менее мерзотный текст от Rocky Linux, с описанием того, что они собираются сделать в ответ на действия RH.

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

Почему этот текст не менее мерзотный?

Вот из-за этого абзаца:

"These methods are possible because of the power of #GPL. No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions"

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

Да, для GPL софта они имеют право получить исходники и SRPMS таким образом.

А вот для не-GPL бинарников - не имеют.

И, на самом деле, довольно много системного софта в Linux не идет под GPL (практически весь графический стек, не считая конечных тулкитов - permissive, например).

В глубине души, я, конечно, больше на их стороне, но, КМК, им надо быть более аккуратными.

#wasm

От сборки примитивной ерунды до запускающегося интерпретатора python прошло не очень много времени:

pg# ./ix run bin/wasm/edge bin/python/11/wasi --target=wasi32 -- wasmedge --enable-all '$(command -v python3.wasm)' --help
usage: python3.wasm [option] ... [-c cmd | -m mod | file | -] [arg] ...
Options (and corresponding environment variables):
-b     : issue warnings about str(bytes_instance), str(bytearray_instance)
         and comparing bytes/bytearray with str. (-bb: issue errors)
-B     : don't write .pyc files on import; also PYTHONDONTWRITEBYTECODE=x
-c cmd : program passed in as string (terminates option list)
-d     : turn on parser debugging output (for experts only, only works on
         debug builds); also PYTHONDEBUG=x
-E     : ignore PYTHON* environment variables (such as PYTHONPATH)
-h     : print this help message and exit (also -? or --help)
-i     : inspect interactively after running script; forces a prompt even
         if stdin does not appear to be a terminal; also PYTHONINSPECT=x
-I     : isolate Python from the user's environment (implies -E and -s)
-m mod : run library module as a script (terminates option list)
-O     : remove assert and __debug__-dependent statements; add .opt-1 before
         .pyc extension; also PYTHONOPTIMIZE=x
-OO    : do -O changes and also discard docstrings; add .opt-2 before
         .pyc extension
-P     : don't prepend a potentially unsafe path to sys.path
-q     : don't print version and copyright messages on interactive startup
-s     : don't add user site directory to sys.path; also PYTHONNOUSERSITE
-S     : don't imply 'import site' on initialization
-u     : force the stdout and stderr streams to be unbuffered;
         this option has no effect on stdin; also PYTHONUNBUFFERED=x
-v     : verbose (trace import statements); also PYTHONVERBOSE=x
         can be supplied multiple times to increase verbosity
-V     : print the Python version number and exit (also --version)
         when given twice, print more information about the build
-W arg : warning control; arg is action:message:category:module:lineno
         also PYTHONWARNINGS=arg
-x     : skip first line of source, allowing use of non-Unix forms of #!cmd
-X opt : set implementation-specific option
--check-hash-based-pycs always|default|never:
         control how Python invalidates hash-based .pyc files
--help-env      : print help about Python environment variables and exit
--help-xoptions : print help about implementation-specific -X options and exit
--help-all      : print complete help information and exit
Arguments:
file   : program read from script file
-      : program read from stdin (default; interactive mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
pg# 

Впрочем, сам интерпретатор пока не очень работает:

pg# ./ix run bin/wasm/edge bin/python/11/wasi --target=wasi32 -- wasmedge --enable-all '$(command -v python3.wasm)' 
Exception ignored error evaluating path:
Traceback (most recent call last):
  File "<frozen getpath>", line 353, in <module>
OSError: [Errno 0] Error
Fatal Python error: error evaluating path
Python runtime state: core initialized

Current thread 0x00000000 (most recent call first):
  <no Python frame>

На phoronix обсуждают какую-то презу, в которой объясняется, почему Linux не используют в mission critical системах.

https://www.phoronix.com/news/Linux-On-Airplanes-Challenges

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

#linux #kernel

#GNOME #gtk #ssd

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6161

Продолжение темы про server side decorations, жирно, годно.

На этот раз господа из gtk прямым текстом говорят, что wayland - им не указ:

"There is no debate. And this is not a standard. It is an experimental protocol that somebody slapped the xdg name on and merged into the wayland repos. It is not implemented by anybody except sway and kwin"

И ответ:

"Please refrain from making fun of the Wayland community this way. We've worked very hard to reach a consensus among all wayland-protocols members, and it feels like you're dismissing this work"

Тут вот активно форсят тему про планирующийся бой Маска и Цукерберга, а я вот, конечно, хотел бы посмотреть, как подерутся Simon Ser и Clasen, например.

#llvm

https://reviews.llvm.org/rG75a1797044fc

Поддержка fat lto .o файлов.

Сделано это изящным (нет) хаком:

"The new pipeline initially clones the module and runs the
selected (Thin)LTOPrelink pipeline, after which it will serialize the
module into a .llvm.lto section of an ELF file"

Натурально, положили IR в отдельную секцию в .o файле.

Получается, что, если, в итоге, будет использован LTO, то дополнительная работа по оптимизации и подготовке объектного кода будет выброшена на ветер.

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

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

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 байткод по их распаковке. Ну, ладно, ладно, где-то еще нужно будет хранить всякие там веса, и прочие данные для декодера.