Продолжение темы #jpeg_xl (а я эту новость вижу именно в таком контексте)

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

Гугл выкатили библиотеку, которая может пожать в обычный jpeg так, что качество будет сравнимо с Jpeg XL.

Это, конечно, неожиданный поворот во всей этой истории, дааа.

https://discourse.llvm.org/t/rfc-improve-binary-security/78121

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

Пользуясь случаем, хочу сделать рекламу нашему (корпоративному) toolchain registry - https://github.com/yandex/toolchain-registry/releases/tag/clang16-v3

Там лежат тулчейны, которые:

* воспроизводимо собираются

* мы их используем для сборки наших open source проектов (да и внутри тоже)

Хозяйке на заметку.

Все, что я пишу ниже, всем известно, и никому не интересно. Но, каждый раз, когда я с этим сталкиваюсь, оно случается, как в первый раз, и я потом долго матерюсь.

Вопрос на засыпку - как ведет stdin/stdout в вашей программе grep (просто для примера, можете взять awk, или sed), с точки зрения буферизации?

Далее ответ на этот вопрос. Вернее, не ответ per se, а набор фактов, которые помогут вам на него ответить:

* Стандарт C, и стандарт POSIX оставляют это unspecified. Ну, то есть, in the wild, вы можете встретить любое поведение.

* glibc соблюдает старую юниксовую традицию - если stdout соединен с tty (ну, считайте, программа запущена в interactive shell), то stdout будет line buffered (то есть, как только в буфер пришел \n, его содержимое сбрасывается в файловый дескриптор). Если не соединен, то stdout buffered, а stderr всегда unbuffered (и это правильно, потому что вы хотите видеть последнее сообщение, которое написала программа перед тем, как умереть по SEGFAULT).

* musl - вроде, тоже, но я не смог там быстро найти проверку, которая бы включала line buffered явно.

* дело усложняется тем, что произвольная программа может положиться на поведение этих потоков по умолчанию, а может как позвать setvbuf(чтобы поменять дефолт), так и звать fflush() в нужных местах. При этом, программа может настаивать на повторении вот этой вот традиции UNIX, то есть, для libc, которая не поддерживает такое соглашение, звать fflush() самостоятельно, или не звать, если считает, что libc устроена согласно разумению этой программы.

* все это усугубляется configure скриптами, которые могут неправильно понять default для нижележащей libc.

Короче, вы поняли - in the wild можно встретить почти любую комбинацию этих поведений, и заранее понять это довольно сложно.

Почему я про это решил рассказать?

Очевидно, потому что столкнулся со странным поведением одного скрипта, который по разному себя вел в процессе отладки, и во время работы в production.

Потратил на #debug пару часов, в результате заменил вызов на gnugrep --line-buffered, чтобы уж точно не зависеть от того, какая программа стоит на хосте, и какие в ней дефолты.

Мораль? Да нет ее, как обычно.

Не на правах рекламы.

Я, где-то с 2021 года, использовал ноуты от Xiaomi:

https://xn--r1a.website/itpgchannel/111
https://xn--r1a.website/itpgchannel/428

Первый ноут был прекрасен, второй - просто неплох (потому что его явно не тестировали с Linux, там были проблемы с ACPI, с питанием, и он почти не держал батарею).

Короче, вот мой новый ноут - https://www.ozon.ru/product/lenovo-xiaoxin-pro-14-2024-32-gb-1-tb-amd-r7-8845h-tonkie-i-legkie-bloknoty-besplatnyy-podarok-1452961844/

Основные отличия от предыдущего моего Xiaomi:

* 90hz -> 120hz. Это прямо хорошо заметно, и очень приятно.

* экран чуть ярче, для OLED это важно, потому что OLED экраны не очень яркие сами по себе.

* 16gb -> 32gb mem. В целом, приятно, хотя мне хватало и 16 почти всегда.

* 512gb -> 1Tb HD. Тоже, приятно, но я не помню, чтобы хоть раз упирался в 500 гиг.

* Проц поновее, побыстрее, и существенно, прямо очень существенно меньше греется. Xiaomi во время сборки чего-то тяжелого я не мог держать на коленях.

* Держит батарею, нет проблем с ACPI (уходит в сон и возвращается без проблем)

* Чуть толще.

* Во всем остальном они прямо близнецы - братья (AMD ryzen, AMD встройка, OLED экран, металлический корпус, клавиатура "как у Мак")

С одной стороны, вроде как, инкрементальные изменения, с другой - видно, что люди проверяли совместимость с Linux, все работает "из коробки", и заметно быстрее, чем раньше.

Цена 50к (я брал за 70, но вот нашел объявление за 50 - https://www.ozon.ru/product/lenovo-xiaoxin-pro-14-2024-32-gb-1-tb-amd-r7-8845h-tonkie-i-legkie-bloknoty-besplatnyy-podarok-1517165298/). Мне кажется, это какой-то демпинг от Ozon, потому что на Ali ноут стоит 100к.

50к, конечно, звучит немного как чудо.

Будни #bootstrap

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

Вот, на этот раз отличился проект x265, перевыложил файл https://bitbucket.org/multicoreware/x265_git/downloads/x265_3.6.tar.gz

Зачем?

На этот раз я совершенно точно знаю, зачем.

Коллега, который готовыл релиз, объебался, и вместо структуры директорий:

src/a
src/b/d
src/e

сделал

a
b/d
e

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

А на следующий день пришлось патчить назад, когда коллега осознал ошибку, и перевыложил "исправленный" файл.

Никогда, никогда не перевыкладывайте новые данные под старым именем.

Как было нужно?

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

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

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

Релиз dropbear.

Из интересного для меня - "Добавлена возможность пробрасывать UNIX-сокеты через туннель, созданный на базе Dropbear SSH"

Одна из вещей, которая не работала в моей модели безопасности (эскалация в root через условный sshd) - это fuse. Потому что он запускает suid helper, и ожидает от него получить файловый дескриптор от fuse, который можно получить только от root.

Ну и вот ранее это не работало, потому что, после запуска этого хелпера через ssh, он пытался вернуть в вызывающую программу файловый дескриптор, и у него это, понятное дело, не получалось.

Сейчас можно попробовать вернуться к этой задаче.

#bcachefs

#Kent выложил код, который умеет читать поврежденные им ранее файловые системы - https://www.opennet.ru/opennews/art.shtml?num=60946

"New repair/construction code is in the final stages, should be ready in
about a week. Anyone that lost btree interior nodes (or a variety of
other damage) as a result of the splitbrain bug will be able to repair
then"

Знаете, вот, на самом деле, когда разработчик FS начинает употреблять что-то типа "split brain bug", то я, например, очень радуюсь, и говорю, что, вот, кто-то, наконец-то, понял, как правильно пилить файловую систему.

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

До этого, КМК, FS писали в парадигме того, что нижележещие устройства или надежны, или мы перемонтируем всю FS в read only, если "снизу" вернули ошибку.

https://lore.kernel.org/lkml/20240405102754.435410987@infradead.org/

Я просто оставлю это здесь:

"... Critically cfs-cgroup throttling is not tested, and cgroups are only tested in so far that a systemd infected machine now boots (took a bit) ..."

#vendor

https://github.com/desktop-app/cmake_helpers/commit/5a19eddd4554486547d6d5dac3002a93bc105867

Тем временем, коллеги откатили scudo, и вернули jemalloc.

Верю, что пройдет еще пара итераций, и там таки окажется #tcmalloc, хехе.

Как я это заметил? Ну, у меня сломалась "кузькина мать", когда не смогла развендорить scudo в новой версии телеги.

UPD: у меня github показывает розовых поней, наверное, это как-то связано

Будни #bootstrap, #homelab, #lab короткая эволюция того, как я катаю код на свой флот.

Мой макетник (#ix) позволяет описать любую статическую комбинацию пакетов, с произвольными флагами для их настройки.

В принципе, этого достаточно, чтобы удобно описать конфигурацию одной машины. Собственно, так у меня и был описан мета-пакет, который и был установлен в мой #realm - https://github.com/pg83/ix/blob/main/pkgs/set/pg/ix.sh

В принципе, этого точно так же достаточно, чтобы описать конфигурацию небольшого кластера - вот, например, у меня по папочке с такими наборами на каждый хост - https://github.com/pg83/lab/tree/master/lab/hosts

Но это, конечно, неудобно.

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

https://github.com/pg83/lab/blob/master/lab/common/ix.sh#L23-L27

Вот, если наш текущий хост входит в определенную группу хостов, на нем поднимаем набор сервисов с определенными настройками.

Дальше - больше.

Дальше мы не хотим иметь этот json статическим, а хотим его генерировать на python. Вот, пример того, как такой json с описанием кластера может генерироваться на python:

https://github.com/pg83/lab/blob/5f6ebd3c236ba42793cfbf0a5ecbb148688dfda7/lab/ix.sh

А дальше Остапа понесло, он не смог остановиться, и применил свой любимый прием - eval(pickle.loads(base64.b64decode('...'))) (я сейчас явно слышу гомерический смех пяти человек). А, конкретно, давайте опишем состояние сервисов python объектами, сериазизуем их состояние, и будем использовать как описание кластера:

https://github.com/pg83/lab/blob/master/lab/cg.py#L9-L39

2 класса - сервиса, и производящая функция всего кластера, которая полностью описывает его структуру, имея на вход низкоуровневое описание кластера (сети, диски, и так далее).

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

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

What a day to be alive, python jit уже на полпути к релизу: https://www.opennet.ru/opennews/art.shtml?num=60966

Будни #bootstrap

Как же я задолбался с 18-ым кленгом.

Попробовал выкатить 18.1.3, так там все точно так же плохо, или хуже:

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

* https://gist.github.com/pg83/e138892353aed9d76b47f85109a1ea05 - вот пример конкретного падения этого кленга (gist я сделал для чуть более ранней версии, там ничего не поменялось). Воспроизводится 100%. Я даже, от безнадеги, собрал чистейший кленг, без своих патчей, с двойной пересборкой себя целиком из исходников. Все равно падает, сволочь.

Писать качественные багрепорты в LLVM времени нет катастрофически, а некачественные нафиг не нужны.

Грусть, тоска, печаль, тлен.

Маршрутизация

Programmer memes

Будни #bootstrap

Продолжаю тему bump alloc, https://github.com/pg83/ix/blob/main/pkgs/lib/bumpalloc/alloc.c

Забавно, но в моей кодовой базе (уникальный код, который я пишу для #stal/ix), использование этого bump alloc только растет:

* Про много мелких программ заранее известно, сколько они съедят памяти.

* Я ненавижу С, потому что без RAII/GC программировать невозможно (с этим согласны даже разработчики одной из самых больших кодовых баз на C - Linux Kernel (если вы не согласны, то что такое RCU, как не форма примитивного GC?)). Но вот если не освобождать за собой память, то программирование программ на C - это почти как программирование программ на Go. Важно, что именно программ, потому что вся обработка ошибок сводится к panic()

* В целом, если мне надо запилить что-то low level, то я либо пишу это на таком вот диалекте C (без free, и с минимальной обработкой ошибок, без return err), либо не пишу вовсе.

Вот, запилил очередную мелкую программулю, вместо которой у меня был скрипт на posix shell - https://github.com/pg83/ix/blob/main/pkgs/bin/cg/unwrap/main.c

Она занимается тем, что запускает другую программу в cgroup, а потом, после ее выхода, прибивает всю cgroup, чтобы не оставалось ошметков в виде stale процессов.

Красота-то какая, лепота!

10 килобайт на диске, ни одной аллокации, если запустить strace, то можно про каждый syscsall сказать, что он делает, и зачем, и почему без него не обойтись.

Как в старые добрые времена DOS, и дискеток на 1.44 мегабайт.

Коллеги, нужно удерживать энергию в рабочем русле еще по крайней мере один день!

Programmer memes

#lab #homelab

https://github.com/francoismichel/ssh3 - прикольная штука, типа, "а давайте запилим ssh поверх стандартных web технологий", типа x509 сертификатов, http/3, quic, и так далее.

На Go, что приятно. В то, что openssh/dropbear написаны "аккуратно", я не верю, потому что на С нельзя писать сложные системы без проездов по памяти.

С точки зрения клиента оно пока довольно harsh, поэтому запилил несколько разных там улучшений:

https://github.com/francoismichel/ssh3/pull/139/files

Посмотрим, что скажут мейнтейнеры.

(особую гордость у меня вызывает способ, которым я зачинил то, что после добавления хоста в known_hosts клиента нужно было перезапустить - https://github.com/francoismichel/ssh3/pull/139/files#diff-8939e1ce1317af19fdceab3a5d7aabbac4949389802b082e926ed37b442fb4f7R203)