#mix digest

* Число пакетов:

pg-> find . | grep mix.sh | wc -l
1097

Надо понимать, что тут содержатся и всякие пакеты для bootstrap, которые пользователю никак не нужны и не интересны. Полезных пакетов около 700. Напомню, что база Arch Linux - 2700 пакетов.

* Постепенно полирую и доделываю всякое. Например, чтобы было понятно:

- до недавнего времени у меня и на пользователя, и на root, были пустые пароли. Ну просто потому что привсунуть их через useradd - не вариант, у нас же "чистое" управление системой, и это нужно было прокинуть через настройки #realm до конкретных пакетов. Выглядит это у меня вот так:

{
    "flags": {
        "failsafe": "1"
    },
    "name": "set/system/0"
},
{
    "flags": {
        "hash": "uz.......c",
        "pubkey": "ssh-rsa AAAh...j2M= pg@mix",
        "user": "pg"
    },
    "name": "etc/user/0"
},
{
    "flags": {},
    "name": "etc/zram/0"
}

пользователям nix/guix подобная схема может показаться знакомой, а остальные могут пофантазировать, как эти flags могут превращаться в конкретные записи в /etc/passwd, в /etc/authorized_keys, etc

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

- Сегодня у меня был день date time. До этого я жил в UTC, выставленным руками. Сейчас я наладил синхронизацию времени через ntp, save/restore времени при reboot, и собрал пакет с таймзонами для musl. Все это несложно, но довольно муторно, и приходится вспоминать вещи, которые никому не нужны и не интересны.

* Фактически, из нерешенных задач у меня осталось две:

- bluetooth stack. Разобраться, чего там нахуевертили в Linux, выбрать реализацию, отполировать. https://www.bluez.org/

- Звук. #alsa

Пожалуй, самая серьезная моя проблема. Я уже выбрал и собрал 2 звуковых сервера на выбор(https://jackaudio.org/, https://sndio.org/). Мне лично симпатичнее всего #sndiod, маленькая, компактная запчасть из openbsd.

Проблема в том, что звука-то я пока ни разу и не услышал, хотя совершенно точно уверен, что до ядра данные идут. А как в этом месте отладить alsa - у меня пока затык. Дрова видны, они подцепляют устройство, микшер их видит, данные текут в канал. Звука нет, в dmsg пусто :( Если загрузиться в Fedora Live CD, звук есть. Дрова подцепляются все те же самые, микшер видит все те же самые устройства.

fun fact - я в какой-то момент времени офигел, узнав, что у меня 2 аудиокрты, и одна из них интегрирована в AMD GPU. Прежде чем я понял, что это такое представление для системы hdmi audio output, я был "слегка" озадачен.

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

"Не для славы, для забавы, я пишу" (с)

Кстати(сейчас уже трудно точно вспомнить, репу я без сохранения истории раза 2 менял), КМК, #Mix исполняется год на днях, я его начал то ли в прошлые майские, то ли немного раньше.

Надо бы собраться, и уже написать эту печальную историю про мои первые 2 попытки запилить свой дистрибутив. Да, #mix это уже третья попытка.

Нашел на просторах интернета красивое.

https://github.com/jasperla/openbsd-wip/issues/86

О судьбе форка firefox Pale Moon в OpenBSD.

TL;DR - коллеги, с точки зрения оунеров Pale Moon, криво портировали браузер, и поэтому не имеют права на официальную символику Pale Moon.

В комментарии пришел, натурально, БОЕВОЙ ДАЛЕК, и сказал, что все должны obey его rules, и obey его license. Exterminate!

Реально, я совсем не утрирую:

"You must comply with the directive or you must disable official branding for your builds."

Тред фееричный, прочитайте обязательно.

———
https://lists.busybox.net/pipermail/busybox/2010-December/074114.html

Забавный текст про историю /bin, /sbin/, /usr/bin, /usr/sbin, /opt, /usr/local в unix.

В #mix есть только /bin, которая symlink на /mix/realm/system/bin, и /usr -> /. Потому что очень много скриптов полагается на наличие /usr/bin/env, и менять это дорого.

Кстати, в этом месте у меня довольно серьезное отличие от nix и guix, если я все верно понял.

nix, guix стараются прописать конкретные пути к выполняемым бинарям(это верно? поправьте, если я неверно понял), а я объединяю наборы пакетов в realm, и замыкаю их PATH на bin/ в этом realm. Получается, можно собрать разные realm, в которых один и тот же пакет взаимодействует с другим внешним окружением.

Cамое простое, можно набор скриптов запустить с coreutils, а можно с busybox. Или с разными версиями интерпретатора python.

Мне кажется, так более composable.

———
Короткое дополнение ко вчерашней теме, #vendor, #npm

То, как устроены per language repo, не помогает мейнтейнерам решать задачу по фильтрации всякого вредного говна.

Схема с мейнтейнерами работает, когда мейнтейнеров мало, они trusted, и дорожат своей репутацией. Если мейнтейнеров много, то они точно так же untrusted, как и оунеры кода, и увеличение числа причастных к процессу людей только увеличивает вероятность факапа.

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

Нужен какой-то компромисс, чтобы те же crates.io/npm/pypi составляли рекомендуемый набор версий, чтобы его можно было относительно легко аудировать внешними силами.

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

Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".

У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo

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

А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH

Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.

Возможно, я тут упустил какую-то интересную часть истории, расскажите.

———
Я решил устроить фичекат в своей пакетной базе. #mix

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

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

Смотрите.

Довольно часто рядом с библиотекой лежат какие-то данные.

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

В случае .a файлов это совершенно не так. После того, как программа слинкована, мы совершенно точно не хотим видеть рядом с данными и бинарями .a файлы.

Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14

Это будет выглядеть весьма криво в случае сборки .so файлов.

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

Короче, я пока решил это дело пофичекатить.

А может, все же, STALIX? #mix

It is settled. #stalix #ix #mix

#stalix - новое название дистрибутива
#ix - новое название пакетного менеджера

Теперь OS и пакетный менеджер называются по разному, во избежание неоднозначности.

Actually, КМК, stalix объективно самое лучшее название.

Посудите сами:

* STAtically LInked LInuX - какое-то дикое пересечение акронима и того, что сокращаем.

* Звучит очень "чисто", "звонко" и "сочно".

Если бы не коннотация со Сталиным, у меня не было бы никаких сомнений, и я бы даже не стал устраивать опрос.

Меня удивило и ободрило, что так много людей посчитало, что stalix - норм.

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

Получил два вполне подходящих мне мнения:

* Всем похуй.

* А тем, кому не похуй - они сделают хорошую рекламу на reddit. Все, что не некролог, как известно, хорошо.

"IX" - пересечение "stalIX" и "unIX", хочу, чтобы название подчеркивало цель быть пакетным менеджером не только для OS stalix, а вообще, для unix-like OS.

Ну и, конечно же, интересная история, которая со мной случилась в момент перименования.

Я сначала сделал ln -s /mix /ix, потом сделал полный ребилд всего и вся по новым путям.

А потом я сделал "./ix gc", и вот тут-то случилась жопа.

gc - это была одна из команд, которую я не перенес в граф, и она выполнялась бинарем пакетного менеджера, в котором я не переименовал mix в ix.

Поэтому он посчитал, что корней для gc нет, и снес все пакеты в /mix/trash/

А я напомню, что у меня раз в 100 секунд запускается процесс, который очищает корзину, это такая оптимизация, чтобы делать это async.

Кажется, я секунд за 10 успел:

* в открытом MC найти в trash бинарник busybox

* c помощью этого бинарника вернуть все пакеты в /ix/store/

* тут мне очень помогло, что у меня предусмотрительно на пятом tty запущена рутовая консоль без логина, для подобных аварийных случаев. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mingetty/runit/ix.sh#L9

Это был первый раз с нового года(а я под новый годе переехал на mix полностью), когда я был близок к потере установленной системы.

Но все обошлось, пути я поменял!

Будни #bootstrap, stal/#ix

А у меня случилось 10к коммитов в репу со stal/ix, https://github.com/pg83/ix/commit/34311a72ea4c5a62edb6a40ad21a1d72f80cdb7a!

(и это без учета того, как проект жил в моем хомяке, а потом под брендом #mix)

Понятное дело, что 90% этих коммитов - это банальный upver, который давно пора автоматизировать, но, тем не менее, число радует своей "приятной округлостью", если вы понимаете, о чем я.

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

"В пакетных менеджерах GNU Guix, Nix и Lix выявлены уязвимиости (Nix, Guix, Lix), позволяющие выполнить код с правами пользователей, под которыми запускаются сборочные задания (например, nixbld* в Nix/Lix), что может использоваться для записи своих данных в сборочное окружение и внесения изменений в сборочный процесс. Проблемы присутствуют в фоновых процессах guix-daemon и nix-daemon, применяемых для организации доступа непривилегированных пользователей к сборочным операциям"

Я, когда дизайнил это место в #IX (https://t.iss.one/itpgchannel/179, тогда это еще называлось #mix, до ребрендинга, #security), смотрел на то, как это сделано в nix и guix. Мне это место с демоном показалось довольно тонким, и я решил, что имеющейся у меня изоляции не хватит на то, чтобы гарантировать безопасность.

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

Фактически, любой вызов ix build у меня содержит вызов su -s /bin/sh ix -- executor ..., для непосредственного применения построенного графа к системе (в других терминах, конечно, потому что у меня нет классических способов поменять пользователя, #suid).

Натурально, можешь стать пользователем ix - можешь менять систему.

Поэтому такой проблемы у меня нет, и быть не может.