snap & flatpack — трагедия общин

    Лонгрид варнинг: вас предупредили, много букв.


    Уже давно ведётся разработка формата дистрибуции приложений, которые были "свободны" от общесистемных зависимостей. Ubuntu очень, очень активно продвигает свой snap, gnome — flatpack. Оба обещают рай и свободу от rpm/deb. Давайте же подумаем про проблему, которую они хотят решить, и цену, которую они просят за решение этой проблемы.


    Библиотеки


    Никто в современном мире не может написать приложение, не используя чужого кода. Причин несколько:


    • Многие библиотеки настолько серьёзны, что написать их функционал с нуля — это Грандиозная Задача. Примеры — поддержка unicode, рендеринга шрифтов, математики.
    • Другие библиотеки предлагают довольно скромный набор функций, но написанных так хорошо, что написать хотя бы так хорошо же, почти невозможно. Стандартные библиотеки языков программирования, различные реализации libc, etc.
    • Стоимость работы по взаимодействию с чужим кодом (чему посвящён этот раздел) чаще всего оказывается ниже, чем цена сопровождения своего кода. Плотность "багов на строк кода" с большой вероятностью будет сравнима, а "свои баги" надо самому же и ловить. Чужие (популярные) библиотеки имеют вероятность быть отлажены и исправлены чужими же руками.

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


    Пример для осознания масштаба драмы: допустим, ваше приложение принимает на вход две строки как опциональные аргументы и выводит их вместе, после нормализации. Если вы пишите индустриальное приложение (приложение, которое похоже на "настоящее"), то:


    • Вам надо парсер командной строки
    • Который должен принимать юникод
    • И, возможно, давать пользователю подсказку, что он опечатался в имени аргумента
    • Что требует фонетического сравнения
    • И, возможно, регулярных выражений
    • В общем случае вам придётся поддерживать не только юникод, но и другие локали, что требует библиотеки поддержи локалей и ВСЁ то, что люди придумали в контексте локалей.
    • Конкатенация строк с нормализацией — ещё одно применение отдельной библиотеки юникода, сами вы такое не реализуете.
    • Вывод на экран (справки по командной строке, вашего результата) с большой вероятностью потребует поддержки ncurses — библиотеки, поддерживающей разные терминалы (можно обойтись текстовым режимом, но приложения часто используют цветовые возможности).
    • Тесты подразумевают использование тестового фреймворка, возможно, библиотеки для моков.

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


    Как вы думаете, сколько библиотек нужно, чтобы гарантированно отработать curl http(s)://...? Много. Вы будете использовать одну, но зависимости ваших зависимостей — это ваши зависимости.


    Copypaste & vendoring VS dynamic linking


    При том, что использование библиотек неизбежно, само использование может различаться по реализации. Обратите внимание, у нас появилось два важных слова "использование" и "реализация использования". Что значит "использование"? В самом грубом виде — возможность вызвать код библиотеки, когда это нужно. А вот реализации этого:


    • Мы можем скопировать код, который делает нужные нам операции. В виде куска кода (copy&paste), как отдельный модуль в языке программирования (объектный файл для компилируемых языков), либо как отдельный модуль (для интерпретируемых языков). Где-то тут же рядом идёт и "скопировать исходный файл библиотеки к себе в каталог с приложением". Какие проблемы это создаёт? Главная, основная проблема — мы теряем (навсегда) связь с оригиналом. Даже если автор оригинальной библиотеки исправит ошибку, мы не будем об этом знать. Более того, если мы просто скопировали код, то следующий человек, работающей над программой, даже не сможет узнать, что этот код "чужой". Фактически, мы срезали путь в вопросе "написать с нуля" и взяли чужое. Однако, мы срезали лишь кусочек, потому что если в этом коде будут ошибки (а они там не будут, они там есть), то их исправление потребует от исправляющего пойти и разобраться в сути проблемы до самого низа. Даже если разбирательство потребует чтения нескольких сотен тысяч строк исходного кода и сотен RFC (а так же комментариев о том, что реализации отличаются от RFC), другого пути у нас нет. Ключевой ошибкой в этом месте является то, что мы потеряли информацию о том, что это код чужой. Наличие комментариев в файле может помочь, но потребует деятельного и глубокого участия человека, потому что если мы напишем в комментарии "взято из libfoobar, src/lib/foo.c версии 364a51577f3782dbf8e5d2482ab941980357c492", то кому-то надо будет посмотреть, где libfoobar находится, какая там версия и что поменялось с предыдущей версии". Чтобы упростить этот процесс, нам нужна машиночитаемая метаинформация.
    • Если мы сопровождаем "чужой код" метаинформацией и используем программы для управления этим кодом (вместо копипаста), то это называется вендоринг, т.е. контролируемое включение чужого кода в свой код. Технически вендоринг может происходить на этапе исходного текста, линковки объектов в исполняемый файл, импорта модулей (в интерпретаторах) из состава приложения, или, даже, динамической линковки с "своей" версией библиотеки (об этом чуть позже).
    • Наконец, мы можем осуществлять динамическую линковку на этапе запуска приложения. Для компилируемых языков это обычные so'шки, для интерпретируемых — наличие модуля в общесистемном импорте. Если его могут импортировать несколько приложений, это это общая библиотека. Если приложение "принесло свой модуль", то библиотека "своя", даже если её интерфейс подразумевает "общую библиотеку". Например, если приложение использует "свою" версию so'шки, вне зависимости от того, отличается ли она от общей, или нет, то это вендоринг. А если импортируется системная, то это общая библиотека (shared library).

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


    • Экономию памяти (оперативной и на диске) для so'шек, уменьшение размеров установленной системы. Чем больше приложений использует одну и ту же so'шку, тем большая экономия памяти. Соответственно, обратно, чем больше "своих" библиотек приносит приложение, тем оно "жирнее".
    • Спор о том, кто следит за уязвимостями — система (предоставляя обновления библиотеки) или автор приложения (вовремя обновляя его).
    • Разрешение конфликта зависимостей (вендоринг решает эту проблему так как общие библиотеки требуют внимания и аккуратности от всех участников процесса, иногда создавая непреодолимые трудности), тот самый легендарный dll hell.
    • Новые версии библиотек — либо они появляются по пожеланию авторов приложения, либо по решению авторов дистрибутива. В одном случае автор может принести нужную ему новую фичу, в другом случае, дистрибутив может принести улучшение существующего приложения за счёт поддержки чего-то нового в библиотеке (например, hidpi экраны начали правильно работать во всех приложениях, динамически линкующиеся с библиотеками qt/gtk).

    Все эти вопросы многократно разбирались ранее. Вместо этого я хочу сфокусироваться на социальных аспектах водораздела "всё своё" и "всё общее".


    Социальный контракт и власть мейнтейнеров


    Общие библиотеки — это кооперация, власть и ответственность. Люди, определяющие какие общие библиотеки доступны в операционной системе диктуют производителям ПО какие общие библиотеки они могут использовать. Многое ПО может использовать разные библиотеки, и указание на то, какую точно версию нужно использовать остаётся на усмотрение линкера (для компилируемых языков) или обработчика файла зависимостей (pip, bundler, etc). Если все приложения в дистрибутиве собраны с одинаковыми требованиями, то наступает благодать: если в какой-то библиотеке есть ошибка, мейнтейнер этой библиотеки обновляет версию, и исправление автоматически применяется ко всем приложениям. Даже если приложение релизится раз в два года, фикс в условном openssl будет применён в течение недели. Если в конкретной ОС принято решение об отказе от старого протокола, каких-то модификациях (например, интерфейса пользователя), то эти изменения так же применятся для всех. Look&feel в общем стиле, который (быть может) может быть изменён пользователем один раз и для всех. Это ли не благодать?


    Власть и борьба за неё


    … Эта благодать требует, чтобы все приложения могли работать с выбранной версией библиотеки. А что, если какое-то приложение хочет очень-очень новую функцию из библиотеки, а все остальные приложения не хотят его использовать, потому что это, допустим, не LTS-релиз библиотеки, т.е. она не достаточно стабильна? А ведь дистрибутив может отказываться переходить на новые версии "из принципа", ибо мы обещали пользователям только багфиксы, а новые версии — только в следующей версии ОС, которая (вроде бы), выйдет через пол-года. И это вызывает сопротивление со стороны авторов приложения. Да кто вы такие, чтобы мне рассказывать с какими версиями мне работать? Я автор, я так вижу. Мне нужна libfoobar 3.14-pre2 или старше, а не ваша древняя унылая libfoobar 3.10.


    … В этот момент автор просто пишет в требованиях к приложению libfoobar>=3.14-pre2. Мейнтейнер берёт и патчит требование, плюс удаляет код, который от этой библиотеки зависел. Может быть. Или просто отказывается принимать новую версию с такой зависимостью, пока эта зависимость (libfoobar 3.16) не окажется в новой версии дистрибутива.


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


    То же самое происходит в ситуации, когда есть несколько дистрибутивов, некоторые новее, некоторые старее. Поддерживать более старые дистрибутивы, тестировать с разными библиотеками — это сложно. Так что вариант "отгрузить со своими библиотеками" возникает почти сразу же.


    Трагедия общин


    Это создаёт предпосылки для возникновения трагедии общин:


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

    При этом, чем больше приложений идут со своими библиотеками, тем меньше польза от системных библиотек. Помните про "благодать"? Чем менее она "всеобщая", тем меньше она благодать. Если общая библиотека используется 5 разными приложениями из 995 других, то польза этой библиотеки — 0.5%. Обидно, да. Причём, это задевает всех пользователей, даже тех, кто, в принципе, не имеет острой потребности в новой фиче — но если приложение доступно только в вендоринговом виде, то у пользователя нет вариантов.


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


    Вот именно тут мы и приходим к спору rpm/deb VS snap/flatpack


    Свобода или рабство?


    Ubuntu очень, очень сильно ратует за snap'ы. GNOME уверен, что будущее за flatpack'ами. Каждый из них — это фреймворк для глубоко индивидуалистических приложений. Всякие electron'ы, у которых с собой не только подкапотный браузер, но и подкапотная операционная система. Свой libc, свой libssl, свои регэкспы, свои ncurses, etc. Общим выступает только ядро, т.е. по сути это тот же контейнеризированное приложение, но для десктопа. Дай каждому своё ядро, и получится appliance в форме виртуалки. Допишите метаданные — и получится контейнер Docker'а.


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


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


    Политика


    Ubuntu зависит от Debian куда больше, чем хотелось бы Canonical (компания, выпускающая Ubuntu). Ценность Ubuntu — не в усилиях мейнтейнеров Ubuntu, а в огромном репозитории ПО, идущем из Debian в форме, когда все приложения хорошо работают друг с другом усилиями тысяч мейнтейнеров отдельных пакетов, являющихся "владельцами" дистрибутива Debian. Canonical добавляет поверх этого свои усилия по полировке результата — и за это любима некоторыми. Добавим чуть-чуть маркетинга и фиксированный lifecycle, который по нраву энтерпрайзу, и получается отличный продукт.


    … Который зависит от воли тысяч добровольцев где-то там.


    Что совершенно не устраивает почти любую коммерческую компанию. Как разорвать эту зависимость? Правильно, сделав свой комплект приложений. Чем больше своих приложений, тем меньше "взбрыки" в апстриме будут задевать компанию. Достаточно вспомнить историю, когда голосование в Дебиан по поводу systemd похоронило upstart, разрабатывавшийся Canonical.


    Но мейнтенить несколько десятков тысяч приложений, некоторые из которых — свой космос (erlang, go, perl, python, R, julia, etc), а некоторые — монстры в соответствующей предметной области (браузеры, emacs, tex, pacemaker, etc) — это неподъёмная работа. Не зря это тысячи мейнтейнеров.


    … И тут есть идея. А, пусть, авторы приложений сами мейнтейнят приложения. Выдадим каждому по песочнице, пусть копаются. Авторы получают свободу, Canonical — приложения, которые не зависят от Debian и которые хоть кто-то мейнтейнит бесплатно. Пользователи получают...


    … приложения, которые жирные, тяжёлые, у которых обновления нерегулярные и которые с лёгкостью могут держать уязвимости неисправленными годами… Зато некоторые из них shiny new.


    И что дальше?


    Представьте себе мир, в котором все всё везут с собой… Знаете как это выглядит? Посмотрите на chefsdk. Он отгружает с собой внутри свою postgresql (со своими зависимостями), свой rabbitmq (который зависит от своего erlang'а), плюс chef-server тоже на erlang'е, так что у него тоже свой erlang. Внезапно, у нас внутри одного приложения два erlang'а и несколько десятков копий одних и тех же библиотек, чуть-чуть различающихся по версии. Это не финальный вариант, т.к. внутри между компонентами всё-таки есть общие библиотеки. Если мы их распилим дальше, то получится несколько десятков копий openssl и libc на одно приложение. Даже не в финальном виде это выглядит как 600Мб на одно приложение.


    … Что, конечно, кратно больше, чем среднее приложение на electron.… И в 12 раз больше, чем целый mariadb сервер (целая СУБД!) или krita или gimp (огромные приложения для работы с графикой).


    А если каждый будет такой? У меня на компьютере установлено 2000 пакетов (не считая -dev и lib)… 2000*300 = 600Гб (За средний размер получившегося я взял половину от chefsdk, т.к. не все настолько ужасны по зависимостям). Сейчас они занимают около 7Гб (включая ресурсы, вроде документации, текстур редакторов, шаблонов CAD-программ и т.д.).


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


    Я понимаю, зачем Canonical пушит snap. Я это понимаю, и не одобряю.

    Поделиться публикацией

    Похожие публикации

    Комментарии 131

      +1

      А где остальная часть статьи?

        +1
        Очень специальная обработка тега cut в markdown-статье. Поправил.
        +8
        Как длинно написано слово «костыли».
          +1
          А еще у привычных менеджеров пакетов (вроде apt) есть фатальный недостаток
            +1
            Фатальный недостаток — понятно. Если бы они решили написать более хороший пакетный менеджер — я бы им только порадовался. К тому же dpkg — фантастические претензии — очень много тьюринг-полных (баш!) мест вместо декларативности. Но подход, который они выбрали — это путь индивидуализма.

            Почему меня это вообще волнует (vs «расцветай сто цветов»)? Потому что ubuntu, к сожалению, почти индустриальный стандарт для инстансов и автопровиза. Их действия могут сильно осложнить мою будущую профессиональную деятельность.
            +1

            flatpak в плане зависимостей спроектирован сделан лучше snap. Емнип, у snap все зависимости в одном пакете, у flatpak от каких-то пакетов (рантайм например) может зависеть несколько пакетов, причем может быть установлено несколько версий одного и того же рантайма.


            Если это превратится в 600Гб

            Не защищаю flatpak. Он, как и snap, со временем на системе все равно превращается в огромную помойку, пусть и не так быстро в теории.

              0
              Кстати, это очень интересный вопрос. В принципе, весь дистрибутив должен быть на одной версии. Иногда смена версии — очень мажорная и breaking change, которые не исправить за разумные усилия. В обычных дистрибутивах это делают поддержкой нескольких версий, плюс semantic version для so'шек. И это зло, с которым мейнтейнеры должны бороться.

              flatpak, наличием зависимостей, делает шаг в правильном направлении, но в сама идеология «от чего хочешь, от того и завись» ведёт к пинингу версий (т.к. меньше вероятность поломки приложения), и разрушает «общее благо» во имя локальных улучшений.
                +1
                flatpak в плане зависимостей спроектирован сделан лучше snap. Емнип, у snap все зависимости в одном пакете, у flatpak от каких-то пакетов (рантайм например) может зависеть несколько пакетов, причем может быть установлено несколько версий одного и того же рантайма.


                Неправда же. Вы, видимо, документацию snap поленились прочесть.

                В обоих случаях (что snap, что flatpack) мы имеем слои. Т.е. предположим рантайм -> гном -> что-то приложение-специфическое. Любой из слоев вы можете ставить хоть 100500 различных версий, при этом приложение будет просить слой A определенной версии, который будет просить рантайм определенной версии, т.е. у каждого слоя есть «предок», который является его зависимостью.

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

                  Допускаю свою ошибку.
                  Документацию действительно не читал, использовал исключительно как пользователь.
                  Просто в flatpak мне эта информация (о слоях) на глаза попалась в процессе использования, в snap — нет.

                    0
                    Ровно такие же слои, только они в терминологии snap base fs называются. И рядом еще parts — некоторые сущности, которые вы можете «монтировать» поверх base.
                  +1

                  У флетпака есть большая проблема — он пытается заниматься не только упаковкой приложений, но ещё и их изоляцией. Причём в принудительном порядке. В итоге запаковать во флетпак какую-нибудь IDE, которой нужно стучаться к установленным в системе тулчейнам просто напросто невозможно. Ибо кому-то пришло в голову, что это "не нужно". У snap в этом плане есть специальный режим для тех, кому таки нужно.

                    +1
                    --filesystem=host
                      +2

                      Отлично, теперь запустите из запакованной во Flatpak IDE какой-нибудь GCC с хоста. Увидите, как он радостно очумевает от того что лежит он теперь в /var/run/host.

                        0
                        Почему он вдруг начнёт очумевать? GCC отлично переносится из одного места в другое. Начиная с версии 4.4, если мне не изменяет память.
                    0
                    Вообще-то Snap подерживает зависимости. Так, после того, как KDE отделил KDE Frameworks в отдельный пакет, размер других Snap-пакетов сильно уменьшился. Подробнее: vasilisc.com/kde-app-framework-snap

                    Встроить библиотеки в один пакет или зависеть от других пакетов — решение разработчика.
                    +15
                    Коренная проблема общего счастья здесь одна — это dll hell, из-за которого LTS дистрибутив отказывается принимать новые версии библиотек, а разработчик приложения вынужден тащить с собой свою локальную версию библиотеки.
                    Но проблема может быть решена под другим углом — нужно поменять парадигму понимания библиотеки, сейчас все понимают библиотеку как одну единую сущность, с которой обязаны линковаться все кто её используют. Для решения проблемы dll hell необходимо принять парадигму, что библиотека — это не одна сущность, а целый набор мало отличающихся друг от друга сущностей (разных версий библиотеки), которые должны без проблем сосуществовать друг с другом в рамках общей системы, а с какой именно версией линковаться — решает каждое отдельное приложение. Это позволит по зависимости легко и без проблем подтянуть в LTS дистрибутив новую нестабильную версию библиотеки, и использовать её будет только то приложение, которому нужна именно эта версия, все же остальные приложения в системе, продолжат использовать стабильную версию, на которую они рассчитаны.
                      +1
                      Если у вас вместо общей на 1000 пакетов библиотеки будет 30 версий библиотеки с средним количеством в 33 пакета, то польза от существования общей библиотеки упадёт в 30 раз, а стоимость maintanance дистрибутива — вырастет. Причём, не факт, что в 30 раз. Если кто-то зависит от openssl==1.0.1f, то запаковать такую версию — не проблема. Пофиксить heartbleed — если это поддерживаемая версия — то разумные усилия. А если нет — то неразумные. Мажорные несовместимости, когда библиотеки есть в двух версиях в дистрибутиве, обычно решают (поддержкой обоих версий). А вот ситуация «с какой именно версией линковаться — решает каждое отдельное приложение» — это как раз тот момент, когда разработчику хорошо, а дистрибутиву — плохо. Про эту проблему я писал в статье.

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

                        Можно ввести концепцию каналов.
                        Допустим, nightly, stable и very_old.
                        Найтли — последний коммит, у которого прошли тесты.
                        Стейбл — последний релиз.
                        very_old — (подставьте сюда LTS-политику дистрибутива).
                        И в зависимости от этого разработчик выбирает нужный канал.
                        С одной стороны, это в 3 раза больше места (на самом деле нет, т.к. жирные приложения все равно в одном экземпляре), но с другой — все более-менее довольны.

                        +2
                        А не перестанут ли авторы при этом обновлять зависимости? Поставил в зависимость версию 1 и работаешь с ней все время. А что вышла уже версия 2 и 3 — даже не в курсе. И что первая дырявая, как решето — тоже. Зачем следить за развитием библиотеки, если и старая работает?
                          +2

                          Многим авторам и сейчас ничто не мешает так делать. Или ставьте либу мохнатой версии — или крутитесь как хотите.

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

                              Подавляющее большинство программ в реальном мире (ну, знаете, там, где делаются журналы, варится сталь и сдаются отчёты в налоговую) — это «поделки на коленке». Которые кто-то сделал за условные 100 рублей (либо вообще по-знакомству). Да даже если и за 100000 рублей заказали у фрилансера!

                              Вот так же, как вы, если вам потребуется тумбочка или шкаф и вы будете делать их на заказ — так же и программы делаются. Один раз. Когда программа сдаётся — она отдаётся заказчику (хорошо если с исходниками, но частенько и без) и… всё. Совсем всё. И там некому следить за тем, «не ломается ли совместимость по мере обновления пакетов». Просто некому. Если у некоторого количества людей эти поделки ломаются при переходе, скажем, на Windows 1810 — то они изобретают способы этот апдейт не ставить. А если их набирается слишком много — Microsoft (то есть разработчик операционки, а не кто-либо ещё!) думает как их чинить.

                              И вот пока Linux не поддерживает подобный подход — шансов на десктопе у него не будет. Пока на десктопе были только соперники, не способные Linux убить (Windows и MacOS) — проблема не была особенно уж острой. Но если туда придёт ChromeOS или, ещё хлеще, Android — то всё. Вот совсем всё. Смысла в Ubuntu больше не будет.

                              Отсюда и все эти flatpak'и и snap'ы. А вовсе не из желания угодить разработчикам, которые могут реагировать на «жалобы пользователей». Не об них речь, совсем не об них.
                                0
                                И вот пока Linux не поддерживает подобный подход — шансов на десктопе у него не будет.
                                Поддерживает, конечно. Вы описываете портативную программу, для этого есть, например, AppImage, или просто статическая компиляция для случаев попроще. Snap и Flatpak избыточны для необновляемых программ.
                                Linux apps that run anywhere

                                «As a user, I want to download an application from the original author, and run it on my Linux desktop system just like I would do with a Windows or Mac application.»
                                «As an application author, I want to provide packages for Linux desktop systems, without the need to get it 'into' a distribution and without having to build for gazillions of different distributions.»
                                appimage.org
                                  0
                                  AppImage не содержит никаких средств интеграции с десктопом. Ни банально добавить приложение в меню запуска, ни зарегистрировать его как обработчик его собственных файлов, etc.

                                  Так-то можно просто статический бинарник собрать — и всё.
                                    0
                                    То-то любое графическое AppImage-приложение при запуске спрашивает, добавить ли иконку в меню, а для автоматического добавления сразу после скачивания (еще до запуска) есть специальный демон.
                                      0
                                      напоминает историю, как андроид и ios пиктограммы в лончере для запуска приложений ищут и раскладывают.
                                        0
                                        Тогда непонятно зачем нужны три несовместимые технологии, делающие, фактически, одно и то же…
                                          +1

                                          Древняя традиция.

                                            0

                                            велосипед, автомобиль, мотоцикл делают одно и то же?

                              +1
                              Такая фигня используется в Windows ru.wikipedia.org/wiki/Side-by-side_assembly
                                –1
                                Очень не законченная и корявая реализация концепции.
                                +1
                                Что, если я завижу от libfoo-0.1.2 и libbar, а libbar зависит от libfoo-0.1.1?
                                  0
                                  типичная проблема зависимостей в python-окружении (да и вендора в golang), которая пока не имеет общего решения.
                                  rpm-based дистрибутивы хотя бы минимум три варианта решения предлагают (не ставим 0.1.2, ставим 0.1.2 и ломаем зависимости, или тащим все подряд)…
                                    +1
                                    Тут мог бы помочь semver пополам со строгой типизацией (где несовместимое изменение API ломает сигнатуры функций по построению, всегда, даже для семантических изменений) плюс определённые допущения на то, что могут или не могут делать библиотеки (например, отсутствие статических данных). Может, даже получится показать, что либо можно втянуть обе версии библиотеки в один процесс без всяких проблем.

                                    Но это так, мысли вслух.
                                    0
                                    В целом система библиотек в линукс позволяет подобные зависимости.

                                    Если это отличия в минорных версиях, а библиотеки соблюдают соглашения semver и замена минорной версии ничего не рушит, то SONAME у обоих библиотек будет одинаковым — например, libfoo-0.1.so (минорная версия не включена в имя), и оба пакета просто слинкуются с последней версией либы (файл libfoo-0.1.so будет симлинком на libfoo-0.1.2.so).

                                    Если это совсем разные версии, так что линковка с libfoo-0.1.2 вместо libfoo-0.1.1 будет ломать продукт, то по соглашению они должны иметь разный SONAME, и тогда программа слинкуется с обеими версиями библиотеки.
                                      0
                                      Если это совсем разные версии, так что линковка с libfoo-0.1.2 вместо libfoo-0.1.1 будет ломать продукт, то по соглашению они должны иметь разный SONAME, и тогда программа слинкуется с обеими версиями библиотеки.
                                      После чего всё развалится, потому что никто не указывается версии для символов — а поиск их в ELF не учитывает имени библиотеки.
                                      +1
                                      Это вопрос о детализации версий в списке зависимостей. Если детализация идёт до 2-й цифры версии, скажем libbar зависит от libfoo-0.1.*, то обновления библиотеки libfoo-0.1.1 до версии libfoo-0.1.2 должны строго соблюдать совместимость ABI как отче нашЪ, тогда libbar при загрузке в память процесса слинкуется с libfoo-0.1.2 и даже не заметит разницы. Если же ломается ABI при обновлении, то это уже должна быть версия libfoo-0.2.0, а не libfoo-0.1.2
                                      Если же говорить о dll hell в рамках одного процесса в памяти, то это уже другая, гораздо более сложная проблема, с которой я тоже сталкивался. Можно подумать, что это вина автора приложения, который не проследил консистентность всего дерева зависимостей приложения, но как оказывется, дерево зависимостей приложения может поломаться уже после успешного создания приложения и внедрения его в эксплуатацию: какая то из библиотек, от которых зависит приложение обновилась и изменила свои зависимости на более свежие версии, которые не совместимы с зависимостями самого приложения или других библиотек, от которых зависит приложение.
                                      Именно по этому я ратую за переосмысление вообще всей концепции разделяемых библиотек, от низа до верха. Во первых менеджер пакетов должен нормально и качественно обустраивать сосуществование разных версий библиотеки в системе (то как это делается сейчас путём включения номера версии в имя пакета, явно указывает на костыльность решения), во вторых сама библиотека должна осознавать, что несколько версий её же может присутствовать в системе (и даже более, могут работать в программах одновременно) и должна это учитывать, в третьих ld_linker при запуске программы должен иметь в себе достаточно умный solver зависимостей, который должен уметь выстраивать внутренне не противоречивое дерево зависимостей программы, подбирая версии библиотек так, что бы не было конфликтов, даже за счёт включения более старых версий библиотек в дерево для обеспечения совместимости, иначе программа просто не запустится. Так-же и сам менеджер пакетов должен иметь внутри себя подобный solver зависимостей, для обеспечения присутствия в системе всех нужных для запуска программ библиотек, даже более старых тогда когда это требуется для формирования непротиворечивых деревьев зависимостей во время запуска программ. Ведь dll hell в рамках одной программы это явно не заложенное изначально автором программы состояние, ведь когда он создавал приложение, оно работало и не было ни какого dll hell, который приползает потом, тихо и неожиданно.
                                      Потом уже можно и поразмыслить над возможностью одновременной загрузки разных версий библиотеки в память процесса и о том как этого достичь…
                                        0

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

                                          0
                                          А разве соблюдение непротиворечивости репозиториев дистрибутивов мейнтейнерами не есть задача очень высокой трудоёмкости? Разве это приемлемо, когда пользователю запрещается использовать более свежее ПО, а авторам программ для обхода этого запрета приходится идти по пути windows, когда любое ПО — это гигабайты и гигабайты дистрибутивов, десятки гигабайт впустую занимаются на диске, только из-за того, что каждая программа тащит с собой всё своё обособленное дерево зависимостей? Но плачут, колются, но продолжают есть кактус, просто потому что и так худо-бедно, но работает. И ни кто в общем то не стремится решать этот вопрос раз и на всегда. А поскольку проблема фундаментальна по своей природе, то и решать её нужно не спеша и основательно.
                                          На мой взгляд здесь нет ни чего неразрешимого — достаточно один раз инвестировать усилия в реформу системы создания ПО, и потом будет очень не малый профит. А за обеспечение устойчивости, что бы ни чего не поломалось, должны отвечать беспристрастные, точные и выверенные автоматические инструменты, которые будут постоянно мониторить и тестировать репозитории, и не допускать в репозитории ПО дистрибутивов пакеты, ломающие существующие зависимости. DevOps и автоматизация рутинных задач рулит.
                                          Но мешает данному прогрессу закостенелость устоявшейся системы разработки ПО, нежелание библиотек-старожилов реформироваться, и не желание всего сообщества пересматривать и менять подходы к своей работе, а для этих реформ нужна всеобщая кооперация, которая должна начинаться как раз с основ — с титанов держащих на своих плечах все дистрибутивы — с основных общесистемных библиотек и программ, вроде glibc и того же линкера, обеспечивающего запуск программ. А они то как раз более всего сопротивляются каким либо серьёзным изменениям.
                                            +1
                                            В литературоведении XX—XXI веков утопии, как и антиутопии, рассматриваются в ряду жанров научной фантастики.

                                            Взято отсюда.
                                              0
                                              Вы очень много оценки добавляете в процесс.

                                              1. Пользователю ничего не запрещается. Произвольные репозитории и deb'ки — пожалуйста.
                                              2. В замен на «старые версии» пользователь получает систему, которая работает, даже после апдейтов. Если в системе появляются куски, которые что-то себе на уме не так как все, то последствий от взаимодействия с соседями никто не понимает (в т.ч. пользователь).
                                              3. Любые усилия по реформе разработки ПО натыкаются на эгалитарный анархизм. Невозможно заставить людей на erlang писать так, как пишут на питоне. Сейчас в дистрибутиве разные модели работы с разными экосистемами. У си своя модель (lib*-dev и lib-*пакеты), у python своя (модули в dist-packages), у ruby своя (version-dependent installation), у go своя (только -dev-* пакеты), у node своя, у java своя и т.д. Попытка всех их выравнять под одну гребёнку ничего хорошего не сделает, потому что за каждой из экосистем миллиарды строк кода. Можно лишь искать пути сосуществования, чем и занимается dpkg. Его принцип — каждый собирает как может, а мы потом пакуем и патчим если надо результат.

                                              То есть тут именно сосуществование — ни мейнтейнеры не могут объяснить ВСЕМ как надо писать, ни конкретные экосистемы не могут заставить мейнтейнеров делать как им сказали (условно, пакеты собираются в отсутствие сети, так что go-way с хождением на github запрещён, так же как и pbr-way с подглядыванием в собственный git за версией — нет гита, есть только сырец).

                                              Важно, что у каждой из этих экосистем есть причины, почему они так делают, и приходить ко всем с одинаковыми лекалами — это пытаться «всех построить». Пошлют, да и только.
                                                0
                                                Ну, как ни крути, без оценки не обойтись. Оценка нужна, что бы понимать что к чему и почему на самом деле. Причём в моей оценке нет унижений и оскорблений, просто констатация фактов, как они есть.
                                                1. Пользователю не запрещается, но подключение стороннего репозитория или установка сторонней deb-ки, может поломать систему, причём так, что откатить изменения совсем не просто, придётся попотеть, а обычному юзеру без продвинутых скиллов по администрированию линукса — проблема вообще не разрешима. Сам не раз боролся с системой deb-пакетов по данному поводу — удовольствие не из приятных (
                                                2. Иногда пользователю совершенно наплевать на всю операционную систему и всех мейнтейнеров дистрибутива, обеспечивающих «рабочую систему», если он не может запустить софт, ради которого он вообще купил компьютер. Для него это уже нерабочая система. Грустно, но факт, что сложность возни с установкой софта под линуксы — одно из главных препятствий для его распространения как основной ОС у обычных пользователей. Да, не возникает проблем с установкой софта, который уже есть в официальном репозитории, но в 90%-100% случаев пользователю нужно ещё что-то, чего в репозитории нет. Да и производителям софта, подстраиваться под весь этот зоопарк совсем не хочется, и их можно понять.
                                                3. В данном случае речь идёт только об основе операционной системы вообще, на самых низах, т.е. об экосистеме C-программ. Другие экосистемы более высокого уровня, такие как erlang, python, ruby, node, java и т.д., могут решать свои проблемы так как им интересно. Хотя проблема зависимостей она вообще то общая и у всех одинаковая. И здесь лишь вопрос о возможности прийти к консенсусу, если говорить о всеобщем принятии стандарта управления зависимостями. Но, я думаю если основа, которая состоит из C-программ, сможет сформировать подход, который докажет свою работоспособность и эффективность, то другие экосистемы наверняка начнут перенимать этот или очень похожий подход. Хотя как раз экосистема C-программ, так уж сложилось исторически — наиболее разрозненная, к сожалению.
                                                А в общем да, вы правы, проблема в человеческой психологии, и эголитарном анархизме как её проявлении. Не доросло ещё человечество на данной планете до осознания общего блага и его ценности. Но это тема для уже совсем другого разговора.
                                                  0
                                                  2 — понятно, что конкретному пользователю тут-и-сейчас нужно-таки-поставить. Но его интересами жертвуют ради интереса остальных пользователей, у которых ровно и хорошо. В принципе, firejail умеет запускать всякую фигню в сэндбоксе, так что даже make install ничего не попортит.

                                                  3. К сожалению, perl и к счастью python, уже давно системная часть дистрибутива. Например, cinnamon использует очень много на питоне — а cinnamon — это window manager в том числе.
                                            0
                                            Потом уже можно и поразмыслить над возможностью одновременной загрузки разных версий библиотеки в память процесса и о том как этого достичь…

                                            В общем случае, например, никак. Статические данные, все дела.


                                            Да что там библиотеки, у меня вот на днях был замечательнейший пример. Есть в C++17 такая новая штука, как std::any. И там есть std::any_cast, который по стандарту должен позволять вытаскивать лежащий в std::any объект, если его type_info совпадает с type_info для шаблонного параметра в std::any_cast.


                                            Ну, написал я соответствующий код, скомпилировал, и ничего не работает. Получаю экзепшон. Ну, выковыриваю руками из any тамошний type_info, сверяю с type_info для типа, который запрашиваю — true, совпадают. Что за хрень?


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


                                            Лезу в libc++, там всё сделано как надо. Но, увы, по очевидным причинам это не вариант.


                                            Меняю std::any на boost::any, где тоже всё сделано правильно. Всё работает.


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


                                            В общем, такие дела. Гнутый софт, собранный гнутыми инструментами в рамках гнутой экосистемы, толком не работает, а у нас тут ожидания какие-то.

                                          +2

                                          Я вот тоже думал о таком способе решения dll hell в линухе, и как же хорошо придумали веб-разработчики со своими composer и npm, а недавно столкнулся с этим самым dll hell уже внутри приложения, которое мне пришлось поддерживать и дорабатывать.


                                          Представьте, что вам достался legacy-код, который вы не понимаете требует стороннюю библиотеку libfoofoo-1, и от вас требуется добавить некую фичу, которая уже реализована в соседнем проекте с помощью опять же сторонней библиотеки libbarbar-2, нужно всего-то копипастнуть немного кода из проекта коллеги, и тут оказывается, что libbarbar-2 тянет за собой libfoofoo-3, которая не совместима со своей первой версией, и вот ваше приложение зависит от двух взаимоисключающих версий чужой библиотеки, а казалось, что работы там всего на полчаса...

                                            0
                                            Буквально вчера подобным страдал.
                                            Плюнул, и со словами «фтопку бинарники», скопипастил весь зависимый код (тем более что мне надо была только одна функциональность). Поставил в комментариях — откуда этот кусок выдран (линк на коммит в гитхабе) и всё.

                                            (но это во мне еще жива память, как был я работал на проекте со своим самописным стдлиб/стдио и правками в принтф. После которого, выдрать кусок кода из либы, раз уж простая линковка не работает, — занятие на полчасика)
                                              0
                                              Заметьте, что в Windows эта проблема давным-давно решена. И даже в Linux есть решение. Вот только разработчики библиотек его не используют…

                                              Отчасти потому, что до появления flatpak и snap упор был на полную пересборку всего и вся при любых, самых минорных изменениях и этого просто не требовалось…
                                                0
                                                Заметьте, что в Windows эта проблема давным-давно решена.


                                                Заметьте, что это не совсем правда.
                                                  0
                                                  Вышеописанный сценарий в Windows не работает только если разработчики libfoofoo приложили специальные усилия, чтобы не позволить двум версиям нормально жить в одном процессе.

                                                  В Linux, наоборот, по-умолчанию две библиотеки будут конфликтовать, а чтобы их «подружить» — нужны специальные усилия.

                                                  Это — довольно-таки принципиальная разница.
                                                    0
                                                    Вышеописанный сценарий в Windows не работает только если разработчики libfoofoo приложили специальные усилия, чтобы не позволить двум версиям нормально жить в одном процессе.


                                                    Ну да, там же магия внутри. Магия все решает. И, конечно, это не в Windows тот же VCRedist за собой целиком таскает всё, что крупнее калькулятора…
                                                      0
                                                      Как раз VCRedist всё таскают именно потому, что могут. В процессе могут быть несколько libc — потому каждый тащит «проверенную».

                                                      А в GNU/Linux — это невозможно
                                                        0
                                                        Как раз VCRedist всё таскают именно потому, что могут.


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

                                                        А в GNU/Linux — это невозможно


                                                        В GNU/Linux невозможно принести за собой нужную версию библиотеки? Давно? Это законодательный какой-то запрет?
                                              0
                                              А что будет с прозрачностью для пользователя?

                                              Хороший пример heartbleed. При нынешнем подходе — я обновляю openssl (либо удостоверяюсь, что на машине установлена версия пакета с устранённой уязвимостью), после чего я не беспокоюсь, что у меня есть какие-то проблемы с точки зрения безопасности, относительно этой уязвимости. При подходе описанном вами я просто буду знать, что какие-то из приложений возможно и перестали быть уязвимы.
                                                0
                                                Такие старые и уже устоявшиеся библиотеки как openssl с очень редко меняющимся ABI, могут иметь очень слабо детализированную зависимость от версий, скажем приложения зависят только от major версии библиотеки, тогда вероятность того, что в системе окажется множество разных версий с уязвимостями, очень мала — скорее всего в системе будет только одна, регулярно обновляемая версия. А другие, более активно меняющиеся библиотеки, как например библиотеки графического интерфейса, будут иметь большую детализацию по версии. Ведь привязка зависимостей к версии на прямую зависит от частоты изменений ABI библиотеки — чем реже меняется ABI, тем меньше версий библиотеки в системе нужно.
                                                И кстати, и сейчас, почему вы обновив библиотеку с уязвимостями, перестаёте беспокоиться? Вдруг какое то приложение внутри себя несёт более старую версию библиотеки с уязвимостью и использует её, а не общесистемную.
                                                  0
                                                  Я перестаю беспокоиться. Накладки могут случаться (включая потерю всей энтропии в ssh), но это ошибки. Технический уровень maintanance в Дебиан достаточно высок, чтобы этого не случалось (как тенденции).
                                                    0
                                                    Такие старые и уже устоявшиеся библиотеки как openssl с очень редко меняющимся ABI
                                                    Как раз OpenSSL — это библиотека со страшным ABI, которое меняется а каждой минорной версии.

                                                    Дело в том, что там куча не-opaque структур, которые меняются от версии к версии, и с которыми напрямую работает приложения. Не то, что новая версия — смена опций компилятора или настроек библиотеки ABI ломает!

                                                    В некотором смысле OpenSSL — это квинтессенция «проклятья GNU/Linux»: так как изначально шёл рассчёт на то, что все всё будут собирать из исходников, то там — черезвычайно нестабильный ABI при весьма стабильном API.

                                                    Забавно, что GLIbC — полная противоположность: невероятно стабильный ABI (Windows отдыхает), но при этом — периодически ломается API.

                                                    Ведь привязка зависимостей к версии на прямую зависит от частоты изменений ABI библиотеки — чем реже меняется ABI, тем меньше версий библиотеки в системе нужно.
                                                    Вашими бы словами!.. к сожалению чуть не у половины версий библиотек версия ABI — вообще одна: 0.0.0. Означает: «да чё вы вообще пристали — некогда нам об API/ABI думать… Мы код кодим»
                                                    +1
                                                    При нынешнем подходе — я обновляю openssl (либо удостоверяюсь, что на машине установлена версия пакета с устранённой уязвимостью), после чего я не беспокоюсь, что у меня есть какие-то проблемы с точки зрения безопасности, относительно этой уязвимости.


                                                    И абсолютно зря не беспокоитесь, стоит признать.
                                                  +6
                                                  Как вы и написали, есть в данной ситуации два экстремума — максимально идеальное общее счастье (коммунизм, минимум свободы пользователю), и максимально жирный дистрибутив и минимум общего счастья (индивидуализм, максимум свободы пользователю).
                                                  Как и в экономике, первый вариант приносит максимум эффективности, но подобен золотой клетке и отсутствию свободы, а второй (как и капитализм) вариант приносит минимум общей эффективности, но приносит свободу.
                                                  Ни тот ни другой вариант не приемлем для пользователя, а значит нужно искать общий компромисс с максимальным локальным результатом для пользователя. И сосуществование в системе разных версий библиотеки — это как раз такой компромисс. Причём это не отменяет возможности обновлять отдельную версию библиотеки, но эти обновления должны строжайше соблюдать совместимость ABI и вносить в общем случае только security&bug fixes.
                                                  Этот вариант — наименьшее зло. И по такому пути пошли разработчики дистрибутива gentoo, они ввели в свой пакетный менеджер понятие слотов, и каждый пакет (теоретически) может быть установлен в системе в нескольких версиях одновременно в разные «слоты». Если у нас на 1000 пакетов будет 30 версий библиотеки (что мало вероятно, скорее всего будет значительно меньше), то это гораздо лучше варианта когда на 1000 пакетов та-же 1000 версий библиотеки. По опыту работы с gentoo могу сказать, что в системе одновременно сосуществует самый максимум 3-5 версий библиотеки, а в общем по системе редко когда больше одной.
                                                  Это приведёт к плавному и безболезненному введению в эксплуатацию новых версий библиотеки, и автоматическому удалению из системы старых версий, которые не нужны больше ни одному приложению в системе. Если какое либо приложение надолго застрянет со старой версией библиотеки, то в конечном итоге во всей системе использовать её будет только это приложение, и это проблемы этого приложения, а не всей системы в целом.
                                                  Вообще эта ситуация удивительна — на дворе уже давным-давно 21-й век, а эта фундаментальная проблема до сих пор не решена, и похоже не собирается решаться.
                                                    0
                                                    Я ж и говорю, по крупным, ломающим изменениям, мейнтейнят несколько версий. Уже. В существующих дистрибутивах.

                                                    Вот примеры:
                                                    libqt4
                                                    libqt5
                                                    libzmq5 (не знаю, есть ли 4)
                                                    libtidy5 vs libtidy-0.99-0

                                                    И т.д.

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

                                                    Мне кажется, что проблема управления зависимостями никогда не будет решена, поскольку она онтологическая. Лучшее, что мы можем получить — это инструмент, который поддерживает оба варианта (мы уже его имеем — те же so'шки), а дальше вопрос политики и уважения к окружающим.

                                                      +4
                                                      По моим эмпирическим наблюдениям, то как сейчас ведут в дистрибутивах сосуществование разных версий библиотеки — поверхностно и недостаточно. Оно и понятно, поскольку это делается вручную мейнтейнерами дистрибутивов, что очень трудозатратно, неэффективно, не надёжно и долго. Зачастую обновления библиотеки в рамках major версии библиотеки всё равно ломают ABI совместимость, из-за чего дистрибутивы предпочитают привязываться к более конкретной версии библиотеки и по прежнему запрещают обновление. Т.е. мы по прежнему имеем запреты на установку более свежих версий библиотеки. Сам на это не один раз натыкался.
                                                      Для полного-же решения данной проблемы необходимо создать инструменты для автоматического управления версиями библиотек в репозиториях дистрибутивов и на инсталляциях дистрибутивов, а детальные метаданные о зависимостях и совместимостях библиотек должны идти с апстрима библиотеки, в виде пригодном для обработки их автоматическими инструментами.
                                                      Именно на это нужно вести политику и давить на авторов библиотек, что бы они поставляли точные, детальные и не глючные метаданные, а не создавать всякие snap&flatpack.
                                                        +1
                                                        Да, в этом вопросе я с вами согласен. Но с метаинформацией есть проблема — если начинать уважать тот же requires.txt, то там очень много пакетов припинено на рандомной версии как "==". Политика debian'а даже игнорирует этот файл, оставляя точные зависимости на усмотрения мейнтейнера.
                                                          +1
                                                          Проблема в некачественных метаданных о библиотеке из апстрима. И именно на исправлении этой проблемы стоит фокусировать усилия — давить на автора библиотеки что бы он поставлял качественные метаданные, возвращать в апстрим исправления метаданных от мейнтейнеров дистрибутивов, вести пропаганду и политику о качественных и своевременно обновляемых метаданных и т.д.
                                                          Ведь в мире совместного использования библиотек, качественные метаданные о совместимостях&зависимостях являются неотъемлемым требованием к самой библиотеке и приложению её использующему в режиме must have, и бить по рукам за отсутствие/кривизну метаданных в апстриме.
                                                          Но как раз на метаданные все хорошенько так подзабили, считая это не важным делом, а по сему имеем что имеем (
                                                          0
                                                          Зачастую обновления библиотеки в рамках major версии библиотеки всё равно ломают ABI совместимость, из-за чего дистрибутивы предпочитают привязываться к более конкретной версии библиотеки и по прежнему запрещают обновление.

                                                          Если дело только в ABI, то сорс-бейзд-дистрибутивы это успешо решают. Preserved libs в той же генте, вот это всё.

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

                                                            Если же разработчики библиотек о совместимости таки думают, а не просто код пишут «как душа просит» — то дальше есть масса решений.
                                                              0

                                                              Почему сорс ничерта не решает для ABI-несовместимостей, устраняющихся простой пересборкой?

                                                                0
                                                                Потому что если всем на всё насрать, то рано или поздно у вас появятся два компонента, которые будут требовать внутри одной программы разных версий одной библиотеки. А так как всем на всё насрать, то символы у разных версий будут иметь одинаковые называния и никак не будут особо помечены.

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

                                                                  Вас не смущает, что описываемые вами проблемы немножко выходят за рамки той проблемы, о решении которой я говорю?

                                                                    +1
                                                                    Собственно, ваше решение с пересборкой не дает эффекта в случае линковки двух версий библиотеки внутри одной программы. Поэтому в частном случае оно работает, а в общем — некорректно.
                                                                      +1
                                                                      Оно и в частном случае не работает. Если в GTK меняется layout manager (как в стабильной версии GTK3 происходило не раз) и у вас два компонента, один из которых работает с GTK+ 3.0.10 включительно, а другой — только с 3.0.16 и новее, то вы можете хоть усобираться — но вся эта конструкция «не взлетит»
                                                        +1

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

                                                          +1
                                                          Каким образом они решают проблему переиспользования кода библиотек? Никак? Тогда это то, к чему стремится ubuntu (и это грустно).
                                                            +1
                                                            1. Так как все артефакты изолированны друг от друга, в системе может быть установлено несколько версий библиотеки
                                                            2. Пакеты, использующие одну и ту же версию библиотеки, используют одну и ту же библиотеку

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

                                                              +1

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

                                                                +1

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


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


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

                                                          0
                                                          И по такому пути пошли разработчики дистрибутива gentoo, они ввели в свой пакетный менеджер понятие слотов, и каждый пакет (теоретически) может быть установлен в системе в нескольких версиях одновременно в разные «слоты».

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


                                                          Как и в экономике, первый вариант приносит максимум эффективности, но подобен золотой клетке и отсутствию свободы, а второй (как и капитализм) вариант приносит минимум общей эффективности, но приносит свободу.

                                                          Эх, как много тут дискуссионных точек. Но, увы, к теме исходного поста это не относится.

                                                          +3

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

                                                            0
                                                            По мне, так подход nix/guix это оптимальное решение — большая часть пакетов может переиспользовать либу (это задача создателей дистрибутива), но если вдруг понадобилось ради одного пакета заиметь другую версию этой либы — пожалуйста.
                                                            0
                                                            Многое ПО может использовать разные библиотеки, и указание на то, какую точно версию нужно использовать остаётся на усмотрение линкера (для компилируемых языков) или обработчика файла зависимостей (pip, bundler, etc). Если все приложения в дистрибутиве собраны с одинаковыми требованиями, то наступает благодать: если в какой-то библиотеке есть ошибка, мейнтейнер этой библиотеки обновляет версию, и исправление автоматически применяется ко всем приложениям.

                                                            Вот к сожалению здесь фундаментальная ошибка, причем причина озвучена же в первом предложении цитаты. Указание на требуемую версию сделано в момент сборки приложения и "просто обновить зависимость" для исправление чего-либо недостаточно. Все, кто эту зависимость используют, должны будут пересобраться с указанием на новую версию зависимости. Не видили что ли ни разу списка обновлений в Ubuntu (в GUI)? Там по десятку раз повторяется "обновлено то-то". Очевидно, если бы приложения получали бы исправления автоматом, то такого бы не было.


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

                                                              +1
                                                              Указание на требуемую версию сделано в момент сборки приложения и «просто обновить зависимость» для исправление чего-либо недостаточно

                                                              Ну если кратко — Вы не совсем правы.

                                                              Есть такие понятия, как API и ABI, и если новая версия библиотеки не ломает их — то и пересобирать приложение нет причины. Как пример — все древние приложения, собранные со старым glibc продолжают работать на новых без каких-либо модификаций.

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

                                                              Исключительно проблемы Ubuntu Debian-based дистрибутивов, у которых в пакетах (подчёркиваю — в пакетах) указаны очень точные (специфичные) версии, и 95% таких обновлений состоит из «обновили циферки в исходниках пакета». Сами бинарные файлы линкуются с гораздо менее требовательным по версиям цифрам.

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

                                                              Да практически все приложения хотят просто >= X.Y && < X+1, а то, что дистрибутив сам наворотил… См. выше.
                                                                0
                                                                Есть такие понятия, как API и ABI, и если новая версия библиотеки не ломает их — то и пересобирать приложение нет причины.


                                                                Это в идеальном мире, например… В реальности все может оказаться более суровым. Поэтому и «предпочтительно пересобрать».
                                                                  0
                                                                  Вы забываете еще более страшную вещь — это, когда, например, втаскиваешь какой-нибудь skype-for-linux на rpm-based дистр и оказывается, что нужно доставить 10+ пакетов руками, потому что парни забыли, что их чертовы бинарники зависят от этих 10+ системных пакетов (преимущественно — всякие библиотеки).
                                                                  Так что проблема действительно в культуре (а точнее — ее отсутствия) релизов сборок пакетов.
                                                                    0
                                                                    Есть такие понятия, как API и ABI, и если новая версия библиотеки не ломает их — то и пересобирать приложение нет причины.
                                                                    Если бы разработчики библиотеки об этом думали. К сожалению подавляющее большинство разработчиков библиотек использует CADT модель — из чего и вытекает всё остальное.

                                                                    Сами бинарные файлы линкуются с гораздо менее требовательным по версиям цифрам.
                                                                    Если бы они не только линковались, но ещё и после этого работали… но об этом — мало кто думает. Сам вопрос «я собрал мою программу с GTK 3.0, запускаю с GTK 3.28, а оно не работает» воспринимается как оскорбление зачастую.
                                                                  +1
                                                                  У проблемы зависимостей нет хорошего решения. Только в разной степени плохие.

                                                                  Лично я за то, чтобы подавляющее большинство софта (особенно ключевого) шло, как сейчас, через обычный пакетный менеджер. А какой-то громоздкий, коммерческий например, софт (те же графические пакеты Adobe, если они когда-нибудь доберутся до Линупса) — вполне можно поставлять в snap/flatpack/прочие контейнеры и пусть вендор сам их поддерживает.

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

                                                                  Из минусов — закрытие уязвимостей ложится на плечи вендоров пакетов, а не дистрибутива.
                                                                    +1
                                                                    Тыг чем более громоздкий софт, тем больше он получает пользы от shared libraries. Условно, тот же /bin/sed прекрасно и в вендореном виде проживёт. А вот gimp — уже не очень. И LOffice — не очень. И Krita — не очень. Точнее, прожить-то они проживут, но за счёт ресурсов рабочей станции. Об этом и статья — что каждый из них будет получать преимущества от вендоринга, но если все будут вендориться, то от дистрибутива останется гигантский блоб.
                                                                      0
                                                                      Все зависит от библиотек которые софт использует. Если это приснопамятный OpenSSL (и подобные ему), то он юзается практически всеми и сидит радостно одной копией расшаренный в памяти.

                                                                      А если это что-то внутренне-специфическое, либо какие-то FFMPEG/ImageMagick-подобные либы, которые использует только этот графический софт (ну может еще парочка на той же машине), то толку использования расшаренных библиотек почти никакого. При этом добавляется головняк следить за выходом всех популярных дистрибов — смотреть не сломалось ли что и чинить.

                                                                      Поэтому, если мы хотим (а мы ведь хотим?) чтобы наконец-то настал «год Линукса на десктопе» :) то snap-подобный подход неизбежен.

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

                                                                      Линукс пока к этому даже близко не подошел, разве что LTS релизы дают 5-7 лет стабильности.
                                                                        +2
                                                                        Тыг чем более громоздкий софт, тем больше он получает пользы от shared libraries.


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

                                                                        Элементарно же, софтина весом 300МБ, которая тащит за собой еще 100МБ зависимостей, которые, кроме нее самой, один фиг никому не нужны — это, конечно, плохо, но относится к разряду «разумного неизбежного зла» или «допустимого компромисса».

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

                                                                        Условно, тот же /bin/sed прекрасно и в вендореном виде проживёт.


                                                                        Сам sed — 109Кб.
                                                                        Зависимости бинарника (libc, linux.vdso выкидываем, т.к. они и для snap'а базовые):
                                                                        libselinux — 155Кб.
                                                                        libpcre — 465Кб.
                                                                        libdl — 15Кб.
                                                                        ld-linux — 171Кб.
                                                                        libpthread — 145Кб.

                                                                        Итого, на 100-килобайтный бинарь мегабайт зависимостей (которые нужны подавляющему числу других системных утилит), что делает «полезную нагрузку» пакета равной ~10%.

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

                                                                        А вот gimp — уже не очень. И LOffice — не очень. И Krita — не очень.


                                                                        А вот это уже можно оспорить. При размере пакета, допустим, в 100МБ, докинуть 20-30 метров специфических зависимостей (особенно учитывая, что вы получаете таки «полновесное приложение» без геморроя с зависимостями) может оказаться разумным выходом.

                                                                        Точнее, прожить-то они проживут, но за счёт ресурсов рабочей станции.


                                                                        Потеря от вендоринга зависимостей на крупных приложениях будет держаться в пределах 20-30% дисковой нагрузки, примерно. Вендоринг «мелочи» — вот это то, что «нагнет» вашу систему.
                                                                      0
                                                                      Тут ещё и софт начал сам отказываться от шаред библиотек. тот же раст и го пошли по принципу улучшения поддержки вендоринга.
                                                                        +7
                                                                        Я понимаю, зачем Canonical пушит snap. Я это понимаю, и не одобряю.
                                                                        Вы упускаете вторую по важности фичу этих пакетных менеджеров. Snap — это, прежде всего, о разделении привилегий и изоляции программ, описания доступа непосредственно в пакете, а также о частых и быстрых обновлениях. Обычные кросс-дистрибутивные пакетные менеджеры уже были, например, 0install, а фишка Snap именно в изоляции, во внедрении модели привилегий iOS/Android на компьютеры.
                                                                        Snap ещё полезен тогда, когда программа слишком бурно развивается и не имеет LTS-версии, либо если она становится бесполезна без обновлений (как пример — youtube-dl). Как правило, такие программы не поставляют в репозиториях.
                                                                        Также Snap/Flatpak не привязан к какому-то конкретному дистрибутиву: если вы хотите быстро установить какую-то программу, чтобы просто её оценить, посмотреть функциональность, а в репозитории вашего дистрибутива её нет, разумно установить её из Snap/Flatpak. Или если вам нужен условный nginx с какими-то нестандартными модулями, для RTMP-вещания видео, в локальной сети на 3 человека, например. В репозиториях его нет, в сторонних репозиториях может и есть, но очень старая версия, а в Snap/Flatpak кто-то собрал и поддерживает. Что должен сделать обычный человек, не Linux-администратор, в этом случае?

                                                                        Эти пакетные менеджеры не от хорошей жизни же появились. DEB-пакеты собирать даже не сложно, а унизительно: стандартных утилит для этого есть минимум 3, плюс какие-то дополнительные обертки вокруг них. Внятная документация в одном месте отсутствует, везде только какие-то куски, разъясняющие техническую часть, но не объясняющие, какой концепции следует придерживаться при создании пакетов, нужно ли выносить разные части программы в разные пакеты, как это корректно делать, как отслеживать и выпускать обновления. Чтобы разобраться в этом программисту, для которого Linux — не основная ОС, требуется несколько дней, и это только для одного формата пакетов/дистрибутива (даже у RPM между дистрибутивами различаются макросы и дефайны, не факт, что .spec из одного дистрибутива соберется в другом). Здесь Snap/Flatpak придется кстати, как для программистов, так и для пользователей менее популярных дистрибутивов.
                                                                          +2

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

                                                                            0

                                                                            Подзаголовки тянут на ещё один сезон Игры престолов ))

                                                                              +3
                                                                              … приложения, которые жирные, тяжёлые, у которых обновления нерегулярные и которые с лёгкостью могут держать уязвимости неисправленными годами… Зато некоторые из них shiny new.

                                                                              Это разве проблема? Больше похоже на нытье. Касательно уязвимостей. Тезис вообще не проходит проверку временем. Условный openssl при фиксе уязвимости ломает обратную совместимость и всем клиентам этой библиотеки приходится делать новый релиз. Действительно, имеем две крайности — либо распухшие пакеты приложений «все свое ношу с собой», либо маленькие и бесполезные программки, которые так и норовят поставить очередную версию системной библиотеки. Где видится баланс? В том, чтобы отделить системную часть от прикладной. Пускай окружение будет стабильным (и производитель за него отвечает), а всякие монстры типа фотошопов и ms office тащат свои библиотеки сами.
                                                                              Еще отдельный вопрос как приложения между песочницами будут обмениваться своими данными (та же автоматизация, RPC etc) — он открыт.

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

                                                                              Насчет локального выигрыша и глобального проигрыша (или наоборот) — в яблочко.
                                                                              Я понимаю, зачем Canonical пушит snap. Я это понимаю, и не одобряю.

                                                                              Я тоже понимаю и есть еще политические соображения. Я ПРОТИВ snap. Но сегодняшная ситуация с бинарными дистрибуциями rpm/deb тоже вряд ли может быть удовлетворительной (ХОТЯ битых пакетов или пакетов с битыми зависимостями стало существенно меньше, чем 10-к лет назад).
                                                                                +2
                                                                                Условный openssl при фиксе уязвимости ломает обратную совместимость и всем клиентам этой библиотеки приходится делать новый релиз.
                                                                                Это как, поясните? Если находят уязвимость в OpenSSL, то разработчики выпускают обновления для всех веток библиотеки, мейнтейнеры обновляют ту, которая используется в дистбирутиве, и никакие программы не ломаются и не требуют пересборки. Для этого, собственно, и существуют разные версионные ветки у серьезных библиотек и программ.
                                                                                  0
                                                                                  Вы наивно думаете, что любую уязвимость можно запатчить путем исправления библиотеки, а не клиентского кода (т.е. кода самого приложения)? Ну-ну.

                                                                                  Openssl — вообще вероятно неудачный пример.

                                                                                  и никакие программы не ломаются и не требуют пересборки

                                                                                  nginx, насколько я помню, таскает свою версию openssl почему-то, причем статически слинкованную. Это к примеру о хороших программах, которые инкапсулируют свои зависимости.
                                                                                    +1

                                                                                    У меня nginx слинкован с системной openssl, ЧЯДНТ?


                                                                                    Можно даже выбирать, собирать с openssl или с libressl.

                                                                                      +1
                                                                                      Вы наивно думаете, что любую уязвимость можно запатчить путем исправления библиотеки, а не клиентского кода (т.е. кода самого приложения)? Ну-ну.
                                                                                      Если эта уязвимость в библиотеке, которую использует программа, как в примере OpenSSL — да.
                                                                                      nginx, насколько я помню, таскает свою версию openssl почему-то, причем статически слинкованную. Это к примеру о хороших программах, которые инкапсулируют свои зависимости.
                                                                                      Это решает администратор/мейнтейнер, на этапе компиляции. Nginx работает со стандартным OpenSSL (не требует какого-то отдельного своего форка), и в дистрибутивах он совершенно точно собирается с динамической линковкой OpenSSL.
                                                                                      Даже если в каких-то сторонних репозиториях его собирают со статически слинкованным OpenSSL, то это не является проблемой, покуда мейнтейнер пакета отслеживает проблемы безопасности зависимостей, и вовремя пересобирает пакет.
                                                                                  0
                                                                                  А, пусть, авторы приложений сами мейнтейнят приложения. Выдадим каждому по песочнице, пусть копаются. Авторы получают свободу, Canonical — приложения, которые не зависят от Debian и которые хоть кто-то мейнтейнит бесплатно. Пользователи получают…

                                                                                  авторы получают не свободу, а необходимость запиливать в свои приложения взаимодействие с API этой самой песочницы. Например, в flatpak это называется "порталы". Что делать, если песочниц несколько, и не проще ли авторам продолжать распространять свой софт в тарболлах, как сейчас, не сообщается.


                                                                                  А пользователи получают по факту никем не контролируемые "репозитории" с майнерами (google 2048buntu) и без общих библиотек

                                                                                    0
                                                                                    Что делать, если песочниц несколько


                                                                                    Очевидно, выбрать одну из них…
                                                                                    +2
                                                                                    Flatpak — это убийца безопасности.
                                                                                    Я просто оставлю эту ссылку тут:
                                                                                    flatkill.org
                                                                                      0
                                                                                      Wow. А я-то думал, что snap'ы — это плохо.
                                                                                        0
                                                                                        Прочитайте внимательно, какая ерунда по ссылке написана. Это просто не поддается критике. Написано явно ярыми противниками Flatpak.
                                                                                          0
                                                                                          Аргументы, что там ерунда будут?
                                                                                          Т.е. я не отрицаю, что материал ангажированный и очень эмоциональный и все, что там написано надо делить на два. Но нужна и оппозиционная точка зрения.
                                                                                            +1
                                                                                            The sandbox is a lie
                                                                                            Flatpak только предоставляет возможность изоляции программ, но не требует обязательного её использования пакетами. В случае без изоляции, программа будет иметь такие же привилегии, как и любая другая программа на компьютере, запущенная от текущего пользователя.
                                                                                            You are NOT getting security updates
                                                                                            Flatpak — такой же «сторонний репозиторий», как и любой другой. Не совсем понятно, о чем конкретно идет речь в тексте, то ли об уязвимостях в базовом слое Flatpak непосредственно, то ли в пакетах программ, которые на сайтах программ помечаются официальными (наиболее вероятно). В последнем случае, это проблема не Flatpak как технологии или программы, а проблема в сборке пакета, и аргументы amarao в этой статье здесь в силе.
                                                                                            Local root exploit? Minor issue!
                                                                                            Похоже на реальную проблему безопасности, которую можно использовать для локального повышения привилегий. Но стоит заметить, что сам устанавливаемый пакет автоматически это сделать не сможет, т.е. в качестве вируса использовать не получится, только для осмысленного применения злоумышленником.
                                                                                      +2
                                                                                      С одной стороны — я понимаю автора, про жирность и уязвимости. Это проблема, да. Но с другой стороны — дистрибутивы для пользователей, а не для мейнтейнеров. А пользователю важен функционал. Его слабо интересуют потенциальные уязвимости (хотя взломов никто не любит) и размер пакетов (все, что меньше рипа фильма максимального качества — мелочь). Пользователь хочет нажать кнопку «установить» — и получить программу. Ему не хочется танцевать с бубном, выясняя, почему программа не встает. Он не хочет выяснять, какую именно версию какой библиотеки имел в виду разработчик — и не хочет знать, чем лучше та более новая версия, которая не работает. Его не интересует, какой новый функционал добавили в последней версии нужной программы, если в ней содержится регресс старой и востребованной конкретно данным пользователем функции. В конце концов, пользователь выбрал бинарный дистрибутив с менеджером пакетов, а не Linux From Scratch со сборкой софта руками прямо из cvs. А это значит, что ставить он будет пакеты. Не библиотеки, не модули, не утилиты — а пакеты.
                                                                                        +1
                                                                                        Пользователю совсем не всё равно, сколько оперативной памяти занято. Как только начинается thrashing, становится «ой». Как только становится вместо 10-20Гб на системный диск 600+ — тоже «ой».

                                                                                        … На самом деле Debian — для мейнтейнеров, например. Они всё в нём решают и делают так, как им удобно. А дальше у нас будет (если каноникал не закопает snap'ы как upstart и unity) чистой воды сравнение debian VS ubuntu. И тут-то пользователи заметят разницу в системных требованиях для того же самого комплекта ПО.
                                                                                          +1
                                                                                          Я так скажу: если у меня, как пользователя Debian, есть возможность поставить софт через apt — я его ставлю. И если он работает — я доволен. А если нет возможности или не работает — то я этот софт предпочту в snap'е через snapd из дистрибутива, чем ставить руками. А ещё snap — это не столько зависимости, сколько инфраструктура. Не библиотеки, но среда для исполнения — в том числе, с настройками. А когда разница между двумя комплектами ПО описывается не только разными требованиями к диску, но и разной сложностью эксплуатации, появляется ценовой баланс «время-деньги» против стоимости гигабайтов. Пока что гигабайты проигрывают =)
                                                                                        +2
                                                                                        Люблю такие критические статьи, но я «по другую сторону баррикад», чем автор. Мир Linux довольно жесток к сторонним программистам с их программами, над которыми они работают не полный день. Разбираться с зоопарком дистров и пытаться попасть в официальные репо — то ещё садо-мазо. Очень многие пользователи благодарят за мои snap пакеты программ, которые никогда не были легко представлены для пользователей. Snap пакеты можете ругать, но они из оперы «сделал раз — работает везде». Вот один из моих поводов для гордости — почти 20к пользователей
                                                                                        image
                                                                                          0
                                                                                          Если вы «сделали раз», то когда вы в последний раз обновляли библиотеки?
                                                                                            0
                                                                                            Когда собрали последний раз приложение. Может на прошлой неделе, может пять лет назад.

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

                                                                                            Snap — это такой способ поддержать подобные приложения на десктопе…
                                                                                              0
                                                                                              Я вам даже больше скажу… авторы программы просто болт положили на Linux и в их вики советы только для Ubuntu 12.04 и 14.04. Snap — просто спаситель такого софта. Старые ли там библиотеки — оооо даааа. А выход какой? Ещё одну программу на помойку?
                                                                                              Вот он суровый мир Linux на примере Дебиан
                                                                                              1320 «осиротевших» пакетов
                                                                                              3194 пакетов, которые кто-то хотел бы видеть в Debian
                                                                                              www.debian.org/devel/wnpp

                                                                                              Малейшее изменение в ОСи и если сторонний программист не следит за изменениями, то всё — пользователи попрощайтесь с программой.

                                                                                            +2

                                                                                            Что ещё в Snap хорошо — вот выпустили JetBrains обновление IDE ломающее, точнее делающее неюзабельным поиск по файлам, я в Snap сразу откатился на предыдущую версию и запретил автоматические обновления. Не представляю, что бы я делал, если бы это обновление прилетело централизованно с обновлением Ubuntu. На самом деле представляю, конечно...

                                                                                              –1
                                                                                              В убунту ещё не завезли снапшоты?
                                                                                              А в опенсусе на btrfs они уже сто лет в обед!
                                                                                                0

                                                                                                Вы в смысле бэкапа и предлагаете откатить всю Ubuntu на предыдущую LTS?


                                                                                                Так-то у меня есть и master disk железный и в виде ISO, и бэкап-диск моего рабочего места с предыдущей версией Ubuntu, так что вернуть старую версию можно примерно за минуту, но хочется-то новую версию, и только одну единственную программу оставить в старой версии.


                                                                                                Впрочем, проблем с апдейтами в Ubuntu практически нет (если не брать Firefox, но это отдельная истeрия), это как раз коллеги с Suse сидят годами без апдейтов, и переходят на Ubuntu только с покупкой нового компа :)

                                                                                                  0
                                                                                                  Вы в смысле бэкапа и предлагаете откатить всю Ubuntu на предыдущую LTS?

                                                                                                  Боюсь, Вы меня не поняли. При любой установке rpm пакета SuSe делает что-то типа «точки восстановления» на основе снапшота файловой системы. Его потом легко подмонтировать и восстановить состояние системы до установки сбойного пакета (даже если GUI «не алё»). Это немного более сложная и развитая вещь, чем «просто бекап».
                                                                                                    0

                                                                                                    Ну вот прилетает апдейт с 16.04 LTS на 18.04 LTS — там устанавливаются сразу ВСЕ пакеты.
                                                                                                    Вернуть один пакет — в общем случае это значит протянуть за собой тонну зависимостей.


                                                                                                    Это немного более сложная и развитая вещь, чем «просто бекап».
                                                                                                    По-моему, это частный случай бэкапа, инкрементальный бэкап только для пакетного менеджера, который поможет при проблемах при установке одного пакета, но вряд ли даст вернуть предыдущую версию какого-либо одного пакета при обновлении всей системы.
                                                                                                      0
                                                                                                      Апдейт 16.04 на 18.04 должен быть атомарной операцией. Но это же убунту ;)
                                                                                                      В этом отношении мне очень нравится подход coreos container linux, atomic, photon os etc.
                                                                                                      Суть в том, что операционная система обновляется целиком. Потом происходит перезагрузка в новую версию. Никакого микса из пакетов и промежуточных состояний — win-win
                                                                                                        0

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

                                                                                                          0
                                                                                                          Не-не — то, что Вы говорите — это другое.
                                                                                                          rpm реально транзакционно ставит пакеты, в отличии от dpkg/apt ( сколько раз приходилось делать `dpkg -i --force-overwrite` или `dpkg-reconfigure` )

                                                                                                          > сисадмин выдаёт настроенный винт с новой версией убунты

                                                                                                          угу. Т.е. чукча — не админ, чукча — пользователь. И задействуется еще специально обученный человек. А где же магия, что все работает само, из коробки?
                                                                                                            0
                                                                                                            Магия на подходе, Snappy Ubuntu же.
                                                                                              +1
                                                                                              Представьте себе мир, в котором все всё везут с собой…

                                                                                              Уже там живём. Каждый десктопный мессенджер (viber/telegram/etc) тянет за собой Qt5, который тянет за собой весь дом, который построил Джек. А самая дичь с которой довелось столкнуться: утилита для мониторинга состояния батареи UPS-а от FSP тащила за собой:
                                                                                              — JRE (что уже странно, но это еще цветочки)
                                                                                              — Tomcat (тут становится понятно, зачем был JRE, но здесь градус неадеквата резко нарастает)
                                                                                              — Adobe Flash Player (а вот тут уже всё...)
                                                                                              Короче, они что сделали: по клику на иконке в трее открывается браузер, по адресу типа localhost:6666 Томкат отдаёт какую-то статичную страничку со встроенным флешем, который, опять таки, стучится в Томкат, и рисует какие-то анимированные графики и диаграммы заряда/разряда батареи. ВСЁ.
                                                                                                +1

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

                                                                                                  +1

                                                                                                  Мониторилка рейда от LSI под винду (StorMan или типа того) работает практически идентично — тоже ява и локальные веб сервера. Это, похоже, заразно...

                                                                                                    0
                                                                                                    StoreMan — это адаптек, и у них есть большая причина — ему не обязательно слушать на localhost, т.к. клиент и сервер (где рейд находится) могут быть на разных серверах. Кривовато, но имеет причины.
                                                                                                      0
                                                                                                      Да, запамятовал, но тулза от LSI по-моему такая же.

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

                                                                                                      Это справедливо и для случая с ИБП выше. Что не повод тащить за собой жабу, томкэта и прочий зоопарк.
                                                                                                  0

                                                                                                  Вот не понимаю, почему установка qTox через flatpak занимает почти в 2 раза больше, чем appImage этого же qTox'а. При установке из flatpak тащит за собой KDE зачем-то.

                                                                                                    0
                                                                                                    Возьмите сборку, отвязанную от KDE.
                                                                                                    0
                                                                                                    Собственно все забыли, что побеждает всегда здравый смысл рынок. Пусть пользователь выбирает сам. Предоставьте пользователю выбор. Хочет — пусть ставить непонятный софт с сайта разработчика и сам следит за безопасностью, хочет — пусть аутсосит это мантейнерам дистрибутива, которые будут просто следить за базой CVE и списком версий, включенных в конкретный (жирный) пакет, а разработчики в свою очередь пусть предоставляют такой список (включил полностью — напиши какую именно версию в манифест), и будут просто исключать пакеты из своего репозитория, если их что-то не устравивает, чуть ли не в автоматическом режиме. Пользователь будет выбирать сам какой дистрибутив и его политика подходят ему.
                                                                                                    Самое интересное, что такая или похожая система уже отработана на примере мобильного софта и это в большинстве случаев срабатывает.
                                                                                                    Важно принять это как рабочую модель, а улучшения в виде разделяемых слоёв с одинаковым содержимым можно делать бесконечно.
                                                                                                      0

                                                                                                      <сарказм>А не нужно беспокоиться, от разрастания требований к месту, просто нужно добавить ещё один слой абстракции: файловую систему со встроенной дедупликацией. Ядро вон и в оперативке данные может дедуплицировать.</сарказм>

                                                                                                        +1
                                                                                                        Сарказм тут явно лишний. Файловая система со встроенной дедупликацией уже есть.
                                                                                                          0
                                                                                                          Я знаю, что есть. Меня огорчает типичный путь эволюции IT, по которому я опасаюсь может пойти развитие: затыкание дыр и проблем от слишком большого количества абстракций добавлением дополнительных абстракций.
                                                                                                          0
                                                                                                          Это метод, да, но он не бесплатный, плюс это не решает проблемы наличия в системе libfoobar 1.1.1, 1.1.2, 1.1.3, 1.1.4b2 и т.д.
                                                                                                          0
                                                                                                          Люблю Ubuntu за возможность выбора: хочу делать по-нормальному и в удобном для поддержания на множестве машин виде — собираю пакеты в свой PPA, а хочу быстрое готовое решение — ставлю snap. Еще нравится acestreamplayer от vasilisc в качестве примера, где snap уместен — лютая проприетарщина с очень развесистой цепочкой зависимостей. Такому самое место иметь защиту AppArmor от snapd из коробки.

                                                                                                          snap хорошо решает конкретную задачу — контейнер приложения с зависимостями, flatpak же устроил параллельную пакетную систему, мейнтейнеры флатпака тоже иногда ломают голову, а почему же приложение не собирается с glibc из Flatpak SDK.

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

                                                                                                          Самое читаемое