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

Релизить что-то ентерпрайзно-системное под 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 кажется более цельным решением.

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