Внимание! Это продолжение предыдущей статьи. Рекомендуется ознакомиться с прошлыми частями для лучшего понимания материала. Здесь я не буду пересказывать содержание предыдущих частей в кратком виде.
Давайте приступим сразу к делу, без лишних вступлений, так как у нас впереди 18 сгенерированных ИИ тикетов, и в каждом из них наверняка осталось много «воды». А в некоторых наверняка ещё и галлюцинации есть. Так что сконцентрируемся на совершенствовании проекта Installer-SH.
Issue #19
Девятнадцатый сгенерированный тикет является бесполезной галлюцинацией ИИ. Хотя, учитывая, что это всё было сгенерировано в ходе флуд-атаки на репозиторий проекта, было бы странно, если бы не было таких тикетов.
Первая претензия затрагивает проверку версии файла локализации перед загрузкой. Мол, если в файле локализации будет несколько переменных с версией, то условие не будет пройдено. Стоит ли говорить, что наличие двух переменных с версиями, само по себе является ненормальной ситуацией? То, что мой старый код отсеивал даже такие ситуации, не является ошибкой, как бы ни оправдывалась нейросеть.
Вторая претензия является повтором тикета #49.
Более того, текущий код уже имеет переработанную проверку версии файла, так что тикет #19 можно закрыть без каких-либо исправлений. Мало того, что он указывал на несуществующую проблему, так ещё и являлся повтором ранее обработанного тикета.
Issue #18
Этот тикет почти полностью является дезинформацией. Третья претензия вполне обоснована. Опечатка в виде лишней точки есть, хоть она и не влияет ни на что. А вот вторая претензия вообще непонятная. Там говорится о том, что может произойти коллизия временных каталогов (шанс астрономически мал), и сразу же предлагается решение в виде добавления дополнительной проверки.
Проблема второй претензии в том, что мои функции очистки временного каталога автоматически вызываются при вызове функции создания временного каталога. Даже если произойдет ситуация, когда останется старый временный каталог и появится шанс наложения, он просто будет очищен автоматически при вызове функции создания нового временного каталога.
Эта довольно хитрая логика реализована уже очень давно и пока ещё не подводила. Более того, функция очистки срабатывает только при наличии временного каталога. В общем, вторая претензия высосана из пальца нейросетью и провоцирует внедрение лишнего кода в проект.
Первая же претензия указывает на использование функции _ERROR вместо _ABORT в случаях, когда архивы с данными не найдены. При этом нейросеть вводит в заблуждение, заявляя, что общая ошибка выводится только на поздних этапах, когда уже начинается установка, а про отсутствующие архивы, якобы, не будет информации.
Следующий скриншот опровергает нейросеть в том, что пользователь узнает только об общей ошибке распаковки на поздних этапах установки. На самом деле ошибки и уведомления об отсутствующих архивах отображаются на первой же странице после запуска инсталлера. До распаковки дело даже не дойдёт, если пользователь вручную не доведёт до этого этапа. Я намеренно сделал эти сообщения обычными ошибками, чтобы упаковщикам было проще проводить отладку и настройку пакетов.
Даже если пользователь попытается установить софт без архивов в тихом режиме, чтобы не видеть ошибки прямо перед глазами, у него ничего не получится, ибо сразу же будет провалена проверка целостности данных.
Такой тикет по-хорошему нужно закрыть как полностью несостоятельный. Но там был пункт про одну опечатку в один символ, поэтому технически он является полезным и заслуживает обычного закрытия.
Issue #33
Два предыдущих тикета оказались «водянистыми», с примесью галлюцинаций и даже какой-то паники, провоцирующей меня на поспешное внедрение лишнего и ненужного кода в проект. В очередной раз можно понять разработчиков, отвергающих сгенерированные ИИ сообщения об ошибках и предложения внести исправления в код. Как выяснилось, галлюцинациями нейросетей даже в 2024 году злоупотребляли при написании тикетов к открытым проектам. Забавная ситуация, а ещё забавнее тот факт, что и я столкнулся с этим. Впрочем, опыт лишним никогда не будет. Другой вопрос — примкну ли я к рядам разработчиков, выступающих против ИИ, даже несмотря на некоторую пользу при правильном взаимодействии с нейросетями.
Давайте вернёмся к тикету #33. Тут огромная водянистая простыня вокруг ошибки с установкой прав на файл с настройками. Ничего критичного в этой ошибке нет, однако она есть и её исправление не представляет сложности. А вы думали, я просто так отвлёкся на забавную ситуацию с нейросетями и открытыми проектами выше? Просто текущий тикет оказался слишком водянистым и неинтересным.
Впрочем, я не только исправил задаваемые права, но и сделал проверку прав после каждого использования sed вместо однократного применения. Старый вариант кода позволил бы произвести только одну замену в условиях работы с поломанным и кривым дистрибутивом Linux. Тикет вроде и затрагивает функцию, в которой я исправил реальный баг, но нейросеть про этот баг ничего не написала в своей простыне.
Issue #47
Тут нейросеть в очередной раз создаёт несуществующие проблемы. Да, избыточное определение переменных в локальной области видимости выглядит некрасиво, и по-хорошему нужно весь код перепроверить на избыточность/недостаточность локальных определений, а не одну функцию из тикета. Но это не является багом, как заявляет ИИ. Технически оно работает правильно, так что называть это багом некорректно.
Можно было просто указать на наличие избыточно определённых переменных в локальной области видимости, приведя несколько примеров, а не разводить эту «воду» про гипотетические последствия так называемого «бага», цепляясь за одну конкретную функцию.
Issue #31
Давайте поищем что-то более полезное. Следующий тикет затрагивает файл деинсталлятора. Замечания насчёт обновления базы данных меню вполне обоснованы. Но решение, предложенное искусственным интеллектом, мне не нравится.
Да и нейросеть тут не видит более серьёзной проблемы, а именно: деинсталлятор продолжает работу, если софт был установлен в системном режиме, а пользователь уже провалил первый запрос системы на повышение привилегий. Если пользователь на новый запрос вспомнит root-пароль, то часть файлов останется как мусор и не будет удалена. Ничего особо опасного в этом нет, но я больше ожидал описания подобных настоящих багов, а не того, что уже выдано в тикете.
Закрываем #31 как исправленный. Не знаю, найду ли я в оставшихся 13 тикетах что-нибудь, относящееся к багу с продолжением работы деинсталлятора после отказа в повышении привилегий от системы. Но если найду, то просто закрою как исправленный, сославшись на текущий тикет.
И да, проблему обновления базы данных меню я решил гораздо более изящным и надёжным методом, не требующим лишнего вмешательства извне, до которого ИИ не додумался.
Issue #21
Данный тикет выглядит обоснованным, но предложенное решение в прямом смысле является ошибкой, а само сообщение — бредом, оторванным от контекста. Суть претензии в том, что аргумент forcemenu (производит только обновление меню) вызывает сначала функцию проверки рабочего окружения, и в ней все сообщения оказываются пустыми, так как локализация не загружается перед выполнением функции.
Да, строки действительно будут пустыми без инициализации функции локализации, однако в контексте данного параметра запуска всё работает как положено, потому что оно не должно жаловаться и выводить какие-либо сообщения. Оно должно тихо обновить меню, загрузив лишь самый минимум, необходимый для этого действия. Именно это оно и делает.
Особенно позабавило меня предложенное решение несуществующей проблемы, где первым делом загружается локализация и только потом инициализируются стили шрифтов, когда должно быть наоборот.
Правильным исправлением будет вообще убрать проверку рабочего окружения перед вызовом функции обновления меню, так как текущая версия функции является самостоятельной.
Issue #17
Сейчас мы имеем дело с очередной галлюцинацией под видом серьёзной проблемы. Нейросеть права в том, что подготовка системы происходит до того, как пользователь выберет режим установки. Но настоящая проблема в том, что тут нет никакой проблемы. Это обычный механизм работы инсталлера: в первую очередь опираться на зашитый в инсталлер режим работы и уже потом обрабатывать выбор пользователя.
Более того, в разделе Reverse scenario нейросеть рассказывает про несуществующую проблему. Там заявляется, что если инсталлер настроен на системный режим, то смена режима пользователем приведёт к проблемам. На самом деле, даже если инсталлер настроен на системный режим установки, то изменение режима пользователем ничего не поломает, потому что в коде есть дополнительные проверки.
Полагаю, нейросеть начала фантазировать только для того, чтобы обосновать прикреплённую метку «BUG» в заголовке тикета. Тем не менее, в этом тикете есть доля пользы. Ведь можно улучшить пользовательский опыт, просто переместив проверку каталогов PortSoft после всех принятых пользователем решений.
Ну а чтобы всё работало правильно, я вынес проверку за пределы условия тихого режима в функции последнего подтверждения. И это архитектурное решение решает ещё не обнаруженные потенциальные проблемы, связанные с проверкой системных основ.
Issue #12
Следующему тикету необоснованно присвоена метка «BUG», потому что с технической стороны работа никак не нарушается. Почему я раньше не задумался о том, что нейросеть довольно часто необоснованно присваивает метки тикетам или обосновывает их галлюцинациями?
Да, в локализации осталось устаревшее имя переменной, указывающее на текущую архитектуру, а должно указывать на нормализованную архитектуру. Но это даже не меняет сути сообщения об ошибке, которое ещё нужно умудриться получить при нормальном использовании.
Исправление затрагивает лишь файл локализации. Мелочь, но и оставлять это без исправления нет смысла.
Issue #30
Здесь у нас сразу три претензии к коду. Первая претензия относится к условиям проверки и выглядит вполне обоснованной. Но я не просто так инвертировал условие проверки, чтобы при любом некорректном значении этапы пропускались. Этапы настройки, исходя из первоначальной логики, должны отображаться только если они не отключены. Это банальная защита от ошибок при настройке пакета. Впрочем, новые функции уже доказали свою полезность, так что можно и изменить условие согласно предложениям нейросети. Так и код будет проще читать, и новые функции станут активными, пока не будут правильно отключены.
Вторая претензия затрагивает функцию создания распространяемого tar-архива с установочным пакетом формата Installer-SH. Тут уже начинаются галлюцинации. Нейросеть либо не выявила настоящий баг, либо неправильно его интерпретировала. Предложенное исправление ровным счётом ничего не решает.
Ну а третья претензия затрагивала глобально объявленную переменную OLD_IFS, которую следовало объявить локально. В итоге только со второй претензией пришлось повозиться, чтобы понять галлюцинации нейросети. Теперь и недочёты исправлены и архивы создаются в правильных местах с правильным содержимым независимо от каталога запуска.
Issue #26
Снова имеем целый ряд претензий в одном тикете. Первая претензия, к переменной терминала terminal_executable, вполне обоснована. Исправляем. Вторая претензия уже затрагивает не проблему моего проекта, а общую несостоятельность мира Linux, когда терминалы могут работать как попало. Есть некоторые, исторически стандартные вещи которым я следую, и флаг -e при вызове терминала является одной из стандартных вещей в мире Linux. Если какой-то кривой GNOME объявил данный стандартный флаг устаревшим, это не значит, что я должен подстраиваться под него. Это GNOME должен подстраиваться под стандарты, а не все вокруг. Тем более, не забываем про совместимость со старыми ОС.
Более того, нейросеть в очередной раз соврала, заявив, что сообщение не появится и пользователь ничего не увидит при ошибке в современных версиях GNOME. Хоть я крайне не уважаю GNOME как рабочее окружение по множеству причин, ложь можно легко опровергнуть настоящими тестами. Реальная проверка в Ubuntu 24.04.1 LTS показала: сообщение об ошибке выводится как положено.
Следует ли винить ИИ за такие галлюцинации и откровенную дезинформацию? Скорее да, чем нет. Но если учесть контекст использования ИИ хейтерами, ради флуд-атаки на неугодный репозиторий перспективного способа распространения софта для Linux и FreeBSD, то тут не за что винить нейросеть. Тут виноваты только хейтеры, совершившие атаку на репозиторий. Если бы запросы составлялись, а результаты работы проверялись компетентными людьми, то я не сталкивался бы сейчас с таким большим количеством галлюцинаций и водянистых тикетов.
Теоретически, это довольно неплохая уязвимость для внедрения постороннего кода в скрипт через путь к исполняемому файлу. Проблема только в том, что злоумышленнику придётся модифицировать скрипт для внедрения вредоносного кода, ибо пути как раз определяются в скрипте лаунчера и я не предусмотрел механизмов вмешательства извне в этот процесс.
Да, есть ещё файл настроек, через который можно внедриться в скрипт. Но опять же, какой смысл злоумышленнику искать какое-то случайное приложение и всем этим заниматься, если он и так уже имеет достаточный контроль над системой для махинаций? Зачем, если можно просто подменить какой-нибудь системный ярлык вредоносным, на примере Ubuntu и при этом пользователь ещё выдаст root-права?
Сначала я думал сократить команду при вызове терминала, убрать лишние точки внедрения и всё такое, но это никак не увеличило бы безопасность в реальном использовании, только серьёзно навредило бы функциональности проекта. Если упаковщик задействует спецсимволы в путях, то это уже само по себе проблема и вопросы к компетентности упаковщика. А если система скомпрометирована, то никакие потуги со стороны лаунчера случайной программы не помогут. Тут уже область работы антивируса, а не формата распространения ПО.
Как раз для антивирусов мой формат под названием Installer-SH крайне дружелюбен, так как скрипты и архивы легко доступны для анализа, в отличие от непрозрачных в техническом плане AppImage, Flatpak и Snap. Злоумышленники всегда выпускали вредоносное ПО, выпускают и будут выпускать. Это лишь вопрос времени, когда мой формат так же будет использован злоумышленниками, как и все прочие.
Хочу я этого или нет, но мне нет смысла бороться с этим явлением, ибо это уже не моя область работы. Да и не смогу я сделать полностью безопасную систему, даже если всё сделаю с нуля, включая аппаратную платформу. Системой нужно пользоваться, а не бесконечно гнаться за недостижимыми идеалами и целями. Жаль, линуксоиды не понимают этого, иначе Linux не стагнировал бы в конвульсиях тридцать лет подряд, а мне не приходилось бы разрабатывать свой способ распространения софта.
В общем, закрываю тикет почти без изменений, ибо нейросеть нагоняет жути в тикете, а ведёт это всё лишь к ущемлению функционала и удобства использования. Может быть, потом ещё подниму этот нюанс, но не сейчас. И так слишком много внимания уделил тикету.
Issue #36
Здесь у нас претензии к стилям шрифтов в терминале. В тикете заявлено, что можно убрать отдельный сброс цвета и применить полный сброс стилей одной командой. Нейросеть развела целый океан воды, объясняя, почему она права.
В целом ИИ прав: можно избавиться от «лишней» команды очистки цвета, заменив её предложенным вариантом полного сброса. Только вот проблема — оформление поломалось. А как так? Ведь ИИ с умным видом заявлял ранее, что разделение сброса оформления на две разные команды якобы ломало оформление и вообще было неправильным.
Увы, но это был очередной тикет ради тикета. Так что закрою его без изменений, потому что с оформлением проблем нет: оно работает ровно так, как было задумано, а предложения в тикете лишь ломают всё. Может быть, потом я займусь переработкой функций оформления, если в этом будет необходимость: уберу всё лишнее и неиспользуемое, сделаю проще и понятнее. Но сейчас я точно не собираюсь переписывать уже созданную и исправно работающую систему оформления, что бы там ни писала ИИ.
Issue #9
Это уже не первый раз, когда проблемы, связанные с одной темой, разбиваются по совершенно разным тикетам. Закрываем, так как это уже исправлено при обработке тикета #49.
Issue #24
Здесь у нас уже тикет по делу, если судить с первого взгляда. Давайте разбираться. В целом замечания вполне обоснованные. Хотя описанные проблемы и не встречаются при обычном использовании в нормальных условиях, вероятность ненормального стечения факторов всё же не нулевая.
Добавил дополнительные проверки. Заодно удалил пару строк лишнего кода.
Issue #28
У нас осталось всего 5 тикетов в репозитории проекта Installer-SH. Радоваться надо, что осталось так мало, но не тут-то было.
Давайте сразу закроем тикет #28, потому что это компиляция прочих уже решённых сообщений. А чему удивляться, если это всё - часть сгенерированной флуд-атаки на репозиторий перспективного проекта? Таким образом, у нас осталось всего четыре сообщения.
Issue #5, #20, #25 и #46
Осталось разобраться с четырьмя тикетами, только вот остались самые неоднозначные из всех. Все они затрагивают техническую составляющую проекта, причём довольно важные части. И проблема тут в том, что предлагаемые ИИ решения порой просто не работают. Полноценно устранить предъявленные претензии не выйдет парой строчек кода, а связаны они со спецсимволами и пробелами в именах каталогов, в которые происходит установка софта. Впрочем, если поискать информацию в сети, то подобные претензии можно предъявить и ко всяким Flatpak / Snap.
Но сейчас мы имеем дело не с линуксоидными способами распространения софта, а с форматом Installer-SH.
Основная суть претензий в том, что инсталлер не переваривает спецсимволы и пробелы, в путях к каталогу установки. Вообще, это логично, что не следует использовать спецсимволы в именах каталогов. Пробелы тоже представляют некоторую проблему. Но тут важно понимать разницу: сам Installer-SH без проблем работает из каталогов, содержащих спецсимволы и пробелы.
Проблемы начинаются в тот момент, когда кто-то начинает вставлять спецсимволы и пробелы в места не предназначенные для этого. Уникальное имя программы, используемое как шаблон для настройки ярлыков в меню и директории bin, является таким местом.
Прежде всего нужно добавить ещё одно предупреждение, потому что старых предупреждений о важности параметра явно недостаточно. Даже если нейросеть и указывает реальные примеры имён приложений со спецсимволами, это не значит, что их следует вкладывать в имя каталога с исполняемыми файлами.
Однако проблема спецсимволов затрагивает не только техническую сторону, поэтому её придется решить хотя бы частично. По крайней мере, чтобы имена программ могли содержать в себе спецсимволы без последствий. Хотя поле для имени программы не ломается от всякого мусора, а ярлыки сохраняют функциональность, оставлять это на произвол судьбы не стоит. Одно дело — техническая сторона, но совсем другое — лицо устанавливаемой программы.
Допустим, я внесу исправления в функции подготовки деинсталлятора, чтобы она не спотыкалась о спецсимволы. Что это даст в целом?
На самом деле, исправления внесённые согласно тикету #25 ничего не дают, потому что инсталлер даже не дойдёт до функции подготовки деинсталлятора с испорченным названием, ибо застрянет в бесконечном цикле подготовки файлов. Оно просто не сможет переименовать файлы во временном каталоге и цикл из-за этого не завершится.
И да, тикет #5 как раз затрагивает этот цикл, указывая на потенциальную возможность бесконечного исполнения. Правда, предложенное решение проблемы выглядит далеко не лучшим. Удивительно, что в сгенерированном тикете не возникло претензий к самой конструкции из команды sed. А ведь там действительно есть к чему придраться.
Я некоторое время экспериментировал, в итоге получился вариант без использования утилит sed и xargs, а значит, сюрпризов в среде FreeBSD быть не должно. Внизу можно заметить заброшенный вариант, оставленный ещё на этапе формирования. Весь лишний закомментированный код будет удалён после тестов, если новый код докажет свою надёжность.
При нормальном использовании всё отлично установилось в среде FreeBSD, а это значит, что новый код справляется со своей работой.
Но спецсимволы приводят к проблемам. Да, софт установился и работает при ручном запуске лаунчера. Однако на этом всё хорошее заканчивается. Думаю, старый вариант, зависающий при столкновении со спецсимволами, работал гораздо лучше, потому что он не позволял так криво установить программу.
Собственно, в этом нет ничего странного, ведь никто в здравом уме не будет использовать спецсимволы в именах файлов и каталогов устанавливаемых программ, поэтому такие ситуации — из разряда намеренно созданных. Хотя пробелы и не являются сейчас особой проблемой при установке софта, в отличие от спецсимволов, это больше мешает не моему инсталлеру, а операционным системам - правильно обработать разделы меню и ярлыки. Да и скрипту, предназначенному для удаления софта, тоже не по душе приходятся пробелы в именах.
Проблему скрипта удаления можно решить простым экранированием элементов массива, но что делать с рабочими окружениями операционных систем, не воспринимающими мусор?
Новый код, хоть и лучше старого, однако он менее надёжен, как бы противоречиво это ни звучало. По крайней мере, деинсталлятор теперь стал гораздо более надёжным: если кто-то и сделает неправильный пакет, от мусора избавиться не составит труда.
На этом можно закрыть пятый тикет, так как код переработан и вероятность ухода в бесконечный цикл устранена.
Сообщение #46 указывает на соседний код. Заявляется, что конструкция с использованием ls ломается от символа перевода строки в именах файлов. Не представляю, каким нужно быть глупцом, чтобы добавить символ перевода строки в имя файла. Но претензия есть и с этим нужно что-то делать.
Вносим исправление и закрываем предпоследний тикет.
Остался последний номер. Этот тикет примечателен тем, что он буквально, предлагает мне вернуться к старому закомментированному коду, от которого я уже отказался, заменив его лучшим вариантом.
Возвращаться к старому коду сейчас никто не будет, но замечание насчёт разделителей было уместным, так что я внёс исправление.
Спецсимволы в имени ПО
Возвращаясь к спецсимволам в имени программы... Проблема тут уже не в моём инсталлере, а в спецификациях XDG Desktop, которые ломаются при использовании спецсимволов в именах категорий. Я не знаю простых способов решить эту проблему и при этом сохранить структурированность меню, без ущерба для пользовательского опыта.
Можно выделить отдельный шаблон замены, специально для отвязки видимого имени программы от базового. Но у этого подхода есть несколько последствий: упаковщикам придётся учитывать новую переменную, а пользователи могут столкнуться с разными именами для одного раздела меню, если разработчик ПО вдруг сменит видимое имя программы на иное.
Эту проблему можно решить и другим способом, например, создав отдельную функцию для формирования записей, основанных на «грязном» имени программы. Достаточно просто заменить спецсимволы безопасными вариантами. Но зачем всё так усложнять? Я считаю, что тут будет лучше предоставить стороннему упаковщику/разработчику возможность настроить базовые и видимые имена так, как он посчитает необходимым.
Уже пошли улучшения от меня, ведь все тикеты закрыты.
Выглядит этот мусор из спецсимволов некрасиво. Именно поэтому я крайне негативно отношусь к использованию спецсимволов в именах программ и каталогов. Даже если мой инсталлер справляется с этим мракобесием, в отличие от линуксоидных форматов вроде Snap, это не значит, что так нужно делать.
SUDO и заключение
Напоследок нужно внедрить проверку, не запускает ли пользователь инсталлятор с root-правами. На самом деле, Installer-SH не предназначен для использования от имени root и запускать его через sudo не нужно. Пришло время внедрить проверку, потому что инсталлятор сам запрашивает привилегии при установке в системном режиме.
На этом можно закончить разбор сгенерированных ИИ сообщений в репозитории проекта Installer-SH. Хейтеры хотели навредить проекту, организовав флуд-атаку на репозиторий, но в результате инсталлятор стал только совершеннее. Да, времени на разбор сгенерированного флуда было потрачено много, особенно учитывая, что были повторяющиеся и бесполезные тикеты. Однако для меня это был интересный и полезный опыт.
Далеко не каждый разработчик вообще стал бы разбираться с такими безграмотно сгенерированными issues. Так что хейтеры должны быть благодарны за то, что я вообще решил рассмотреть этот поток сомнительного флуда. Всё же большинство тикетов были переполнены водой и галлюцинациями и лишь некоторые, по чистой случайности, были действительно хорошо сформулированы.
Я не спешу выпускать Installer-SH 2.9, потому что нужно сначала упаковать какую-нибудь программу и протестировать её в разных операционных системах. Вдруг будут обнаружены косяки. Но это уже материал для другой статьи.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
Читайте далее на сайте
Видеокарта NVIDIA RTX PRO 6000 Blackwell с 96 ГБ памяти подорожала более чем на 65% до 13 250 $
В США за четыре месяца заблокировали более 75% проектов дата-центров на 130 млрд $