О последствиях использования искусственного интеллекта в Open Source

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

Разумеется, аккаунт пользователя, совершившего флуд-атаку, был обоснованно заблокирован. Стоит отметить: несмотря на агрессивное и недостойное поведение (угрозы, шантаж, оскорбления, обесценивание работы и т. п.), я неоднократно предоставлял возможность этому пользователю начать конструктивный диалог. Но своим поведением он ясно дал понять, что никакого конструктива не будет, потому что пришел лишь с целью всячески навредить проекту.

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

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

Issue #15

Начнём текущий выпуск с тикета #15. В нём перечислено несколько замечаний относительно скрипта pack_archive. Основное замечание касается использования неопределённой переменной. Второе касается отсутствия флага -r при работе с командой read. Ну а вишенка на торте — это претензия к логике записи хэшей в текстовый файл.

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

Закрываем тикет #15 без изменений.

Issue #16

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

Ошибка действительно есть, однако она является чисто визуальной. При разработке я в первую очередь думаю о том, чтобы всё работало с технической стороны. Именно поэтому мой Installer-SH, несмотря на 47 сгенерированных issues, исправно работает и проходит испытания в реальном использовании.

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

Issue #13

Следующая претензия относится к опечатке в исходном коде скрипта "for-tests-in-VM-create-PortSoft-in-RAM". Вместо "echo -e" написано "echo -у".

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

Короче говоря, проблема вроде и есть, но в то же время нет. Эта опечатка точно не стоит сгенерированной простыни текста в виде issue #13. Можно было обойтись парой предложений, указав на конкретную опечатку. Да и не ломает эта опечатка форматирование вывода, как уверяла нейронная сеть. Если бы ломала, я бы это и сам обнаружил.

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

Issue #4

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

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

У меня набралось довольно много аргументов запуска, думаю, есть смысл переработать свою первую реализацию проверки аргументов.

После исправлений всё работает по конкретным именам аргументов без пересечений, хотя выглядит довольно нагромождённо. Стоит ли перейти на использование более сложного case вместо простого и понятного if? Даже не знаю. Думаю, пока нет смысла усложнять визуальное и логическое восприятие кода переходом на конструкцию case.

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

Issue #35

Сообщение #35 указывает на имя локальной переменной, в которую записывается список выявленных конфликтов перед установкой программы. Оно не понравилось нейронной сети. В этом вся суть здоровенной текстовой простыни от ИИ...

ИИ там ещё серьёзно рассказывает про разработчиков, якобы способных запутаться в десяти строках кода с обозначенной переменной. Думаю, если разработчик запутается в простой функции на два десятка строк кода, то такому разработчику вообще нечего делать в разработке ПО. Более того, переменная находится в локальной области видимости и буквально три раза используется. Я, конечно, изменил её название, но это по своей сути было «дурной работой». Зачем ради этого создавать целую объяснительную простыню из текста? Точно, все эти тикеты ведь были сгенерированы хейтерами не для того, чтобы помочь проекту, а чтобы навредить.

Каков тикет — таково и исправление. Меня больше забавляет, что вместо решения более существенных нюансов, вроде излишне определённых переменных в качестве локальных, нейросеть в руках хейтеров придирается к названиям переменных. Это многое говорит о «компетентности» тех самых хейтеров, напавших на проект Installer-SH. К самому искусственному интеллекту тут претензий нет, ибо это следствие квалификации людей, возомнивших себя самыми умными. В итоге имеем придирки с высосанными из пальца обоснованиями под видом решения серьёзных проблем.

Issue #27

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

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

Issue #6

Давайте рассмотрим что-то более полезное. В шестом тикете говорится про ошибку в костыле для систем, у которых слетают права на файл после работы утилиты sed. Вариант команды для FreeBSD должен проверять значение 100744 вместо линуксоидного 744. Технически всё работает даже с ошибкой в условии, разве что создаёт лишние вызовы на установку правильных прав доступа.

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

Issue #3

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

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

И да, сообщение подтвердилось на практике. Как эта проблема оказалась незамеченной? Правильно, потому что я никогда не сжимал форматом tar.xz крупные программы, при сжатии которых можно было бы заметить неладное. А при сжатии маленьких пакетов размером в несколько мегабайт разницы особой нет.

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

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

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

Issue #11

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

Я уже объяснял, почему были отключены старые функции и разработана новая. Если вкратце: старые функции работали слишком агрессивно и не охватывали все рабочие окружения, так как некоторые рабочие окружения просто не имеют адекватных функций обновления меню или ломались при попытке обновления через «костыли». Именно поэтому старые реализации корректно работали только в LXDE, XFCE и KDE.

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

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

Так что отклоняем тикет, потому что эта проблема высосана из пальца.

Issue #14

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

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

Issue #10

Тут замечание касается новой функции обновления меню приложений после установки софта. Забыл добавить sudo перед утилитой update-desktop-database в системном режиме установки. Радует, что обошлось почти без воды в этом репорте.

Issue #8

Что-то я увлёкся обработкой самых лучших тикетов из сгенерированных, как бы не оставить напоследок худшие и водянистые... Ладно, тут у нас претензия к команде mv с линуксоидным аргументом -T, который не понимают базовые утилиты FreeBSD.

Просто убираю параметр -T при операции перемещения, так как он больше не нужен. Таким образом добиваюсь хорошей совместимости как с Linux, так и с FreeBSD без лишних проверок.

Issue #34

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

Хотя на функционал это не влияет, опечатка действительно неприятная, так что исправляем.

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

На этот раз было закрыто порядка тринадцати сообщений в разделе Issues проекта Installer-SH. Ещё 18 тикетов остались открытыми. Но на этом я закончу в данной статье.

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

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

Следите за обновлениями, чтобы не пропустить продолжение этого разбора.

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