Когда сервер в соседней комнате и хочется контролировать процесс перезагрузки не вставая со стула:

> cat /etc/systemd/system/beep.service
[Unlt]
Descriptlon=Beep on boot and shutdown

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/beep -f 440 -n -d 100 -f 660 -n -d 100 -f 880
ExecStop=/usr/bin/beep -f 880 -n -d 100 -f 660 -n -d 100 -f 440

[Install]
WantedBy=multi-user.target default.target

Дальнейшая разработка #tinkerbox становиться ещё интереснее.

Предположим образы (images) podman у нас будут играть роль снимков состояния контейнера. Тогда неизменность контейнеров podman можно обыграть на пользу контейнеров как среды разработки.

Пользователь получает возможность делать снимки состояния контейнера, под капотом делается обычный `podman commit`. Для отката мы удаляем поломанный контейнер и разворачивается точно такой же на базе сделанного ранее, при помощи commit, образа.

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

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

Можно использовать pdoman commit --squash, что бы не плодить образы.

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

Значит буду переписывать #tinkerbox на python в том виде в котором он уже сейчас есть, разве что добавлю шаблоны для контейнеров и добавлю параметров для монтирование директорий.

Ещё можно по эксплуатировать podman mount для получения доступа к файлам, и держать проекты полностью в контйенерах, а не монтировать их из домашней директории.

Так же уже думаю что GUI для управления контейнерами было бы не плохо.

Мои приключения с разработкой софта внутри контейнеров продолжаются.

Systemd-nspawn не пойдёт, так как требует прав рута для каждого чиха. А вот LXC может сработать. А ведь когда-то я писал код именно в LXC контейнерах.

Чем это может быть лучше чем podman/docker? Тем что конфигурацию контейнера можно будет менять после его создания. Можно будет монтировать новые устройства и директории в имеющиеся контейнеры. Distrobox это обходит тем, что в него подмонтировано вообще всё, в случае же с моим #tinkerbox я реализую изоляцию файловой системы, монтируется только то, что пользователь явно указал монтировать.

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

Текущая версия tinkerbox, работающая поверх podman, лежит тут: https://codeberg.org/akhil/tinkerbox/

По моему #podman и #docker не лучшим образом годятся для разворачивания интерактивного окружения и обновления его после, как это делается в distrobox, toolbox и в моём tinkerbox.

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

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

И вот теперь я думаю, не попробовать ли мне переделать свой #tinkerbox для работы с systemd-nspawn?