#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, то стимул починить С++, конечно, был бы существенно выше, я был бы оптимистичнее про судьбу С++.

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

Я, конечно, пытаюсь свои патчи отправлять в upstream, но чаще всего оказывается, что оунеры кода - те еще негодяи.

Вот, отправил свой патч про отказ от double fork. -20 строк кода, сплошное упрощение и улучшение. Как думаете, какие шансы у патча? Я вангую, что околонулевые.

https://github.com/swaywm/sway/issues/6828

Теорминимум по #bootstrap

Разные команды вкладывают в это понятие очень разные смыслы.

Кто-то - что в процессе сборки не должны участвовать бинарные блобы(за исключением возможного минимума). Понятие "бинарный" часто не конкретизируется. Java VM, python pickle - чаще всего "бинарные блобы". По мне, так программы для "раннебутстрапного" forth от бинарных блобов не отличимы, но это никого не останавливает.

Кто-то идет еще дальше, и считает, что автосгенеренные исходники использовать тоже нельзя. Эти люди занимаются бутстрапом flex/bison/ragel/etc. К сожалению, на этом пути лежит пропасть и бездна - configure скрипты. Уважаемым коллегам или приходится переписывать систему сборки части кода, или бутстрепать код в бездну веков. Это, например, GUIX.

Кто-то больше всего печется о "чистоте" результата. Ну, чтобы рандомный Васян мог воспроизвести md5-equal result. Используется ли при этом бинарный seed, или нет, коллег особо не волнует. Это, например, Nix.

Я тут стараюсь придерживаться прагматичной стороны - я не перестраиваю configure на ранних этапах bootstrap, но когда у меня готов perl, начинаю перестраивать. Типа, получить 95% результата за 5% денег. Если у меня 1000 пакетов, и в 995 из них я убираю сгенеренные файлы, поверхность для атаки я уменьшаю многократно, и вполне достаточно для практических целей. Бинарный seed я, фактически, использовать не могу, потому что чаще всего он рассчитывает на наличие glibc.

Еще интересная дихотомия - какой язык использовать в качестве "изначального". Чаще всего это компилятор С, потому что достаточно высокороуровнево(не надо мудохаться с ассемблером и гипервизором в кольце 0), можно дотащить цепочку, куда угодно, большинство системного кода написано на С.

Я тяну цепочку с С++, потому что поддерживаю Darwin, а там единственный компилятор, который умеет рожать Mach-O - это clang. Есть проекты, которые тащут tcc/scc под Mach-O, я с удовольствием за ними слежу(потому что С++, это, конечно, многовато).

Наверняка есть попытки затащить эту цепочку с Rust, но я о чем-то таком успешном пока не слышал. В принципе, все для этого есть - uutils, наверняка есть простой компилятор С на Rust, шелл точно есть. Если тащить с Rust, то, конечно, с собой нельзя брать Cargo. Весь смысл теряется, если добавить cargo в seed, да и не спортивно это. Как #mrustc тянет cargo через свой minicargo - это же песня.

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

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

Я перенес построение realm/environment из пакетного менеджера в граф построения пакетов. Звучит странно, и непонятно, зачем это нужно?

#realm - definition ***

realm/environment - это материализованное в FS множество пакетов. Если говорить просто - папочка, которая содержит кучу симлинков на файлы из других папочек(пакетов). Куча симлинков образует некоторую сущность(realm, env), которая самодостаточна для выполнения какой-то задачи.

Чтобы совсем просто:

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

* realm из пакетов busybox + runit + kernel достаточен для запуска компьютера.

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

Теперь построение папки с симлинками погружено в тот же граф, что строит пакеты. Фактически, с точки зрения системы realm стал таким "пакетом с пакетами", если вы понимаете, о чем я.

Почему это вообще важно? Теперь вторая часть моего сегодняшнего рассказа!

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

* Сначала у меня в системе был только root, все пакеты строились от него, все было в едином namespace. Я так отлаживал пригодность модели "куча папок с симлинками" для управления файлами системы вообще.

* Потом я завел пользователя mix. На этом этапе построение пакетов и realm/env выполнялось от пользователя mix, я сам был залогинен в mix, но сервисы уже работали от root. Я так отлаживал свою модель эскалации привилегий и модель "пакеты не от root". Это уже почти норм, кроме того факта, что неловким движением можно снести всю пакетную базу.

* С пятницы я живу в модели "пакетный менеджер - это демон, который крутится от пользователя mix, принимает команды на управление пакетной базой, и выполняет в соответствие со своей моделью безопасности". Важно отметить, что примитивная команда - это не "установи в систему bin/bash", а ПОЛНОЕ описание(граф с зависимостями) того, как построить бинарник bash, и установить его в систему. Я эту модель опишу в следующих сериях.

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

Короче, модель вполне жизнеспособна, пакетный менеджер я отселил в socket activation daemon*, с точки зрения модели безопасности мне все очень нравится.

* забавно, как можно продать одно и то же говно, но разными словами. Мой socket activation daemon - это "mix gen-graph —json | ssh mix@localhost /bin/mix execute —stdin" (напомню, что мои su/sudo - это suidless программы, которые делают ssh на localhost)

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

*** я намеренно выбрал странное слово realm, а не всем знакомое env, потому что, конечно, мой realm похож там на env из Nix, но не настолько, чтобы считать их одним и тем же. Чтобы в голове не было путаницы, я выбрал похожее, но другое, слово. IMHO получилось хорошо, удобно, и однозначно(меньше путаницы в голове это уж точно)

https://tjournal.ru/news/533398-rukovoditeli-ibm-vo-vnutrenney-perepiske-nazyvali-rabotnikov-starshe-40-let-dinozavrami-kotorye-dolzhny-vymeret

Новость, конечно, позитивная, потому что это сразу решит проблемы с дедами в Комитете С++, мешающими этот стандарт двигать вперед. Or not? #cppcom

https://www.opennet.ru/opennews/art.shtml?num=56691 #lust

У меня пара свежих мыслей на тему:

* За пределами big tech мало кто понимает, что ядро на голой сишечке - это леденящий душу пиздец. Intel-у, например, вполне OK.

* За последние несколько месяцев я прочел довольно много кода драйверов(kernel, mesa), чтобы понять, что средний драйвер - это очень тупая штука, которая берет набор за-OR-енных generic флагов, превращает их в набор за-OR-енных device specific флагов, и пишет это число в порт. Управления памятью в среднем драйвере или нет, или очень мало.

* Желание читать мануалы про за-OR-енные device flags чаще всего антикореллирует с желанием прогать на высокоуровневом языке.

Поэтому мое IMHO - в текущем виде это проект для себя и узкого круга компаний, типа Facebook, которые "понимают". Я считаю, что текущее целеполагание проекта - странное. Ну перепишут Гугл драйвера для своих TPU, а дальше что? Intel и средний "kernel hacker" это не купят.

IMHO правильным целеполаганием было бы "переписать tcpip stack"(потому что новые алгоритмы для congestion control, конечно, проще на Rust/C++), или "переписать шедулер". Впрочем, возможно, истинное целеполагание именно такое, просто оно не озвучивается. Это, конечно, было бы хорошо. Мне не нравится Rust, но вот писать на С я в ядро точно не полезу, а на Rust полезу.