пользователям source-based дистрибутивов

Зачем это нужно?

Много зачем. Ну допустим тебе надо зафиксить баг в библиотеке и протестировать фикс при работе с конкретным приложением.

Так я и не собираю, нахрен он не нужен

Бгг, а я наоборот собираю :) Каждому своё.

USE-флагами

Скорее -O2 -march=платформа (x86-64, i686 и т.д.).

generic применяется для -mtune

Ну так накатываешь патч (в той же генте) на библиотеку и смотришь, работает ли приложение с данным фиксом.

А чтоб патч ломал другие приложения после фикса, такого не видел. У тебя была подобная ситуация?

У тебя была подобная ситуация?

Легко, патч вообще все может ломать. Я с первого раза рабочий код не гарантирую писать.

Может. Но патчи же тестируют, перед тем как выкладывать в upstream, в той же генте. Я так понимаю, что с такой проблемой ты всё же не сталкивался. ИМХО фича сомнительная, но если она есть в NixOS, то почему бы и нет.

Но патчи же тестируют

Если это мой патч, то кто его тестирует? Вот я и тестирую. Для этого мне не надо сразу всю систему патчить.

Вне NixOS это решается сборкой в контейнере и отладкой в нем. В NixOS удобнее.

Вот deadbeef например - использует кучу патченных либ. При этом никому не уперлось гарантировать что эти патчи не сломают другой софт. Линкует их статически.

В NixOS не надо было бы линковать их статически. Пакет deadbeef патчил бы либы прямо из репов NixOS не ломая всю остальную систему.

Хм, если ты пишешь патч для библиотеки, чтоб с этой библиотекой работало другое приложение, которое, например, крашится без патча, выколадывается на bugzill'y дистрибутива и там уже компетентные товарищи смотрят, всё ли там правильно и добавляют его в upstream. Я не пытаюсь тебя «подцепить», просто обычно так это и происходит.

боретесь вообще) с идиотскими зависимостями для сборки софта?

На FreeBSD при установке софта из портов конфигурирую правильными опциями порты в цепочке зависимостей и стараюсь на этом этапе по-максимуму отрезать всё ненужное. После сборки и установки ПО в систему у меня нет никаких «идиотских зависимостей».

Да, насчёт Deadbeef я знаю, но это опять всё та же самая программа, для которой можно выделить отдельный оверлей и собрать его с патченными тобой версиями библиотек. Они же не перезаписывают стандартные библиотеки?

и там уже компетентные товарищи смотрят, всё ли там правильно и добавляют его в upstream

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

Для deadbeef «компетентные» товарищи так вот до сих пор и «смотрят». Уже больше 10 лет.

Лично мне тоже эти «компетентные товарищи» нафиг не нужны.

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

Можно конечно, по сути это NixOS и делает, только более удобно.

Кстати, раз ты пользовался гентой, какие ещё фичи есть в NixOS, по сравнению с ней?

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

Ну так ты и делай это в своём dev-окружении. Причём тут системный пакетный менеджер? Зачем системному пакетному менеджеру фичи ПМ для программиста?

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

А ещё вот что интересно: как на nixos с flatpak?

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

В NixOS атомарные обновления. Вот в генте ты начал обновляться, 100 пакетов обновилось и все сдохло. Все, система в сломанном непредсказуемом состоянии. В NixOS «обновление» происходит не при физической распаковке пакета на диск. Пакеты сначала ставятся в Nix store. А потом когда все развернуто и готово, симлинками и переменными окружения формируется новая, обновленная среда. То есть в процессе обновления система не может быть сломана никак.

При этом, после обновления, старое состояние системы никуда не девается. В него можно загрузиться выбрав в Grub нужный пункт при загрузке. То есть такую систему вообще невозможно сломать. (можно, но надо сильно уметь).

Зачем системному пакетному менеджеру фичи ПМ для программиста?

Давай поставим вопрос иначе, более правильно. Зачем нужен «ПМ для программиста»? Ответ простой - затем, что системный ПМ нихрена не может, либо системного ПМ вообще нет (винда, мак). При наличии нормального системного ПМ еще другие «ПМ для программиста» под каждый долбаный язык становятся не нужны. Все может делать один ПМ.

если ты используешь nix как пакетный менеджер для разработки, это необязательно делать на nixos.

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

как на nixos с flatpak?

Обычно, так же как и везде. Только вот именно на NixOS нужность флатпака сомнительна, потому что все то же самое делает Nix и лучше. Кроме одного - изоляции приложений и системы разрешений. Если надо изолировать что-то, то можно ставить из флатпака и это будет работать как на любом другом дистре.

-O2

Точно? По умолчанию, если не указывать никаких -O*, применяется -O0

-march=платформа (x86-64

-march=x86-64 ничем не лучше -march=generic

Кроме одного - изоляции приложений и системы разрешений

Так это и есть киллер фича, без этого флатпак и не нужен.

Обычно, так же как и везде.

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

Ну это работает.

Вообще эта фича уже отпилена от флатпака. Порталы и bubblewrap теоретически могут работать без флатпака с тем же Nix или чем угодно. Осталось это на практике осуществить.

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

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

Например там есть какие то странные врапперы для стима, чтобы он работал.

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

Как это невозможно? Никакого отличия от убунты в этом плане тут нет. Даже еще хуже. В убунте например не нужен revdep-rebuild.

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

С нюансами, типа не подтянулись шрифты, темы, иконки.

Но это сломает максимум этот самый пакет, но не всю систему

Ну конечно. Слом пакета glibc сломает только glibc, а вся система на libastral продолжит работать?

Слом пакета тучлейна - ничего страшного, что ты больше ничего пересобрать не можешь, у тебя сломан тулчейн?

В убунте например не нужен revdep-rebuild.

С FEATURES=preserve-libs в gentoo тоже не нужен.

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

Вообще, было бы интересно посмотреть на аналог flatpak с nix вместо ostree. Или guix.

-O2 стандартная опция оптимизации, может и есть дистры, собирающие пакеты с -O0.

В -march нет опции generic, только в -mtune.

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

Он же не только ее решает.

Вообще, было бы интересно посмотреть на аналог flatpak с nix вместо ostree

Я собираюсь заняться. Два направления - «магазин» на базе AppStream поверх Nix, и изоляция/разрешения через порталы и bubblewrap с GUI управлением.

В генте можно наложить сколько угодно патчей на сколько угодно пакетов. создаёшь соответсвующую директорию в /etc/portage для кадждого пакета и компиляешь.

Тяжёлые пакеты типа libreoffice или google-chrome беру прямо из дефолтного дерева генты. Там вообще многие тяжёлые пакеты доступны в бинарном виде. И беру я их бинарниками не из-за «мусора», который лежит на винте и кушать не просит(с моими домашними террабайтами это вообще мелочи), а потому что на моей кофеварке оно просто долго компиляется. Оно, конечно, не мешает никак. Компиляется там себе в фоне и ладно, я проболжаю спокойно пользоваться компом. Но всё-равно надоедает.

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

Хотя я использую и gentoo(на десктопе), и debian(на ноуте и личных серверах).

Ты совсем невнимательно читал. Нельзя сделать то о чем я писал.

В генте можно наложить сколько угодно патчей на сколько угодно пакетов. создаёшь соответсвующую директорию в /etc/portage для кадждого пакета и компиляешь.

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

Ааа.. Точно. Ну да, я такого способа не знаю. Но когда-то очень много лет назад я и простые патчи накладывать не умел. Надо порыть в доках. Там с патчами и сборкой система довольно гибкая. Я до сих ингда натыкаюсь на что-то новое.

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

NixOS так может делать ценой слома всей традиционной структуры файловой системы линукса.

Скорее наоборот, интересно было бы посмотреть на аналог Nix на основе OSTree (то, что есть сейчас, не сопоставимо по функциональности).

Так есть уже. Называется flatpak)))

Только вряд ли он тебе понравится, в сравнении с Nix.

Только вряд ли он тебе понравится, в сравнении с Nix.

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

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

Nix напротив, в первую очередь занимается сборкой, и только как следствие дает подобие контейнеров.

Поэтому я не знаю что можно назвать прямо аналогом Nix на OSTree.

То есть это был бы условный source-based flatpak, который позволяет флатпаки не просто ставить готовыми, а собирать из неких более мелких пакетов. Но это выходит далеко за пределы функций OSTree.

Можно флатпак пакет собирать при помощи Nix. То есть тупо упаковывать /nix/store во флатпак и распространять через OSTree. Только никакого преимущества перед голым Nix я тут не вижу.

А вот это что то сомнительное. Но вообще, есть rpm-ostree.

Не, флатпак мимо.

OStree — это, насколько я понимаю, способ создавать параллельные FHS-совместимые (в отличие от Nix) образы, в том числе образ базовой системы. В той же FCOS базовый образ — это просто монолитный базовый образ. Но ведь никто его не запрещает собирать с помощью Nix. Да, чтобы поменять что-то в базовом образе, нужно перезагружаться. Но, по-моему, это скорее плюс. А для того, что хочется изменять, не перезагружая систем — создавать свои образы. В Silverble/FCOS для этого применяют Flatpak (для «десктопных» приложений) и Docker (там, где не хватает Flatpak). Но ведь по сравнению с Nix это просто костыли. Нужно только прикрутить Bubblewarp и прочую обвязку, как у Flatpak, и интеграцию с OSI (в дополнение к уже существующей системе управления контейнерами на основе systemd-nspawn).

Примерно так я представляю идеальную систему управления пакетами (и системой в целом). И если у @t184256 получится достаточное количество коллег заразить идеями Nix, то, возможно, такое мы увидим от Red Hat.

Я мог бы продолжить простыню. Например, мог бы написать про то, как и почему стоит объеденить функциональность Flatpak и Appimage в рамках вышеописанной вундервафли, но мне немного лень. Но если вдруг кому-то интересно…

пользователям source-based дистрибутивов (комментарий)

Но если вдруг кому-то интересно…

Мне интересно, напиши пожалуйста. Я собираю пока мнения по этому вопросу.

И если не сложно, можешь подробнее раскрыть то что ты выше писал по «идеальному управлению пакетами»? У меня есть возражения, но я очень подозреваю что не так тебя понял.

Надеюсь, ты осилишь эту огромную стену текста.

И если не сложно, можешь подробнее раскрыть то что ты выше писал по «идеальному управлению пакетами»?

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

Изменения в системе делаются изолентно-сопельным способом. С распространением софта тоже беда. Даже если, например, твой дистрибутив официально поддерживается, то это не значит, что для установки не будут требоваться костыли, способные превратить систему в тыкву и/или несовместимые с другими костылями, которых требует какой-то ещё софт.

Сам подход к обновлениям в дистрибутивах типа Debian и Ubuntu LTS — это тоже попытка игнорировать проблемы и уклоняться от их решения до тех пор, пока игнорировать не станет просто невозможно. А к тому моменту зачастую проще переустановить систему и портировать на новую версию все не потерявшие актуальность манипуляции с изолентой и соплями.

Есть прикручиваемые сбоку костыли типа Ansible и Docker, каждый из которых пытается решить часть проблем. Но основательно и на системном уровне им это сделать не удаётся — именно потому, что прикручены сбоку.

Есть FCOS/MicroOS/Silverblue, где попытались решить «системно», но до конца не осилили. Улучшили воспроизводимость ценой кастомизируемости, что позволило в том числе сделать автоматические обновления намного менее болезненными. Но в итоге для многих задач такую систему адаптировать не получится. К тому же никак не озаботились управлением конфигурацией и декларативностью. Даже конифиги, не созданные явно пользователем, из /etc не убрали, как это сделано в Clear Linux. Да и для реализации того, что не поулчается сделать в базовой системе, предлагают использовать Docker.

Есть NixOS. Уже писал про неё некоторые мысли. Для программистов, админов, DevOps и прочих рептилоидов она системно и последовательно решает чуть ли не все проблемы чуть ли не самым лучшим способом. Потому что профессионал, особенно если ему платят за работу, способен изучить используемый инструмент и опакетить/настроить всё так, как этого требует NixOS. Но это не отменяет проблемы несовместимости с FHS и бескомпромиссности, требующей абсолютно всё делать средствами Nix. Проблема усогубляется тем, что дистрибутив малопопулярный и заставить всех остальных делать «как надо» не получится, из-за чего дополнительная работа ложится на плечи мейнтейнеров и самих пользователей (что, в свою очередь делает дистрибутив менее привлекательным для широкой публики).

Теперь можно перейти к тому, как я (приблизительно и на данный момент) представляю себе идеальную «систему управления системой». На основе декларативных файлов конфигурации собирается FHS-совместимый образ базовой системы для OStree, в который производится загрузка. Конфигурацию можно изменять, и после пересборки образа и перезагрузки изменения будут применены. Можно создавать дочерние образы с нужными пакетами и настройками на основе системного, чтобы не перезагружаться каждый раз. При входе в образ эффект такой же, как при использовании Docker/Flatpak — попадаешь внуть FHS-совместимой системы. К управлению этими образами прикручены механизмы изоляции и прочая обвязка, чтобы их можно было использовать в качестве замены Flatpak и в качестве OCI-контейнеров (вроде бы в Fedora как раз был движ по поводу интеграции контейнеров). Для отдельных пакетов или для образа целиком должна быть возможность отключить «автопилот» и написать конфигурацию в ручную, а также возможность включить rw-режим. Т. е., например, чтобы можно было под системным образом создать rw-образ, в котором можно изменять все системные файлы, чтобы можно было использовать «дедовские» костыли, когда без них совсем никак. (Тут, правда, скорее всего, не обойтись без оживления aufs.) В любом режиме в /etc образа должно храниться только то, что было либо сгенерированно системой управления конфигурацией, либо создано самим пользователем, включившим режим «я здесь власть». А для контроля самих файлов должен применяться как минимум Git.

Всё (или как минимум подавляющее большинство) из того, для чего сейчас создают отдельные дистрибутивы, должно быть реализуемо в рамках нашей вундервафли, как и возможность иметь несколько «дистрибутивов» (или тех же «рантаймов») внутри одной системы. Если все дистрибутивы, которые могут быть интересны нормальному человеку, перейдут на эту модель, то навсегда решатся проблемы с распространением софта. Даже от make install в инструкциях на «гитхабе» (и от необходимости всяких там AUR) можно будет избавиться, потому что везде будет работать одна система сборки. ПМ специального назначения типа язычковых тоже можно будет заменить репозиториями и/или обётками к нашей вундервафле.

Пропихнуть такое в массы способна только шапка. С одной стороны, это может быть затратно и болезненно. С другой стороны, во-первых, это решает проблемы, которые они и так пытаются решить костылями, во-вторых, воспроизводить баги в воспроизводимых сиситемах гораздо проще (внезапно!), а следовательно и исправлять. А бизнес у них строится именно на поддержке.

Наконец, про Flatpak, Appimage, «десктоп» и распространение сторонними разработчиками приложений для него. Flatpak создатели гордо называют «будущим распространения пакетов для GNU/Linux», при этом проблемы, которые он неспособен решить либо сам же и создаёт, попросту игнорируются. Во-первых, даже для установки одного небольшого приложения уже надо тащить сотни мегабайт (а то и гигабайты) зависимостей, дублирующих то, что уже есть в системе. А разным приложениям могут быть нужны разные версии «рантаймов» — «хромбук» с накопителем на 32 ГБ такое уже не потянет. Во-вторых, там огромные проблемы с интеграцией как с системой, так и с остальными приложениями: попробуй, например, завести прокси или KeepassXC в браузере, установленном через Flatpak (или gtk3-nocsd). В-третьих, скачать/установить Flatpak-пакет можно только через пакетный менеджер и только из репозитория. Разработчик не может просто так выложить у себя установщик, нужно обязательно заливать либо на Flatuhub, либо куда-то ещё. Нет человеческого способа скчать пакет для последующей оффлайн-установки или же раздать пакет относительно небольшому количеству людей, не забивая голову всякими там репозиториями.

Appimage, в свою очередь, в основном позиционируется как более простая и легковесная альтернатива Flatpak. При этом его разработчики/сторонники тоже упорно игнорируют тот факт, что пригоден он только для портативных приложений, а не в качестве замены Flatpak или традиционным ПМ. Т. е., например, вполне годится, чтобы поставить что-то «на посмотреть» (в т. ч. для бета-версий), но на постоянной основе этим пользоваться проблематично. Во-первых, нужны костыли для создания .desktop-файлов и прочей интеграции с системой, а также для обновлений. Во-вторых, забит болт на изоляцию и порталы. Для изоляции предлагают использовать Firejail (который требует отдельной кропотливой настройки для каждого приложения и чуть менее, чем полностью непригоден для использования на «десктопе»), т. е. игнорируют объективную реальность и отрицают проблемы, вместо того чтобы хотя бы попытаться их решить. В-третьих, каждущаяся легковесность достигается за счёт сжатия. Но ведь для того, чтобы использовать приложение, нужно его распаковать. И распаковывают в /tmp. Опять же, для использования большого количества приложений на постоянной основе такое не годится. В-четвёртых, там каждое приложение тянет за собой все зависимости. При установке большого количества приложений это неэффективно (и в любом случае небезопасно).

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

Продолжение комментария выше

Теперь, собственно, про то, как, по моему мнению, должно быть. Так как все задачи по управлению пакетами уже успешно решаются вундервафлей, в рамках Flatpak (который можно переименовать обратно в xdg-app) должны развиваться только механизмы изоляции и интеграции с системой. Должны быть решены проблемы совместимости с нетривиальными «юзкейсами». А то ведь в XDG/GNU/Linux даже нет такого понятия, как «приложение». Из этого вытекает отсутствие централизованного управления разрешениями и прочие проблемы с интеграцией. Например, какой-нибудь VPN, где нужно настроить исключения для отдельных приложений. В Windows и Android можно, а в XDG/GNU/Linux возможен только выбор бинарника. (desktop-файлы — лажа и очередной пример игнорирования проблемы. Попробуйте выбрать /usr/bin/chromium и удивитесь, что ничего не работает.)

А для распространения установщиков сторонними разработчиками должен использоваться формат .bundle. В нём запакованы все зависимости приложения, отсутствующие в базовой поставке XDG-платформы, а также адрес репозитория для обновлений (опционально). Bundle-файл можно запустить как портативное приложения. В таком случае он будет работать как Appimage, но со всеми интеграциями и изоляцией, как у Flatpak. А для постоянного использования можно выбрать режим установки. В таком случае по возможности зависимости будут установлены не из установщика, а сразу из репозиториев — последней совместимой с приложением версии и без дублирования. «Рантайм» должен иметь одну поддерживаемую версию (вместо зоопарка из нескольких).

Основные дистрибутивы будут сразу использовать пакеты, совместимые с «рантаймом», чтобы зависимости не дублировались; но для «не таких как все» остаётся возможность держать несколько параллельных «рантаймов» (вундервафля эту проблему решает на ура).

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

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

Должен быть API для (полу)автоматического обновления с разрешения пользователя. Т. е. как, например, в Firefox на Windows — чтобы не приходилось дёргать ПМ.

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