если в пакет надо запаковать один скрипт на баше

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

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

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

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

А дедупликация как же?

Потому что 100500 разных систем контейнеризаций и результат распухает что инсталлер на венду или макось. Всегда можно определить базовый набор дистров, в которых аппликуха саппортится и собирать самостоятельно пакеты, пускай и с включением супер-свежих либ в пакет (это пакет от разрабов, а не дистрибутивный эталон).

The operation would result in removing the following protected packages: kernel-core
(try to add '--skip-broken' to skip uninstallable packages)

Когда 30-ка только вышла, то была такая фигня и при обновлении через dnf, но потом быстро починили. Решение я даже не гуглил, и так ясно, что dnf не может удалить старое(четвертое) ядро, а rpm с этим справлялся, в общем не критично.

Потому что 100500 разных систем контейнеризаций и результат распухает что инсталлер на венду или макось.

А когда тарболы в /opt разворачиваешь ничего не распухает? Ну-ну. А вообще - контейнеризация десктопных приложений одна - flatpak. За все остальное разное благодари своего космонавта-вредителя.

Распухать оно конечно распухает, потому что как минимум рантаймы флатпака дублируют системные библиотеки. Но это неизбежное зло. И не такое большое как проблемы, которые это решает.

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

За это пора руки отбивать. Любая программа для линукса должна работать и саппортиться в любом линуксе. Все технические возможности для этого есть. А кто не хочет делать нормально и вываливает всякие deb которых хватит всем - луддиты.

Так это детские болезни перехода на новую систему

Мне так не кажется. Федора никогда не была дружелюбной: вот инструменты — иди и настраивай.

У меня с флатпаком намного серьезнее фигня - в нем не поддерживается jack

Флатпаки могут только пульсу?

Мне так не кажется. Федора никогда не была дружелюбной: вот инструменты — иди и настраивай.

Проблемы флатпака касаются далеко не только федоры.

Флатпаки могут только пульсу?

Пока да. Пилят PipeWire, который помимо прочего эмулирует jack для клиентов в контейнере, но пока вроде не готово. Вопрос висит.

SSD и памяти 16гиг

И это поделие умудряется тормозить на SSD с 16 гигами памяти? Жесть...

А ты уточни сначала какое именно поделие. Выяснилось что совсем не сабжевое.

Но это неизбежное зло.

Это глупость а не зло. Запустить CI со сборкой пакетов под основные дистры - дело несложное и доступное даже небольшим командам. В сложных проектах контейнеризированное решение тоже не панацея - то одну либу забыли, то другую, то третью. Ей-богу, уж лучше пользоваться дистровыми зависимостями, чем вот эта вот «пляска святого Витта»

За это пора руки отбивать. Любая программа для линукса должна работать и саппортиться в любом линуксе.

Какой вьюношеский максимализьм :) А если флатпак пакет работает на определенном дистре с косяком, что кому отрывать конечности будем? И ваще, всяких васяндистров немеряно - нужна сборка, пусть сами под свой дистр и делают.

А кто не хочет делать нормально и вываливает всякие deb которых хватит всем - луддиты.

s/deb/flatpack/ - не благодари :)

А ты уточни сначала какое именно поделие. Выяснилось что совсем не сабжевое.

Вопрос - флатпак чем так от снапа отличается? Разве вы сами не писали про дублирование либ? Вот чтобы поднять весь стек в память и тратятся эти 5-10сек. Точно такой же эффект у портируемых на венду/макось прог - пока все свое барахло поднимут, появляется временной лаг.

Суть новости и автора: ненужно-пиарящее НЕНУЖНО на коротком поводке у НеНужно пиарит тестовое НЕНУЖНО aka Ненужно 31.

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

Что значит забыли? Если ты либу забудешь, у тебя пакет не соберется. Чтобы создать флатпак пакет надо его собрать из исходников уже в контейнере. Без всех либ он не соберется тупо.

Запустить CI со сборкой пакетов под основные дистры - дело несложное и доступное даже небольшим командам.

Только непонятно, нафейхоа это нужно теперь когда есть флатпак.

Ей-богу, уж лучше пользоваться дистровыми зависимостями, чем вот эта вот «пляска святого Витта»

Какая конкретно пляска?

А если флатпак пакет работает на определенном дистре с косяком, что кому отрывать конечности будем?

Приведи технические подробности, как это возможно, технически? От дистрибутива флатпак-приложение использует только ядро, и все. У тебя ядро неправильное будет? Или вместо линукса винда?

И ваще, всяких васяндистров немеряно - нужна сборка, пусть сами под свой дистр и делают.

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

s/deb/flatpack/ - не благодари :)

Реальность такова, что флатпак хватает всем, а deb - только убунтоидам, которым на всех остальных плевать, как и их лидеру-вредителю.

вьюношеский максимализьм
флатпак
:)

Это когда вьюноши в основной массе перестали иметь дома компьютер для учёбы с шестьдесят-четырьмя гигабайтами памяти? Вы что-то тут путаете. Ставите людей с ног на голову. И даже не стесняетесь.

Оперативно rh-positive удалил моё сообщение. Видимо, разгадал значение каждого слова «ненужно», а ведь первое и второе были не совсем очевидны.

Вопрос - флатпак чем так от снапа отличается?

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

Вот чтобы поднять весь стек в память и тратятся эти 5-10сек.

На SSD у тебя система должна загружаться c нуля за 10 секунд, система, Карл! Какое нафиг поднятие стека? В течение 10 секунд????

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

Что за ерунда, под виндой каждая не портированная программа тянет все библиотеки с собой, не хуже любых контейнеров. Ты винду то видел? Какая там разница, что портировано а что нет?

Это когда вьюноши в основной массе перестали иметь дома компьютер для учёбы с шестьдесят-четырьмя гигабайтами памяти?

Вам бы всем полечиться, я на работе использую флатпак на компьютере с 2 ГБ памяти. Два гигабайта, Карл!

А я на это всё это пользуюсь кучей лис, емаксом и ещё на много чего остаётся.

А я на это всё это пользуюсь кучей лис, емаксом и ещё на много чего остаётся.

Я как-бы тоже.

Без всех либ он не соберется тупо.

Молодой человек, сразу видно, что вы не имели опыта по сборке сложных проектов. Есть куча опциональных зависимостей, которые если не соблюсти при сборке, то функционал будет просто обкоцанный. Пример: ImageMagick можно собрать без стека используемых либ (libtiff, libpng и т.п.) Но поддрежка форматов будет обкоцанной. И так со многими либами при сборке из сорцов. И в сложных проектах такие зависимости не всегда очевидны и понятны. Например, вы точно знаете какой стек либ нужен для поддержки кхмерского текста в libpango? Можете не рыться в инете - выяснение этого вопроса может занять много времени. И часто-густо контейнеростроевцы лажают вдоль и поперек в таких ньюансах.

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

Васяндистры разве заслуживают большего?

Что за ерунда, под виндой каждая не портированная программа тянет все библиотеки с собой, не хуже любых контейнеров. Ты винду то видел? Какая там разница, что портировано а что нет?

Вьюноша, идите учите матчасть.

Вьюноша, идите учите матчасть.

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

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

Отлично, а теперь объясни как ты избегаешь означенных проблем при сборке deb пакетов. И сравним.

Васяндистры разве заслуживают большего?

Такие васяндистры как убунта - может и нет.

Вообще смешно конечно, я думала тут тред будет про докер или про wayland. Ну на худой конец про systemd. А тут у нас нашлась «главная проблема Fedora»(tm).

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

А вот не задавались-ли Вы вопросом flatpak и прочие контейнеры зойчем? В чём основная причина появления? Подсказка: есть код, есть данные которые нужно обрабатывать, есть средства разграничения доступа. Далее, что будет если набор утилит, который должен иметь доступ к некоторым данным мы обернём в контейнеры? Правильно, ничего, суть не поменялась. Мы лишь изолировали действия утилит на базовую ОС, но.. Мы это можем сделать при помощи базовых средств разграничения!!!

Они что, их никогда не тестировали, не открывали что ли?

нет почему же. они тестирируют до состояния беты. а потом устраивают релиз-пати и дальше уже агитируют на тестирование сообщество. fedora - это technical preview rhel. в этом состоянии я ее поюзал с 24 по какой-то там релиз. опробовал wayland на открытых дровах, подергал за systemd и снес.

А вот не задавались-ли Вы вопросом flatpak и прочие контейнеры зойчем?

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

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

не была. именно демагогию наблюдал и я.

Да... Но приложение при установке меняет систему и так-же требует конфигурации. У каждого контейнера есть зависимости от нижележащих слоёв. Сложнее инфраструктура. Больше объём вращающегося на ядрах кода. Больше потенциальных дыр. А аппликухи можно сделать не мешающими друг другу и базовыми средствами. Потом,, представьте ситуацию абсолюта контейнерезации - каждая утилита системы в контейнере. Что поменялось? НИЧЕГО!!! Для вывода «Привет грёбаный мир» на экран теперь мы нагреваем воздух в 10 раз больше. Тают льды, плачут пингвины, дальше цензура заменила все первопричины словом «философия».

нет почему же. они тестирируют до состояния беты.

они его тестируют лишь до состояния альфа.. )

Вот уж где лол. Давно в твоей вселенной промышленный дистр намбер ван превратился в васянадистр?

Я на это могу ответить лишь советом не доводить идеи до маразма (это про каждую утилиту в контейнере) и завязать наконец со спиртным.

Все изложенное похоже на непонятной природы список иррациональных страхов, не имеющих отношения к реальности.

Но приложение при установке меняет систему и так-же требует конфигурации.

При установке в контейнер приложение меняет контейнер, а не систему. Конфигурация вся внутри контейнера.

У каждого контейнера есть зависимости от нижележащих слоёв.

Только от ядра. Не думаю что это проблема.

Сложнее инфраструктура. Больше объём вращающегося на ядрах кода. Больше потенциальных дыр.

Контейнеризация реализуется как раз «базовыми средствами». Используется bind_mount (это базовое средство которому 100 лет), pivot_root (то же самое, chroot еще в древнем риме использовали и никто не жаловался), ну и неймспейсы всякие.

Так и не понятно что такого жирного добавляет контейнеризация в систему. Пока видно что ничего сверх того что там и так было.

Для вывода «Привет грёбаный мир» на экран теперь мы нагреваем воздух в 10 раз больше.

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

Вот уж где лол. Давно в твоей вселенной промышленный дистр намбер ван превратился в васянадистр?

Он всегда им был, практически с самого начала. То, что он намбер ван - это не более чем рекламная требуха.

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

Это типичное васянство.

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

винда - глюкало, говорили они :)

> Но какие-нибудь утилиты... серьёзно, тебе гуглить приходится?

Бывает такое, как ни странно. Далеко не всегда очевидно, что делает вон тот чекбокс или что написать вот в это поле и в каком формате.

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

PS на тему гуй vs консоль. Майкрософт очень долго морщил нос, типа вот вам гуй, там и возите мышкой, а последние несколько лет запилил powershell, через который можно всё, гуй не нужен.

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

https://www.easycoding.org/2019/10/14/sravnenie-samodostatochnyx-paketov.html

Да, отличается, и очень сильно: https://www.easycoding.org/2019/10/14/sravnenie-samodostatochnyx-paketov.html

Ммммм, а факты будут?

А, так вот, спасибо анону, тебе и ответ на вопрос почему приложения по 10 секунд из снапа запускаются.

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

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

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

Как ты будешь в гимпе/блендере/кденлайв в консоли работать?

Тут был анекдотичный случай. Нужно было что-то сделать с фотками сотрудников. На повторить гимпами почти одинаковую операцию с достаточной точностью пару сотен раз никому не хватило уверенности в мощи UI. Т.ч. решалось imagemagic + for i in *. Ничьи мозги не взорвались, и производительнсть вместе с чтением манов и исправлением ощибок получилась очень приемлемой. Как мне кажется – замерять не догадался.

Пользователи федорки это и есть бета-тестеры

Некоторые предпочитают питаться ещё не протухшими продуктами. Бетатестеры.

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

У меня всегда вылазили какие-то недочёты что в Fedora Core, что в последующих версиях. Так в 30 после определённого обновления машинка перестала стартовать. Чёрный экран ещё до grub. Пришлось фиксить через настройки bios. Хотя в archlinux при почти таких же версиях и настройках все работает. То borg перестанет работать, то Eclipse, то в до выхода pgadmin4 3 версия вылетает, то без amdgpu.dc=1 жёсткий фриз, хотя в том же archlinux, debian норм. И так далее.

В установщике полный бардак. Можно легко получить ситуацию когда создаёшь шифрованный раздел с luks2, а на выходе получить все равно luks первой версии. И не только.

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

Silverblue.

Я не довожу до маразма. Пример «все приложения контейнеры» лишь показывает что и субъекты и объекты никуда не делись а остались на месте. Вы не поняли меня. Контейнеризация не решает проблемы безопасности ДАННЫХ в принципе, пользовательских, системных(всё так-же надо хранить конфигурацию), конфигурации системы контейнеризации(в свою очередь обеспечивая её безопасность). Вероятность безотказной работы, равно как и безопасной(с некоторомы оговорками) равна произведению вероятностей безотказной работы входящих в эту систему частей это классика. Какая разница если я скомпрометирую сервис, имеющий доступ к данным, в контейнере или «в обычном режиме», получив доступ? Да никакой. Контейнеры это для кручения на одном хосте кучи однотипных сервисов с РАЗНЫМИ пользовательскими данными точка. Зачем на локалхосте это?!

Ещё на тему гуй vs консоль

1. Нет никакого «гуй vs консоль». Консоль это терминал, прибитый гвоздями к прибору. Все пользователи нотбуков, мобил и подавляющего большинства персоналок работают с консолью. И нынче она больше гуёвая.

2. Также, это не «vs команды» – мышой ты отдаёшь компу те же команды.

3. Также это не «vs текстовый» – хоткеи в гуе почти ничем не отличаются от «–arg=». Хотя их делают слишком мало и скрытно.

4. Также это не «vs CLI» – графические команды поступают так же последовательно, как в «строке» и макросы могут быть достаточно близки к «строке команд».

Так что же это? У меня такие гипотезы:

A. каплями vs вагонами. Больше к конкретному языку/интерфейсу, но исторически оно рядом ходит.

Б. лезть vs прыгать. С откликом и возможностью исправить, или авось.

В. sync vs async. Контролировать шаги, или потом доложишь.

Итого, гуй(*) – не для продуктивных, уверенных и терпеливых. (*) В его обычном (до сих пор) виде – сегодня мне кажется, что можно объединить преимущества обоих в одном интерфейсе, достаточно «графическом» для любителей гуя и продуктивном для хейтеров.

ЗЫ. ещё - редактируемость и повторяемость, но поздно вспомнил.

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

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

Отлично, а теперь объясни как ты избегаешь означенных проблем при сборке deb пакетов. И сравним.

На линуксе у меня нет таких проблем - ставишь в пакете зависимость libpango или libmagickwand и все. Остальное уже за меня делает система управления пакетами. А вот на винде или на маке приходится перебирать вручную весь стек либ со всеми ньюнсами по сборке:

https://github.com/sk1project/build-macos/tree/master/src

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

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

Я бы сказала gui vs text – это исследование(discovery) против исполнения(execution).

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

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

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

Некоторые предпочитают питаться ещё не протухшими продуктами. Бетатестеры.

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

А протухшие - то к пользователям Debian Stable.

CentOS/RHEL гниль тогда?