Разработчики Debian сочли qBittorrent некошерным и выкинули его из testing-а.

У меня то тоже, но вот сначала ситуация с Audacious, теперь - с qBittorrent. Дискомфортненько.

А каким образом AppImage запомоивает систему?
Ошмётки свои по всей FHS раскидывает?

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

И зачем мне выша ссылка на Sid (Unstable)? Это ни разу не Testing.

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

Ниже вроде бы отвечал. Перефразирую: мне нравится концепция FHS и у меня нет ни малейшего желания управлять пакетами руками в /home. Если приложений 1-2 - не проблема, но если их, скажем, 20, то обновлять их руками, обновлять desktop-файлы в меню руками, (вероятно) обновлять конфиги руками - это уже проблема. Это задача ПМ, вот пусть ПМ этим и занимается.

А ведь точно. Они рекомендуют не смешивать stable/testing, про testing/sid другая история. Благодарю.

мне нравится концепция FHS

Только концепция эта устарела уже лет на 20 как и не отвечает современным реалиям для десктопа.
Для сервера +/- ок.

Это задача ПМ, вот пусть ПМ этим и занимается.

Ознакомься с тем как работают scoop, homebrew, chocolatey (им не требуются никакие FHS кувыркания, софт прекрасно ставится и обновляется командами в терминале).

Только концепция эта устарела уже лет на 20 как и не отвечает современным реалиям для десктопа. Для сервера +/- ок.

Вероятно. Но альтернативы, я считаю, ещё хуже.

Ознакомься с тем как работают scoop, homebrew, chocolatey (им не требуются никакие FHS кувыркания, софт прекрасно ставится и обновляется командами в терминале).

Ничто из этого не линуксовое. В случае macOS и Windows, над этими штуками висит монолит с устоявшимся API и обратной совместимостью. На линуксах такого нет. Что там сверху, Systemd или OpenRC? Xorg или Wayland? Голая ALSA, PulseAudio, или JACK? KDE или GNOME? А конфиг ядра совместимый? А конфиги вышеперечисленных? И т.д. Весь стек за собой таскать не выйдет. Собрать пакет, который бы работал везде, - наверно тоже. Скажем, есть у нас Flatpak. На бумаге он вроде бы ничего так, но в Gentoo его нет в репозиториях, а из оверлея - не собирается; в Debian - поставить удавалось, но некоторые приложения не запускались. Т.е. вместо задуманного «одного ПМ-а что б править всеми» получилась монстрятина Франкенштейна - Fedora Silverbule (Или как её там) с двумя ПМ-ами.

В общем, мы имеем это. Вместо того что бы делать Deb для Ubuntu/Debian, RPM для RHEL/CentOS/Fedora/OpenSUSE и *.tar.gz с бинариками/исходниками для всех остальных, теперь разработчикам приходится делать Snap для Ubuntu, Deb для Debian, RPM для RHEL/CentOS/OpenSUSE и Flatpak для Fedora. Хз чем и кому эти новые «стандарты» помогли.

На линуксе также нет и ОДНОГО РЕПОЗИТОРИЯ.
В том же дебиане каждый первый пакет уродуют своими патчами, так что девелопер родной не узнает.

Как будто это вина винды/мака в том, что в десктоп-линуксе бардак.
При этом рядом есть замечательный пример успешной реализации концепции единого источника приложений — клиент steam.

На линуксе также нет и ОДНОГО РЕПОЗИТОРИЯ. В том же дебиане каждый первый пакет уродуют своими патчами, так что девелопер родной не узнает.

Не совсем понял.

Как будто это вина винды/мака в том, что в десктоп-линуксе бардак. При этом рядом есть замечательный пример успешной реализации концепции единого источника приложений — клиент steam.

А с каких пор он единый? GOG, Origin, EGS, Uplay и т.д. - вот этим все взаимонезаменяемые системы распространения контента, они куда делись?

А с каких пор он единый?

Смысл в том, что он ставится на любом линуксе, так что сама концепция рабочая.
И сама по себе возможность поставить рядом GOG со своим набором софта, это лучше чем отдельный репозиторий который при случае уничтожит систему.

А есть линукс, на котором он не только ставится, но ещё и работает нормально? Так то он у меня на Gentoo стоит (С рантаймом убунты), но при этом, например, диалог перемещения игорей виснет, ссылку на скриншот невозможно открыть в браузере, диалог сохранения файлов работает через раз и так далее. Про отсутствие звука в играх в Debian слышал, где там нужно удалять несколько библиотек из рантайма? Вот это вот всё - ничем не лучше репозитория. Да и что это за «отдельный репозиторий, который при случае уничтожит систему»?

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

Это очень плохие новости для Gentoo. Лично я не совсем понимаю зачем вы вообще используете до сих пор этот давно исчерпавший себя дистрибутив. Но ладно, это лично мое мнение, не навязываю его.

Т.е. вместо задуманного «одного ПМ-а что б править всеми»

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

Хз чем и кому эти новые «стандарты» помогли.

Один и тот же Snap теперь во всех актуальных версиях убунты работает. Это может очень сильно помочь.

То же - с флатпаком для федоры. К тому же флатпак везде работает.

deb для Debian - ну что ж, идейный мазохизм тоже убеждения, будем их уважать.

RPM для RHEL/CentOS/OpenSUSE

Это временно, до прихода туда флатпака во все поля.

Да и что это за «отдельный репозиторий, который при случае уничтожит систему»?

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

Про отсутствие звука в играх в Debian слышал, где там нужно удалять несколько библиотек из рантайма?

У меня всё работало на дебиане, мне кажется стим везде так или иначе хорошо заводится.
Но вообще десктоп-линукс настолько плохо спроектирован, что вполне верю что у кого-то может не быть звука в стиме.
Только это не проблема стима (при том что вульва старается сотрудничать с сообществом).

Вот это вот всё - ничем не лучше репозитория.

Одно отсутствие зависимостей уже перекрывает все плюсы реп на десктопе. Игры запускаются на разных релизах дистра.

Мы уже 30-20 лет попробовали репозитории и что-то в итоге стим родил именно не нативную модель (с рантаймом убунты), а не пересборку под все дистры.
Репозитории на десктопе это чудовищная перерастрата всех вовлечённых в процесс, от разработчиков, до конечных пользователей.

++ :)

Это очень плохие новости для Gentoo. Лично я не совсем понимаю зачем вы вообще используете до сих пор этот давно исчерпавший себя дистрибутив. Но ладно, это лично мое мнение, не навязываю его.

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

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

Этого не будет, пока не случится унификация всех слоёв ниже флэтпака. И да, никто не заставляет даже в классических ПМ-ах опираться на системные библиотеки - есть же /opt, куда ставятся всякие неделимые монолиты. В частности, разработчик Deadbeef вроде как-то так и поступал.

Один и тот же Snap теперь во всех актуальных версиях убунты работает. Это может очень сильно помочь.

А уверенность в этом есть, вы их все и на всех версиях проверяли? Просто теория теорией, а практика совсем иной может оказаться.

То же - с флатпаком для федоры. К тому же флатпак везде работает.

Да-да, то же и с флэтпаком от федоры - не везде работает.

deb для Debian - ну что ж, идейный мазохизм тоже убеждения, будем их уважать.

Можно и не уважать, а предложить более адекватное решение. К сожалению, такого пока что нет.

Это временно, до прихода туда флатпака во все поля.

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

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

А, ну вот. Я и говорю, NixOS (В первую очередь) и Gentoo спасают от подобных ситуаций.

У меня всё работало на дебиане, мне кажется стим везде так или иначе хорошо заводится. Но вообще десктоп-линукс настолько плохо спроектирован, что вполне верю что у кого-то может не быть звука в стиме. Только это не проблема стима (при том что вульва старается сотрудничать с сообществом).

А его разве проектировали вообще? Вроде бы всё развитие шло по сценарию «Я его слепила, из того что было».

Это, ЕМНИП игр на сурсе в основном касалось. Вот вики, что там удалять было нужно - в секции Troubleshooting.

Одно отсутствие зависимостей уже перекрывает все плюсы реп на десктопе. Игры запускаются на разных релизах дистра.

Мы уже 30-20 лет попробовали репозитории и что-то в итоге стим родил именно не нативную модель (с рантаймом убунты), а не пересборку под все дистры. Репозитории на десктопе это чудовищная перерастрата всех вовлечённых в процесс, от разработчиков, до конечных пользователей.

Ещё раз повторюсь: проблема не в зависимостях, проблема в ПМ-ах и несовершенстве FHS, которую стоило бы слегка подпилить.

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

Например, что бы это могло всё быть в одной системе, но при этом что бы каждое конечное приложение не включало по копии:

libfoo : 1.2 : amd64 : org.example
libfoo : 1.2 : i386 : org.example
libfoo : 1.3 : amd64 : org.example
libfoo : 1.3 : amd64 : org.another-org
libfoo : 1.3 : amd64 : org.and-another-org

Но даже что бы это было возможно, одним уровнем ниже этого ПМ-а должно быть нечто унифицированное, некоторая основа. Потому что в некоторых случаях подобное не будет работать, в одной системе не может быть два разных ядра, два инстанса systemd (Или, скажем инстанс systemd и инстанс OpenRC), два Xorg-сервера и т.д. (Технически, может, но это чудовищный костыль).

около-ванильного

Смех, местами переходящий в истерику.

Этого не будет, пока не случится унификация всех слоёв ниже флэтпака.

Я пока не понял, зачем и какая унификация вам нужна. И - ниже флатпака что? Ядро, иксы и системд. Их унифицировать? Зачем - между разными их версиями хорошая совместимость. Вот с чем проблемы - это с версиями библиотек.

И да, никто не заставляет даже в классических ПМ-ах опираться на системные библиотеки - есть же /opt, куда ставятся всякие неделимые монолиты.

Монолиты не нужны - это дупликация. А надо, именно как вы пишите

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

И это обеспечивает флатпак внутри себя. Но там осталась проблема - флатпак все равно дублирует внешнюю, базовую систему пока.

Потому что в некоторых случаях подобное не будет работать

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

Славно заливаете. Удивительное рядом,

А я ведь только собирался обратно мигрировать!

А мигрировать откуда? Или с чего?

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

Решено в Gentoo: версионность, слоты.

А что такого нетривиального в использовании Gentoo? Утилиты слишком текстовые, что ли? Или боязнь правки конфигов?

Конкретно в Gentoo 2 утилиты для обновления конфигов, 2 утилиты для прописывания (локальных?) юзов. Да и сам Portage с хорошими подсказками.

Создай себе небольшое репо дебиана уже.

Да-да, я выше по треду говорил что Gentoo решает эту проблему. Про нетривиальность - я говорил не за себя. Меня только время компиляции не устраивает, особенно если в зависимостях какой-нибудь жир, вроде qtwebkit.

Так то я на Gentoo сейчас и сижу, если вы тред читали.

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

Собирал дебы, используя официальное руководство: основное – составить файл control, по мелочи (если надо) всякие preinst/postinst скрипты и прочее. Дальше dpkg-buildpackage -us -uc (если вкратце).

особенно если в зависимостях какой-нибудь жир, вроде qtwebkit.

Вебкиты можно собрать в бинарные пакеты (-bin) (при желании и на отдельной машине)

Да, это я тоже проходил. Если нужна одна версия одного пакета под одну архитектуру - жизнеспособно. Но если вдруг хочется обновлений, то каждый раз всё перепатчивать - это боль. У них же не принято пользоваться VCS, сборка происходит из тарболов. В общем, собрать - не проблема, проблема - поддерживать. Да, у них есть системы автоматической пересборки, но я не осилил.

Машина у меня одна. А т.к. вёбкиты всё равно нужно собрать, то бинарные пакеты ничего не дают, увы.

Это всё, что нужно знать о разработчиках Debian.

Да, это свидетельство, что там реально волонтеры, которые занимаются пакетами по мере возможности, а не разрабы на ЗП с корпоративной дисциплиной. Хорошо иметь хоть один такой дистрибутив.

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

протолкнули без лицензии разрешающей модификацию.

Так получается, что даже самые ярые борцы за свободу, GNU - «копирасты»:

https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/GNU-Free-Documentation-License.html

Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

(выделение от меня)

И, да, gcc-doc находится в Debian в… «non-free». Выходит, не нормы первопроходцев GNU, а Debian - самые-самые свободные.

Ну хз. Не увидел чем оно удобнее, например, ruinit.

Конечно GNU копирасты. Кто бы сомневался, что буквоеды будут копирастами? Но у нас сейчас весь мир копирастов, так что без них никак.

Ну, каждому - своё. Если вам нужен только init, то возможно systemd ничем и не лучше. Однако, systemd - это далеко не только init. Это, как некоторые заметили, менеджер системы. Несомненно, есть ситуации, где его использование несколько неоправдано (Embedded, Контейнеры приложений), но для десктопа и сервера - самое оно.

Однако, systemd - это далеко не только init.

Да, системды это комбайн. В общем случае он мне не мешает, конечно, но читать обязательное требование как наличие системды - странно.

Несомненно, есть ситуации, где его использование несколько неоправдано (Embedded, Контейнеры приложений)

Почему же неоправдано? Вполне себе.

но для десктопа и сервера - самое оно.

Для десктопа и сервера ровно до того момента пока не мешает его можно игнорировать.

успеть до заморозки testing

До заморозки еще полгода. Они там совсем ретарды?

ситуация с Audacious

А что произошло?

А что такого нетривиального в использовании Gentoo?

ДОЛГАЯ компиляция. Поставить пакет пощумать - час ждать. Обновить - час ждать. Это преступление против Греты Тунберг, в конце концов.

Для меня без systemd жизни нет, увы.

Я с приходом systemd вообще не понимаю, в чём смысл не RedHat дистров с systemd.
Сам на десктопе пользуюсь salix (Slackware с зависимостями пакетов).

Да, системды это комбайн. В общем случае он мне не мешает, конечно, но читать обязательное требование как наличие системды - странно.

Да не то что бы. Альтернативы не имют многих важных фич.

Почему же неоправдано? Вполне себе.

Потому что огромное число функций systemd там бывает ненужно, а занимаемое место может иметь значение.

Для десктопа и сервера ровно до того момента пока не мешает его можно игнорировать.

Окей, это аргумент. Но я себе не могу вообразить ситуацию, где бы оно мешало.

Ну, Audacious изначально был с оболочкой Gtk, но разработчики решили что следующие версии будут (Вроде как, только) с Qt. В stretch завезли Audacious с Gtk и Qt. Вроде бы должно было всех устроить. Но нет, кто-то побежал в багтрекер и пожаловался, что «Gtk приложение тянет Qt зависимости», поэтому в stretch он остался только с Gtk. И в Buster - тоже. В bullseye (Текущий тестинг) вроде как только с Qt. При том что Qt интерфейс был более удобным.

В том, что RH-дистрибутивы гномоодержимые, а так же принудительно внедряют сомнительные технологии. Изначально меня дико раздражало, что «всё решили без меня». И наглость разработчиков, которые сказали «Мы будем делать как хотим, а вы перестраивайтесь». Но продолжительное пользование systemd показало, что альтернативы и рядом не стоят, а решения, хоть и дерзкие, но на то есть обоснование.

Да не то что бы. Альтернативы не имют многих важных фич.

Какие же важные фичи тебе нужны на десктопе, к примеру?

Потому что огромное число функций systemd там бывает ненужно, а занимаемое место может иметь значение.

И сколько оно занимает места? И навскидку можешь перечислить число этих функций?

Но я себе не могу вообразить ситуацию, где бы оно мешало.

Пока не работаешь с этим, ничего не мешает. :)

Я волком бы выгрыз бюрократизм.

Я волком бы выгрыз бюрократизм.

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

С волками жить - по волчьи выть. С бюрокартами жить - бюрократов бюрократией крыть.

Будто в RH нельзя KDE запускать.

Правда, зачем KDE на сервере???

Рабы мейнтейнеров должны страдать, а те бы лучше системой занимались, а не пользовательским ПО.

Права кого? Код в том файле был public domain, просто это не было явно указано.

Права кого?

Права того, кто не был указан.