Fedora Silverblue: как «канонично» устанавливать софт для командной строки?

Еще я не знаю, почему доустановленные на хосте шрифты в том же gnome-tweaks, установленном на хосте, не видны, но это мелочь, линакс же для десктопа не готов перманентно.

...И кого бы насмерть запинать за отсутствие вменяемой документации. Вообще, для столь революционных проектов как можно более полная документация is a must.

как по мне это наркомания, чуть что доставил и нужен ребут, а документация реально для телепатов.

Ну, сама идея мне нравится, только требует доводки. И именно оттого и спрашиваю: если мне нужно доустановить набор тулзов, то базовый образ системы — как бы не самое лучшее место для этого. Но и опять-таки, не flatpak.

Надо бы скастовать alpha.

После установки приложения можно так:sudo rpm-ostree ex livefs-и ребут не нужен.

А потом ты до ребута не можешь ничего изменить в /etc, ну то есть можешь, но изменения пропадут.

Если просто добавить к базовому окружению, то rpm-ostree install. Добавить можно все, что требуется, из федоровских реп. Если нужно отделить от системы, то flatpak можно и для консольного софта использовать. Только экспорт комманд там идет по app-id, то есть не vim, org.vim.Vim, или flatpak run org.vim.Vim. Если хочешь более привычный и удобный запуск, алиасы в помощь.

Что касается сред разработки, пожалуй да, имеет смыл делать как общие бандлы их. Но для flatpak есть свой подход. У флатпаковского бандла всегда указывается какой рантайм использовать для исполнения, и в пару к такому рантайму идет рантайм для сборки, который содержит различные компиляторы и инструменты. Как, например, org.freedesktop.Platform и org.freedesktop.Sdk. Так вот, SDK-рантаймы можно и для исполнения использовать, что и делается в бандлах c Atom или VSCode, например. А gnome-builder так же исползует рантайм org.gnome.Sdk.

Теперь, для недостающих копиляторов и прочих компонентов во flatpak предусмотрен механизм расширений(Extensions), но документации нет. Можно ещё к большей хитрости прибегнуть, объявив --persist= директорию, и выкачав нужные инструменты туда, что может быть удобно тем, что можно для готовых бандлов использоваться, без пересборки.

Ну и помимо того, в Silverblue ещё для контенеров предлагается podman, можно смотреть в эту сторону, но он скорее для сервисов подойдет, нежели для десктопного софта.

Я сама эту Silverblue не тыкала ещё, хотя уже наверное пора и к новому релизу придется приглядеться.

Тут кстати обещают на днях (в четверг 20 сентября) тестовый день:

https://fedoramagazine.org/give-fedora-silverblue-a-test-drive/

Можно напрямую пообщаться с разработчиками в IRC.

Если хочешь более привычный и удобный запуск, алиасы в помощь.

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

Ну и помимо того, в Silverblue ещё для контенеров предлагается podman, можно смотреть в эту сторону, но он скорее для сервисов подойдет, нежели для десктопного софта.

Ну так отож. Это зоопарк. Для консольной разработки предлагается buildah. Оба, что это, что podman — сырые. И я еще не разобрал, как разделить с минимальным трением каталог с исходниками между хостом и контейнером, который его компилирует. И как интегрировать с этим IDE.

Похоже, нужен тестовый месяц. :)

Я сама эту Silverblue не тыкала ещё, хотя уже наверное пора и к новому релизу придется приглядеться.

Оно даже работает, я бы сказал — вполне такая себе растет неубиваемая система на бабушкин ноутбук. Загадится малварью — откатываем до factory settings, с сохранением домашнего каталога даже. Обновления системы практически с нулевым риском что-то сломать. А вот power user вроде меня видит там пока что кучу проблем, созданных для того, чтобы их героически обходить, во имя какой-то абстрактной чистоты концепции.

Получается что-то вроде Apple Lisa, где для разработки грузилась совершенно другая ОС с компиляторами и редакторами.

Можно ещё к большей хитрости прибегнуть, объявив --persist= директорию, и выкачав нужные инструменты туда, что может быть удобно тем, что можно для готовых бандлов использоваться, без пересборки.

Meh. Если бы flatpak свои алиасы сам расставлял... То есть устанавливаю, допустим, git, и вижу его в системе именно как команду git, видную из PATH, могу вокруг него собственные скрипты писать и т. п.

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

Еще я пророчу, что оно не взлетит, пока не будет rpm-ostree search.

Так тебе нужна изоляция или не нужна? Если нет, тогда тебе rpm-ostree install даст обычную федорку с откатами. OSTree имеет отношение к контейнерам чуть более чем никакое. Ну и в концептуальном предшественнике, NixOS, это тоже давно есть.

Если нужна изоляция без боли с доступом, то тут все плохо. Она не появится с нуля на пустом месте, нужна практика использования и решения возникающих проблем, это вопрос будущего, а не настоящего.

Пока же для flatpak есть костыли вроде --filesystem=host или classic confinement для snap, с понятными последствиями.

Так тебе нужна изоляция или не нужна?

Ессно, нужна, иначе бы зачем. Но изоляция при помощи деревянных рукавиц не дело, они работать мешают.

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

$ switch-to-environment shit1
$ pwd
/home/shimon/src/project
$ id -u
1001
$ compiler --version

Foo compiler, version 6.5
$ switch-to-environment shit2
$ pwd
/home/shimon/src/project
$ id -u
1001
$ compiler --version

Foo compiler, version 4.3

А не проще просто юзать виртуалки? А для окружений я бы юзал chroot'ы или контейнеры (если сборка в /sys или /proc не лезет, иначе только виртуалки или UML). Вообще, когда так жестко намешано всего, чинить становится не реально, проще переставить. Такие дистрибутивы далеко обхожу стороной.

Мне интересно вот это управление системой со слоями, концептуально.

Вообще, когда так жестко намешано всего, чинить становится не реально, проще переставить.

Именно эту проблему SilverBlue и пытается решить. Другое дело, что оно не отточено.

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

Да как всегда, только вместо dnf юзай rpm-ostree, вот и всё, чё огород городить, думай что это стандартный WS, настраивай и работай, потом разберёшься, а layered packages-ы зачищаются одной командой, никаких хвостов.

Документация вскользь философствует на тему, что можно использовать по контейнеру на каждую среду разработки

Есть же в документации коротко про toolbox, там три-четые простых команды, создавай контейнеров сколько хочешь.

ни как обеспечить прозрачность доступа к домашнему каталогу изнутри контейнеров

Ничего делать не надо, из toolbox-а прекрасно видно домашний каталог, можешь там создавать и удалять файлы и каталоги.

Еще я пророчу, что оно не взлетит, пока не будет rpm-ostree search.

Ищи dnf-ом как привык в toolbox-e.

Смотри чё есть в системе rpm-ом.

Еще я не знаю, почему доустановленные на хосте шрифты в том же gnome-tweaks

Нужна перезагрузка в новый слой, сидишь в старом, смотри rpm-ostree status.

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

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

Рекомендуется понятное дело podman. На чуть более высоком уровне посмотри fedora-toolbox

https://docs.fedoraproject.org/en-US/fedora-silverblue/toolbox/

Но если по-честному мне кажется что best practices по этой теме на самом деле просто ещё нет. Поэтому есть какие-то интересные подходы, а есть какая-то ересь иногда, и все пробуют, смотрят что кому удобно, а потом спорят до посинения.

как обеспечить прозрачность доступа к домашнему каталогу изнутри контейнеров

А эту проблему podman как раз решил. Поскольку он запускается от пользователя, а не от рута, то он не портит права при монтировании файлов в контейнер и всё очень просто делается. Контейнеризованные утилиты из подмана запускать практически также легко как напрямую в cli. При условии что контейнер правильный.

правильная контейнеризация способна решить проблему

Да. И решила.

для общего случая

В общем случае очень часто контейнеризация неправильная.

Вот я тут некоторое время назад расписывала про пользователей у podman в подробностях:

монтирование данных в rootless-контейнер с rootless-пользователем внутри

Нужна перезагрузка в новый слой, сидишь в старом, смотри rpm-ostree status.

Ох, теперь для установки шрифтов надо перезагружаться, дожили :)

На венде такого не было даже в 3.11 для рабочих групп ;)

Зачем этот кадавр, если есть NixOS?

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

Чтобы RPM. Да, не для всех это минус.

Перезагружаться надо потому, что ты установил пакет, а это новый слой, текущий ридонли(ваш КЕП)

Хвала небесам NixOS КЕП прохлопал и там все отлично работает себе без перкзагрузок.

если есть NixOS?

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

И ядро?

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

Нет, конечно, только юзерспейсные файлы и сервисы.

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

«И эти люди запрещают мне ковыряться в носу». В смысле, и эти люди смеются над тем, что у Apple есть фанатики, способные с упоением доказывать, что клавиатура с «бабочками» прекрасна, а что не работает — так это вы ее неправильно чистите.

Это плохой UX. Red Hat тратит кучу усилий для убеждения в том, что софт в официальном репозитории лучше и безопасней разведения слаки в хомяке или /usr/local. И это правильно! Но йорж вашу медь, не надо за это наказывать.

Можно, например, пробрасывать системный каталог со шрифтами и темами во flatpak. Можно сделать флатпаковские рантаймы слоеными, и сделать возможной доустановку флатпаков со шрифтами и темами. Да боже мой, было бы желание и возможность на жопе посидеть ровно и сделать прототипов пару-тройку и выбрать что-то нормальное.

Но при этом не делать объективно хуже, а потом до хрипоты доказывать, что так лучше.

авторы не разделяли твоего взгляда

Да что ты, нет у меня никаких взглядов. :-)
Я сходил на сайт NixOS, полистал, не бро, не впечатлило.

эти люди смеются над тем, что у Apple есть фанатики, способные с упоением доказывать, что клавиатура с «бабочками» прекрасна

Чё за люди? Я щитаю, что у Яббла офигенные клавы и вообще дизайн железа, даже предпринимал честные попытки пересесть на них, но МакОС… не, это не моё, а линукс на макбуке сами знаете, там вся фишка в тачпаде и батарейке, libinput на такое не способен, а батарейка в линуксах… ну ты в курсе.

Red Hat тратит кучу усилий для убеждения в том,

Вот в чём RH & Fedora хороши, так это в том, что не занимаются пропагандой самих себя на пустом месте, что хорошо, то хорошо, чего нет, того нет.

что софт в официальном репозитории лучше и безопасней разведения слаки в хомяке или /usr/local.

Какие проблемы с /usr/local? В Silverblue тоже пожалуйста, даже не заметишь, что в реале /var/usrlocal, а хомяк он и в африке хомяк – bash первым делом ищет проги в $HOME/.local/bin и $HOME/bin.

Можно, например, пробрасывать системный каталог со шрифтами и темами во flatpak.

Фига ты революционэр. Вообще-то WS & Silverblue идут со шрифтами на борту, ничего делать-то не надо, если нет особых предпочтений, а юзать темы в гноме не рекомендуется разработчиками, так что любителям самопальных интерфейсов с гномом не попути, я с ними согласен целиком.

только юзерспейсные файлы и сервисы

В федоре довольно бодро работают над ядром, постоянно прилетают обновы, кроме него и других системных обнов множество, в любом случае лучше перегрузить комп, так что количество перезагрузок в Silverblue не особо превосходит классику. Другое дело если ты осваиваешь silverblue впервые, тут да, сначала количество перезагрузок может доставать, но потом, когда разберешься чего и как, оно сравняется с WS.

Перезагружаться надо

Вот этого взгляда.

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

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