Рассматриваю проблемы проекта Installer-SH в разделе Issues на платформе GitHub

Недавно была доработана и выпущена новая версия формата распространения ПО для Linux и FreeBSD под названием Installer-SH. После этого в формат Installer-SH был успешно перепакован графический редактор Krita. В результате удалось сжать тринадцать версий графического редактора за 10 лет истории выпуска, в единый установочный пакет размером всего ~740 МБ, тогда как эти же версии программы в исходном формате AppImage при хранении весили ~2,5 ГБ.

Более того, новость о выпуске Installer-SH 2.8 была опубликована и на ресурсе OpenNET, администрация которого действительно работает и выполняет свои обязанности согласно правилам ресурса, в отличие от печально известного примера.

Но сейчас речь не об этом. Installer-SH отлично проявил себя как формат распространения ПО, оставив позади все прочие протестированные способы из мира Linux и FreeBSD. Я надеялся ещё какое-то время оставаться в тени и спокойно работать над проектом в одиночку, продолжая совершенствовать его и внедрять новый функционал, не забывая про исправление ошибок. Но на проект уже обратили внимание.

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

С первой же страницы отчётливо видна закономерность: сообщения от пользователя NeonCatRC явно сгенерированы автоматически, так как все они были опубликованы за очень короткий промежуток времени — менее чем за полчаса. Человек не может так быстро написать 47 сообщений с детальными заголовками, если только не подготовился заранее. Но тут серьёзной подготовкой и не пахнет.

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

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

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

Туда же и сообщение под номером 43. Костыль для поломанных дистрибутивов Linux действительно указывает на каталог portsoft в домашней директории пользователя, и никуда иначе. Это логично, учитывая, что инсталлятор предназначен в первую очередь для установки софта именно в домашней директории пользователя. Ломает ли это что-либо, если программа установлена в системном режиме, как заявлено в заголовке так называемой проблемы? Конечно, нет.

Даже если пользователь полностью проигнорировал рекомендуемые режимы установки и упорно всё устанавливал с root-правами, в специальную директорию в корне файловой системы, это ничего не ломает. Да, зайти в каталог не выйдет, но к критическим сбоям это не приводит. Сам костыль от этого не поломается и будет выполнять своё прямое назначение в «поломанных» дистрибутивах Linux, чтобы у пользователя не пропадал раздел в меню приложений, из-за косяков разработчиков дистрибутивов.

Особенно позабавило сообщение под номером 41, указывающее якобы на опечатку, хотя на самом деле оно написано именно так, чтобы пользователь или разработчик визуально не перепутали схожие по написанию слова «clearing» и «creating», если столкнутся с данным сообщением. Да и следующее сообщение, под номером 40, тоже абсурдно, потому что это всего лишь пример для упаковщиков, требующий соответствующей настройки. Оно даже не используется, пока не будет активировано в настройках пакета.

Сомнений больше не осталось: все эти сообщения однозначно сгенерированы искусственным интеллектом, потому что человек, потративший время на изучение проекта, точно не стал бы создавать issue из-за очевидно намеренно оставленных «опечаток» в тексте. Но и списывать со счетов всё это мы не будем, даже если часть сообщений — откровенный мусор.

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

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

Issue #32

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

Речь идёт о файле «for-tests-in-VM-batch-install.sh», предназначенном для упрощения тестирования пакетов. Данный скрипт требует предварительной настройки, но суть не в этом. Заявляется, что в этом скрипте есть опечатка, и она действительно есть; правда, никакого вреда она не наносит, от слова «совсем».

Основная же претензия кроется во втором аргументе, при вызове функции InstallFile: мол, значение «sss» бессмысленное. Так и есть, значение не имеет смысла, но и оставлять пустую строку не хотелось при вызове функции, требующей два аргумента для работы. Исправление, конечно, внесу, но оно такое же бессмысленное, как и сама претензия, особенно учитывая крайне маленький размер скрипта.

Ну и третья претензия затрагивает две переменные внутри функции: мол, они не объявлены как локальные. Тут претензия вполне обоснованная, однако, учитывая, что она предъявлена в контексте скрипта на 50 строк кода, половина из которых — пустота... Ну не знаю. Для разминки сойдёт, заодно приведу скрипт в более человечный вид. Тем более если кто-то захочет использовать данный скрипт как часть более массивной системы, исправление позволит избежать загрязнения глобальной области видимости (global scope). В таком необычном плане использования, исправление действительно может оказаться полезным.

Было ли полезно данное issue? С практической стороны — нет, так как никаких технических проблем оно не решило, хотя и было с пометкой «BUG». О чём, к слову, сказано в конце сообщения: выявленные нюансы не оказывают никакого функционального влияния.

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

Может показаться, что я обесцениваю сообщения об ошибках и как-то возвышаюсь над всем этим. Нет. Тут просто нет никакой практической пользы от внесённых исправлений при использовании скрипта так, как задумано. Но в любом случае вношу исправления и закрываю «проблему», так как хуже точно не стало.

Issue #29

Перейдем к сообщению под номером 29, которое затрагивает файл "for-tests-in-VM-create-PortSoft-in-RAM.sh", также предназначенный для упрощения задачи тестирования собираемых пакетов. Основные замечания заключаются в том, что в коде нет проверок данных, вводимых пользователем при выборе размера выделяемой памяти под файловую систему, нет проверок на ошибки при выполнении операций mkdir и mv, а также отмечена возможность коллизии при многократном запуске скрипта.

Переменная RANDOM действительно предоставляет всего 32 тысячи значений, что при многократном запуске может привести к коллизии имён. Но проблема в том, что данный скрипт предназначен для однократного использования в виртуальной машине и только при необходимости. Снова ИИ не учитывает контекст и назначение инструмента.

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

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

Ну а остальное было серьёзно переработано вручную, так как простыми исправлениями там было не обойтись. После переработки я обратился к локальному ИИ ёмкостью 7.5 миллиарда параметров для дополнительной проверки и оценки получившегося скрипта. Одна голова — хорошо, но вторая может обнаружить проблемы, не замеченные первой.

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

Ну а после я протестировал скрипт в реальных условиях. Всё работает правильно.

Таким образом, мы успешно закрыли 29-е обращение.

Продолжение следует...

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

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

У меня нет времени заниматься исключительно проектом Installer-SH, разгребая полученные замечания относительно исходного кода. Однако двумя проблемами стало меньше, так постепенно можно обработать и остальные сообщения. Но это уже оставим для следующих статей.

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

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