Это продолжение предыдущей статьи; рекомендуется ознакомиться с ней для более полного понимания материала. Если коротко, то на репозиторий оригинального проекта Installer-SH была произведена атака хейтерами. Проект примечателен тем, что уже решает одну из самых серьёзных проблем в мире Linux, а именно — проблему распространения софта. Installer-SH — это новый и перспективный формат распространения софта, уже неоднократно доказавший свою эффективность.
В отличие от традиционных способов распространения ПО, мой Installer-SH уже работает в широком спектре дистрибутивов Linux, а также позволяет создавать мультиплатформенные и мультиархитектурные установочные пакеты. Более того, оба свойства могут быть совмещены в едином пакете формата Installer-SH, что делает все прочие форматы, вроде Flatpak, Snap, AppImage, практически бессмысленными для обычных пользователей.
Разумеется, хейтерам очень не понравилось, что кто-то наконец начал решать реальные и серьёзные проблемы платформы Linux и делает это весьма успешно. В итоге была произведена флуд-атака на репозиторий проекта Installer-SH с помощью сообщений об ошибках в разделе Issues, сгенерированных ИИ. Хейтеры думали, что таким образом смогут меня затравить и манипулировать мною, но не тут-то было. Я просто воспользовался ситуацией в свою пользу и спокойно продолжил развивать свой исправно работающий проект.
В процессе работы над тикетами, со стороны активного недоброжелателя последовала эмоциональная реакция, не подкреплённая техническими аргументами. Я переработал очередной компонент своего инсталлера, тем самым сделав его ещё более надёжным и совершенным, и закрыл два тикета в разделе Issues. Также аргументированно закрыл одно сообщение без каких-либо исправлений, так как в нём был сплошной поток галлюцинаций, оторванных от фактического положения дел. Исправлять там было нечего.
Хейтер такого не выдержал, в ответ выдал некоторое количество некультурного бреда и лишь подтвердил мои предположения, что травля ведётся группой лиц. Хотя он и пытается уверить, что он якобы один-единственный и никакой «группировки» нет. Ещё он рассказывал о том, что они якобы водятся со мной уже порядка семи лет. Что-то не припомню, чтобы я водился с такими личностями целых семь лет. Видел всяких, но чтобы водиться...
Я мог обоснованно заблокировать данного индивида уже после первых его оскорбительных комментариев оставленных в репозитории проекта Installer-SH. Но я решил дать ему шанс реабилитироваться и начать конструктивный диалог по существу. Увы. Ввиду отсутствия конструктива и перехода с его стороны на личные оскорбления, нет возможности продолжать диалог, из-за чего я был вынужден заблокировать его аккаунт.
Тем не менее, я благодарен за создание этих 47 обращений в разделе Issues. Несмотря на тот факт, что значительная их часть являлась непроверенным спамом и галлюцинациями ИИ, этот инцидент помог взглянуть на код под другим углом.
Кроме того, был создан публичный форк, который сам создатель позиционирует как пародийный и направленный на дискредитацию оригинального инсталлятора. Подобные деструктивные действия в мире Open Source, к сожалению, не редкость. Но это уже не мои проблемы, особенно если хейтер решит внедрить вредоносный код в свой форк.
Не удивлюсь, если ему вообще заблокируют аккаунт на платформе GitHub после всего, что он уже натворил: травля, оскорбления, угрозы, шантаж, флуд и создание форка в злонамеренных целях. Ну а для всех остальных, это наглядный пример того, что клон клону рознь в мире Open Source, и некоторые могут быть созданы со злым умыслом, несмотря на красивые философии свободного и открытого ПО.
Более того, он способствует увеличению популярности моего оригинального проекта Installer-SH (https://github.com/Shedou/Installer-SH). Так что пусть потешается. Будет даже немного жалко, если на него обратят внимание модераторы платформы из-за его деструктивного поведения и нарушения правил. Также стоит учитывать риски безопасности: в данном форке, как и в любом другом, может появиться некорректный или вредоносный код.
Вот так Open Source и работает и в этом нет ничего нового. Не я первый и не я последний в этом токсичном круговороте. Подобная нездоровая атмосфера и давление на разработчиков — одна из скрытых проблем экосистемы Open Source. Столкнувшись с необоснованным хейтом, многие авторы перспективных проектов, скорее всего, просто закрывают их или уходят в приватную разработку. Это замедляет развитие независимого софта под Linux, если не откатывает его назад и усиливает позиции крупных корпораций с закрытым кодом, где разработчики защищены от прямого деструктивного вмешательства.
Чтобы не быть голословными, давайте детально разберем очередную партию тикетов и то, как они повлияли на архитектуру Installer-SH.
Возвращаемся к работе над проектом Installer-SH. Давайте пройдёмся по тикетам, имеющим признаки низкого качества репортов (или сгенерированного спама). Напомню: все сообщения в разделе Issues на данный момент сгенерированы исключительно недоброжелателем с помощью нейронных сетей, поэтому никто и не бросается быстро вносить исправления.
Если судить по заголовку, то механизмы оптимизации и отката к рабочему варианту при ошибках выставляются как проблема проекта, которую необходимо исправить. Стоит ли говорить какое недоверие вызывает сообщение с таким заголовком? Потому и нужно тщательно перепроверять такие сгенерированные вбросы, что не каждый разработчик захочет делать.
В сообщении говорится о функции локализации. Основные претензии заключаются в том, что Installer-SH не загружает файл локализации при работе в тихом режиме, а также всегда возвращается к стандартному при ошибках (файл отсутствует, версия не совпадает и т. п.), не уведомляя об этом пользователя.
Только вот проблема: в тихом режиме загружать локализацию нет смысла. Это лишняя трата ресурсов и потенциальная точка отказа в процессе, который при нормальной работе не выводит ни единого символа. Поэтому он и называется тихим режимом.
Там целая простыня сгенерированного текста, но суть сводится к тому, что инсталлятор якобы должен загружать локализации даже в тихом режиме. Ну а при невозможности загрузить подходящий фай, инсталлятор должен выводить пользователю информационное сообщение о причинах, что, к слову, может нарушать работу тихого режима, если внести исправления согласно предложениям в issue.
Как раз для того, чтобы у пользователя не возникало ошибок, упаковщик пакета обязан провести отладку и исправить свои недочёты, если он их допустил. Тем более в инсталлере есть вспомогательные инструменты для тестирования функционала локализации. Зачем делать так, чтобы локали постоянно грузились из файла, даже когда они совершенно не нужны? Ну или мучить пользователей бесконечными предупреждениями о том, что файл локализации не найден?
Это линуксоиды привыкли: тяп-ляп и в продакшен. Installer-SH же, бьёт по рукам за такое безалаберное отношение. Но тут я вижу, что мой инсталлятор недостаточно бьёт по рукам безответственных упаковщиков. Кое-что я всё же возьму на заметку, а именно: уведомление о несоответствии версии файла локализации. Я не собираюсь мучить пользователей бесконечными уведомлениями об отсутствующих файлах локализации под конкретные языки, но вот безответственных упаковщиков лишний раз дёрнуть всегда полезно, чтобы не расслаблялись.
Насчёт загрузки локализации при работе в тихом режиме, ситуация гораздо сложнее. Потому что оно нивелирует имеющуюся оптимизацию и спровоцирует множество лишних обращений к диску, в поисках той самой локализации при массовой установке софта. Вот что значит просто набросать сгенерированные отчёты без должной проверки компетентным человеком.
Вывести ошибку несоответствия версии легко. Гораздо сложнее разработать грамотную систему гибкого подключения локализации в случае прерывания работы тихого режима, о чём хейтер совершенно не подумал, выдав такой сгенерированный отчёт. Тут нужно взвесить сложность реализации, затрагиваемые части кода и определить, целесообразно ли этим вообще заниматься.
Начнем и закончим тем, что мне придется серьезно переписать свой инсталлятор, чтобы внедрить гибкую подгрузку функций локализации при прерывании процесса тихой установки. Тут уже встает выбор между поверхностной реализацией, когда локализация загружается независимо от режима работы, и серьезной переработкой проекта. Можно конечно, оставить как есть, но многим уже известно, что я люблю экспериментировать, если в результате может улучшиться пользовательский опыт, даже если немного пострадает оптимизация.
Попутно я добавил вывод сообщений об ошибках после выполнения в тихом режиме, так как в этом была необходимость. Разумеется, пользователя не будут беспокоить уведомления об отсутствии подходящей локализации. Скрипт способен автоматически подбирать язык в соответствии с настройками ОС пользователя, но не должен заваливать его бесконечными объяснениями того, почему не загрузилась локаль.
Теперь инсталлятор будет бить по рукам только безответственных упаковщиков, но не доставит лишних проблем конечным пользователям. Помимо этого, были доработаны вспомогательные скрипты для запуска с разными локалями. Ранее они не передавали аргументы запуска дальше по цепочке, что могло затруднить всестороннее тестирование.
Был ли issue под номером 49 полезен? И да, и нет. Был ли он грамотно сгенерирован и представлен? Нет. И я могу понять разработчиков, которые буквально объявили войну ИИ. Видимо, такие «вредные хейтеры» уже изрядно достали разработчиков в мире Open Source. Тем не менее, даже из такого безобразного тикета мне удалось извлечь реальную пользу для проекта. Осталось поработать над описанием внесённых изменений и закрыть «проблему».
Следующая претензия относится к базовым файлам подготовки меню приложений и затрагивает «костыль» для сломанных дистрибутивов Linux. Костыль изначально создавался лишь с одной задачей — вернуть пропавшее меню в некорректно работающих дистрибутивах Linux. Попутно я сделал этот «костыль» функциональным, чтобы можно было быстро открывать каталог с программами и спецификациями PortSoft.
То, что ярлык открывает каталог PortSoft исключительно в домашней папке пользователя, не является ошибкой и никаких исправлений тут не требуется. Именно так и должен работать данный ярлык. Если бы хейтер действительно собирался помочь с развитием инсталлятора, он бы перепроверил сгенерированный флуд и подобные сообщения либо вообще исключил из публикации, либо предложил бы иные варианты, вместо того чтобы портить правильно работающий компонент.
Да, нейронная сеть в оправдание своих выводов и решений отметила, что стандартный каталог PortSoft может быть изменён упаковщиком, но это не значит, что я поддерживаю данную возможность. Более того, я открытым текстом заявил рядом с соответствующей настройкой, что её изменение может всё поломать и её ни в коем случае не следует трогать без крайней необходимости.
Но и тут я смог извлечь пользу для проекта. Достаточно сделать второй ярлык, указывающий на системный каталог PortSoft. Так у пользователя появляется возможность быстро перейти в любой из каталогов.
Запускаем инсталлятор с флагом принудительного обновления базовых файлов для тестирования моего нововведения.
Теперь в меню два ярлыка, позволяющих перейти в соответствующие каталоги PortSoft, если они существуют. Если же каталоги не существуют, я добавил проверку, чтобы открывалась корневая директория или домашний каталог пользователя. Да, это можно сделать и вручную: открыть проводник и зайти. Но во-первых, далеко не во всех дистрибутивах Linux файловый менеджер работает адекватно — порой открытие нужного каталога превращается в тот ещё «квест». Во-вторых, чем плоха возможность быстро зайти в общий каталог с программами? Особенно если система пользователя уже захламлена классическим линуксоидным софтом, превратившим домашний каталог в свалку отходов.
На этом можно закрыть issue под номером 43. Хотя сам тикет указывал на несуществующую проблему, мне всё равно удалось извлечь из него пользу, пусть и косвенно.
Материала набралось уже многовато. Думаю, на этом можно закончить текущую часть серии, посвященной совершенствованию нового и перспективного способа распространения ПО для Linux и FreeBSD.
Что касается деструктивных действий заблокированного пользователя, то ввиду отсутствия конструктива, наличия прямых угроз и нарушений правил платформы я даже не думал вступать с ним в перепалку. Я давал ему возможность начать конструктивный диалог по существу, и не один раз. Он же предпочёл продолжить травлю, не допуская мысли, что сам может быть неправ. Разработчики открытого ПО не должны тратить своё личное время на разбор неаргументированного давления и деструктивного поведения, цель которого — не улучшить проект, а нанести ему вред.
Обоснованная критика — это неотъемлемая часть Open Source, которая помогает проектам развиваться. Однако грань между анализом архитектурных ошибок и целенаправленной травлей очевидна: деструктивный подход не создает ничего нового, а лишь пытается разрушить чужой труд.
Учитывая количество труда и времени, потраченных на изучение сгенерированных тикетов, я с таким же успехом мог бы вообще обойтись без этих Issues. Тем более, большинство предложенных ИИ-исправлений либо ломали исправно работающие компоненты проекта, либо не решали саму проблему, а лишь маскировали ее симптомы.
В какой-то степени я даже начал понимать разработчиков, которые начали борьбу против софта и тикетов, сгенерированных с помощью ИИ. Однако сам к их числу пока примыкать не собираюсь. Пусть рассмотрение сгенерированного «флуда» и отнимает много времени (другие разработчики просто удалили бы всё это и были бы правы), но я никуда не тороплюсь. Так что не вижу проблем в том, чтобы продолжить рассмотрение и дальнейшее совершенствование проекта Installer-SH в текущем темпе.
На этом, думаю, можно завершить разбор данного инцидента. Следите за обновлениями, чтобы не пропустить следующую статью.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.