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 полезу.

https://codeberg.org/dnkl/foot/src/tag/1.11.0/README.md#user-content-xtgettcap #terminfo

Хорошая же тема, да, чтобы эмулятор терминала сразу отдавал свои capabilities, без всяких terminfo database, да?

Как бы это сделал вменяемый разработчик? Например, чтобы эта функция терминала отдавала TERMINFO запись as is, чтобы ее можно было там передать в curses, и использовать сразу? В крайнем случае, машинно-понимаемой трансляцией в json/xml/yaml.

Но, очевидно, Том #Хуйкин(разработчик xterm), индус #Ковид(разработчик Kitty), и неизвестный мне разработчик #foot(ссылку на опус которого про поддержку sync updates я тоже кидал), к такому решению, конечно, прийти не могли - это ж всего 3 строчки кода, и победную реляцию не напишешь!

Поэтому, конечно, все это сериализуется в промежуточный непонятный формат(с потерей в процессе), а клиенты потом должны восстанавливать. Зато можно будет написать еще 10 победных реляций про очередную перемогу в стиле "а мы поддержали еще 5 полей из terminfo"(несовместимым, конечно, образом).

———
https://www.opennet.ru/opennews/art.shtml?num=56703
https://www.opennet.ru/opennews/art.shtml?num=56704
https://www.opennet.ru/opennews/art.shtml?num=56700
https://www.opennet.ru/opennews/art.shtml?num=56699

Слушайте, вот вы понимаете, зачем люди клепают эти производные Debian с нескучными обоями? Меня, как автора настоящего, интересного, дистрибутива, это все, конечно, напрягает.

———
https://lobste.rs/s/adr60v/single_binary_executable_packages

Очередной срачик static vs. dynamic. Автор, конечно, говорит дельную вещь - а давайте, типа, сразу все приложения готовить в виде одного исполняемого файла, но он, наверное, сам так не пробовал, и не понимает, в чем проблема такого подхода.

Кстати, совсем забыл. Если вы такой же фанат машграфа, как и я - обязательно подпишитесь на https://www.facebook.com/sergey.tsyptsyn/

Вернусь к вчерашней ссылке про static vs. dynamic.

https://lobste.rs/s/adr60v/single_binary_executable_packages#c_xoxpbs

1) Там подняли интересные темы про статическую линковку в Rust и Go.

2) СЯУ, что в Rust нет кросс-компиляции. Ну, точнее, есть, по модели CMake(#cross #cmake на сайте написано, что есть, а cargo таки оперирует одним графом). Я это еще заприметил, когда только начал им пользоваться, но у меня не хватало уверенности, чтобы об этом сказать.

———
https://codeberg.org/dnkl/fuzzel/pulls/53

Автор #foot классный. Я как-то писал про проблему первого кадра в sway, так вот, коллега тоже обратил на нее внимание, и даже предложил решение.

———
https://rtpg.co/2022/02/13/your-own-sudo.html

Товарищи, если кто-то в вашей окружности решит написать sudo на python, пристрелите его.

* питон загружает много модулей
* авторам so-шек обычно нет выхода, кроме как заполучать параметры для себя через env
* man secure_getenv, и связанные с загрузкой so #suid-ными бинарями CVE.

———
https://gankra.github.io/blah/text-hates-you/
http://rastertragedy.com/RTRCh0.htm

Классные тексты про text rendering и text shaping.

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

Кстати, про шрифты - связка Inter + IBM Plex мне нравится даже больше, чем набор шрифтов в macOS.

https://github.com/skarnet/execline/issues/9

Успел посраться с автором s6, по поводу утилиты #execline. По очкам я, конечно, победил, но мое предложение он, конечно, отверг.

———
Будни бутстрапа.

Как-то писал про то, что система зависает, если убить sway неправильно. Оказалось, что она не зависает, а просто прекращает как-то реагировать на ввод. Фикс, что характерно, я подсмотрел в трекере sway. https://github.com/pg83/mix/blob/main/pkgs/bin/fixtty/main.c https://github.com/swaywm/sway/issues/4540

Фикс этот, конечно, не может войти в sway, и его вряд ли примут mainstream дистрибутивы. Я не гордый, я дергаю программулю перед каждым новым логином:

https://github.com/pg83/mix/blob/main/pkgs/bin/mingetty/runit/mix.sh#L16

У меня лучший дистрибутив для работы со sway!

Заодно выпилил хаки, и прибиваю stale процессы почем зря.

Отдельно скажу, что вот эти tty - это, конечно, кошмар. Про них Линус и так говорил, что не понимает, как они работают, но после того, как к ним привязали KMS/DRM, стало вообще худо. https://lwn.net/Articles/343828/

Еще интересный факт - у меня, когда я еще использовал Fedora, регулярно не просыпался ноутбук после сна. Теперь я смог это раздебажить. Оказывается, драйвер amdgpu начинал сыпать стектрейсами, sway падал в кору, и система приходила в волшебное состояние, которое я описал выше. Теперь же она из него замечательно выходит сама, и я увидел все корки в dmesg.

Простота - это хорошо. В федоре у меня не было никакой возможности увидеть эти трейсы. Чинить баги, а не документировать их в wiki, как делают Arch/Gentoo - тоже.

Кстати, amdgpu не сыпет этими стектрейсами в 5.17, ждем релиза.

https://mobile.twitter.com/marcan42/status/1494213855387734019 #asahi

У меня чет знатно долбануло от заявления этого долбоеба разработчика Asahi Linux Гектора Мартина:

"Well, this is unfortunate. It turns out Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity."

Давайте я вам расскажу, что там происходит.

Гектор жалуется, что macos "читит" - некорректно реализует семантику fsync(а я, кстати, позволю себе напомнить, что macos - сертифицированный Unix, в отличие от), и, за счет этого, обгоняет его драгоценный Ляликс на бенчмарках NVMe. И отмечает, что, если в Apple ткнуть паяльником, то после ребута она потеряет данные.

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

Вы в macos теряли данные после ребута? Я не терял.

Если инженеры Apple:

* Хорошо отладили свою ОС, настолько, что ГАРАНТИРОВАТЬ, что OS сбросит буфера FS и контроллера на диск при нажатии на кнопку Reset.

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

То им просто не надо реализовывать ту семантику fsync, о которой говорит Гектор, чтобы обеспечить целостность данных.

Я напомню, что вот та семантика fsync, о которой пишет Гектор, нужна, когда твою OS пишут красноглазые пионеры без тестов. Потому что заставить весь зоопарк FS флашить данные пофайлово - невозможно. Заставить FS флашить данные корректно - невозможно https://danluu.com/file-consistency/ https://www.deconstructconf.com/2019/dan-luu-files Убедиться, что весь зоопарк контроллеров флашит данные корректно - невозможно.

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

Короче, Кисо обиделось, что кто-то хорошо проделал свою работу, и может на это полагаться, и срезать пару острых углов на этом, и хорошо смотреться на бенчмарках. И что не рассчитывает на паяльник. А его красноглазое поделие такой роскошью не обладает. И что это поделие не способно эффективно работать в той модели sync, на которую рассчитывает macos.

Ну чо, норм, но не надо говорить, что macos "читит", это вводит людей в заблуждение. "if you don't care about data integrity" - Гектор просто не понимает, насколько, а самое главное, КАК, Apple заботится о integrity.

И, кстати, еще такая мысль - подобные штуки поясняют, почему Apple против Хакинтошей, и почему Хакинтоши - так себе мысль. macOS работает на железе, которое сделано по несколько другой философии, это нужно учитывать

Давно обещал написать про Фуксию, и, думаю, пора. #gold

WARNING: я лично очень хочу, чтобы то, что я напишу ниже, произошло, поэтому этот текст во многом - wishful thinking.

Для начала - исторический экскурс.

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

Фактически, у индустрии было 2 пути:

* MINIX. К сожалению, Таненбаум уперся рогом, и отказался выпустить эту OS под нормальной лицензией.

* BSD. К сожалению, в тот момент AT/T && Bell Labs сошли с ума, закрыли код Unix, и начали вовсю судиться за его наследие. Поэтому судьба BSD ответвления была неясна, а корпорации не любят, когда правила игры не известны, и не лезут в это. Конечно, появился проект по переписыванию спорных частей BSD, мы его теперь знаем как FreeBSD. Но он немного опоздал.

(открытие кодовой базы Solaris, я, например, не рассмариваю, потому что она была ответвлением той же "проблемной" BSD)

В этот момент появился Linux. Нормальный(для того времени) код, более-менее приличная лицензия. Энтузиасты подхватили, корпорации пошли вслед за ними. Да, я считаю, что залог успеха Linux - это не качество его кода и не личность Торвальдса, а, в основном, что это было good enough решение, появившееся just in time.

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

Я, например, на тот момент перепробовал и Linux, и все семейство BSD, и я не могу сказать, что кто-то из них был явно лучше. Более того, я могу совершенно уверенно заявить, что на момент 2010 года core Linux и FreeBSD по качеству отличались не сильно. Perf поисковых программ на Linux и на FreeBSD были вровень вплоть до самого перехода.

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

Теперь я хочу сформулировать некоторый ключевой для текста поинт.

Мой поинт - core Linux прогрессировал не шибко сильно, по крайней мере, конкуренты в лице FreeBSD все еще смотрятся неплохо на его фоне(драйвера оставляем за скобками). Ссылок давать не буду, perf тесты на всяких phoronix легко доступны. То есть, не надо думать, что там запилили кучу крутых алгоритмов, которые делают что-то умное - кодовая база это не позволяет.

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

Еще одно ключевое утверждение - современное железо становится все больше и больше черным ящиком с какой-то mini-OS внутри, работающим по фиксированному протоколу. Поясню, что я имею в виду - в Linux 50 драйверов для SATA устройств, потому что эти драйвера напрямую программируют соответствующий контроллер. А вот NVMe - это, простите, 1 generic driver на всех. USB HID - 4(джойстик, мышь, клавиатура, и 1 я забыл) generic driver на всех.

(Из этих 2 утверждений следует все остальное)

Что я хочу этим сказать? А то, что важность Linux как коллекции драйверов будет неизбежно падать, и конкурировать с другими OS он снова будет шедулером, VM, и прочими generic штуками. И, как я уже показал выше, другие OS не то чтобы сильно отстали в этом направлении(потому что, повторюсь, в core Linux нет магии, это очень обычное ядро из 90-ых).

#gold

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

Например, код Фуксии я понимаю влет, и смогу включиться в разработку в любой момент времени. Шедулер OS - это, на самом деле, очень простая вещь. Это надо прочесть 10 академических статей, попробовать 100 вариантов на симуляторе, и выбрать наилучший. Проблема в том, что в кодовой базе Linux это невозможно. А в Фуксии - возможно, и это будет сделано.

Виртуализацию, которую пилили 15 лет, можно будет нагнать за 2 - 3 года, имея современную кодовую базу и язык.

Исходя из всего написанного, и из того, что разработчики Linux не поменяют свою тактику, вот вам мой прогноз:

Важность Linux будет падать. Его роль в качестве гипервизора займут современные системы, написанные на современных безопасных языках. По мере того, как устройства будут упрощаться с точки зрения OS, Linux потеряет важность и как коллекция драйверов. Потом он уйдет под управление гипервизором как неплохой POSIX слой, но и там он потеряет свою важность, потому что:

* FreeBSD тоже норм POSIX слой, а корпорации таки не любят GPL.
* Я ожидаю, что свободные OS на безопасных языках подтянутся и в этом месте, и станут неплохой POSIX-пускалкой внутри гипервизора. Если там не нужна коллекция драйверов, то какая разница, кто для приложения обеспечивает POSIX fs?

(кстати, macOS тоже можно рассматривать по этой модели - non-POSIX OS снаружи, POSIX layer внутри)

Короче, в перспективе 20 лет, если кернелхакеры не поменяют свое отношение к разработке, я не вижу Linux нигде.

Будет ли там гипервизором фуксия, а POSIX слоем redox - я не берусь гадать. Фуксия лично мне нравится, но Google ее точит под IoT, и что там выйдет на больших машинах - я ХЗ. (redox мне не нравится, и вряд ли он там будет)

Почему я лично хочу, чтобы это случилось?

* Я хочу, чтобы на компе у меня стояла OS, в которой можно ковыряться

* Я хочу, чтобы у меня не тормозил браузер во время компиляции браузера

Я готов и сам экспериментировать с шедулером, но не в кодовой базе Linux. Это контрпродуктивно.

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

У меня для вас сегодня парочка анекдотов. Про сборку, конечно.

* https://github.com/pg83/mix/blob/main/pkgs/bin/net/tools/mix.sh#L18

Авторы net-tools настолько упоролись, что решили, что их сборка может быть запущена только руками, и ответы на вопросы надо вводить в терминале. К счастью, в Unix есть утилита yes, видимо, как раз для таких случаев. expect не понадобился. Чо делать, если, вдруг, на какой-то вопрос надо будет ответить N, и порядок плохо определен, я не представляю. Рецепт я подсмотрел то ли в arch, то ли в nix. Я часто обращаюсь к ним за помощью - у меня всего 1 человек на 500 пакетов, а с них не убудет.

* https://github.com/johnsonjh/OpenVi/blob/master/GNUmakefile#L402

Автор openvi при инсталляции готовит для себя какой-то бекдор(ладно, на самом деле, нет, просто так выглядит). Без всякого PREFIX, DESTDIR, в систему по живому. А временные файлы он хочет хранить в /tmp, и больше нигде.

* https://github.com/pg83/mix/blob/main/pkgs/bin/yambar/00.diff

Автор yambar настолько упоролся по плагинам, что вынес в плагин часть core, и ему приходится принудительно рассчитывать на этот плагин. Мой патч просто заменяет dlsym() на прямой extern символ, потому что ему пришлось оставить этот символ в бинарнике. Плагины такие плагины.

* Для сборки ядра нужна тулза bc. Тулза bc от проекта GNU требует для сборки программу ed. Но если собирать bc от GNU с ed от GNU, то ed зависает на входе. При этом, замечательно срабатывает ed из проекта heirloom, но на получившемся bc виснет сборка самого ядра(я смотрел на выхлоп heirloom ed, и почти готов дать зуб, что он таки правильный). На этом замечательном результате я остановился, и взял bc из проекта busybox.

https://news.ycombinator.com/item?id=30410457

Я тут подумал, что, по сути, тема #bootstrap интересует меня с глубокого детства - как сделать что-то из ничего? Мои любимые приключенческие романы:

* Робинзонада
* Жюль Верн - каждое второе произведение про то, как люди оказываются в ситуации, когда у них ничего нет, и надо сделать что-то(чтобы далеко не ходить - "Таинственный остров")
* Майн Рид - скажем, "Морской волчонок".

Конечно, это все про bootstrap в чистом виде.

Clean room bootstrap второй личности - кажется, очень интересная тема. Тоже низачем, тоже в качестве хобби.

———
Хочу развить тему кражи заимствований из других пакетных баз.

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

Недавно я придумал, как мне существенно сократить время на version update.

Мне нужно распарсить репозитории arch и nix, вытащить оттуда url'ы, и, если для какого-то моего урла у меня есть префикс в этой украденной базе, но суффикс не совпадает, то это значит, что у меня появилась новая версия.

Это позволит мне(на первых порах, конечно!) не заниматься скриптами парсинга страниц от вендоров на предмет наличия новых версий, и в несколько раз сократит время на занятие такой поддержкой. Предположительно, минут 5 в день на 1000 пакетов.

———
В продолжение предыдущей темы - про размеры пакетной базы.

Arch и Nix впечатляют своими размерами, но надо понимать, что это "ни о чем".

БОльшая часть этих пакетов - это автоматически сгенеренные описания из хорошо формализованных источников типа pypi, cargo, cabal, etc.

Ну вот у меня тоже такое есть для pypi - https://github.com/pg83/mix/blob/main/pkgs/pip/pypi.json (оно пока неполное, потому что надобности в полном pypi пока нет).

<—Кстати, заодно похвастаю своим механизмом VFS - произвольные части дерева пакетов могут быть построены программным образом. Например:

* https://github.com/pg83/mix/blob/main/pkgs/pip/mount.py - вот такая генерилкя для этого pypi.json. То есть, пакетная система на лету строит описания пакетов для экспорта из pypi.

* Оверлеи в пакетной системе для произвольного локального переопределения произвольного поддерева сборочных пакетов.

Протокол очень простой - если в поддереве есть mount.py, то позвать его метод serve() на суффикс пакета(за вычетом префикса поддерева) - https://github.com/pg83/mix/blob/main/pkgs/pip/mount.py#L68 Конечно, такой VFS слой может вернуть и код какого-то другого mount.py(даже программносгенеренного) в своем поддереве. Мета-мета-программирование my ass!—>

Короче, если выкинуть все такое формализованное, и посмотреть на ручную работу, то у меня 250 библиотек в lib/, а у Nix - 1700 в development/libraries/. Разница есть, но даже не на порядок.

Ну, зато я теперь могу задуматься про импортозамещение Nix && GUIX!

#sway Simon Ser наконец-то очнулся. Видимо, с такой скоростью разгребания входящего потока сообщений наша переписка займет 2 - 4 месяца.

Ну я не удержался, конечно, от того, чтобы поучить его жизни - https://github.com/swaywm/sway/issues/6828#issuecomment-1047656334

А чо, пусть коллега изучит используемые им API, наконец-то. Конец, наверное, тоже немного предсказуем.

Системы по загрузке плагинов делятся на: #plugins

* "Нормальные"

Точка входа в XXX.so имеет вид OBJECT* init_XXX(CTX*). Так устроен, например, python. Версионирование, без излишних вызовов dlsym(), без модификации глобального состояния. В общем, приемлемо, ну, насколько это вообще может быть приемлемо. Статически линкуются только в путь.

* "Ну такое"

Все, то же самое, но точка входа имеет вид init(), без _XXX. Это норм, когда система плагинов не подразумевает никакой возможности статической линковки. В случае статической линковки приходится ходить sed'ом по коду, и сводить все к первому случаю. Ну, например, vulkan loader.

* Всратые

Всратость бывает, конечно, разная. Например, плагины для gio подсистемы из glib:

https://github.com/GNOME/glib-networking/blob/master/tls/gnutls/gtlsbackend-gnutls.c#L278

Казалось бы, первый тип? Нет, 2 строчками ниже опциональная регистрация в каком-то глобальном объекте, если в конструктор не передали место, куда регистрироваться. Опциональная с точки зрения runtime, но не линкера.

Ну, от GNU и #GNOME особо никто ничего и не ждал.

* Всратейшие.

Тут кто во что горазд. Например, FAR Manager - 20 точек входа, 10 из которых - это глобальные объекты в плагине. Все это добро может быть, а может и не быть. Плагин имеет произвольный доступ к состоянию программы, к ее глобальным объектам. Ссылок не дам - это все размазано по всему коду. Ощущение такое, что кто-то порезал монолитную программу на .so произвольным образом, но, вместо того, чтобы динамически с ними слинковаться, сделал из этого плагины.

* Леденящий душу пиздец

Например, загрузка плагинов для загрузки разных форматов изображений в gdk-pixbuf. https://github.com/GNOME/gdk-pixbuf/blob/master/gdk-pixbuf/gdk-pixbuf-io.c

Что бы я тут особо подчеркнул:

- 2 разных системы загрузки плагинов - для встроенных, и для внешних

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

- Самое встратое - вместо того, чтобы полистить содержимое директории с плагинами, это говно ожидает, что установщик очередного плагина добавит метаданные этого плагина в какой-то очень встратый файлик. Повторить это я не смог, и притворился, что svg - это встроенный плагин, но загружаемый через dlopen() https://github.com/pg83/mix/blob/main/pkgs/lib/gdk/pixbuf/00.diff

- Конечно, всё это говно только ради одного единственного настоящего плагина in the wild - загрузчика svg

Точек входа у каждого плагина там 2, это важно. Имена у всех них одинаковые, статическая сборка не предусмотрена.

Отдельной строкой хотел бы упомняуть лоадер из opengl(). Там, конечно, есть GetProcAddr(const char*), чтобы можно было одни драйвера делать послойно над другими, но, несмотря на это, каждый драйвер должен проэкспортировать все 300 функций из opengl() явно. Благо, это просто - все 300 функций описаны в удобном XML файле. Отсюда десятки проектов типа https://github.com/anholt/libepoxy, которые генерят мегабайты кода в виде .so, только чтобы подменить пару функций. Я думаю, программистам на C это очень заходит - мегабайты кода без единой аллокации и возможных проездов.

Я, кстати, прикидывал - средний вызов в opengl/vulkan проходит 3 - 5 уровней косвенности. Так и живем.

Я не люблю проекты GNU и #GNOME за их левацкую, SJW-шную показушность, очковтирательство, и нечестность.

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-42-Beta

GNOME 4X - это сплошная ложь.

Я не уверен, что на старте у них вообще были приложения, портированные на GTK4, сейчас таких приложений около половины, и ни одного, в которых вы проводите бОльшую часть времени. Epiphany(WEB браузер), Evince(просмотр документов), terminal - все еще на GTK3. inkscape(хотя и не часть GNOME) вообще только недавно перешел с GTK2 на GTK3). Просмотрщик шрифтов на GTK4 - это, конечно, круто(нет, это херня). Я не думаю, что вы проводите много времени в control center и просмотре шрифтов.

Благо, отличить на внешний вид приложение на GTK4 от приложения на GTK3 невозможно. С одной стороны, это может быть и хорошо в виде преемственности, а с другой - зачем тогда вообще бампать версию тулкита, если там только рефакторинг интерфейсов?

Бампать мажорную версию DE, с таким трудом обновлять в репах, чтобы что? Чтобы видеть те же приложения в том же интерфейсе и с теми же фичами?

Кстати, вчера каналу исполнилось полгода, принимаю поздравления и фидбек. Напомню, что лучшее, что вы можете сделать - поделиться ссылкой на канал где-нибудь(разве что, вот тут не надо - https://bdsmpeople.club/).

В одном там рабочем чате с коллегами зашла речь, кто как смотрит порно. Мне пришлось признаться, что я для этого использую рабочий macbook, потому что в моем браузере все еще не работает поддержка видео. Собственно, у меня там 3 заметных проблемы:

1) Поддержка видео. Как починю, обязательно напишу про эту эпичную историю.
2) Про кривые иконки из-за старой librsvg я уже писал, надо или как-то затащить Rust, или научить это оффлоадить в inkscape. Я склоняюсь ко второму пути.
3) И сегодняшняя история - поддержка PDF!

Epiphany, как и многие, поддерживает PDF через PDF.JS. Но оно почему-то не работает. Конечно, как обычно, дело в динамическом связывании - код, которому нужен код читалки, не может его найти в runtime. И в данном случае дело не в статической линковке, а в чем-то еще(что-то с ресурсной системой glib, я не разобрался пока).

Чинить это займет время, а pdf-ки читать надо уже сейчас.

Я решил вечерочком собрать себе читалку - Evince. Думал, плевое дело, простая программа, все зависимости уже в репе, 5 минут, не больше. Ага, конечно.

* В программе есть плагины. Читатели у меня уже прошаренные, поэтому я просто скажу, что загрузка плагинов там по второму типу #plugins Плагины много времени не заняли, все же, это основная фишка дистрибутива.

* После загрузки программы я увидел надпись "unsupported mime type application/octet-stream", и тут я понял, что это надолго.

Не буду утомлять скучными подробностями #debug, но:

* glib неявно зависит от базы данных для определения mime types. Неявно - значит, все делает вид, что работает, до поры до времени, примерно как TLS в той же #glib.

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

* Самое страшное - сборка этих данных зависит от docbook xml, а это моя дикая боль. Я напишу об этом отдельно, но надо понимать, что там очень сложная динамическая линковка данных поверх XML, все это сдобрено perl, с легким налетом GNU. Я это затащить могу, но очень не хочу, и пока просто обходил стороной. А тут жесткая зависимость сборки.

Короче, я решил, что вместо всей этой херни я вкорячу старую-добрую libmagic, из пакета file http://www.darwinsys.com/file/. Хороший, древний, проверенный код, без изъебов.

revision 1.1
date: 1987/08/23 19:51:05;  author: ian;  state: Exp;
Initial revision

Код чуть младше меня.

Замечания по ходу процесса:

* Пришлось сделать thread-safe обертку над api libmagic: https://github.com/pg83/mix/blob/main/pkgs/lib/mimetype/mix.sh

* Как оно используется: https://github.com/pg83/mix/blob/main/pkgs/lib/glib/01.diff (блин, а код без аллокаций на C писать вполне норм!) Я бы хотел тут остановиться, и сказать, что оно заработало like a charm, но нет

* glib сначала пытается определить тип по расширению, в #libmagic этого нет. Я это обошел тем, что всегда определяю по данным. NVMe все стерпит.

* Без нужных ему данных glib определяет длину буфера для autodetect в 0. Ну, починил.

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

Короче, все заработало, а бонусом я выяснил, что в диалоге открытия файлов в GTK не работали иконки, потому что им нужен mimetype. А я и не замечал.

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

Если честно, то мне, конечно, пишется не очень.

Но я решил:

* Что лучшее, что я могу сделать - это продолжать писать на интересные темы

* Тут про говнюков у власти я писать не буду, много чести, пишу про них на других площадках

———
Продолжаю изучать Epiphany. #igalia

Разработчики из https://www.igalia.com/, конечно, феерические долбоебы.

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

Но разработчики Igalia, потому что не умеют программировать:

* Перенесли в основной процесс браузера резолв сайтов
* Хождение за adblock
* И всякого по мелочи

Как я нашел? Я отлинковал glib-networking от основного процесса, и оставил только в WebKitNetworkProcess. Основной процесс сломался. Дальше strace.

(epiphany:12977): epiphany-WARNING **: 
14:01:08.569: Cannot fetch source for 
filter 1f353f7cdbb012b9fb1226455f1b3bec
ba42070e1970c1524996fa3a871af406 from 
<https://easylist-downloads.adblockplus
.org/easylist_min_content_blocker.json>: 
Error resolving “easylist-downloads.adblockplus.org”
: Try again

В условиях динамической линковки плагинов такой фокус провернуть было бы сложно, на правах рекламы :)

———
https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.9

Грепните на предмет "we add an extra sanity check", и удивитесь, каким эзоповым языком разработчик описывает фикс реальной cve про проезд. А как будто и не было ничего, а если и было - то совсем неважно.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-getrandom-8450p

Нормальные люди бы сказали "убрали валенок на пульте", а не ускорили в 85 раз. И то, и то, конечно, правда. Зато вторая правда никого не обижает!

———
Меня тут спрашивают, на кого из известных программистов я хотел бы походить.

Конечно на Тео Де Раадта!

1) Сквернословит
2) В одиночку поддерживает целую OS
3) Записывает хуйовые песни перед каждым релизом!

------
https://discourse.llvm.org/t/parallel-input-file-parsing/60164

Разработчики LLVM - люди гордые, не пнешь, не полетят!

Получив пинка от разработчика mold, коллеги из LLVM решили пооптимизировать LLD. Лучше поздно, чем никогда!

Обещал тут написать про модель безопасности. #seq_model #gold

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

* Удобно рассматривать эту модель как двухпользовательскую - root + user, факт, что какие-то там системные процессы запущены от nobody фактически ничего не меняет.

* Все ценные данные на вашем ноутбуке принадлежат вашему личному аккаунту. Кредитки, пароли, ключи доступа. root владеет лишь системными файлами и демонами.

* Поэтому, если вредонос получает доступ к вашему пользователю, то он получает доступ ко всему полезному содержимому вашего компьютера. Заполучить root права НЕ ЯВЛЯЕТСЯ целью атаки. root в такой системе ни для чего не нужен, не нужен даже для запуска регулярного фонового процесса, потому что в любой современной OS есть сессионные пользовательские супервизоры процессов. Скажем, dbus.

* Скрыть свое присутствие - это тоже не про root, BTW, это немного другие дыры в системе.

Отсюда интересное следствие.

Удобно рассматривать root не как пользователя, который может все, а как способ разделить опасные операции, которые требуют подтверждения, и на все остальные. То есть, sudo в такой системе - это не эскалация привилегий, а подпись, что текущую команду ты запускаешь, понимая, что она делает. Ну и, соответсвенно, гарантия, что обычный rm -rf $STEAM_ROOT/ не снесет весь корень(https://github.com/ValveSoftware/steam-for-linux/issues/3671)(да, я знаю, что щас rm -rf / работает несколько не так).

Соответственно, у меня довольно наплевательское отношение ко всяким там CVE для #system0. Классно, конечно, что там какой-то проезд позволяет локально получить рута, но я надеюсь, что я сумел объяснить, что иногда от этого не горячо и не холодно.

Отдельная тема - где же тогда лежит периметр безопасности в вашем ноутбуке. Ответ достаточно очевидный - он лежит в вашем браузере. Софт вы качаете из сторов, всякое говно из интернетов не запускаете. Периметр - в sandboxing кода, выполняющегося в браузере. В обработке картинок браузером. И так далее. Браузер надо любить, холить, обновлять. Браузер единственная(ну, ладно, еще sshd) программа в системе, которую я вижу смысл облизывать с точки зрения безопасности - всякие там libc hardening, ASLR(pic), etc.

И ужу точно не в вашем /etc.

Почему это не про телефон? Потому что ваш телефон это не двухпользовательсякая среда, а многопользовательская, пользователи не доверяют друг другу.

Почему не про BYOD? Потому что в BYOD 3 пользователя, вы, root, и товарищ майор(которому надо и скрыть свое присутствие для зловреда, и обнаружить такогого). Тоже интересная модель, но как нить в другой раз.

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

Я люблю, когда все "ортогонально". https://en.wikipedia.org/wiki/Orthogonality_(programming) В практическом понимании это значит, что код, отвечающий за какую-то сущность, должен быть локализован. Причем, конечно, желательно, чтобы не просто локализован в виде лапши в одном файле, а в виде функции, желательно, вообще сжат в одну строку кода :) Так модификация функциональности затрагивает меньше мест, и менее подвержена ошибкам.

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

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

Короче, я там "ортогонализировал" одно CLI API.

У меня был такой CLI по управлению #realm :

add realm_name [pkg_name [pkg_flags]*]+
remove realm_name [pkg_name]+
upgrade [realm_name]*, 0 вхождений == all
purge realm_name - удалить realm

Думаю, особых комментариев тут не нужно, более-менее стандартные для пакетного менеджера операции.

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

Я поменял это все на 2 команды(можно на одну, но получается немного неудобно):

update [realm_name [(|+|-)pkg_name [pkg_flags]*]*]
purge realm_name

update без параметров это upgrade all, update realm_name это upgrade realm_name, а если есть параметры, то они формируют цепочку добавлений и удалений пакетов в realm_name.

Стер пару килобайт кода, и упростил оставшееся. Думаю, что, если бы я попробовал миновать стадию add/remove/update, получилось бы не так естественно.

Кстати, для любителей rust update у меня называется не "update", а, конечно, "mut".

Возможно, purgе я со временем редуцирую в update (|+|-)realm_name, если понадобится какая-то атомарность и в этом месте.

PS: понимаю, что сегодняшний текст больше похож на braindump процесса размышления над разработкой фичи, но, IMHO, это тоже может быть интересно и полезно.

Про происходящий пиздец я, как и обещал, ничего не пишу, но в приложении к моему хобби, думаю, можно.

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

Я на своей странице github убрал упоминание что я из России, и сменил почту на нейтральный домен. Не то, чтобы я чего-то стыдился, но я не хочу быть part of the problem, если вы понимаете, о чем я. Предполагаю, ЕБЖ, число ревьюх от меня в OSS проекты вырастет, и я не хочу чтобы они отправлялись в никуда из-за политических взлядов автора модифицируемого кода, или его национальности.

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

Вышел mold с LTO, но чуда не произошло, с LTO он по скорости такой же, как LLD. Впрочем, я пробую, just for fun, пересобрать весь Mix с Mold вместо LLD.

———
https://www.rbc.ru/technology_and_media/27/02/2022/621a7f4f9a79473d8899b18d

———
https://www.phoronix.com/scan.php?page=news_item&px=ReiserFS-Deprecate-Remove-2025

fun fact - я читал 3 англоязычных форума про эту новость, и все 3 почти моментально скатились на тему личности Ганса и убийство им его жены.

Мой любимый https://www.opennet.ru/opennews/art.shtml?num=56747 скатился только после того, как кто-то там не сказал "а чо все обсуждают, а мы нет", и то, ненадолго.

https://panorama.pub/news/dlya-obxoda-sankczij-rossiyu-mogut-pereimenovat

Господин Белковский, из ФСБ, решил выступить в роли пентестера. Я, конечно, считаю, что решение очень интересное, и может проканать. Понятное дело, что базы данных ЕС и США не очень-то рассчитаны на переименование стран. Причем надо именно переименовать inplace, распустить страну и создать новую на том же месте поможет не очень.

———
https://github.com/pg83/mix/blob/main/pkgs/mix/hooks.sh#L41

У меня есть враппер для компилятора, с помощью которого я "навязываю" пакетам свои решения. Прокидывать это через cflags и прочие опции для cmake/meson/configure - это для очень богатых людей, я себе такое позволить не могу.

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

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

Пока это, конечно, закат солнца вручную - https://github.com/pg83/mix/blob/main/pkgs/bin/evince/mix.sh#L83