Большое сравнение и тестирование форматов установки ПО в дистрибутивах Linux и FreeBSD (x86/x64)

Оглавление

• Вступление
• Общие требования к установочному пакету
• Первый сбор информации
  
• Первое сравнение форматов распространения ПО
  
• Второй сбор информации
  
• Второе сравнение форматов распространения ПО
  
• Подготовка к практическому тестированию
  
• Тестирование
• Практическое тестирование (Debian 7)
  
• Практическое тестирование (Fedora 20)
• Практическое тестирование (Gentoo 2016)
  
• Практическое тестирование (Manjaro 20)
  
• Практическое тестирование (openSUSE 13.1)
• Практическое тестирование (Slackware 15)
  
• Практическое тестирование (FuryBSD 12.1)
  
• Практическое тестирование (NomadBSD 14.1)
  
• Результаты и заключение
  

Вступление

Это продолжение предыдущей серии статей. Рекомендуется ознакомиться с первой и втор ой частями для лучшего понимания материала, хотя это и не обязательно. Для краткой справки: в прошлых частях был переработан установочный пакет Installer-SH, отточена в коде мультиплатформенность, а также скомпилирована игра «2048» для 32-битных платформ Linux/FreeBSD в дополнение к уже существующим 64-битным вариантам.

Теперь осталось провести тестирование нового пакета игры «2048» в формате Installer-SH. Пока что этот пакет доступен только для внутреннего тестирования. Однако, если всё пройдёт успешно, можно будет выпускать как дистрибутивный архив с игрой, так и релиз Installer-SH версии 2.8.

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

Общие требования к установочному пакету

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

1. Простота копирования и распространения.
2. Работа на компьютерах без доступа к интернету.
3. Работа без root-прав.
4. Работа в старых и заброшенных ОС (2013+ года).
5. Простота установки и удаления ПО.
6. Полнота и удобство представленной информации о программе.
7. Проверка целостности данных.
8. Прозрачность.

Набралось целых 8 пунктов, но это нужно ещё переработать в конкретные критерии оценки. Это будет сложно, но я постараюсь выделить критерии, по которым можно объективно оценить установочные пакеты программ в разнообразных форматах.

• Копирование и распространение установочного пакета одним файлом/архивом.
• Работает на автономных системах.
• Работает на системах без root-прав.
• Работает в Debian / Fedora / OpenSUSE / Manjaro / Gentoo / NomadBSD / GhostBSD.
• Установочный пакет можно распаковать обычными архиваторами вроде Ark, Engrampa, File Roller.
• Установочный пакет можно проанализировать с помощью текстового редактора.
• ...

В общем, я потратил слишком много времени на попытку сформировать критерии оценки, по которым буду проводить тестирование. Думаю, гораздо лучше будет просто составить тестовую таблицу. Единственное — мне придётся как-то учитывать серьёзные недостатки линуксоидных форматов распространения софта, отсутствующие у моего Installer-SH. Например, для работы AppImage нужна системная зависимость FUSE, а она есть далеко не во всех дистрибутивах Linux. Такие зависимости сами напрашиваются на то, чтобы их помечали как недостаток.

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

Первый сбор информации

Чтобы лучше разобраться в ситуации, мне нужно собрать дополнительную информацию. Я даже попытался установить пакетный менеджер Flatpak через пакетный менеджер APT, но столкнулся с проблемой «мёртвых» репозиториев. Какая ирония.

Мне было просто интересно, насколько сложно извлечь готовую программу в формате Flatpak для офлайн-использования. Оказалось — очень сложно. Эти «танцы с бубном» могут растянуться на целую статью. Да и потом неясно, как такой перенос распространять, ведь далеко не все дистрибутивы Linux имеют предустановленный пакетный менеджер Flatpak.

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

Со Snap история оказалась не менее весёлой. Утилита snap download вроде бы честно скачивает приложение, но вместо одного понятного файла выдаёт два: сам пакет .snap и файл цифровой подписи .assert. Попытка установить их «в лоб» превращается в бесконечную борьбу с ошибками доступа (access denied) и жалобами системы на то, что она не может найти метаданные подписи. Без консольной магии и прав суперпользователя запустить игру офлайн не получится. Да и весит она весьма прилично.

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

С Arch Linux ситуация интереснее: в Manjaro пакет игры удалось выудить прямо из локального кэша /var/cache/pacman/pkg. Пакет .pkg.tar.zst готов к переносу, но его жизнеспособность без интернета под вопросом — он тянет за собой системные зависимости, которые могут вызвать конфликты на целевой машине. Собственно, как и в случае вытягивания пакетов из кэша репозиториев APT.

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

Первое сравнение форматов распространения ПО

Из первой таблицы можно заметить, что полноценно и без лишних костылей работать без root-прав могут только Installer-SH и AppImage, в то время как Flatpak требует для этого специфических параметров в терминале. Если Installer-SH сам подготавливает всё необходимое в системе пользователя при установке ПО, создает ярлыки и работает по спецификациям, то целесообразность существования AppImage уже вызывает вопросы.

В плане сложности получения распространяемого пакета с ПО самыми простыми оказались Installer-SH и AppImage. Все остальные репозиторные методы варьируются от среднего до очень сложного уровня. Разумеется, наивысший уровень сложности оказался у формата Flatpak. Даже Snap не настолько сложен, хотя и вводит пользователя в заблуждение, демонстрируя в краткой справке неверные команды для установки загруженного пакета.

В плане мультиплатформенности конкуренцию формату Installer-SH не может составить ни один из представленных способов распространения ПО. Более того, основные репозиторные форматы ограничены конкретными ветками дистрибутивов Linux.

Только Installer-SH является кросс-архитектурным форматом среди представленных, так как позволяет создавать единые установочные пакеты не только для разных платформ, но и для разных архитектур. Хотя .deb-пакеты и бывают для всех архитектур (all), они ограничены скриптами и данными; настоящей поддержки разных архитектур в едином пакете там нет.

Среди самодостаточных форматов можно отметить только Installer-SH, так как он единственный способен самостоятельно подготовить систему и ПО к использованию согласно спецификациям и при этом не требует никаких предустановленных пакетных менеджеров. Для работы Installer-SH достаточно базовых утилит Coreutils, tar и bash, тогда как для прочих способов, в том числе AppImage, требуются специфические системные зависимости. AppImage с натяжкой можно назвать частично самодостаточным, но это не заслуга самого формата — отсюда и такая оценка.

Поддержка архитектур у Installer-SH и AppImage на высшем уровне, но AppImage нужно компилировать, тогда как Installer-SH не требует компиляции, поэтому насыщенный зелёный цвет только у Installer-SH. Худшую архитектурную совместимость имеют пакетные менеджеры Flatpak и Pacman.

Второй сбор информации

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

Чтобы составить максимально информативную и точную таблицу, я не только обращаюсь к искусственному интеллекту, но и лично беру случайные пакеты из репозиториев и проверяю их на возможность распаковки и анализа содержимого. Например, Installer-SH можно полностью распаковать и проанализировать простыми архиваторами и текстовыми редакторами, но вот пакет для FreeBSD из репозитория уже нельзя проанализировать, потому что внутри перемешаны бинарные данные с текстовыми. Из-за такой «каши» я не могу поставить высокую оценку прозрачности формата распространения софта.

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

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

Ну а так как игру «2048» в формате Flatpak найти в виде пригодного для распространения файла не удалось, я пошёл в поисковую систему и выкачал какой-то непонятный Flatpak-bundle весом 13 мегабайт. Вряд ли это получится хоть где-то установить, но для тестирования формата в реальных условиях сойдёт.

Второе сравнение форматов распространения ПО

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

Первые пункты затрагивают простоту установки и удаления приложений. В случае с Installer-SH никаких проблем с установкой и удалением программ нет. AppImage уже имеет некоторые изъяны, ибо разбрасывает файлы по всему домашнему каталогу, как только может это сделать программа, упакованная в данный формат. Поэтому удаление программ в формате AppImage — это та ещё головная боль, ведь «хвосты» в большинстве случаев придётся чистить вручную.

Да, Installer-SH тоже может оставлять «хвосты», ведь пользователь может выбрать домашний каталог для хранения файлов конфигурации при установке программы вместо стандартной изоляции в отдельной папке рядом с программой. Но в этом случае пользователь сам так поступает, так что это не проблема формата.

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

В плане изоляции классические пакетные менеджеры заслуженно получают «красную метку», ибо они не только размазывают файлы программ по всей ОС, но и используют домашний каталог пользователя как свалку для всего мусора, создаваемого в процессе работы программ. Installer-SH позволяет выбрать, где хранить мусор: рядом с программой в выделенном каталоге или в домашнем. AppImage же по умолчанию всё разбрасывает в домашнем каталоге. Ну а Flatpak и Snap стоят особняком со своей «внутренней кухней» в разных местах системы.

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

Среди восьми способов распространения ПО только Installer-SH оказался полностью прозрачным, без оговорок и нюансов. Худшими форматами в плане прозрачности оказались Flatpak и PKG: там вообще каша из бинарного кода и текстовых метаданных, непригодная для быстрого анализа вручную. Ну а .rpm-пакеты и вовсе скрывают логику и метаданные в заголовке пакета, недоступном для извлечения без специализированных инструментов.

Как пользователь, я не хочу просто доверять какому-то пакету из интернета или репозитория — я хочу иметь возможность сам проверить пакет перед использованием. Да и скрыть вредоносный код в bash-скрипте гораздо тяжелее, чем в скрытых заголовках и «бинарной каше». Архивные структуры и образы вроде cpio и squashfs тоже, мягко говоря, не добавляют прозрачности для обычного пользователя.

Подготовка к практическому тестированию

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

Инструкции порой бывают крайне глупыми — например, на ресурсе pkgs.org, предлагающем неподходящие для установки автономных пакетов команды. Тем не менее некоторые репозитории оказываются слишком сложными в использовании и буквально не позволяют зайти через браузер и скачать нужный пакет, поэтому я пользуюсь такими «посредниками», предоставляющими удобные ссылки на скачивание пакетов из репозиториев.

Мне не удалось найти именно ту версию игры, которая упакована в формат Installer-SH, потому что в разных репозиториях всегда попадались разные варианты игры «2048». Да и в формате Flatpak мне вообще не удалось найти ничего полезного, кроме случайного файла весом 13 мегабайт. Это не очень хорошо, но с этим придётся смириться, потому что работаем с тем, что есть, и не выдумываем ничего лишнего, чтобы угодить какому-либо формату.

Теперь подберем дистрибутивы Linux и FreeBSD для тестирования. Я буду использовать как современные дистрибутивы, так и очень старые: в суровой реальности выбирать не приходится, с чем иметь дело. Действительно хороший формат распространения ПО должен быть гибким и совместимым.

Чтобы охватить весь диапазон пакетных менеджеров и форматов, была собрана следующая подборка из разнообразных дистрибутивов Linux и FreeBSD: Debian 7, Fedora 20, FuryBSD 12, NomadBSD 14, Gentoo 2016 года выпуска, openSUSE 13, Slackware 15, Manjaro 20.

Хотя у Slackware используется свой формат архивов (.txz), а Gentoo и вовсе опирается на сборку из исходных кодов через систему Portage, для разнообразия они тоже будут протестированы. Архитектуры у дистрибутивов разные (32- и 64-битные), в наличии как старые, так и современные — уж какие под руку попались. Также отмечу дистрибутив NomadBSD: он распространяется исключительно в виде образов файловой системы, поэтому я сконвертировал его в образ для виртуальной машины и там провел первоначальную настройку перед использованием. Сама система чистая и нетронутая.

Тестовая виртуальная машина — VirtualBox 7.2.2, выделено 16 гигабайт ОЗУ и 8 ядер процессора. Так что ресурсов точно должно хватить каждой операционной системе. И да, все проверки будем проводить в офлайн-режиме (интернет недоступен), а также в режиме Live CD, кроме NomadBSD, так как он предназначен для записи на флешку и является предустановленной ОС со своей предопределённой файловой системой.

Тестирование

Теория без практики мертва, а пакетный менеджер без интернета — зачастую просто бесполезный набор данных. Чтобы окончательно расставить точки над «i» и проверить жизнеспособность каждого формата в условиях полной автономности, мы развернули масштабный тестовый стенд.

Задача проста до безобразия: взять готовый пакет с игрой «2048» и попытаться штатными методами установить и запустить его здесь и сейчас. Однако реальность сразу внесла свои коррективы: в формате Flatpak мне так и не удалось найти или собрать полноценный автономный бандл с игрой «2048». Поиск автономных пакетов в экосистеме Flatpak — это сущий кошмар, поэтому для данного формата придется довольствоваться единственным найденным тестовым пакетом неизвестного содержания.

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

Практическое тестирование (Debian 7)

Начнем наше экстремальное тестирование с одного из самых суровых испытаний для современного софта — дистрибутива Debian 7 (Wheezy). Полный офлайн, режим Live CD и старое рабочее окружение GNOME.

Запуск универсального инсталлятора версии 2.8 прошел штатно, без привлечения прав суперпользователя (root). Скрипт корректно предупредил о специфическом поведении текущего окружения.

• Выдал предупреждение об отсутствии переменных XDG_SESSION_DESKTOP.
• Отметил, что меню GNOME не вполне корректно следует спецификациям XDG.

Тем не менее, инсталлятор успешно завершил интеграцию. В системном меню «Applications» аккуратно прописались ярлыки для консольной версии «2048.c» со всеми четырьмя предустановленными цветовыми схемами (от классической до «Blue-to-red» и «White-to-black»). Статически скомпилированный бинарник запустился прямо из меню и отработал безупречно. Первый «плюс» отправляется в нашу итоговую таблицу.

Попытка запустить или хотя бы извлечь файлы из других автономных пакетов в условиях Debian 7 превратилась в фиаско:

• Все прочие заготовленные установочные форматы оказались абсолютно непригодными для использования в старой ОС. Их не удалось открыть даже как обычные архивы, чтобы извлечь исполняемый файл игры вручную.
• Контейнер AppImage потерпел крах на взлете. Самодостаточный (в теории) формат выдал критическую ошибку нехватки зависимости: «GLIBC 2.14 not found».

Так как во многих дистрибутивах «из коробки» нет специализированного софта для порчи файлов, пакеты были подготовлены заранее. В HEX-редакторе ровно в середине каждого файла был изменён всего один байт. Теоретическая устойчивость пакета к повреждениям — это хорошо, но как форматы поведут себя, если файл «побьётся» при копировании на старую флешку?

Результаты этого теста оказались крайне показательными:

• Installer-SH справился с проверкой. Архитектура инсталлятора включает две независимые системы контроля целостности. Первая проверяет архив с базовыми системными файлами (для подготовки системы согласно спецификациям XDG и PortSoft), вторая — архив самого приложения. Установщик мгновенно обнаружил повреждение контрольной суммы, остановил автоматический процесс и выдал пользователю явный запрос: готов ли он продолжать установку на свой страх и риск.
• AppImage полностью проигнорировал факт повреждения контейнера. Он просто выдал всё ту же ошибку об отсутствии GLIBC 2.14, даже не попытавшись провалидировать собственную целостность до запуска.

Мы пока не будем ставить AppImage окончательный «неуд» за проверку целостности в нашей итоговой таблице. Справедливости ради нужно протестировать этот битый контейнер в более современном дистрибутиве, где все системные зависимости (glibc) изначально на месте, чтобы увидеть, среагирует ли формат на повреждение в штатном режиме работы.

Практическое тестирование (Fedora 20)

Вторым подопытным на нашем изолированном от интернета стенде стал дистрибутив Fedora 20 с графической оболочкой XFCE. Installer-SH снова отработал без проблем: игра установилась, интегрировалась и нормально запустилась, несмотря на небольшие проблемы в тестируемом дистрибутиве.

AppImage не запустился (отсутствует зависимость FUSE), но проявил дружелюбность (только при запуске в терминале) и предложил провести распаковку контейнера с помощью специального параметра запуска. К сожалению, распакованная игра также не запустилась по вине «ада зависимостей».

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

Ну а родной для Fedora пакет в формате .rpm погряз в зависимостях с головой. Разумеется, я попытался установить и повреждённый пакет через dnf/yum, но оба пакетных менеджера просто выдавали ошибки зависимостей; никаких проверок целостности обнаружено не было.

И что теперь — снова заявлять, что «дистрибутив неправильный», и искать под этот конкретный RPM-пакет самую современную версию Fedora? Извините, но я не буду этим заниматься. Так можно до бесконечности подбирать идеальную ОС под каждый отдельный пакет с программой. Это чистое безумие: никто в здравом уме не станет переустанавливать операционную систему ради одной утилиты. Наверное, именно из-за такой логики Linux и остался «вечно трехпроцентным» в мировой статистике ОС.

Практическое тестирование (Gentoo 2016)

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

А ещё я заметил, что имеющийся у меня образ Gentoo на самом деле имеет архитектуру i686, но при этом запускается и работает в виртуальной машине с архитектурой x86_64. Нужно внести исправления в таблицу, ведь я думал, что у меня x86_64-версия дистрибутива (в имени образа есть «amd64»).

Среди всех способов распространения ПО сработал лишь один — Installer-SH. Даже AppImage отказался как-либо «шевелиться»: заготовленный контейнер был собран под 64-битную архитектуру, а сама система встретила нас ошибкой «Cannot execute binary file: Exec format error». Тем не менее Installer-SH не только установил и интегрировал игру в систему, но и корректно выбрал исполняемый файл для работы в 32-битной системе.

Да, все терминалы, а также файловые менеджеры дистрибутива Gentoo выглядят и работают как поломанные, но всё установилось, запустилось и работает правильно. Не знаю, из-за 64-битной ли виртуальной машины поломались иконки в файловом менеджере и терминале дистрибутива, но даже в таких суровых условиях Installer-SH отработал и доставил игру пользователю в рабочем состоянии.

Практическое тестирование (Manjaro 20)

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

Installer-SH снова безупречно отработал и выполнил своё прямое назначение — распространение и установку приложений. Да, дистрибутивы Linux порой разрабатываются некомпетентными разработчиками, из-за чего отсутствует вложенность разделов в меню приложений, а это приводит к хаосу из ярлыков. Но любое уважающее себя меню приложений имеет настройки, позволяющие включить вложенность категорий для соответствия спецификациям XDG Desktop, если вдруг разработчики дистрибутива этого не сделали.

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

AppImage-вариант игры, на удивление, запустился, а вот заведомо повреждённый пакет вылетел с ошибкой «Bus error (core dumped)». Никакой проверкой целостности в формате AppImage и не пахнет: вижу только бездумную попытку запустить испорченный файл. Нам придётся вернуться к старым таблицам и исправить пункт проверки целостности, ибо её просто нет.

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

Ну а проверка целостности здесь неоднозначная, потому что при открытии целого архива выдаёт ошибку «Unexpected error», а битого — «Cannot open package file». Причём для проверки ключей, судя по всему, требуется доступ в интернет, и вот на этом моменте весь смысл «автономных» пакетов Pacman теряется. Мы снова столкнулись с плохим пользовательским опытом: непонятно, что происходит. Проверка целостности неоднозначна и смешивается с другими ошибками, а в локальных ключах нет смысла, потому что всё равно требуется проверка через интернет.

Хотя в Manjaro 20 предустановлен пакетный менеджер Flatpak, реальной пользы от него нет — от слова «совсем». Он не смог установить имеющийся Flatpak-bundle в систему. Похоже, содержимое данного «автономного» пакета в формате Flatpak так и останется неизвестным.

Встроенный в Manjaro менеджер Flatpak оказался абсолютно бесполезен без интернета, превратив автономный бандл в тыкву. Это ли будущее распространения софта, как заявляют разработчики Flatpak на своём официальном сайте? Не думаю.

Практическое тестирование (openSUSE 13.1)

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

В данной операционной системе заработал только Installer-SH. Больше и показывать тут нечего: остальные способы распространения ПО полностью провалились.

Практическое тестирование (Slackware 15)

Вот мы и подобрались к последнему дистрибутиву Linux в нашем списке. Slackware также является весьма специфической операционной системой со своим уникальным форматом распространения ПО, как и openSUSE.

Здесь отработали только Installer-SH и AppImage. Остальные способы распространения ПО снова оказались бесполезными. На этом можно перейти к тестированию дистрибутивов FreeBSD.

Практическое тестирование (FuryBSD 12.1)

Сейчас мы имеем дело с заброшенным дистрибутивом FreeBSD 2020 года. Разумеется, все линуксовые форматы распространения ПО здесь отпадают сами собой, в том числе и AppImage.

Более того, FuryBSD оказался не только заброшенным дистрибутивом FreeBSD, но и непригодным для нормального использования, так как не монтирует накопители автоматически. Мне пришлось вручную через терминал монтировать второй диск, поскольку система этого сама не делает. Разумеется, пришлось «потанцевать с бубном», пока привыкал к среде.

Хотя FuryBSD оказался не только заброшенным, но и «поломанным» дистрибутивом FreeBSD (косяки в работе терминала), Installer-SH уверенно установил и запустил игру.

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

Практическое тестирование (NomadBSD 14.1)

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

Программа в формате Installer-SH установилась безупречно. Однако нативный способ в виде .pkg-пакета не сработал, так как пакетный менеджер пытается обновить репозитории через интернет во время установки пакета с игрой. Тут больше нечего сказать.

Результаты и заключение

Мы полностью заполнили нашу заготовку. Практическое тестирование во всех 8 операционных системах официально завершено. Вот как выглядит итоговая таблица-матрица:

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

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

Нативные пакетные менеджеры (APT, PKG, Pacman, DNF) оказались абсолютно беспомощными в условиях, приближённых к реальным (что есть, с тем и работаем). Вместо того чтобы просто взять локальный файл и развернуть его, они требуют обновить репозитории, проверить ключи или скачать ворох библиотек. В офлайне нативный пакет — это просто мёртвый груз.

Иллюзия универсальности (Flatpak, Snap, AppImage):

• Flatpak и Snap — это раздутые, интернет-зависимые монстры, которые физически не способны работать без привязки к своим централизованным хабам (Flathub, Canonical).
• AppImage показал себя чуть лучше, но его «самодостаточность» заканчивается ровно там, где начинается старая версия glibc или отсутствие подсистемы FUSE в системе «из коробки». Плюс — полное отсутствие контроля целостности данных при повреждении файла.

Почему победил Installer-SH? Потому что он спроектирован по классическим, проверенным временем канонам: независимость от библиотек ОС, поддержка нескольких архитектур в одном пакете, работа без root-прав и честный CRC-контроль целостности архива прямо перед распаковкой. Он уважает пользователя и операционную систему, а не пытается переделать её под себя.

На этом, полагаю, можно выпустить релизную версию Installer-SH 2.8, так как я не обнаружил существенных проблем при использовании формата на протяжении всех тестов. Протестированную игру «2048» в формате Installer-SH можно найти в репозитории Chimbalix-Software-Catalog.

Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.