https://www.phoronix.com/news/Inkscape-Switches-To-GTK4

Inkscape как-то очень быстро и решительно запилили поддержку gtk4.

Я почему-то, смотря на gimp, думал, что они не переедут примерно никогда, потому что переписать с одной версии gtk на другую - ну, чуть мнее сложно, чем переписать вообще на другой тулкит.

Видимо, здесь дело в разнице между сильно типизированным языком (С++), и слабо типизированным (С).

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

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

#xz_gate

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

Не менее прекрасно и то, как эксплоит был найден:

https://mastodon.social/@AndresFreundTec/112180406142695845

"I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.

Really required a lot of coincidences"

А что же #stal/ix?

А stal/ix эксплоиту не подвержен, по двум причинам:

* IFUNC не работает со статической линковкой. Это ограничение не принципиально, можно и завести, но всем лень.

* Более интересная причина - потому что я проактивно борюсь с такого рода возможностью, когда сумасшедший мейнтейнер может учудить, и не беру tgz, сваренные человеком, а беру tgz, сваренные системой контроля версий (прямые ссылки на архивы бранчей и коммитов) - https://xn--r1a.website/itpgchannel/93.

UPD: https://github.com/tukaani-project/xz - репу закрыли :(

github - контора пидорасов. Дважды пидорасов.

Потому что, по сути, они закрыли источник кода без наложенного вредоноса (https://github.com/tukaani-project/xz). Ну и сломали большое количество CI по всему миру.

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

В Rust std нет семафоров, их выпиляли давным-давно. Решил поискать готовое, но лучше бы сразу сделал велосипед.

Зато нашел вот такие перлы. Рукалицо, дайте мне это развидеть.

Всегда проверяйте чужой код (даже если он из std - тоже проверяйте).

Истории про мою home #lab.

Заебался я на самом деле с этой загрузочной флешкой.

Много чего было, расскажу про две проблемы.

Первая - то, что root fs пытается настроиться до того, как проинициализирован usb controller.

Сука, это леденящий душу пиздец.

GRUB загружает ядро Linux, передает в загрузчик ядра partition uuid, а потом Linux не может найти этот partition uuid, потому что разделы на флешке еще не пронумерованы, потому что система их еще не нашла.

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

Дебажил это реально несколько часов.

Решение?

Слушайте, вот как бы эту проблему решил нормальный разраб? Я бы написал там какой-то retry, с exponential backoff, пытаясь примонтировать rootfs до того момента, когда инициализация драйверов не будет полностью завершена.

Конечно, это было бы слишком просто, и работало бы слишком хорошо, поэтому это явно не Linux-way.

Заботливые кернел-какеры предлагают вот такую опцию - https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re58.html. Ну, типа, сделайте sleep 20, наверняка за это время все usb устройства будут найдены.

Леденящий душу пиздец. Программирование многопоточных программ на sleep, ага.

Истории про мою home #lab.

И вторая проблема - а как написать правильную конфигурацию GRUB, чтобы не надо было заморачиваться с probe всего и вся?

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

В итоге, решил я это так:

* На первой партиции, в которой лежит EFI, я кладу же и сам GRUB, с его конфигом, который устроен вот так:

https://github.com/pg83/lab/blob/master/lab/services/mk/boot.sh#L19-L28

set root=hd0,2
configfile /etc/grub.cfg
set root=hd1,2
configfile /etc/grub.cfg
set root=hd2,2
configfile /etc/grub.cfg
set root=hd3,2
configfile /etc/grub.cfg
set root=hd4,2
configfile /etc/grub.cfg

А дальше, на второй партиции лежит уже настоящий конфиг, который адресован относительно root:

https://gist.github.com/pg83/7941d82e39c6a019ce184e01572ed62d

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

Работает like a charm, загружается на любом моем конфиге.

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

Истории про home #lab.

Пока я переводил хосты на новую схему загрузки (с флешкой в качестве /dev/root), мне несколько раз пришлось пошатать #etcd.

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

Два раза все прошло хорошо, на третий раз я осмелел, и решил устроить ученьки с disaster recovery.

Взял, и под живым инстансом etcd забил его базу из /dev/random, дождался, пока это все не дошло до кластера, ребутнул, переналил на новую схему, поднял пустой инстанс etcd.

В общем, провел пару часов за чтением документации, кластер оживил.

Но это было несколько сложнее, чем я ожидал.

Потому что кворум из двух машин перевел этот третий инстанс в состояние "never again", то есть, пометил его id как сломанный навсегда, и отказывался с ним иметь дело даже после переналивки.

Выяснилось, что надо вручную удалить из кластера этот id, и добавить новый инстанс с новым id.

Зачем так сложно, и зачем эта процедура отличается от предыдущей, не очень понятно.

Зато, КМК, теперь я получил некоторый опыт, и уверенность, что, в случае чего, данные в etcd я не проебу, и мне теперь не сташно класть туда какие-то master/original данные, а не только легко восстановимые копии.

Будни #bootstrap

Я настолько задолбался, что сел, и запилил свой велосипед.

Его формат - максимально простой.

Это пожатый \n-delimited json, примерно такого содержания:

{"type": "file", "data": base64(data), \
 "path": "a/b/c.x", "flags": ["exe"]}
{"type": "dir", "path", "x/y/z"}
{"type": "symln", "path": "a", "to": "c/d"}

Да, да, это текстовый формат (не так, как в дурацком nar, а действительно текстовый):

* не нужно велосипедить парсер

* для отладки (поиска отличий) достаточно diff

* парсеры и сериализаторы json настолько быстрые (https://github.com/simdjson/simdjson), что даже оставляют за собой всякие бинарные форматы, типа protobuf. Ну потому что json мы перекладываем чаще всего, вот он и соптимизирован в хламину

* после сжатия каким-нить нормальным компрессором (я взял zstd -10), вы не увидите разницу между моим форматом, и специализированным бинарным, потому что все ключи часто повторяются, и займут примерно 0 байт, ну а то, что compress(base64(data)) ~~ compress(data) - факт довольно очевидный.

https://github.com/pg83/ix/blob/main/pkgs/bld/pzd/scripts/ser.py - вот, например, компрессор
https://github.com/pg83/ix/blob/main/pkgs/bld/pzd/scripts/des.py - а вот декомпрессор

Да, на python, потому что на golang заняло бы в 2 раза больше строк, а работало бы так же, потому что json в python соптимизирован в хлам, но требовало бы бутстрепа golang, а python у меня есть всегда.

Вот эти вот несчастные 50 строк кода:

* работают на полтора десятичных порядка быстрее, чем мой предыдущий вариант на shell, который на каждый файл зовет chown/chmod (чтобы привести все к одному набору флагов). Нет нужды оптимизировать, потому что стало о-малое от времени на download всего этого дела.

* решили вообще ВСЕ накопившиеся у меня проблемы с этим форматом

Надо было сразу не бояться велосипедить, и сделать все по уму!

Назвал я его, конечно, .pzd, от Packed ZstD

Вышли coreutils 9.5 https://www.opennet.ru/opennews/art.shtml?num=60872

Все бы хорошо, но:

"Сокращено время запуска утилиты sort за счёт прекращения динамического связывания с библиотекой libcrypto в ситуациях, когда не указана опция -R"

Sooqa, эти люди стали загружать openssl через dlopen, потому что, видите ли, их коллеги по цеху не смогли запилить достаточно быстрый динамический загрузчик.

Поэтому мы не будем линковаться с ним в процессе сборки, но обязательно позовем в runtime, со всеми вытекающими (код будет работать по разному у тех, кто поставил себе openssl, а кто - нет)

Я как-то косвенно упомянул #heirloom https://heirloom.sourceforge.net/ , это аналог coreutils/busybox, но только родом из традиционных UNIX, типа Sun, Caldera.

Очень интересный проект, и он у меня участвовал в процедуре #bootstrap - это когда нужно иметь хоть какие-то версии утилит, для того, чтобы собрать более продвинутые версии утилит.

Ну, типа, configure скрипты gnu grep/awk/diff/patch/sed/etc требуют уже работающих awk/grep/sed/diff/etc.

Раньше, когда я только начинал пилить #ix, я использовал heirloom как "начало начал" - имея только libc, нужно получить хоть какие-то unix тулзы, чтобы дальше собирать что-то еще.

Вот у меня был самый отвратительный shell script ever - https://github.com/pg83/mix/blob/main/pkgs/bld/boot/2/heirloom/darwin/ix.sh#L70-L95

Тут literally описан порядок сборки всяких mkdir/cp/rm, чтобы дальше можно было собрать что-то еще, из поставки heirloom.

Я постепенно заменял этот скрипт на:

* sbase - для базовых утилит, из проекта suckless - https://core.suckless.org/sbase/ (там есть слабенький grep, и sed, который падает в корку)

* minised - https://github.com/bostikforever/minised

* bmake - https://www.crufty.net/help/sjg/bmake.html - реализация make, которую можно собрать через cc *.c https://xn--r1a.website/itpgchannel/82

* и, вот, появилась новая реализация awk, для проекта https://github.com/landley/toybox (https://xn--r1a.website/itpgchannel/145), которая зависит только от C - https://github.com/raygard/wak

Я, конечно, добавил ее в процесс бутстрапа, и отправил этот гадкий скрипт на заслуженный отдых, потому что heirloom больше не участвует в моей процедуре bootstrap!

После этого вашего #xz_gate какие-то хаотические движения во всем open source:

Кто-то обсуждает отказ от xz.

Кто-то пилит способ воспроизвести все окружение, нужное для того, чтобы запустить эту дырень - https://github.com/amlweems/xzbot, прямо https://anekdotov.net/anekdot/all/bspkstvskrnnvsh.htm

кто-то предлагает пострипать лишние зависимости у systemd - https://www.opennet.ru/opennews/art.shtml?num=60912 Наверное, люди уже написали весь важный код, и надо писать не очень важный.

Кто-то пишет большие заметки, пытаясь срубить хайпа на великих (Кен Томпсон с его trusting trust) - https://joeyh.name/blog/entry/reflections_on_distrusting_xz/

Кто-то вендорит xz (https://github.com/Genivia/ugrep):

Making all in lzma/C
  CC       libviiz_a-viizip.o
  CC       libviiz_a-7zAlloc.o
  CC       libviiz_a-7zArcIn.o
  CC       libviiz_a-7zBuf.o
  CC       libviiz_a-7zBuf2.o
  CC       libviiz_a-7zCrcOpt.o
  CC       libviiz_a-7zDec.o
  CC       libviiz_a-7zCrc.o
  CC       libviiz_a-7zFile.o
  CC       libviiz_a-7zStream.o
  CC       libviiz_a-Bcj2.o
  CC       libviiz_a-Bra86.o
  CC       libviiz_a-Bra.o
  CC       libviiz_a-BraIA64.o
  CC       libviiz_a-CpuArch.o
  CC       libviiz_a-Delta.o
  CC       libviiz_a-Lzma2Dec.o
  CC       libviiz_a-LzmaDec.o
  CC       libviiz_a-Ppmd7.o
  CC       libviiz_a-Ppmd7Dec.o

Я вот дернул кофе, и написал этот обзор.

Продолжение темы #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к, конечно, звучит немного как чудо.