Будни #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/прочая нечисть.

Релизить что-то ентерпрайзно-системное под Rust - еще та специальная олимпиада. Если мой код обычно собирается с 1.65+ (когда завезли let-else, и то я не большой его любитель), то авторы популярных (в том числе специализированных) крейтов норовят всунуть чуть ли не nightly. А потом ноют, что люди не апгрейдятся.

Всё, Rust большой мальчик. Под PikeOS компилятор старше 1.68 не принимается. Ferrocene тоже сидят на 1.68 (кстати, забыл объявить, его уже сертифицировали под ISO 26262 и IEC 61508). Брать последнюю версию компилятора, чтобы писать код внутри компании - пожалуйста. Брать последнюю версию компилятора, чтобы релизить паблик-крейты - вас и вашу маму будут нехорошо вспоминать.

p.s. к слову, приличные люди всё уже фиксируют где-то на 1.65-1.68

#lab #homelab #minio

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

В целом, я посмотрел на свои задачки:

* обслуживать торренты прямо из сети, с кешом блоков в каком-нибуть распределенном хранилище

* кеш артефактов для #IX (кеш исходников, бинарные пакеты)

* распределенный стор для запускалки произвольных задач (к которым относится и CI для IX)

, и, мне кажется, что наиболее мне бы подошел локальный S3.

А дальше у меня вопрос:

* https://github.com/minio/minio

* https://github.com/seaweedfs/seaweedfs

Первое кажется ровно то, что надо, второе несколько более низкоуровнево, но и S3 там соорудить можно.

Смотрел и код обоих поделий, и читал диздоки, читал, как развертывать. seeweed мне показался несколько более half baked, какие-то не очень связанные слои, и странные админские скрипты для управления этим барахлом, minio кажется более цельным решением.

Есть у кого опыт эксплуатации этих хреновин? Запилите прохладных!

В этих ваших интернетах разгорается целая новая драма!

https://save-nix-together.org/

Офигенный текст, из которого следует, что, если в Nix срочно не появится moderation team, и если проект не перестанет получать деньги от военных, то он обречен. Правда, на что он обречен, и почему, я так и не понял, потому что с логикой у этих господ явно проблемы.

По мне так nix только набирает обороты, и сталкивается с какими-то (небольшими) проблемами роста, не более того.

#nix #nixgate

дополнение к гениальному "вjobывать"

Когда работаешь бариста, но хотел быть дизайнером...

Про развитие одного моего механизма настройки программ в /etc.

В /etc лежит довольно много конкатенативных файлов. Это значит, что любой пакет может захотеть завести себе "кусочек" какой-то общей конфигурации.

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

Традиционные дистрибутивы решают эту проблему, требуя, чтобы сервисы умели в схему /etc/xxx.d/, то есть, чтобы они умели читать не 1 конфиг, а целую директорию, куда уже отдельные пакеты будут класть свою часть конфигурации.

У меня /etc приготавливается атомарно, вместе со всеми остальными запчастями system #realm. Поэтому я решил, что я могу не требовать от сервисов того, чтобы они читали директорию, а просто конкатенировать содержимое некоторых директорий в /etc в момент подготовки окружения.

Ну, то есть, сервис в своем install hook создает файл ${out}/etc/passwd.d/some_user, и потом есть hook, который конкатенирует все файлы из etc/passwd.d/* в 1 файл etc/passwd.

Потом я так начал обрабатывать группы.

Потом окружение, которое должно быть доступно всем на машине, для этого любой пакет может просто завести файл etc/env.d/xxx.

Потом публичные ключи для рутового доступа стали объединяться так в authorized_keys.

А потом Остапа понесло.

Я решил, что, вместо 10 копипастных хуков, я заведу 1, но какой!

https://github.com/pg83/ix/blob/main/pkgs/etc/core/concat.sh

Короче, я сказал, что я буду вообще все директории в etc/, которые оканчиваются на .d, превращать в конкатенацию их содержимого, в файле, который образыется из имени этой директории, но без .d:

cat etc/xyz.d/* -> etc/xyz.

Это совершенно потрясающий и мощный механизм, у меня теперь на нем сделано вообще все. Даже /etc/runit/{1, 2, 3} генерируются таким образом, то есть, любой пакет может подложить кусочек init скрипта, без всяких там systemd и прочей нечисти.

Поэтому мои startup скрипты, конечно, получились довольно интересные.

Потому что:

* если ты все настройки окружения задаешь декларативно

* у тебя есть вот такой механизм конкатенации

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

https://gist.github.com/pg83/ccb23c7fc1dbc986b30d16f25f2b32f8 - вот произвольный init скрипт с одного из моих серверов.

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

Ну, то есть, я могу в систему установить пакет

ix mut system etc/static/ip \
    --ip=10.0.0.64 \
    --gateway=10.0.0.1 \
    --mask=24 \
    --iface=eth0

И это превратится в прямой вызов вида

ip addr add 10.0.0.64/24 dev eth0
ip link set eth0 up
route add default gw 10.0.0.1 eth0
resolvconf -u

(на самом деле, я даже такой пакет не ставлю, а его вызов генерируется скриптом, который строит всю топологию моего кластера)

Потому что зачем использовать vendor specific настроечные скрипты того или иного *Manager, если можно сделать проще?

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

Поэтому у меня, например, нет /etc/fstab, потому что порядок монтирования проще описать без него, из декларативного описания.