Почему разработка софта для Linux это сущий кошмар на примере Installer-SH для Chimbalix

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

Да, с маленькими и простыми архивами размером 50-100КиБ утилита прекрасно справлялась, но стоило мне создать установочный пакет с массивным и сложным приложением, как начали выявляться серьёзные проблемы:

Так всегда с линуксами, сразу всё вроде прекрасно, а потом как начинается всякое дерьмо то тут, то там...

Так и с утилитой archivemount, сначала вроде всё прекрасно, а потом как началось! Сначала выявилась проблема крайне низкой скорости доступа к файлам смонтированного архива. Насколько это ужасно? Настолько, что устанавливать любой массивный софт просто невозможно: скорости менее 100 КиБ/с:

Но скорость это ещё не самое страшное, эту проблему можно частично решить используя tar без сжатия, но о быстрой установке приложений размером более 2 ГиБ речи, конечно же не идёт.

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

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

Как говорится - "Linux is only free if your time has no value" (Linux бесплатен только в том случае, если ваше время ничего не стоит), видимо не просто так любителей линукса называют "красноглазиками"...

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

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

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

Спустя некоторое время произошёл конфликт с версией зависимости rustc, классика линуксов, идём танцевать с бубном над зависимостью, максимальная версия которой в линуксоидских репозиториях ниже, чем нужна для компиляции, а это значит лишь то, что нужно вручную искать нужную версию и каким-то образом скармливать:

В общем уничтожил DEB версию rustc, чтобы не конфликтовала с тем, что я собираюсь сделать, и подсунул костылями всё что надо было, но устранив одну линуксоидную зависимость - получил ещё немного дерьма с другой зависимостью:

Ух...

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

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

Чуть шаг в сторону и всё рассыпается: в хвалёном Open-Source, нельзя просто взять, и скомпилировать какое-либо приложение из исходного кода, даже если взять из репозитория соответствующего текущему запущенному "линуксу", наверняка будут какие-то зависимости, без которых всё изойдёт ошибками.

В итоге было решено полностью переработать структуру скрипта установки приложений, отказаться от кривых возможностей линуксов в плане монтирования архивов, и в какую же сторону пойти? Правильно, в сторону инструментов от адекватных разработчиков, что выпускают адекватные и независимые по большей части исполняемые файлы, буду теперь полагаться на 7-zip архиватор от Igor Pavlov:

Причём я не буду полагаться на линуксоидное извращённое мракобесие под названием p7zip аж 2016 года, что занимает в линуксах исполняемое имя "7z", и обычно используется по умолчанию, ведь от него зависят такие архиваторы как engrampa, file-roller и dtrx (может быть и другие):

И да, если подменить линуксоидный p7zip нормальным 7-zip, это так же поломает зависимые архиваторы, так что увы, но оно намертво прибито гвоздями к "линуксу"...

Потому я буду использовать портативную, статически скомпилированную версию 7-zip 2024 года, ибо пошли эти линуксоидные зависимости куда подальше, тем более новая версия архиватора значительно быстрее старых:

Так как всё равно нужно всё переделывать, я подумал, и решил обойтись без монтирования архивов, а это значит придётся разбивать всё что ранее было одним единым архивом, потому все файлы размещу в каталоге installer-data рядом со скриптом установки, так будет хоть какой-то порядок:

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

В каталоге installer-data я пришёл к структуре из трёх каталогов, которые потом будут паковаться в отдельные архивы специально подготовленным скриптом (пока не готов), program_files отвечает за файлы приложения, они будут просто распакованы в каталог назначения, system_files содержит в себе файлы меню и бинарные "ярлыки", они будут подготавливаться в процессе установки отдельно в зависимости от настроек:

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

Ну а в папке tools сейчас находится 7-zip архиватор, мне не хотелось нести вместе с установочным архивом бинарные файлы, ведь под линуксами всякое дерьмо может произойти на ровном месте, например слетят права для запуска, а это значит придётся писать дополнительный код для решения всевозможных линуксоидных проблем, но это всяко лучше, чем полагаться на болото зависимостей.

Файл шаблона "uninstall.sh" было решено перенести в каталог приложения, ибо другого места ему не нашлось, а это значит, что подготавливаться файл будет прямо в папке приложения, ранее это делалось во временном каталоге:

Разумеется никто сейчас не будет переписывать основной скрипт, сейчас важнее сформировать новый "скелет".

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

В любом случае надо начать набрасывать скрипт:

Можно конечно извращаться с tar.xz, чтобы не носить с установочным пакетом 7-zip, но этот формат в разы больше ресурсов расходует, и соответственно медленнее работает, короче нецелесообразен.

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

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

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

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

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

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

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

Что насчёт интерфейса пользователя? Про терминальный dpkg я вообще молчу, давайте посмотрим на более развитые варианты, и... Ну такое себе, на "красноглазика":

Даже размер приложения после установки взят с потолка, что за 2079? В какой это единице измерения? А это с учётом зависимостей? А то я часто замечал враньё со стороны центров приложений в линуксах, когда показывают размер приложения условные 50 МиБ, а по факту скачивается полтора гигабайта зависимостей для работы 50 мегабайтного приложения...

В конце концов, как указанный в DEB пакете размер (2079) соотносится с реальными 1.5 МиБ, которые действительно будет занимать приложение? Даже в таких мелочах DEB работает как кривая поделка:

Зачем линуксоиды вообще создали поле "installed size", если оно показывает температуру по Фаренгейту на экзопланете CoRoT-7b?

Про всякие Flatpak и прочее подобное дерьмо я вообще промолчу, у них даже скачать установочные файлы невозможно бывает по-человечески, по сути даже хуже DEB, особенно если учесть, что всякие "флатпаки", более ущербные в плане работы приложений.

Так что увы, но велосипед велосипеду рознь, я не хочу ездить на линуксоидных велосипедах с квадратными колёсами и рулём вместо седла.

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

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