https://felipec.wordpress.com/2023/03/04/one-decade-later-gnome-still-sucks/

Обычный #rant про #GNOME, текст интересен ссылками, которых я раньше не видел.

Here’s another lovely example from a gnome-terminal bug:

No.

CHRISTIAN PERSCH

Ну и так далее.

Для комментариев.

https://gvisor.dev/blog/2023/04/28/systrap-release/

Текст про #gvisor.

Приятно, что проект жив и развивается. Считаю, что за таким вот очень lightweight sandbox большое будущее. Напомню, что контейнеры - не sandbox, а вот KVM и gvisor - sandbox (KVM в большей степени, gvisor - в меньшей).

Хотел прекратить читать текст после того, как увидел график про getpid, потому что это нечестное сравнение (в одном случае используется vdso, в другом, очевидно, нет), и люди, которые этот график нарисовали, не могли про это не знать.

Используемая техника довольно стандартная, "а давайте перезапишем mov ..., eax; syscall на какой-нить подходящий jmp".

Ускорение вполне заметное, хотя, конечно, не такое впечатляющее, как график про getpid.

https://github.com/carbon-language/carbon-lang/discussions/2807

#carbon

Очередной transparency report, а вы чего ждали? Кода?

https://www.phoronix.com/news/Linux-6.4-x86-Mem-Copy

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5624566431de76b17862383d9ae254d9606cba9

Дед опять забыл принять таблетки, и буянит

На мой неискушенный взгляд, Линус зачем-то выделил часть кода из двух файлов в один новый, и назвал это рефакторингом, с объяснением на страницу текста.

Мне кажется? Я в глаза долблюсь?

Вышел новый #musl, https://musl.libc.org/releases.html

Постоянство - признак мастерства, новые версии выходят раз в год, примерно в одно и то же время.

Запилили в dns resolver поход по TCP, вот только я приспособил #dnsmasq, ага.

Убрали макросы stat64, lstat64, и прочее барахло для совместимости с API glibc. Сломали сборку примерно всего кода, ожидающего glibc-style API по поддержке 64-битных оффсетов, печаль-беда.

#dbus #systemd #kdbus

https://www.phoronix.com/news/Ubuntu-23.10-Dbus-Broker-Plan

dbus-broker - это замена dbus-daemon, но:

* linux-only
* https://github.com/bus1/dbus-broker/blob/main/meson.build#L76 довольно безальтернативно зависит от libsystemd, без нее глючит в плане запуска процессов
* зависит от каких-то велосипедных библиотек для С - https://github.com/c-util, https://github.com/bus1/dbus-broker/blob/main/meson.build#L24 Факт того, что уже есть безальтернативная зависимость от #glib, никого не волнует - это не +-1, это +1 велосипедная либа

И все это для чего? Для того, чтобы показать эфемерный выигрыш в производительности. Ага, для десктопной шины, которая должна тумбнейлеры запускать, это, конечно, очень важно.

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

Мораль? Да какая мораль, все равно нас всех скоро заменит AI, пусть кожаные порезвятся напоследок.

С musl, и с их чисткой "ненужного" кода, конечно, попандос.

https://github.com/bminor/binutils-gdb/blob/master/gdbserver/linux-low.cc#L5384

Вот, gdb, например, при configure, считает, что pread64 больше нет, потому что смотрит на линкер, а не на компиляцию. И в данном ifdef попадает на fallback, компиляция которого валится каким-то интересным образом.

Или, вот, например, как валится сборка std crate через #mrustc:

ld.lld: error: undefined symbol: open64
>>> referenced by libstd.rlib.c
>>>               .../libstd.rlib.o:

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

Нормального способа в musl узнать про наличие той или иной фичи нет, и это их принципиальная позиция.

Я пока откатил версию musl к херам.

Ночной (уже) #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, почитайте, не пожалеете. Однин из самых захватывающих твердых НФ романов, что я читал!