Debian 9.5

snap, flatpak — это следствие того, что в линкусы набежала хипстота и прочие неосиляторы, очевидное зло. AppImage — не замена пакетов и никто его так не продвигает. А Nix и Guix — закономерная эволюция, движение от хорошего к лучшему. Причём, ты не прав, NixOS существует уже 15 лет и давно стабильна, никакой это не эксперимент. Ну и не путай дистрибутивы и пакетные менеджеры.

snap, flatpak — это следствие того, что в линкусы набежала хипстота и прочие неосиляторы, очевидное зло.

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

AppImage — не замена пакетов и никто его так не продвигает.

Это аналог portable apps чтоб не срать в системе.

никакой это не эксперимент

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

софт все жиреет

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

Это аналог portable apps чтоб не срать в системе

Именно. Никто же не предлагает выпилить пакетные менеджеры и запихнуть всё в AppImage. У портативных приложений своя роль.

На сегодняшний день процентов 25 у меня Appimage

Ну так там зависимости ещё жирнее.

Ну так а я о чем.

не хотят (не осиливают) работать с зависимостями, это да

А зачем этот мартышкин труд в XXI веке, в веке бурного роста нтп и автоматизации.

пора обновляться

Частный случай. Это вопрос личных предпочтений. У меня парочка тоже есть, да и по возможности свой десктопный софт я тоже пытаюсь упаковывать в AppImage, хотя в некоторых случаях задача это нетривиальная.

этот мартышкин труд

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

Не соглашусь, это очень полезное дело. Спапы и флэтпаки — это деградация

Аргументируй

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

standards.png

Идиот-мейнтейнер может засадить багованные библиотеки в дистрибутив и не обновлять их

ну такие дистрибутивы я не использую )

Все вопросы к мейнтейнерам.

там просто авторы софта немного переборщили с сиестой, у них в 18 году вышла версия которая тянет QT4.

AppImage — не замена пакетов и никто его так не продвигает.

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

Дело не в том, что софт жиреет, а в том, что возможности мейнтейнеров ограничены, и с увеличением количества софта лучше бы сами разработчики сами готовили универсальные наборы для использования. И AppImage тут отлично подходит - даже пакетный менеджер ему не нужен. Просто скачал и запустил даже на жёстко кастрированной системе.

а запилить AppImage зачастую гораздо сложнее пакета.

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

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

там просто авторы софта немного переборщили с сиестой, у них в 18 году вышла версия которая тянет QT4.

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

А какой хороший?

Один из самих хороших дистрибутивов. Хай живе Debian GNU/Linux!

Оплот стабильности и «рабочая лошадка». Он теплий и уютний.

Правда переход на системд огорчил, но что поделаешь :(

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

Нет какого-то магического и универсального способа создания AppImage типа rpmbuild или dpkg-deb --build, где достаточно спеки/контрол-файла. Вместо того чтобы просто указать зависимости, ты должен их затолкать в AppImage, либо избежать. Возникает дилемма, как поступать с зависимостями, просто выколупать всё нужное из уже готовых пакетов, либо собирать самому, также нужно это автоматизировать. Где-то тебе надо собрать ещё дофига зависимостей для твоих зависимостей, а что-то мб лучше слинковать статически, если лицензии позволяют, где-то лучше исследовать вопрос о доступности зависимости в основных дистрах, чтобы вовсе её не включать. Короче, пакет взял и собрал, а тут работы больше, как ни крути, тем более, что надо ещё тестить больше дистров, тогда как пакет ты собираешь под более-менее конкретную целевую систему.

Федорка же его любимая.

Fedora хороша когда ты единственный пользователь в системе, которому много не надо: интернет, плеер аудио/видео, ide. В противном случае начинается ад.

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

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

хотя по-уму надо было портировать на QT5 и собирать так чтоб оно юзало как можно больше из системы.

А еще у них python второй что немножко приводит к геморрою поскольку это у меня единственный софт который его требует.

python они вроде в AppImage не засунули, и то хорошо

Сами пакетные менеджеры выкидывать, конечно, не стоит. А вот прикладуху на AppImage переводить очень даже нужно

Как раз в этом и суть. Разные мелкий терминальный софт через стандартные репы и пм, а монструозные софтины вроде blender, libreoffice, проприетарщину вроде skype в самодостаточные пакеты. А что насчет того же snap и flatpak скажешь?

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

Может в создании одного appimage работы и больше, зато один раз собрал и будет работать под всеми системами.

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

Нет какого-то магического и универсального способа создания AppImage типа rpmbuild или dpkg-deb --build, где достаточно спеки/контрол-файла. Вместо того чтобы просто указать зависимости, ты должен их затолкать в AppImage, либо избежать. Возникает дилемма, как поступать с зависимостями, просто выколупать всё нужное из уже готовых пакетов, либо собирать самому, также нужно это автоматизировать.

Это необходимые последствия, которые ничем плохим не являются, так как указать использовать системные библиотеки всё ещё можно. Универсального магического способа полноценно собирать deb и rpm, кстати, тоже нет - либо через упрощённую схему с помощью checkinstall, либо через более сложную средствами пакетного менеджера. Сама же сборка итак универсально настолько, насколько это возможно. Ради того, чтобы приложение заработало вообще везде, можно и не обращать внимание на то, что сборка ориентирована не на конечного пользователя, а на (внезапно) разработчика.

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

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

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

То же самое они могут сделать, если будут собирать deb или rpm. Вообще для некоторых приложений это оправданная схема. А про половину древней убунты ты преувеличиваешь очень сильно.

хотя по-уму надо было портировать на QT5 и собирать так чтоб оно юзало как можно больше из системы.

Чтобы к следующему дистрибутиву отвалилось, ага! При таком раскладе лучше под конкретный дистрибутив пакеты собрать.

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

Не знаю, о каком пакете ты ведёшь речь, но судя по тому, что ты пишешь, лучше бы они туда python засунули.

Разные мелкий терминальный софт через стандартные репы и пм

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

А что насчет того же snap и flatpak скажешь?

Уже много раз говорил: это те же пакеты с пакетными менеджерами, которые ничего нового не дают, никакую проблему вообще не решают, зато добавляют фрагментации и геморроя. Тем, кто итак пакеты под популярные пакетные менеджеры собирают, они неинтересны. В итоге остаются психически больные лица, которые вытворяют треш, угар и содомию со span и flatpak. Дело дошло до того, что для какой-то программки установка то ли snap то ли flatpak приводит только к тому, что в стандартный старый пакетный менеджер добавляется репозиторий с пакетами той программки. Snap и flatpak сделаны для того, чтобы подмять под себя другие дистрибутивы, а не решить проблемы, поскольку архитектура у них исключительно под это заточена. AppImage же сделан для того, чтобы проблемы решить.

Для этого достаточно определиться, что в любой системе стоит, и докинуть необходимые библиотеки в комплект. Надо использовать системные библиотеки? LD_LIBRARY_PATH и LD_PRELOAD всегда доступны. Да и библиотеки и различные зависимости можно тоже минималистично собирать по мере возможности. Разработчики больших прикладух, у которых зависимостей полно, только облегчение испытают (там итак своя среда разработки и сборки, а не каждый новый день берутрандомный дистрибутив и шпарят как хотят), так как объём вырастет не так сильно, зато куча проблем решится. А мелкие прикладухи много с собой не таскают.

и работает долгие годы практически на любом дистрибутиве, даже на не вышедшем

Это если не завязываться на системные библиотеки.

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

Я об этом (в том числе) и говорил.

где-то лучше исследовать вопрос о доступности зависимости в основных дистрах, чтобы вовсе её не включать

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

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

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

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

Ты имеешь в виду статическую линковку?

Про сетевую прозрачность здесь: Как вы относитесь к переходу на Wayland? (комментарий)

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

А что плохого в увеличении энтропии?

Ты имеешь в виду статическую линковку?

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

народ и выбирает Ubuntu Devuan.

Fixed.

А почему у тебя в девуане в процессах systemd?

Там бредятина. Сначала говорили «Мы в вяленде не будем делать сетевую прозрачность, так как она не нужна и вообще только тормозит графику». Как только оказалось, что сетевая прозрачность оказывается много кому нужны, тогда и начали петь «ну можно реализовать в вяленде - он это позволяет... но вы будете жрать VNC потому, что мы наврали вам только что!». Да и сам Мартин уже был замечен в крайней неадекватности ранее. Что характерно, чаще всего защищающие вяленого ссылаются на этого идиота (почему он идиот, недавно можно было наглядно наблюдать на примере его препирательств с разработчиками из KDE VDG) и на обмудка Дэниела Стоуна (который, опять повторю, намеренно портил исходники свободного видеодрайвера для радеона).

Вообще все эти высеры в стиле «Сетевая прозрачность в оконной системе не нужна. В X11 она не подходит» и прочие неадекватные заявления обычно выдают из-за незнания архитектуры X11 и некомпетентности в области графики.

А Debian -ужасный и древний дистрибутив!

Админ локалхоста детектед.

Debian - это операционная система

Внезапно...

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

Но ты ведь эти сайты не листал, не читал? Ты точно долбанутая мартышка.

А почему у тебя в девуане в процессах systemd?

Это только в твоих влажных мечтах.

Может так тебе будет понятней вопрос. А почему у тебя в девуане в процессах systemd?

А причём здесь энтропия?

Может так тебе будет понятней вопрос.

Да, ты прав. На одной из машин так и остался Debian, а в теге я допустил ошибку. Теперь уже не исправить...но все равно спасибо.

То есть /dev/random Стаса Михайлова и Донцовой это не увеличение энтропии?