Q: Как правильно писать логи?

A: Надо писать в виде \n-delimited json, одна строка - одна запись в логе. В этом json должно быть поле "type", а все остальное - по желанию. Лог надо писать в stdout программы, чтобы можно было декомпозировать запись логов, доставку, и ротацию. Не дело, когда каждая программа содержит в себе код по ротации своих логов.

Я тут подумал, что смог обмануть систему, и подсунул одной там программе, которая очень не хотела писать лог в stdout, "/dev/stdout", в качестве пути файла для логгирования.

Все было хорошо, до тех пор, пока эта программа:

* Не запустилась от рута

* Решила ротировать свой лог

Directed by Robert B. Weide

https://www.phoronix.com/news/Ben-Skeggs-Joins-NVIDIA

Гля чо пишут, NVidia занялась разработкой nouveau!

Вышел 18.1.4, и, вроде как, он норм.

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

Напомню, что ранее у меня падал busybox в некоторых своих апплетах, и падал epiphany, прямо на старте.

Сейчас, уже целых 5 минут, все нормально.

Кстати, таки перевесил.

Теперь dropbear у меня слушает только на оверлейных адресах, но я, на всякий случай, поднял ssh3 на все остальное.

Почему так?

Потому что, как вы знаете, я не верю, что на C можно написать софт без проездов, но верю, что на Go - можно.

Поэтому dropbear висит на адресах, активность на которых может быть только от доверенных источников, как-то так.

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

Линус - мелкий пакостник.

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

Но вот насыпать табов в рандомные места, чтобы они там "просто были" - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?bid=CFD0C5CECEC5D4&id=d5cf50dafc9dd5faa1e61e7021e3496ddf7fd61e

https://www.phoronix.com/news/Autodafe-0.2-Released

И вторая (на сегодня) новость про системы сборки.

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

Зачем это может быть кому-то нужно, я не понимаю.

В общем, что-то починилось, а что-то - нет.

Например, ICE из https://gist.github.com/pg83/e138892353aed9d76b47f85109a1ea05 не починился.

Поэтому вчера я пошел, и завел два багрепорта в clang github, вот сюда https://github.com/llvm/llvm-project/issues.

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

Но, как оказалось, коллеги просто очень быстро разобрали и закрыли мои репорты:

https://github.com/llvm/llvm-project/issues/89158
https://github.com/llvm/llvm-project/issues/89157

Что интересно, оба багрепорта уже были им известны, и один даже пофикшен в trunk.

Что еще более интересно, тот, что пофикшен в trunk, сам по себе в багфикс релиз не выезжает. Фиксы в транке - фиксами в транке, а вот если тебе что-то нужно, то ты сам создавай PR в стабильную ветку, и оно, возможно, доедет.

https://github.com/llvm/llvm-project/issues/89158#issuecomment-2063377604

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

Этот подход, конечно, приводит к странному.

Вот я себе соорудил патч - https://github.com/pg83/ix/commit/4b466b7c6b8261fb9e2f3d023ccf8c1fdf20504d#diff-cedd7b3dceaaa717e4a4056a6360bb64d017de7119ca809bf799462248836876

И какой у меня теперь стимул заводить PR в последнюю стабильную ветку 18.1.X, если я точно знаю, что в транке оно пофикшено, и у меня оно тоже пофикшено? С моей колокольни это просто "лишняя работа", которую можно не делать.

Ну, у "нищих слуг нет", поэтому если кому-то надо, то вот пусть он и мержит.

А проекту LLVM, конечно, желаю хорошего релиз-инженера.

Будни #bootstrap

Сломалась сборка телеги, причем на пустом месте, час назад работала, через час сломалась, bisect не помогает, то есть, в сборку как-то пролезла система. А это всегда головная боль, потому что непонятно, как это дебажить.

TL;DR - перенес /home в другое место (не спрашивайте, понадобилось побольше места, делать хорошо было лень, все там были), и /home стала симлинкой на какую-то другую папку, /home -> /new/home.

В итоге, сломался вызов protoc в сборке телеге.

protoc - программа очень хитрая, она выводит имена модулей из содержимого -I., и путей к файлам, и если оказывается, что proto файл не лежит в одном из -I., то protoc сходит с ума, и отказывается работать.

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

Собственно, protoc стал отказываться генерировать нужные файлы, потому что посчитал, что .proto файл лежит в неверном месте.

Такие дела.

#GNOME #gtk #bootstrap #rant

Вот есть такая библиотека https://gitlab.gnome.org/GNOME/gdk-pixbuf

Библиотека умеет загружать примерно 4 формата картинок (если не считать half baked поддержку #svg), при этом, она не сама их парсит, а зовет соответствующие библиотеки по разбору форматов.

Казалось бы, 1 раз написал, и все - не надо ее ни трогать, ни дописывать, ничего?

У меня в репозитории лежит версия *.6 - https://github.com/pg83/ix/blob/main/pkgs/lib/gdk/pixbuf/t/ix.sh#L4

Потому что:

В версиях с 7 по 10 сломана сборка gtk3 с ней (А это, на минуточку, один из двух главных потребителей этой библиотеки! Кто второй? gtk4, а вы что думали? Это гномье говно больше никому не нужно, по очевидным причинам)

В версии *.11, которая вышла вчера, починили все ошибки сборки, зато с ней коркается примерно каждое второе gtk приложение, которое ее использует. Кажется, там где-то убрали проверку на 0, и зовут какую-то строковую функцию от nullptr, где-то в инициализации.

Мораль?

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

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

Наконец-то годный проект, а не все эти ваши bpf/ebpf/wasm/прочая нечисть.