Nix vs Flatpak

во flatpak графические приложения, 100500 версий баз данных к таковым не относятся

Тебе никто не мешает любые СУБД упаковать во флатпак и запустить из флатпака. Как и любые консольные приложения.

Никакого ограничения «только графические» там нет.

Другое дело что это может быть весьма неудобно для пользователя. Но работать будет.

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

Мешает то что это работать не будет. А флатпак работать будет.

Не путай «неудобно» и «невозможно».

а я и не писал, что «невозможно» лишь указал на то что во флэтхабе по-моему вообще ни одной консольной утилиты

во флэтхабе по-моему вообще ни одной консольной утилиты

Ну тогда не путай флатпак и флатхаб

Это все равно что путать гит и гитхаб. Зашквар короче.

в чем зашквар? - это ж основной репозиторий для флэтпука

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

Это не проблема.

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

Если уж говорить о консольных утилитах на флатхабе то там недостатка в них нет.

Выполни

$ flatpak run --command=bash org.kde.Sdk

и ты попадешь в шелл, где доступны все основные юникс-утилиты, компиляторы gcc и clang, python3, системы сборки qmake, cmake, meson, autotools. Это только в одном пакете с флатхаба! К нему еще на флатХАБе есть куча пакетов-расширений со всякими нодами, растами и прочим.

Какие еще утилиты командной строки нужны я не знаю )))

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

Ковырялся… уже разобрался как все сделать. И тут обнаружил, что есть же

Узнаю мир Nix, да. Когда на коммит, сломавший твой workflow, невозможно злиться, потому что это тот же коммит, что ввёл вместо двух файлов твоих костылей опцию «сделать зашибись».

Причем, они еще и bubblewrap используют в этом пакете. То есть получается, в NixOS начали делать изоляцию через bubblewrap, и в перспективе появятся разрешения по типу флатпака у приложений?

Первый раз слышу, звучит круто. Больше кубиков лучшему конструктору.

Там функция buildFHSUserEnvBubblewrap.

Я до конца не разобрался как конкретно оно работает, но видимо это как раз оно.

а в докере можно запустить de и через rdp подключиться…

Да, что гномовский, что кдешный - ужас. Это правило такое, чтоли?

А флатсеал попробую, спасибо. Ковыряться в сосноли и соснолешаться с заклинаниями очень неохота.

Когда сидел в void то там сборка avidemux была с утилитой командной строки, что было удобно.

А вот в Mint уже хитрят и ставят flatpak и cli уже отсутсвует. :(

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

Оба не нужны. Zypper+Docker=🦾.

Ну вроде да.

Символ «+» это символ провала. Значит что ни тот ни другой не могут делать того что от них требуется.

К Docker здесь претензий меньше - у него есть специфические функции выходящие за рамки управления софтом, и там его заменить пока нечем.

А вот что с zypper? Он обеспечивает повторяемые сборки? Атомарное обновление? Что с откатами обновлений? Обеспечивает частичное обновление, только тех приложений которые я хочу обновить гарантированно не затрагивая другие?

Интересно. Прям локальная победа flatpak над snap.

Это символ двух разных задач.

Zypper управляет пакетами, и справляется с этим отлично, а с приведёнными требования я не согласен, ибо задача ПМ — доставлять обновления и обеспечивать консистентность системы в целом, остальное — какие-то бестолковые хотелки с неясным целеполаганием. Docker позволяет невозбранно запускать что угодно и как угодно без влияния на окружение.

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

Zypper управляет пакетами, и справляется с этим отлично

Ну вот к нему я озвучил ряд вопросов, непосредственно касающихся того как он справляется. Хоть на один вопрос положительный ответ есть?

а с приведёнными требования я не согласен

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

какие-то бестолковые хотелки с неясным целеполаганием

Я могу очень ясно пояснить целеполагание по каждому пункту, если надо.

доставлять обновления и обеспечивать консистентность системы в целом

Да. И ПМ без озвученных мной требований не способен ни доставлять обновления, ни обеспечивать консистентность системы. Потому что обновления все сломают, и любой сбой в процессе неатомарного обновления все сломает.

Работает почему-то и не ломается.

Ой, ну толсто. =)

Задача ПМ — подавать мне нужный софт. Если ПМ не может просто взять и подать мне rsyslog с патченным gnutls, то это не ПМ, это аппстор. Если ему ещё и нужен для этого докер, то это уже провал.

Ты вообще не очень понимаешь назначение докера, судя по множеству твоих комментариев о нём. Хотя польщоваться умеешь, что характерно. Nix не то, что не заменяет докер, это вовсе разные плоскости.

Функция докера — стильно модно молодёжно распространять и послойно дополнять чруты.

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

ЧиТД.

Ой, как будто у тебя другое есть =Р

А это была моя презентация перед этим.

А ссылка/слайды есть?

Там был ремэйк https://www.youtube.com/watch?v=ZDhfpqRnpwI, может в чем-то чуть менее корявый и с заходом со стороны шелла а не питона, но вряд ли сильно более интересный. Могу так пересказать: xonsh is both shell and Python, try it.

В долгую Nix лучше. Flatpak даёт лишь песочницу, а на долгой дистанции создаст фрагментацию похлеще 100500 различных дистрибутивов. Крупные дистрибутивы будут создавать свои runtime и на их основе создавать свои flatpak. Эту тенденцию уже сейчас можно проследить.

Крупные дистрибутивы будут создавать свои runtime и на их основе создавать свои flatpak. Эту тенденцию уже сейчас можно проследить.

Скорее всего да, потому что стремление просто перепаковать свою пакетную базу во флатпак и получить свой репозиторий «на халяву» не победить.

И flatpak-builder, который не имеет фактически пакетной системы и предлагает собирать эдакий мини-LFS в песочницу, пусть и автоматизированно, этому сильно способствует тоже. У многих возникнет желание выкинуть flatpak-builder и создавать флатпаки просто перепаковкой из уже готовых классических deb/rpm репов.

Подскажи пожалуйста, все перерыл и не могу совсем понять.

Как сделать чтобы было 2 разных ядра и через grub при загрузке можно было выбирать, на каком грузиться?

Ты в телевизоре. Сходи привет передай.

У nixos-rebuild должен быть свич для создания слегка именованных конфигураций, оно?

Ну можно так, через –profile-name, тогда придется два configuration.nix файла иметь, в каждом со своим ядром? Теперь бы понять как их не дублировать.

Наверное, всю общую часть вынести в третий файл, и его инклудить в обе конфигурации.

А ты хотел один файл, с которого разом две конфигурации одного хоста? Это как-то чересчур для моей фантазии, ИМХО это уже надо будет NixOS патчить, переделывая опцию «выбранное ядро» в список выбранных ядер и чиня что сломается до самого загрузчика.

{ config, pkgs, ... }: {
  specialisation.latest = {
    inheritParentConfig = true;
    configuration = {
      system.nixos.tags = [ "latest" ];
      boot.kernelPackages = pkgs.linuxPackages_latest;
    };
  };
  specialisation.xanmod = {
    inheritParentConfig = true;
    configuration = {
      system.nixos.tags = [ "xanmod" ];
      boot.kernelPackages = pkgs.linuxPackages_xanmod;
    };
  };
}

Пользуйся.