LINUX.ORG.RU
ФорумTalks

Обратная сторона систем распространения приложений в обход дистрибутивов

 


0

2

Я пропустил или тут ещё не было?

http://kmkeen.com/maintainers-matter/2016-06-15-11-51-16-472.html

http://www.opennet.ru/opennews/art.shtml?num=44611

Кайл Кин (Kyle Keen), один из мэйнтейнеров дистрибутива Arch Linux, обратил внимание на проблемы, связанные с внедрением систем самодостаточного распространения приложений для Linux, таких как продвигаемая компанией Canonical технология snap. По мнению Кайна, идея прямой сборки и поставки пакетов разработчиками приложений может привести к проблемам с качеством и безопасностью.

и т.д.

★★★★★

один из мэйнтейнеров

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

ptarh ★★★★★
()
Ответ на: комментарий от slovazap

В AUR вроде каждый может залить свой PKGBUILD в два клика. И он будет качать исходники из мест типа pypi или github куда тоже каждый может залить это в два клика. Для многих программ в AUR много альтернативных версиях под названиями типа mozilla-git mozilla-nighbuilds-latest-with-new-wallpapers. Многие ли прям так вчитываются в PGKBUILD`ы и проверяют откуда они берут исходники и всё ли там в порядке?

pawnhearts ★★★★★
()
Ответ на: комментарий от Deleted

Он умолчал о нескольких крупных проблемах репозиторной модели: неоперативность мантейнеров

The promise: By cutting out the maintainer middle-man, security fixes can be pushed out to users faster.

The reality: Often maintainers are faster, particularly with anything using shared libraries. A distro can update a shared library once and all software is now safe, without needing to rebuild every piece of software using it. Most of the sandboxes do not share libraries and so you are waiting on the slowest ISV to rebuild their software. If they ever do. ISVs are notorious for using ancient libraries with extensive out-of-tree patches and never migrating the patches forward.

deps-hell

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

невозможность охватить всё множество софта

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

Axon ★★★★★
()
Последнее исправление: Axon (всего исправлений: 1)
Ответ на: комментарий от Deleted

В чем геморрой то? Я вообще не понимаю, почему hell? это в винде dll-hell, а в линуксе libfoobar.so.{5,6,7,8} и никакого hell-а.

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

На рабочей системе просто ставишь libfoobar{5,6,7,8} и всё

У меня libncurses и libpng двух версий совершенно спокойно стоят.

sergej ★★★★★
() автор топика
Ответ на: комментарий от leg0las

Но без решения наподобие снапа или какого-то стандартизированного метода упаковки бинариков - типа «засунул бинарик и либы в спец архив, везде работает» - в линуксе не будет CADов, проф. софта для работы со звуком/видео, включая аппаратные всякие там микшеры, и прочая прочая.

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

Axon ★★★★★
()
Ответ на: комментарий от leg0las

И софторазрабы потянутся.

Главное - изобразить аэропорт, тогда и самолёты с ништяками подтянутся.

Axon ★★★★★
()
Ответ на: комментарий от Zampolit

Ну да, а как в раче - 3.5 пакета в main, а остальное пакуют мимикрокодилы - это, конечно, качественно и безопасно.

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

Axon ★★★★★
()
Ответ на: комментарий от Zampolit

А помойка типа AUR явно не качественнее и не безопаснее snap-пакетов.

Не качественнее - возможно, но безопаснее однозначно.

Axon ★★★★★
()
Ответ на: Сорта от Camel

Часто бухгалтеры уже одинэс из deb'ов ставят?

Бухи 1С не ставят, его ставят 1Сники. И, да, под линукс они его ставят из дебов.

Axon ★★★★★
()
Последнее исправление: Axon (всего исправлений: 1)
Ответ на: комментарий от Zampolit

snap пакеты решают проблемы с её распространением.

Проблемы с её распространением в большинстве случаев носят не технический характер. Snap пакеты эти проблемы не решают никак.

А архив с исходниками на том же ftp подменить не могут, да.

Чексумма не сойдётся.

Axon ★★★★★
()
Ответ на: комментарий от Aceler

А в AUR не так?

Не так. Из AUR ты собираешь пакет лично сам.

Майнтейнеры арча могут дать честное пионерское, а в убунту не могут?

А при чём тут убунту?

Axon ★★★★★
()
Ответ на: комментарий от invy

Т.е. когда раньше блоб поставляли (та же vmware), его не волновали проблемы с безопасностью?

Проприетарщину не исправить. Чувак паникует, что этот рак даст метастазы в опенсорц.

Axon ★★★★★
()
Ответ на: комментарий от pawnhearts

Многие ли прям так вчитываются в PGKBUILD`ы и проверяют откуда они берут исходники и всё ли там в порядке?

Да, многие. Там вчитывания-то пять строчек.

Axon ★★★★★
()
Ответ на: комментарий от Axon

Дело не в пяти строчках, а куда они ведут. Вот ставишь ты какой-нибудь пакет модные_патчи_для_шг и ведет он на чей-то гитхаб, непотяно чей, ты будешь все исходники там читать?

Некоторые вещи вообще не ставятся из AUR потому что ссылки битые.

pawnhearts ★★★★★
()
Ответ на: комментарий от pawnhearts

Дело не в пяти строчках, а куда они ведут. Вот ставишь ты какой-нибудь пакет модные_патчи_для_шг и ведет он на чей-то гитхаб, непотяно чей, ты будешь все исходники там читать?

Если url выглядит подозрительно, то я, как минимум, посмотрю куда он ведёт.

Некоторые вещи вообще не ставятся из AUR потому что ссылки битые.

Недавно переезд на новую версию был, всё неподдерживаемое старьё само отвалилось.

Axon ★★★★★
()
Ответ на: комментарий от Axon

Не так. Из AUR ты собираешь пакет лично сам.

Мы говорили про ОУД майнтейнера в AUR или майнтейнера в snap. Технические подробности здесь никого не интересуют.

А при чём тут убунту?

А ты пробовал читать весь тред, а не отдельные слова в предложении? Мы тут вообще-то snap обсуждаем. Какое отношение snap имеет к убунту и зачем для установки snap нужна учётка в canonical, оставлю тебе в качестве самостоятельной работы.

Aceler ★★★★★
()
Ответ на: комментарий от pawnhearts

Если так то он, возможно, бОльшая помойка чем порты FreeBSD, но всё равно несравнимо более безопасен, чем всякие snap'ы.

slovazap ★★★★★
()
Ответ на: комментарий от flyshoot

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

flatpak, возможно snap

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

увы. snap - canonical, flatpak - gnome, от которого уши красношляпы торчат.

feofan ★★★★★
()
Ответ на: комментарий от Axon

В линуксе есть и прекрасно (в широком понимании этого слова) работает куча проприетарщины.

прекрасно (в широком понимании этого слова)

В цитатник.

feofan ★★★★★
()

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)

Ох сколько срачей на эту тему ещё дальше будет.

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

систем распространения приложений в обход дистрибутивов

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

Странно видеть сколько находится защитников традиционного распространения ПО через репозитории. Будто эти люди никогда не пользуются софтом, которого нет в репах. И при этом тут чуть ли ни каждый второй балуется проприетарщиной. Так что это за двоемыслие?

Вполне вероятно, многие защищают этот подход, потому-что когда-то он преподносился как одно из преимуществ ОС GNU/Linux, как и то что вирусов нет, и к ресурсам не требователен.

Esteban_Garcia
()
Ответ на: комментарий от Esteban_Garcia

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

С т. з. треда это не «в обход». Здесь речь о системе зависимостей и динамической компоновке.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Deleted

неоперативность мантейнеров, deps-hell, невозможность охватить всё множество софта, и т.д.

Ещё одна из главных проблем: дыра в отдельной программе легко может стать дырой всей ОС. Тут один аргументов: дырявые библиотеки разных версий. Но какая проблема в том, что например калькулятор использует дырявую версию библиотеки, позволяющей получить удаленный доступ к моей истории вычислений, когда он вообще не имеет доступ к сети?

Esteban_Garcia
()
Ответ на: комментарий от intelfx

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

Здесь речь о системе зависимостей и динамической компоновке.

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

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

Это вообще наглое 4.2.

Esteban_Garcia
()
Ответ на: комментарий от Axon

Стим

Который тащит с собой чрут

скайп

Который работает через раз. Зимой еще крашился, в зависимости прилетел use-флаг для qtwebkit.

leg0las ★★★★★
()

Пока даже snap'а Firefox нет, о чем-то говорить сложно. Но для таких вещей как Firefox, snap бы действительно подошел. Впрочем его и так поддерживают хорошо и оперативно.

anonymous_sama ★★★★★
()
Ответ на: комментарий от Axon

snap нинужэн

Бухи 1С не ставят, его ставят 1Сники. И, да, под линукс они его ставят из дебов.

Что добавляет очков deb'у. snap всё ещё выглядит ненужной сущностью.

Camel ★★★★★
()
Ответ на: комментарий от thunar

Guix rules

решается сторонними репозитариями ==> deps-hell

Засуньте себе dependency hell в Debian. В GuixSD ад зависимостей принципиально невозможен. Никакая* программа не может при установке вызвать конфликт с имеющимися программами.

*На самом деле некоторые программы могут стоять только в единственном числе, например загрузчик. Никаким образом нельзя в единственную загрузочную область вписать 5 GRUB'ов. Некоторые программы могут использоваться только в единственном числе в некоторый момент времени, например ядро или система инициализации. Можно поставить много ядер и систем инициализации, но при загрузке выбрать что-то одно. Всё остальное guix позволяет ставить и одновременно использовать хоть по миллиону штук.

Camel ★★★★★
()

Утверждение: Изоляция приложения в sandbox-контейнере позволит защититься от недобросовестных поставщиков.

Реальность: Изоляция блокирует лишь часть угроз, но не может ограничить этические злоупотребления. Возможно мэйнейнеры могут не заметить некоторые технические ошибки, которые будут блокированы в sandbox, но они точно заметят уловки нечистых на руку производителей (например, мэйнтейнер не согласится принять мобильное приложение с реализацией фонарика или темы оформления, требующих доступа к сети и телефонии);

Часть угроз? Перехват пользовательского ввода, в т. ч. паролей. Чтение сохраненных данных с диска, слежка за пользователем и отправка данных в сеть. Это всё тольк часть угроз? Для меня это существенная часть. Злоупотребления в рамках отдельного ПО в своей песочницы уже менее существенно. А ограничения доступа вообще лучше устанавливать лично, а не доверять кому-то.

Утверждение: Мэйнтейнер является дополнительным промежуточным звеном, замедляющим доведение до пользователя устранений уязвимостей;

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

Пожалуй единственный пункт соответствующий действительности. Хотя это не всегда работает, только с частью софта.

Утверждение: Универсальные пакеты позволят производителям не заботиться об особенностях каждого дистрибутива.

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

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

Утверждение: Каталоги-магазины приложений (App Stores) являются реинкарнацией традиционных репозиториев дистрибутивов - централизованное размещение программ, удобный поиск, простая установка и автоматические обновления.

Реальность: Отсутствие поддержки системы зависимостей, непригодность для распространения системных программ и автоматизированные проверки, не исключающие добавление вредоносного ПО;

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

Утверждение: Достаточно создать каталог-магазин приложений и миллионы разработчиков наполнят его своими программами.

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

Магазины не нужны.

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

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

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

Утверждение: Самостоятельный выпуск пакетов разработчиками программ снизит дублирование работы между дистрибутивами.

Реальность: Разные дистрибутивы существуют из-за разных предпочтений пользователей. Например, пользователи Puppy Linux хотят чтобы из программы было вырезано всё лишнее и были применены все возможные оптимизации. В Live-дистрибутивах для увеличения срока службы Flash требуется отключить автозапись. Пользователи Ubuntu хотят получить максимум функциональности и плагинов. Пользователи LFS и Gentoo предпочитают самостоятельно собрать программу из исходных текстов. Само по себе создание пакета не составляет труда. Основные усилия уходят на исправление ошибок, которые остаются неисправленными в основном проекте, и, так как патчи общедоступны, они вполне успешно совместно используются разными дистрибутивами;

В крупных проектах вполне могут не скупиться и держать именно мэйнтейнера. Да и в случае сборки разработчиками, они тоже вполне заинтересованны в отсутствии проблем в поставке их ПО. Другое дело когда нужно собирать для ОС с 1% пользователей, но под все особенности различных дистрибутивов, что это потребует 99% работы, то конечно, даже крупные проекты как Firefox поставляются в виде архива, либо соберут .deb под последние версии Ubuntu/Debian. Во вторых, сборка в виде самодостаточных пакетов вовсе не запрещает пересобирать пакет с различными оптимизациями. Даже мэйнтейнеров не запрещают.

Утверждение: Можно избежать многих ошибок, так как разработчик лучше разбирается в своей программе и более опытен, чем мэйнтейнер.

Реальность: Чтобы не оскорбить разработчиков, Кайл Кин предложил поверить ему на слово, что это не всегда так, и предпочёл не приводить конкретные примеры.

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

Утверждение: Прямая поставка ПО от производителя не содержит лишних звеньев в цепочке доверия и лучше для пользователей.

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

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

В заключение. В андроиде, несмотря на те самые «самодостаточные пакеты» модель мэйнтейнеров и репозиториев таки работает, на примере F-Droid.

Esteban_Garcia
()
Ответ на: комментарий от Esteban_Garcia

ISO-ляция

Изоляция в GuixSD уже есть или когда обещается?

Изоляция кого от чего?

И таки вы отвечаете на которое из моих высказываний? О том что в GuixSD невозможен ад зависимостей? Где я не прав?

Camel ★★★★★
()
Ответ на: комментарий от Esteban_Garcia

Поддержка

Это вообще наглое 4.2.

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

Camel ★★★★★
()
Ответ на: комментарий от feofan

Если бы. 90% игорь таки тащат свои версии багов. У них даже под вантузом каждая игорь свой директикс личный тащит.

Goury ★★★★★
()
Последнее исправление: Goury (всего исправлений: 1)
Ответ на: комментарий от leg0las

в линуксе не будет CADов, проф. софта для работы со звуком/видео

потому что и так и так бинари

и в таком случае все равно что внутри, tar.gz с бинарниками или snap пакет

включая аппаратные всякие там микшеры

вот как раз с аппаратными микшерами на онтопике такая лафа не сработает

reprimand ★★★★★
()
Ответ на: комментарий от flyshoot

weare: А открытый софт весь качественный и безбажный... мммдя.

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

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

Отличная позиция чё. Вон тебе 12 тысяч пакетов, выбирай-нихочу. Зачем тебе какой-то другой софт? Ведь с точки зрения мэйнтейнера, пакеты только именами да зависимостями различаются.

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

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

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

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

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

Частично, то есть почти никак. Все лишь вопрос доверия.

А snap и аналоги это один большой путь распространения зловредного кода.

Я бы предпочел считать код заведомо зловредным, и не давать ему доступа больше, чем требуется. А если кто хочет слишком много доступа, то закономерный вопрос: сх**ли? Открытый софт + мэйнтейнеры != решение проблем безопасности. Именно потому разрабатывается Qubes например или SubgraphOS. Но изоляция отдельных приложений куда более элегантное решение.

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

Всё точно так же решается: хешами и подписями.

И как ты его собрался проверять? И будешь ли? И все ли будут?

Проверять будет система установки. Во flatpak уже есть проверка GPG подписей, в snap тоже. В андроиде это используется уже давно, и там проблем с подменой пакетов как-то нет.

а о проприетарщине которая на таких пакетах будет просто-таки цвести, даже говорить не хочется.

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

flyshoot: Я считаю, что переводить всё на snap это бред. В мире открытого софта они не нужны, не хватало на каждую программку тащить все либы.

Все не надо. Но вот тот же Firefox, с ним особой разнцы нет, как поставлять, весить он будет примерно одинаково. Или более реальный пример с LibreOffice собранный под flatpak.

Esteban_Garcia
()
Ответ на: ISO-ляция от Camel

Изоляция ресурсов системы от доступа в приложениях. Snap и Flatpak эту проблему решают. А причем тут Guix в этой теме?

Esteban_Garcia
()
Ответ на: комментарий от Esteban_Garcia

Все не надо. Но вот тот же Firefox, с ним особой разнцы нет, как поставлять, весить он будет примерно одинаково. Или более реальный пример с LibreOffice собранный под flatpak.

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

flyshoot
()
Ответ на: комментарий от Esteban_Garcia

Ответ нечитателю

Изоляция ресурсов системы от доступа в приложениях. Snap и Flatpak эту проблему решают. А причем тут Guix в этой теме?

А вы пробовали читать? Guix это ответ на ад зависимостей. Возможно не окончательный, но близкий к тому. В плане борьбы с dephell guix гораздо лучше чем snap и flatpak, потому что в последних библиотеки таскаются вместе с пакетом, по сути это аналог статического связывания. Если в snap положить, скажем, QtCreator и Skype, и оба используют Qt-4.2.1, то в каждом пакете будет своя копия Qt-4.2.1. В GuixSD в аналогичной ситуации будет только одна копия Qt-4.2.1.

Camel ★★★★★
()
Ответ на: Ответ нечитателю от Camel

Да это я знаю. Но ты пишешь что snap ненужен. А пока выходит что как раз guix не готов.

Ответ нечитателю

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

В плане борьбы с dephell guix гораздо лучше чем snap и flatpak, потому что в последних библиотеки таскаются вместе с пакетом.

Во flatpak только часть. И если они часто повторяются, их можно выносить в отдельные общие пакеты. Я знаю как решена проблема зависимостей в NixOS, и если бы в Guix добавили к этому ещё изоляцию, это было бы хорошим решением. Но пока нет.

Esteban_Garcia
()
Ответ на: комментарий от Esteban_Garcia

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

flyshoot
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.