Ночной (уже) #rant

У меня продолжает бомбить от обновления #musl, да.

Есть такое, довольно популярное мнение, что мы "должны" open source'у, и что надо тащить все изменения в #upstream, неважно, насколько там упоротые мейнтейнеры.

Я с этим категорически не согласен, ничего мы никому не должны, кроме того, что написано в файле LICENSE.txt.

Вот, возьмем данную ситуацию.

Что я якобы "должен" сделать?

* Сходить к Ричарду Фелкеру, и попытаться его убедить, что надо дать людям возможность узнать версию musl, с которой ты собираешься, чтобы по этой информации сделать какой-либо вывод? Да щаз, он в readme своего проекта написал, что этого не будет никогда (https://wiki.musl-libc.org/faq.html "Why is there no MUSL macro?"), а он же не может ошибиться?

* Сходить к авторам configure/autoconf скриптов, и рассказать, как "правильно" детектить наличие тех или иных фичей? Так никто не знает, как "правильно", даже Фелкер, потому что есть тесты на собираемость, и есть тесты на linkability, и они в C/C++ могут давать разный результат, из-за "define pread64 pread" https://git.musl-libc.org/cgit/musl/tree/include/unistd.h#n203 - какой-то класс тестов может не скомпилироваться, какой-то - не слинковаться.

* Сходить к авторам rust (компания пидорасов, не забываем про это!), и сказать им, что не надо руками писать интерфейсы к libc - https://github.com/rust-lang/rust/blob/master/library/std/src/sys/unix/mod.rs#L98 ?

К кому из этих трех обобщенных высокомерных мудаков мне сходить? В чем убедить?

Правильно, я пойду к самому близкому ко мне высокомерному мудаку с сильным мнением - к себе!

Мое "сильное мнение" в данном вопросе - не надо чинить то, что не сломано, и пошел бы Фелкер со своим мнением к херам.

Он удалил функции, я их вернул назад. Без патчинга исходников, просто скопировал символы - https://github.com/pg83/ix/commit/632e40fdcb56917c19f9299c165b56d77052675b#diff-d0dfd80046e1a8679abbcdebbc7ee3984b5b75653d63cc2469ec0ee6427b7c20R25

Думаю, я в хорошей компании!

Призывал и буду призывать владельцев open source софта всегда делать официальный бекап на github.

Потому что github самый надежный, а ваш sr.ht/repo.cz/gitlab/whatever однажды ляжет, и поднимать его будут неделю.

Поэтому я всегда радовался, какие же хорошие люди с freedesktop. Несмотря на то, что у них есть свой gitlab, до сего момента у большинства их проектов был mirror на github, чем я и пользовался. Их gitlab периодически лежал, и мешал релизным процессам.

Но нет, нет покоя дуракам, все снесли - https://github.com/freedesktop/

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

https://github.com/GNOME тоже, наверное, долго не продержится, а жаль.

Коллега написал хвалебную статью про какой-то новый компилируемый заменитель питона, как будто мало их - https://www.fast.ai/posts/2023-05-03-mojo-launch.html #mojo

К языку имеет отношение небезызвестный Крис Латтнер (который LLVM/Swift/etc), поэтому я пошел почитать документацию.

Сломался я на https://docs.modular.com/mojo/programming-manual.html#using-the-mojo-compiler "You can run a Mojo program from a terminal just like you can with Python. So if you have a file named hello.mojo (or hello.🔥—yes, the file extension can be an emoji!)" - слушайте, ну пусть зумеры и хипстеры на таком программируют, а мне это даже не кажется смешным, если это шутка.

Наверное, опять какая-то попытка хайпануть на Python/ML/AI/whatever.

Между прочим, тот, кто сегодня провисел весь день на главной https://lobste.rs/, и даже пару часов висел на первом месте - тот я!

Это прямо классно, в каком-то смысле, большое дело и достижение!

(не просьба накрутить лайки, если что)

https://www.primevideotech.com/video-streaming/scaling-up-the-prime-video-audio-video-monitoring-service-and-reducing-costs-by-90

Статья от Amazon Prime про то, как можно сэкономить кучу бабла, перейдя с микросервисов на монолит. Это все, само по себе, давно известно и никому не интересно.

Но, знаете ли, пока я читал эту статью, у меня не проходило ощущение какого-то пиздеца. Потому что Amazon должен писать другие статьи - про то, как надо пилить все на микросервисы, запускать их в Лямбде и Функциях, и иметь свой "web scale".

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

Пчелы против меда какие-то, короче.

https://serge-sans-paille.github.io/pythran-stories/how-unity-builds-lurked-into-the-firefox-build-system.html

Кажется, уже все мажорные браузеры используют jumbo/unity builds, потому что без них собрать браузер обычному пользователю, без доступа к распределенной сборке, ну очень уж долго.

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

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

Сам, потому что техника тогда была, видимо, не очень известна, поддержки в cmake, конечно, не было, ну и браузеры ее не использовали.

https://github.com/golang/go/issues/59968

А вот, например, rsc стебет коллег на предмет hello.🔥

Пользуясь случаем - можно у нас где-то купить https://aliexpress.ru/item/1005005456708903.html?sku_id=12000033157726361&spm=a2g2w.productlist.search_results.15.19ce730fO0psAP, но не на aliexpress? Они, к сожалению, не доставляют в мою деревню.

Не прошло и года Чуть больше года назад рассказывал про #vfs, и про оверлеи для пакетной базы.

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

Какие решения приходили в голову:

* usr/mount.py. Если вы прочли предыдущий текст, то вам сразу должно стать понятно, о чем идет речь. Если коротко - завести в корне пакетной базы папочку usr/, и в ней запилить mount.py, с подходящей vfs. Которая, например, по какой-нить переменной среды "монтировала" туда поддерево пользовательских пакетов. Такой symlink "на стероидах". Это решение хорошо всем, кроме одного - а как дать пользователю переопределять системные пакеты для своих нужд? Например, подхачить сборку lib/c.

* использовать github. Это очень простой способ - форкайте пакетную базу на github, правьте ее, как хотите, периодически делайте rebase на trunk. Самый лучший, самый простой, способ, его я предлагаю всем по умолчанию. Его недостаток - а как один и тот же оверлей использовать для двух разных снепшотов основной пакетной базы ix?

* Как в nix. overrides.nix. Все overrides.nix, которые я видел - они кривые и косые, они должны содержать все изменения в пакетной базе одномоментно. Мне не нравится. Это придется придумывать еще один формат файла, с новой семантикой, не такой, как у простого пакета.

* IX_PATH, содержащий набор путей, в которых искать пакеты. Дальше - где первыми нашли определение пакета, оттуда его и брать. Очень хороший, удобный способ, но у него есть понятная проблема - как адресоваться между слоями? Ну, вот, я в своем слое определяю lib/c/ix.sh, и в нем я хочу сказать "возьми lib/c/ix.sh из базового слоя, и подправь там то-то и то-то". Проблема в том, как адресовать вот эту конструкцию - "lib/c/ix.sh из одного из базовых слоев". Я решил решить эту проблему так - положить все оверлеи, помимо корня, где они заменяют друг друга, в vfs, примерно следующего наполнения: layers/0/lib/c/ix.sh, layers/1/lib/c/ix.sh, можно не по абсолютным номерам, а по каким-то именам, типа prev, netx, etc. И теперь lib/c/ix.sh может адресовать lib/c/ix.sh из любого нужного ей слоя, например, из базового: layers/-1/lib/c/ix.sh (а почему нет?).

Последнее решение я и заимплементил, потому что оно мне не нравится в наименьшей степени.

Вот, так, не нравится, но лучше я ничего не смог придумать.

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

"Леннарт Поттеринг предложил добавить в systemd режим мягкой перезагрузки"

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

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

Кстати, совсем в сторону - этот абзац мне чем-то напомнил концовку https://ru.wikipedia.org/wiki/%D0%A2%D0%B0%D1%83_%D0%9D%D0%BE%D0%BB%D1%8C, почитайте, не пожалеете. Однин из самых захватывающих твердых НФ романов, что я читал!

Вечерний #rant

https://www.phoronix.com/news/QEMU-8.1-Adds-PipeWire

Вот QEMU уже использует SDL. Почему нельзя для проигрывания звука пользоваться портабельным SDL API? Почему, когда у погромистов появляется свободная минутка, так и тянет запилить фабрику-другую с поддержкой кучи разных API, криво и косо, вместо того, чтобы поддержать одно портабельное API, но хорошо?

Наверное, это кажется низковисящим фруктом - "хей, смотрите, мы поддерживаем pipewire, мы молодцы"! "да, молодцы"!

Фрукт этот маленький и невкусный, потому что что стало лучше-то по сравнению с цепочкой sdl -> pipewire, или pulse over pipewire?

Вот стоило похвалить github, как он немного лежит уже который день подряд. https://www.githubstatus.com/

Давайте, давайте, троллируйте меня! :)

https://www.phoronix.com/review/gcc13-clang16-raptorlake/5

Сразу даю ссылку на страницу с результатами.

"When taking the geometric mean of all the raw performance metrics, Clang 16 was faster than GCC 13 overall by about 6% on this Intel Raptor Lake system running Fedora Workstation 38. Stay tuned for similar benchmarks on AMD Zen 4"

На моей памяти, это первое такое разгромное соревнование, чтобы clang побил gcc по качеству сгенеренного кода.

За годы я уже привык, что clang, скорее, обычно отстает на 2 - 3 процента.

https://leaningtech.com/announcing-cheerpj-3-0-a-jvm-replacement-in-html5-and-webassembly-to-run-java-applications-and-applets-on-modern-browsers/

Коллеги запустили JIT компилятор java в webassembly в webassembly (именно 2 раза, да).

Я не думаю, что эра java апплетов к нам вернется, но мысль, конечно, интересная.

https://lobste.rs/s/o6birb/way_radically_improve_security_sudo_make
https://github.com/memorysafety/sudo-rs/issues/291

Вот, коллеги пришли к похожему умозаключению, что не нужно иметь #suid bit sudo, если можно иметь демон. С кучей аргументации, с которой, я, в общем-то, согласен.

Я, конечно, не упустил момент получить толику PR, и похвастался, что оно у меня уже так работает!

https://lobste.rs/s/o6birb/way_radically_improve_security_sudo_make#c_fso4zn

.

Воскресный #rant из серии "лучше бы они".

https://www.phoronix.com/news/Intel-oneAPI-Embree-4.1

Лучше бы они портировали под arm https://github.com/intel/hyperscan.

Проблема, конечно, в том, что hyperscan - полезная библиотека, и так-то быстрые регулярки - вполне себе платформенное преимущество.

Поэтому intel никогда (ну, пока оно таки является преимуществом) не портирует hyperscan под arm, и даже патчи про это не примет в апстрим https://github.com/intel/hyperscan/pull/272.

https://github.com/intel/hyperscan/issues/197

Соответственно, тем, кому "очень нада", приходится поддерживать форк. https://github.com/VectorCamp/vectorscan

Знаменитый блоггер #maskray продолжает радовать нас зануднейшими текстами про устройство линкера. КМК, читать такое можно только либо за зарплату, ну или если вы - фанат. https://maskray.me/blog/2023-05-14-relocation-overflow-and-code-models

Основной текст интересен только тем, кто сталкивается со статической линковкой библиотек от nvidia (e.g. cuda), потому что они огромные, и не помещаются в 2GB. TL;DR - чуда не произошло, хотя, иногда, возможно, станет чуть лучше (когда из .text не получается дотянуться до .data в large code model, если я все верно понял).

Мякотка для моего блога в:

Static linking also offers performance benefits in several aspects:

* Link-time optimization is more effective when all dependencies are known. Providing shared object information during executable optimization is possible, but it may not be a worthwhile engineering effort.

* Profiling techniques are more efficient dealing with one single executable.

* The traditional ELF dynamic linking approach incurs overhead to support symbol interposition.

* Dynamic linking involves PLT and GOT, which can introduce additional overhead. Static linking eliminates the overhead.

* Loading libraries in the dynamic loader has a time complexity O(|libs|^2*|libname|). The existing implementations are designed to handle tens of shared objects, rather than a thousand or more.

В копилочку преимуществ статической линковки, конкретно, почему "быстрее".

https://martinheinz.dev/blog/97

Пишут, что скоро можно будет запусить python subinterpreter, в котором будет свой, отдельный, gil.

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