Продолжаю разбор сгенерированных ИИ сообщений об ошибках и улучшение проекта Installer-SH

В прошлых частях мы уже разобрали семь тикетов в общей сложности. Каждый тикет представляет собой массив текста, сгенерированный с помощью ИИ. Такой флуд-атакой хейтеры, судя по всему, попытались навредить перспективному способу распространения софта для Linux и FreeBSD под названием Installer-SH: человек, создавший сообщения, вёл себя весьма агрессивно и некультурно, мягко говоря. Он даже не занимался проверкой генерации, из-за чего часть тикетов была настолько бесполезной, что буквально указывала на несуществующие проблемы. Многие разработчики, скорее всего, просто удалили бы такую пачку сгенерированных сообщений об ошибках, но я попытался извлечь из этой ситуации пользу.

Больше мы не будем подробно останавливаться на деструктивном поведении хейтеров, ведь у нас впереди ещё целых 40 сообщений в разделе Issues проекта Installer-SH. Так что перейдём сразу к делу, так как каждое из этих сообщений является сгенерированным и непроверенным.

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

Issue #48

Давайте начнём с чего-то простого. Хотя суть тикета и является тривиальной, нейронная сеть раздула всё на целую «простыню» формата А4. А всё потому, что хейтеры, устроившие флуд-атаку на репозиторий, явно не были заинтересованы в качестве сообщений. Ранее я критиковал разработчиков, начавших войну против тикетов и ПО, созданных с помощью ИИ, но думаю, мне не нужно объяснять, почему они так поступили. Впрочем, я не собираюсь примыкать к их рядам. Глупо полностью отказываться от ИИ, но текущая флуд-атака нагляднейшим образом доказывает: без контроля со стороны человека нейросети могут генерировать тонны бессмысленного шума.

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

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

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

Вроде и мелочь, а сколько времени было затрачено на анализ и правильное исправление недочёта размером в две лишние строки кода...

Issue #42

Я долго пытался понять, какие грибы курила нейронная сеть у хейтеров, когда генерировала тикет под номером 42, но так и не понял...

Данный issue представляет собой отборную галлюцинацию, потому что он указывает на несуществующие участки кода и объясняет несуществующую проблему. Закрываем без каких-либо исправлений. Мне не удалось извлечь из этой информации ничего полезного.

Issue #40 и #7

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

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

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

Однако есть и сообщение под номером 7 с темой «хелперов», и вот оно уже действительно указывает на реальную ошибку в коде.

Вносим изменения и закрываем седьмой номер как исправленный.

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

Issue #22

Следующий тикет указывает на опечатки в файле русской локализации. Выглядит как очень лёгкая задача для решения.

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

Issue #44

Тут у нас претензии к наименованию переменной UseMD5, указывающей на то, что должна использоваться утилита md5 (платформа FreeBSD), а не утилита md5sum (Linux). На самом деле это сообщение указывает на несуществующую проблему, так как не планируется вводить функционал, отключающий проверку целостности пакета, и упаковщикам незачем трогать данную переменную, что бы ни рассказывал ИИ. Даже если я и решу ввести функционал отключения проверки целостности, эта переменная уж точно не помешает.

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

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

Issue #41

Данный тикет трактует намеренную и осознанную реализацию как ошибку. В написании слова «clearinG» ошибки нет. Это было сделано специально, чтобы визуально похожие элементы легко различались, так как слова «Clearing» и «Creating» выглядят крайне схожими, тогда как «clearinG» и «Creating» выглядят уже совершенно по-разному.

Дальнейшие рассуждения ИИ про команду echo и слово «clearinG» вообще можно отнести к галлюцинациям. Там, где нужно, я и так использую «echo -e», а где не нужно — простое echo. Тут нет никакого смысла использовать printf, если только нет умысла навредить проекту, бессмысленно усложняя и фрагментируя исходный код.

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

Однако здесь можно всё же внести исправление, заменив слово на «deleting» или «removing», но это уже немного исказит смысл сообщения. Ведь его суть — уведомить пользователя об ошибке очистки конкретного временного каталога.

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

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

Issue #38

Следующий отчёт можно было уместить в две строки текста, но нейронная сеть размазала всё на целую страницу формата А4. Суть сводится к тому, что поле TryExec в ярлыке не заполнено.

Это же присутствует в тикете #28. Но до этого тикета, созданного в результате флуд-атаки на репозиторий неугодного проекта, мы доберёмся позже.

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

Issue #39

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

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

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

За текущую серию мы разобрали целых девять тикетов. Несмотря на то что все эти тикеты были сгенерированы ради флуд-атаки на репозиторий неугодного проекта, мне, как автору перспективного формата распространения ПО для Linux и FreeBSD, уже удалось извлечь реальную пользу. Хейтеры явно хотели навредить проекту, потому что с добрыми намерениями никто не будет врываться в чужой монастырь, раскидывая мебель и рисуя на стенах. Но таков уж Open Source. Пусть я сам так не поступаю, но вот «сообщество» очень даже не брезгует подобными варварскими методами давления на открытые проекты.

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

Забавный факт: человек пришел с предложением на печально известный ресурс под названием «ЛОР», а его просто назвали клоуном... Браво, сообщество Linux!

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