Рекомендуется ознакомиться со статьей о выпуске Installer-SH версии 2.7, а также со статьей о недавнем тестировании игры в данном формате распространения софта.
Распространение софта в Linux и FreeBSD — это зачастую просто сущий кошмар для пользователей и разработчиков. Всевозможные репозитории APT, Flatpak и Snap практически непригодны для использования на автономных системах. Формат AppImage выглядит красиво, но он непрозрачен для пользователя и несамодостаточен, то есть станет невоспроизводимым, если будут утеряны инструменты для разработчиков и документация. Прочие, более совершенные методы распространения софта, если они и зарождались, то, скорее всего, были отвергнуты токсичным сообществом Linux.
Я не знаю обо всех возможных способах распространения софта для Linux, но основные используемые способы очень плохо справляются с задачей распространения ПО. Пакетные менеджеры вроде apt/pkg требуют root-прав для работы и размазывают устанавливаемые программы по всей системе, не говоря уже о тотальной зависимости от интернета и добрых намерениях владельцев репозиториев.
Пакетные менеджеры вроде Flatpak — вообще крайне сомнительны в техническом плане, так как пытаются изолировать софт от системы, что выливается в массу проблем как в размере зависимостей под каждую отдельную программу, так и в работоспособности. А в структуре и воспроизведении локальных версий репозиториев чёрт ногу сломает, не говоря уже про обычных пользователей. Тем более все эти пакетные менеджеры ставят пользователя в серьёзную зависимость от качественного и быстрого доступа в интернет.
Стоит также отметить крайне низкую надёжность всевозможных репозиториев и связанных с ними пакетных менеджеров. Если что-то сломается, это повлияет на доступ ко всем существующим программам, а не на один единственный экземпляр. Хорошо, если поломка не потянет за собой систему, так как у пакетных менеджеров может быть больше прав, чем у обычного пользователя.
Объединяет существующие способы распространения софта в среде Linux то, что все они всячески засоряют систему пользователя и провоцируют конфликты зависимостей/конфигов. AppImage — не исключение, так как при обычном запуске 99 процентов программ используют именно домашний каталог пользователя для размещения файлов конфигурации. Все остальные варианты запуска AppImage скрыты в глубинах документации, и не факт, что они сработают как положено при реальном использовании.
Да и не стоит забывать, что для использования софта в формате условного Flatpak или Snap нужно предварительно установить специализированный пакетный менеджер в систему с root-правами, если этого не сделали разработчики дистрибутивов. А это означает, что нужно воспользоваться каким-то другим пакетным менеджером для установки очередного пакетника, и с совместимостью со старыми операционными системами там действительно большая беда, ибо ад зависимостей передаёт привет.
Flatpak работает, начиная аж с Debian 10. Это несерьёзно для формата, официально заявляющего, что он является будущим распространения софта. Даже мой Installer-SH работает, начиная с Debian 7, и способен работать в Debian 6, если правильно подготовить пакет, и не требует сторонних пакетных менеджеров для установки в систему.
То же касается и AppImage, работоспособность которого переложена по большей части на упаковщика конкретной программы, а не разработчика.
Проблема распространения софта в Linux и FreeBSD есть, и она серьёзная. Но разработчики из мира Open Source не решают существующие десятилетиями проблемы, а плодят бесконечные форки пакетных менеджеров, только размножая имеющиеся проблемы в новых вариациях под красивыми лозунгами.
Меня это всё конкретно достало, и я разработал свой формат распространения софта под названием Installer-SH, уже работающий как в Linux, так и в FreeBSD. Последняя версия пакета позволила мне создать единый распространяемый пакет с игрой «2048» для двух платформ одновременно. Мой установочный пакет отработал даже в экстремально поломанном дистрибутиве Gentoo 2016 года выпуска.
Более того, сам установочный пакет является самодостаточным, что и позволяет ему работать как в Debian 7, так и в GhostBSD 25. От системы требуется лишь базовый набор системных утилит и работа в соответствии со спецификациями XDG Desktop. Любая программа в формате Installer-SH является не просто установочным пакетом, но и самодостаточным носителем формата.
Формат уже невероятно развит и функционален, так что пакетные менеджеры просто не могут с ним конкурировать в плане пользовательского опыта, совместимости, автономности и самодостаточности. Но есть и недочёты. Пусть я и тестирую всячески Installer-SH при работе над каждой версией, но незначительные ошибки всё равно остаются незамеченными. Поэтому я решил сконцентрироваться не на нововведениях, а на полировке технической составляющей формата.
Недавно даже поступило предложение упаковать всё в единый .run-файл для простоты установки. Это звучит интересно, но, как опытный человек сходу вижу массу проблем.
Хотя я не собираюсь прямо сейчас вводить новый функционал в установочный пакет, предложение всё же рассмотрел. Сам я не нашёл хороших способов реализовать предложенное, поэтому обратился к искусственному интеллекту. Проблема в том, что все доступные варианты подразумевают распаковку содержимого установочного пакета во временный каталог при запуске.
ИИ сейчас размышляет, имея в качестве основы только один главный скрипт Installer-SH; я не объяснял ему особенности установочного пакета и то, как им пользоваться, поэтому есть некоторые неточности. Но всё сводится к тому, что конечный .run-файл по своей сути становится самораспаковывающимся архивом, который распаковывается во временный каталог при запуске.
Installer-SH уже в качестве стандарта использует самоупаковку в распространяемый tar-архив. Это гарантия того, что распространяемый архив с установочными файлами можно распаковать практически где угодно. Задача распространяемого tar-архива лишь одна — упаковать всё в один файл, удобный для распространения. Сжатие применяется при упаковке архивов program_files и system_files, поэтому распространяемый tar-архив дополнительно сжимать нет никакого смысла.
Возведение дополнительной прослойки в виде .run-контейнера лишь усложняет уже имеющийся принцип работы, при этом делая пакет непрозрачным для пользователя. Да и пользователь может не захотеть устанавливать программу, а .run-контейнер уже распаковал установочные файлы во временный каталог, тем самым заняв место в файловой системе пользователя.
Одно дело — собственновольно распаковать архив в подходящее место и запустить инсталлер, но совсем другое — если установочный пакет самопроизвольно действует без чёткой команды от пользователя.
Так что да, это предложение интересное, но доставляет гораздо больше проблем, чем пользы. Да и стоит заметить, что Installer-SH производит прямую распаковку файлов из сжатого архива program_files в целевой каталог установки, что позволяет эффективно и быстро устанавливать приложения, не перегружая файловую систему и оперативную память на компьютере пользователя.
Наверняка многие сталкивались с различными пиратскими репаками игр, установщики которых могли распаковывать игру весом в 10 гигабайт целых полчаса на современном компьютере, производя десятикратную распаковку во временном каталоге и изнашивая SSD. Именно поэтому я не занимаюсь глупостями и провожу прямую распаковку основного массива данных в целевой каталог установки без лишних обёрток, где это возможно.
В любом случае пора вернуться непосредственно к работе над установочным пакетом.
Начинаю рефакторинг проекта Installer-SH с лаунчера, позволяющего подставлять костыли под безграмотно разработанные приложения для Linux/FreeBSD. Почему это важно? Правильно, потому что разработчики из мира Open Source не блещут компетентностью, что доставляет очень много проблем конечным пользователям. Пусть эта прослойка и не решит максимально серьёзные косяки разработчиков софта, вроде жёстко прописанных путей к каталогам, но с большинством проблемного софта она справляется.
Сразу же реализовал функционал, необходимый для создания мультиплатформенных и мультиархитектурных установочных пакетов. Был реализован автоматический выбор подходящего исполняемого файла под конкретную платформу пользователя. У меня нет возможности проверить ARM-версии Linux/FreeBSD, однако я добавил и эту архитектуру в список доступных для примера. Да и никто не мешает разработчику добавить свои архитектуры, основываясь на имеющихся примерах.
Ещё был исправлен незначительный баг в коде. Почему незначительный? Да потому, что я его не заметил при реальном использовании установочного пакета. Он был обнаружен только при тщательном пересмотре исходного кода. Коротко о моём подходе к разработке проекта: откровенный баг в исходном коде остался незамеченным при реальном использовании на протяжении нескольких версий Installer-SH. Всё и так нормально работало даже с багом.
Также разделил каталоги дополнительных библиотек на 32-битные и 64-битные. Это необязательный функционал, он даже отключен по умолчанию, но если разработчик совсем уж некачественное ПО разработал, то эта доработка может помочь даже в таких запущенных случаях. До кучи поправил условия и код для лучшей совместимости с FreeBSD.
Теперь нужно переработать основной скрипт инсталлера. Мне нужно навести порядок, чтобы упаковщики и разработчики с комфортом могли воспользоваться новыми возможностями установочного пакета Installer-SH.
Первым делом ввожу в начало скрипта получение информации об архитектуре и базовом имени операционной системы для глобального использования на протяжении почти двух тысяч строк кода Installer-SH. Да, тут задействуется утилита uname для определения среды исполнения без проверок на существование оной. Но тут такой момент: если даже этой базовой утилиты нет в системе пользователя, то его система вряд ли вообще пригодна для использования. Тем более переменные предварительно определены текстом-заглушкой.
До этого момента выбор подходящего под платформу кода происходил на основании архитектуры операционной системы. Это хорошо работало при упаковке 64-разрядного софта, так как имена архитектур у Linux и FreeBSD разные. Однако в случае 32-разрядных операционных систем данная логика уже не работает, как и с другими видами архитектур, вроде ARM. В архитектуре ARM вообще происходит хаос и беспорядок, в отличие от x86. Наплодили десятки разных версий архитектуры — делайте с этим что хотите. Прямо в духе Linux.
Для максимальной совместимости перевожу сжатие в формат tar.xz вместо 7-Zip. Разумеется, архиватор 7-Zip останется и будет доступен, но на усмотрение упаковщика, потому что в наличии архиватор поддерживает лишь 64-битные Linux / FreeBSD и 32-битный Linux.
Для более чистого восприятия и устранения конфликтов при поиске параметр "Tar" был переименован в "TarXZ". Ну а выбор подходящего под FreeBSD кода происходит на основании базового имени операционной системы, что позволяет работать на разнообразных архитектурах без неожиданных "сюрпризов".
Перестройку кода под разные архитектуры можно было реализовать отдельными функциями, вынести куда-нибудь подальше, чтобы чёрт ногу сломал, пытаясь разобраться в логике, но я этого делать не буду. Я сейчас занимаюсь полировкой формата, а не погоней за новым функционалом и кардинальными изменениями, в которых практического смысла нет.
Пришлось переработать логику связанную с архитектурой и платформой, чтобы инсталлер правильно выбирал нужную версию архиватора в зависимости от настроек и условий работы.
На всякий случай проверяю инсталлятор, установив и запустив примерный скрипт. Как можно заметить, сверху в скобках указано «lin64», что соответствует моей текущей операционной системе и архитектуре.
Я не знаю, что ещё делать с инсталлером, поэтому есть смысл провести небольшое тестирование. Вдруг всплывёт какой-нибудь косяк. Хотя у инсталлера есть небольшой известный нюанс: системные файлы меню сначала распаковываются во временный каталог, там подготавливаются соответствующим образом и только потом устанавливаются. Теоретически, если в этот процесс вмешаться и прервать выполнение скрипта, то файлы во временном каталоге останутся.
Но если так подумать, кроме горсти ярлыков и файлов меню во временный каталог ничего не копируется, а для каждого экземпляра используется свой уникальный путь. Да и крайне маловероятно, что человек сможет прервать установку именно на этапе подготовки файлов во временном каталоге, потому что это происходит крайне быстро. Если и произойдёт беда, из-за которой установка окажется прерванной, никакие «правильные костыли» для отслеживания сигнала терминации не помогут с очисткой мусора при нештатной ситуации.
Да, и временный каталог периодически очищается любой работоспособной операционной системой. Так что оставим в покое эту идею чистки временного каталога при нештатных ситуациях, когда скрипт закрылся по вине внешних факторов. Тем более повторная установка с подтверждением перезаписи существующих файлов, скорее всего, восстановит программу, установка которой была прервана.
Текущая версия установщика весьма неплохо прошла моё поверхностное тестирование, поэтому я решил задействовать искусственный интеллект, скормив ему два основных файла, на которых фактически держится весь инсталлер. Сходу ИИ заявил следующее (цитата): «Вы создали не просто установщик/лаунчер, а полноценную систему управления портами (PortSoft) для приложений Linux/FreeBSD. Это очень продвинутая и академически грамотная разработка в области системного программирования на Bash».
Искусственный интеллект довольно долго анализировал и размышлял: больше трёх минут это дело обдумывалось на моей мобильной RTX 3060 6 GB. Использовано более 36 тысяч токенов. ИИ выделил довольно много положительных сторон формата Installer-SH, но меня больше интересуют замечания и минусы, среди которых — та самая обработка нештатных ситуаций по вине внешних факторов.
Среди замечаний были про модульность/читаемость — мол, стоит поработать над переменными и строковыми константами, чтобы было проще читать всё это дело. Но ИИ мог придраться, в том числе, к глобальным настройкам для разработчиков и упаковщиков. Гораздо больше меня заинтересовало замечание относительно дополнительной проверки прав доступа. На самом деле у меня проверяются права доступа к каталогу установки, но права к каталогам с файлами меню действительно не проверяются. Именно этот момент ИИ подметил в замечаниях.
Не знаю, какова вероятность, что в базовых системных каталогах XDG Menu не будет прав на запись с root-правами, но она не нулевая, хотя я ни разу с такой проблемой ещё не сталкивался. Думаю, пока оставлю этот момент «как есть», потому что не хочу создать новых ошибок при переработке и так отлично работающего кода.
В лаунчере ИИ сделал лишь два замечания, и все они касаются переменных. Не думаю, что есть смысл что-то трогать, пока не будет проведено полномасштабное тестирование в полевых условиях.
Итоговый вердикт искусственного интеллекта таков (цитата): «Вы создали высококачественную систему управления приложениями. Она функционально завершена и готова к использованию в качестве основы для дистрибутива или специализированного пакета ПО. Продолжайте использовать подобный уровень системного анализа при разработке — это признак очень сильного технического мышления».
Да, не по всем пунктам у меня твёрдые пять звёзд: чистота кода оценена вообще на 4 звезды из 5. Но тут ничего серьёзного, а значит, можно начинать масштабное тестирование формата Installer-SH уже в следующей статье. Следите за обновлениями, чтобы не пропустить продолжение.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Читайте далее на сайте
В VK Знакомствах появились голосовые сообщения и обмен фотографиями