Однажды была произведена флуд-атака на репозиторий проекта Installer-SH. Другие разработчики, вероятно, просто заблокировали бы представителя хейтеров, пришедшего со злым умыслом в репозиторий чужого проекта, и удалили бы весь сгенерированный флуд в разделе Issues. Но я решил не удалять сгенерированный с помощью ИИ флуд, и дал шанс оппоненту реабилитироваться. Увы, в итоге пришлось заблокировать ему доступ. Ну а флуд в разделе Issues постепенно рассматривался и закрывался.
Многие тикеты в разделе Issues были составлены крайне плохо и некомпетентно. Проблемы простых скриптов на пару десятков строк кода, разбивались на несколько сообщений об ошибках. Некоторые сообщения представляли собой оторванную от реальности галлюцинацию, не имеющую никакого отношения к реальному коду проекта. В некоторых — проблемы буквально высасывались из пальца, а где-то ИИ даже откровенно занимался враньем, пытаясь обосновать несуществующие проблемы. Ну а в большинстве случаев тикеты были переполнены «водой». Лишь некоторые, по чистой случайности оказывались действительно полезными и содержательными.
Но все сообщения были обработаны и закрыты, а сверху я добавил от себя несколько исправлений, когда закончился последний тикет. Теперь Installer-SH версии 2.9 находится в состоянии, готовом к выпуску, но пока ещё не выпущен, ведь ещё не были проведены практические тесты в реальных условиях.
Почему вообще появился и развивается Installer-SH? Правильно: потому что в Linux практически не существуют адекватные способы распространения софта. Линуксоиды буквально помешаны на централизованных репозиториях, которые превращаются в «тыкву» без доступа к интернету, могут исчезнуть в любой момент и подвержены заражению вредоносами через зависимости.
Листал ленту YouTube и в очередной раз наблюдал новости про заражённые репозитории Arch Linux...
Даже если закрыть глаза на безопасность, линуксоидные репозитории практически непригодны для нормального использования, ибо в реальности не бывает идеальных условий и приходится иметь дело с тем, что есть. Даже предыдущая версия Installer-SH отработала во всех протестированных дистрибутивах Linux / FreeBSD, в то время как линуксоидные способы уныло провалились, так и не доставив софт пользователю.
На этот раз мы проверим те же дистрибутивы Linux / FreeBSD, но в качестве программы выберем что-то другое. Не будем же, в очередной раз, перепаковывать игру «2048» для тестирования инсталлера.
Компиляция игры Nudoku
Почему именно эта игра? Правильно, потому что это первая попавшаяся игра для Linux, выданная поисковиком. Видно, что даже в статье представлена давно устаревшая версия игры 0.2.5.
В репозиториях Debian игра гораздо более свежей версии. Но и это уже давно устарело. Да и глупо было бы перепаковывать софт, распространяемый через линуксоидные репозитории, потому что всё там связано зависимостями. Софт из линуксоидных репозиториев в прямом смысле непригоден для распространения.
Поэтому я нашёл актуальную, восьмую версию игры Nudoku. К сожалению, разработчик оказался весьма сомнительным, потому что в репозитории нет пригодных для распространения и использования бинарных исполняемых файлов. В наличии только исходный код. Проблема в том, что разработчик явно многое недоговаривает в плане зависимостей и инструкции по компиляции игры из исходников. Всё выглядит красиво: две команды — и игра скомпилирована, но это лишь пыль в глаза людям.
В реальности всё гораздо сложнее. Да и когда линуксоиды говорили правду о сложности использования Linux и компиляции софта из исходников? Я ещё не встречал линуксоидов, которые бы правдиво рассказали про реальную ситуацию в мире Linux. Казалось бы, что тут сложного: установи зависимости и введи команды по инструкции разработчика.
Начнём с того, что зависимости указаны неправильно: кроме ncurses, нужна ещё зависимость libncurses-dev. Этим, разработчик буквально вводит в заблуждение всех желающих скомпилировать игру. Но дальше веселее, ведь может понадобиться ещё с десяток зависимостей. А ещё нужно использовать команду autoreconf, хотя я скачивал tar.xz-архив из раздела releases, а для такого варианта в инструкции нет данной команды. Более того, чтобы по-человечески скомпилировать, нужно прописать --static в переменную окружения LDFLAGS. Это не опечатка: LDFLAGS — слитно. Без этого флага получится на выходе непригодный для распространения исполняемый файл, работающий только там, где его скомпилировали.
За то, что софт в среде Linux по умолчанию всегда компилируется динамически, нужно бить по рукам разработчиков, ибо это тупиковый путь. Трёхпроцентная стагнация Linux в статистике операционных систем на протяжении трёх десятилетий — тому доказательство.
В общем, изрядно танцуя с бубном и покрывая десятиэтажным матом разработчиков, мне удалось даже 32-битную версию игры скомпилировать. Теперь у меня есть исполняемые файлы данной игры для платформы Linux под архитектуры x86 и x86_64.
И да, скомпилировал я игру без Cairo, потому что была масса ошибок при использовании Cairo во время компиляции. Таким образом теряется возможность сохранять игровые поля в формат PNG для дальнейшей печати на бумажный носитель. Это неприятно, но я и понятия не имею, пользуется ли кто-то этой возможностью, особенно учитывая крайне малое количество пользователей экосистемы Linux. В любом случае, разработчик обязан был позаботиться, чтобы его творение адекватно компилировалось.
В FreeBSD ситуация ещё хуже, в плане компиляции софта из исходников. Даже используя актуальную версию дистрибутива GhostBSD, мне не удалось собрать все необходимые зависимости для компиляции игры. Их просто нет в тормозных репозиториях. Я уже молчу про 32-битные дистрибутивы FreeBSD, ибо там репозитории зачастую вообще мертвы. Это неприятная ситуация, потому что я хотел сделать мультиплатформенный установочный пакет для тестов.
Пришлось снова танцевать с бубном. Жаль, конечно, что централизованные репозитории настолько ненадежны, что буквально может оборваться загрузка пакетов в любой момент.
Впрочем, даже собрав зависимости, скомпилировать программу из исходников не удалось. Где там адепты компиляции софта из исходного кода? Наверное, опять пользователь во всём виноват, но ни в коем случае не изначально мёртворождённый подход к распространению софта...
Похоже, версия GCC в FreeBSD отличается от линуксоидной. Такое чувство, будто я вручную мог бы скомпилировать игру быстрее, чем если бы танцевал с бубном вокруг этих идиотских систем автоматизации из мира Linux.
Изрядно танцуя с бубном мне удалось пройти этап autoreconf без ошибок, однако компиляция всё равно обрывается ошибками. А ещё некоторые осмеливаются заявлять, что нет никакого ада зависимостей в юниксах (Linux/FreeBSD).
Сколько бы проблем я не решал в попытках скомпилировать игру из исходного кода, всегда появлялись новые, усугубляемые крайне ненадёжными репозиториями в сети. Более того, пакетный менеджер постоянно выдавал случайные ошибки, при попытке установить массивный пакет с исходными кодами дистрибутива. Только после того, как я вручную распаковал пакет в файловую систему, пакетный менеджер наконец осилил установку. Даже первые версии Installer-SH не компостировали мне мозги так сильно.
Судя по всему, игру не получится просто так скомпилировать для платформы FreeBSD. Её и под Linux скомпилировать было проблематично. Вот вам и распространение софта в виде исходного кода вместо адекватных и независимых исполняемых файлов.
Теоретически можно было взять порт игры под названием GNUDoku для FreeBSD, но проблема в том, что репозитории проекта мертвы. Кто бы сомневался. Ну а выковыривать предварительно скомпилированные исполняемые файлы в виде pkg-пакетов бессмысленно, ибо они непригодны для распространения по вине ада зависимостей.
Можно было ещё поковыряться в репозиториях в поисках кусков исходного кода портированного проекта, потом как-то воссоединить их и попытаться снова скомпилировать. Но знаете что? Пошло оно подальше. Обойдёмся без FreeBSD на этот раз. Что уж поделать, коль у некоторых разработчиков руки растут непонятно откуда.
Правильный установочный пакет с игрой
Так как игра скомпилирована только для Linux, новый установочный пакет будет мультиархитектурным, поэтому я оставляю соответствующую настройку включенной. Чтобы убедиться, что игре не нужны «костыли» для удержания окна терминала, я поиграл в игру и оценил её поведение. «Костыли» здесь не нужны, ибо выход происходит явным образом по команде пользователя.
Это и отличает правильный установочный пакет от хлама. Как упаковщик, в данном случае я забочусь о том, чтобы программа работала корректно. Ведь однажды собранный пакет в формате Installer-SH будет жить до тех пор, пока существует хоть одна его копия. Это вам не линуксоидные репозитории, бесконечно заражаемые вирусами в аду зависимостей. Тщательно проверенный пакет в формате Installer-SH пользователь может сохранить как доверенный и не надеяться на милость и компетентность владельцев репозиториев.
Также копирую оригинальный архив с исходным кодом в каталог рядом с программой, так как формат распространения под названием Installer-SH позволяет это.
Закинул исполняемые файлы и исходники, немного настроил пакет и упаковал всё в архивы. Ничего сложного. Настоящие разработчики наверняка смогут даже автоматизировать это под свои нужды, пока «линуксоиды» ноют, требуя, чтобы я сделал за них интеграцию со всякими новомодными "пайплайнами".
У меня и так достаточно многое автоматизировано, и меня более чем устраивает текущий вариант сборки, при котором можно и руками собрать и интегрировать в стороннюю систему автоматизации. Было бы желание, остальное — пустой звон.
Всё отлично установилось и запустилось. Это называется правильным способом распространения софта: никаких танцев с пакетными менеджерами, «адом зависимостей», репозиториями и прочим «линуксоидным» мракобесием — просто устанавливаем и играем.
Единственное, ярлыков здесь явно не хватает. Ведь игра консольная, и именно через аргументы командной строки настраивается сложность. Надо бы добавить разные ярлыки — это и называется работой над пользовательским опытом.
Хотя я не создал ярлыки для всех возможных вариантов запуска, основные я выделил. Да и никто не мешает запускать игру через терминал, по старинке.
Так у нас получился распространяемый мультиархитектурный пакет с игрой Nudoku актуальной версии, размером чуть больше одного мегабайта. На сам Installer-SH уходит около 100 килобайт. Одно обновление списка пакетов в линуксовых репозиториях, расходует на порядки больше трафика, чем весит автономный, мультиплатформенный, мультиархитектурный, самодостаточный и крайне жизнеспособный Installer-SH. Не это ли достойно называться будущим распространения софта для Linux и FreeBSD?
Тестирование
Пакет собран, осталось протестировать его в разнообразных дистрибутивах Linux. Так как мне не удалось скомпилировать игру под платформу FreeBSD, список операционных систем будет скорректирован с учётом реальной ситуации. В информации об игре уже заявлена совместимость с Debian 7+ и Fedora 20+, с этих дистрибутивов мы и начнём.
Для тестирования будем использовать виртуальную машину, а устанавливать игру — прямо в режиме Live CD. У меня нет столько свободного места на SSD, чтобы полноценно устанавливать десятки дистрибутивов Linux и FreeBSD. Оперативной памяти можно было выделить меньше, ибо 16 гигабайт на каждую виртуальную машину — избыточно, но оставим как есть, так как современные дистрибутивы Linux, вроде Ubuntu, потребляют очень много оперативной памяти.
Debian 7 (x86/x86_64) и Fedora 20 (x86_64)
Без каких-либо проблем удалось установить, запустить и удалить игру в 64-битном дистрибутиве Debian 7, как в стандартном режиме установки в домашний каталог пользователя, так и при установке для всех пользователей.
То же самое проворачиваю в 32-битном дистрибутиве Debian 7, а для разнообразия устанавливаю, используя тихий режим. Что немаловажно, установка происходит прямо из виртуального CD-привода. Мне просто было лень копировать установочный пакет куда-либо перед установкой.
Fedora 20 также проходит тест без проблем.
Gentoo 2016 (x86/x86_64)
Этот дистрибутив Linux отличается от прочих. Это один из самых «сломанных» дистрибутивов Linux из всех, что мне известны. Он настолько «сломан», что у него напрочь отсутствуют даже переменные окружения, отвечающие за локализацию. За это мне и нравится Gentoo 2016 года выпуска. Впрочем, даже в такой «кривой» операционной системе мне удалось без проблем установить игру, поиграть в неё и спокойно удалить, наигравшись.
А что до ошибки, связанной с локализацией? Ну, тут я просто добавлю дополнительную проверку в Installer-SH, и всё придёт в норму, насколько это возможно в изначально «поломанном» дистрибутиве Linux.
Вношу исправления не только в новый установочный пакет с игрой, но и в сам Installer-SH. Также проверяю пакет в 32-битной версии дистрибутива Gentoo. Всё устанавливается и работает без проблем.
openSUSE 13.1 (x86/x86_64)
Этот Linux тоже весьма специфичен и проблемен, но Installer-SH прекрасно отработал и установил игру как в 64-битной версии openSUSE, так и в 32-битной.
ROSA Fresh 12.2 (x86_64)
Все основные ветки дистрибутивов Linux уже протестированы, поэтому я решил взять что-то экзотическое. Мне под руку попалась ROSA Fresh уже давно устаревшей версии 12.2.
Я не знаю, живы ли репозитории этого дистрибутива Linux, но разве это важно, когда есть Installer-SH? Игра установлена и прекрасно работает.
Ради интереса я ввёл sudo dnf check-update, чтобы получить список доступных пакетов в репозиториях, если они ещё живы. Без этого невозможно устанавливать софт в систему через пакетный менеджер. Но на получение одних только списков, было растрачено 116 МБ трафика, а в процессе была выдана огромная «простыня», с рядом исключённых пакетов, подсвеченных красным. Не знаю, ошибки это или так надо, но это был просто отвратительный пользовательский опыт.
В итоге мне удалось установить Nudoku из репозиториев; правда, версия давно устарела, и общий объём скачивания превысил 116 МБ просто для установки игры. При этом полученный пакет нежизнеспособен за пределами конкретного дистрибутива и архитектуры. Тем временем актуальная версия игры Nudoku в формате Installer-SH не зависит от конкретного дистрибутива и архитектуры, а весит пакет всего 1,1 МБ, что в 105 раз меньше, чем версия, полученная из репозиториев Linux.
Некоторые начнут возмущаться: мол, нечестно считать служебную информацию общим размером устанавливаемой игры. Но вот в чём нюанс: Installer-SH — самодостаточный формат, он несёт всё необходимое в себе, тогда как пакетные менеджеры из мира Linux просто не смогут работать без этой массы служебной информации. Будет ли честно сравнивать нерабочий «линуксоидный» пакетный менеджер с рабочим Installer-SH? Не думаю.
NixOS 23 (x86_64)
У меня тут ещё завалялся какой-то NixOS, и вот тут Installer-SH завершал работу, ругаясь на недостатки операционной системы. Но даже так, отключив недостаточно проработанные проверки, мне удалось установить игру даже в столь специфическом дистрибутиве Linux.
Небольшое исправление — и мой перспективный формат распространения софта стал совместимым даже со специфической NixOS.
Кстати, как там поживает Flatpak, самопровозглашаемый будущим распространения софта для Linux? Да никак. Он просто не поддерживается данным дистрибутивом Linux. Судя по всему, настоящее будущее — за Installer-SH, если судить по результатам реального использования.
FreeBSD
Так как игру не удалось скомпилировать под эту платформу, я установлю сам Installer-SH.
Однако выявилась проблема при запуске деинсталлятора: она заключалась в экранировании внутри команды sed. Оно отличается от GNU-версии, поэтому для быстрого исправления придётся отказаться от экранирования. Да, так пути с пробелами будут доставлять неудобства, но, опять же, использование таких символов в именах каталогов при установке и так являлось недопустимым. Так что доработку экранирования оставим для будущих версий Installer-SH, а ошибку исправим сейчас.
Заодно исправлю досадную опечатку, ибо осталась старая версия в переменной базового имени программы. Придётся обновить уже выпущенные пакеты, заменив их исправленными. Не люблю я этого делать, но вариантов нет. Выявленные ошибки нельзя оставлять. Это говорит лишь о том, что каким бы надёжным ни был Installer-SH, всегда есть куда его улучшать.
Заключение
Полагаю, на этом можно выпустить релизную версию Installer-SH.
Также загружаю собранный пакет с игрой в репозиторий Chimbalix-Software-Catalog.
https://github.com/Shedou/Chimbalix-Software-Catalog/releases/tag/nudoku800
В очередной раз была доказана несостоятельность обычных способов распространения ПО в виде исходного кода и через пакетные менеджеры. Перспективный формат под названием Installer-SH в очередной раз подтвердил на практике своё превосходство над прочими форматами из мира Linux и FreeBSD.
Installer-SH прекрасно себя чувствует даже там, где Flatpak, Snap и прочие пакетные менеджеры бессильны. Именно так должен работать настоящий формат распространения софта. Неудивительно, что хейтеры из мира Linux уже пытаются навредить проекту Installer-SH, ведь он действительно работает и решает реальные проблемы экосистемы. На этом завершим статью.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Читайте далее на сайте
Релиз видеоигры Outward 2 перенесли на 2027 год
Lexar предложила запускать ИИ-модели на ПК с меньшим объёмом оперативной памяти
JetZero построит в Северной Каролине завод для выпуска самолётов Z4 с экономией топлива 50%