Борьба с зависимостями: Встраиваю браузер Mozilla Firefox в сборку SD WebUI Neuro

С чего бы начать... А начну с того, что я вполне успешно сделал две сборки на основе Stable Diffusion web UI, и эти сборки вполне хорошо работают, даже если запускать с USB флешки:

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

Почему именно Mozilla Firefox? Я не знаю, просто этот браузер первый попался под руку...

Для начала из автономного установочного пакета устанавливаю браузер в виртуальной машине чтобы ничего лишнего не произошло:

Далее располагаю браузер в одной папке со сборкой:

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

Пожалуй настало время запустить:

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

Впрочем, я заранее позаботился о том, чтобы вырезать всякие "updater.exe" из браузера, ну а ещё до кучи удалил лишние сервисы и сборщики отчётов:

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

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

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

Так же отключаю всё что выделено жёлтым цветом, нечего тратить ресурсы на функционал в котором нет абсолютно никакой нужды:

Кстати, а что там в папке DATA на которую я сослал браузер? Ожидаемо в папке появились файлы, и даже пустая папка "Рабочий стол", забавно:

Хм, раз уж решил заглянуть поглубже, то надо бы проверить кое-что, вдруг браузер запустил свои щупальца в систему пользователя? И в целом да, всё отлично, даже имя пользователя указано как надо, щупальцы зависимостей подрезаны достаточно неплохо, нужно только COMPUTERNAME ещё переопределить, так, на всякий случай:

Пожалуй следует рассказать как я вообще пришел к такому "изощрённому" способу сделать FireFox портативным, мне просто нужен был браузер, а портативных браузеров я не знаю, потому мне приходилось искать варианты в интернете как сделать браузер портативным, одним из таких вариантов был PortableApps:

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

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

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

Ну да ладно, этот нюанс пока следует оставить в покое, ведь есть более серьёзная проблема.

У Mozilla Firefox есть отвратительная особенность, на следующем скриншоте показано как выглядит это назойливое уродство. И да, раньше можно было отключать проверку обновлений, примерно до 63 версии FireFox, но потом у пользователей "заботливо" отобрали настройку отключающую проверку обновлений...

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

В общем иду в скрытые настройки и начинаю колдовать всякое:

Конечно не стоит забывать о телеметрии и рекламе, всё лишнее отключить! А вы думали Open Source весь из себя хороший и пушистый лис?

Теперь обновления не потревожат пользователя, да и кучу всякой телеметрии отключил, но есть другая проблема...

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

Хорошо что у разработчиков хватило мозгов сделать аргумент позволяющий указать путь к профилю пользователя (профиль браузера с настройками и историей) и параметр указывающий имя пользователя:

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

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

Да, эти записи никак не мешают, но всё же неприятный нюанс который я так и не смог решить в итоге.

В целом браузер работает, теперь можно работать со Stable Diffusion, однако не царское это дело запускать браузер вручную.

Я знаю что можно запустить несколько приложений одновременно, первое займёт порт 7860, второе 7861, третье 7862, а это значит что я не могу просто взять и через BAT файл вызвать вкладку в браузере с локальным адресом и конкретным портом, ведь порт может быть разным.

С одной стороны пользователь может запустить хоть десяток Stable Diffusion одновременно, только вот хватит ли у обычного пользователя памяти на это? Я запустил всего один экземпляр CUDA GPU и два экземпляра CPU, а у меня уже почти 30 ГБ ОЗУ занято:

В итоге я полез в код SD WebUI и начал ковырять прокаченным блокнотом всё интересное:

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

Идём дальше, у меня уже запущен один Stable Diffusion, и перед запуском второго экземпляра я дописал пару строчек кода в файл webui.py, в итоге получил адрес который уже можно скормить браузеру:

И как на зло в момент написания кода кому-то очень нужно было электричество, и оно пропало из розетки, а вместе с ним и мой ПК выключился... Впрочем, у меня есть привычка постоянно прожимать CTRL+S, потому я ни строчки своих трудов не потерял, да и Windows загрузилась как обычно без проблем после такого внезапного отключения, хорошо что я не в Linux дистрибутиве был загружен, а то пришлось бы опять переустанавливать линукс...

Вот и ответ на вопрос одного комментатора из прошлых статей, что будет если вырубить электричество? Правильно, ничего не будет работать, очевидно же. А в каком веке мы живём? Вообще это очень сложный вопрос, ведь в мануалах написано 21, а в терминале и часах 20...

В итоге я добился чего хотел, SD WebUI теперь запускает не только системный браузер, но и Mozilla Firefox находящийся в соседней папке:

При этом можно запустить сколько угодно экземпляров и они будут правильно открываться в портативном Firefox:

Теперь нужно почистить код от хлама, напоминаю, я не программист, потому делаю как умею:

Дальше надо поработать над BAT файлом, конечно же отключить вывод мусора в консоль, и убрать команды "pause" чтобы не требовало от пользователя нажатие любой клавиши:

А ещё нужно убрать аргумент "autolaunch", просто чтобы SD WebUI не открывал стандартный браузер в системе пользователя, ведь я хочу чтобы приложение работало с портативным браузером Firefox:

Наконец я оборвал зависимость от браузера в системе пользователя:

Только один момент, нужно отключить проверку орфографии в браузере...

Теперь время обратить внимание на BAT файлы для запуска SD WebUI, было решено убрать код отвечающий за автоматический выбор cudart библиотеки в зависимости от операционной системы, вообще я думал сделать файл с настройками и там указать текущую используемую версию, но это бессмысленно усложнит всё.

Я буду использовать cudart версии 11.4 по умолчанию, она работает как с Windows 7, так и с Windows 10/11, проблем с ней в любом случае не было обнаружено, ну а если пользователю очень хочется поэкспериментировать, то в папке Redist всегда доступны BAT файлы для смены версии cudart:

Почему я не уберу из BAT файла исправление для venv? Ведь его можно перенести в Python файл! И да, и нет, тут проблема курицы и яйца в некоторой степени, я не могу через приложение работающее на Python исправить путь к Python, ведь для выполнения кода нужно запустить тот самый Python путь к которому нужно исправить перед запуском...

Так что эту часть я оставлю в BAT файле.

Пришло время совместить изменения с чистой сборкой, что загружена в GitHub, для этого распакую архив с версией v1 и переделаю в v2 версию:

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

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

Проверяю, работает отлично, осталось только настроить мелочи, почистить кэш браузера, поправить ReadMe файл, запаковать как сборку версии v2, и протестировать в виртуальных машинах:

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

А теперь посмотрим на размер всего добра необходимого для работы приложения включая браузер, хотя на самом деле тут больше чем надо, но даже так, это всего ~650 МБ, как раз на один CD диск, при размере самого приложения в ~9.2 ГБ это не такая уж и большая растрата на зависимости ради адекватной работы.

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

Одна зависимость в системе пользователя на десяток приложений скорее оправдание кривым рукам недальновидных разработчиков, которые не осилили сборку зависимостей вместе с приложением, поправьте если я не прав, мне очень интересно посмотреть на новые забавные оправдания болоту зависимостей в Linux дистрибутивах и некоторых приложениях.

Ладно, не будем отходить от темы далеко, в ReadMe файле теперь появился раздел описывающий изменения, выглядит он вот так:

А теперь самое интересное, буду проверять сборку в виртуальной машине.

Чтобы подлить масла в огонь я буду запускать сборку SD WebUI Neuro через общую сетевую папку, но с отключенным интернетом в виртуальной машине, да, я не буду копировать сборку в виртуальную машину ибо это накладно по занимаемому месту на диске... Первый запуск, упс, ругань на отсутствующий VC Redist, ничего страшного, в комплекте со сборкой есть установочный файл, достаточно оказалось установить только x64 версию VC Redist:

Ладно, фреймворки установлены, запускаю сборку и она прекрасно запустилась! А ещё 12 ГБ памяти оказалось слишком мало, да и в виртуальной машине нет видеокарты, потому я использую ЦП для генерации:

Ничего страшного, нужно просто выделить 32 ГБ памяти для виртуальной машины:

Уж теперь точно хватит памяти чтобы наверняка ничего случайно не упало от нехватки ОЗУ без файла подкачки! На удивление 12 ГБ оперативной памяти было прямо впритык при первом запуске, а ведь это практически чистая Windows 7 SP1...

В итоге работа сделана и правильно сохранена, хм...

Пора усложнить задачу, почему бы не запустить сборку из общей сетевой папки в виртуальной машине с отключенным сетевым кабелем с Windows 11? По сути сделать то же самое что и в Windows 7 делал? Звучит интересно, но Windows 11 тот еще хлам кривой...

Я так и не понял что происходит, но Windows 11 просто уходит на перезагрузку когда пытаюсь запустить что-либо из общей сетевой папки...

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

Впрочем, сборку я скопировал, а проводник перезапустил целиком, по итогу Windows 11 перестала "падать", ведь теперь я запускаю приложение с локального диска, а не из сетевой папки.

Microsoft явно делают Windows с каждой версией всё хуже и хуже, наверное пытаются опустить свою ОС до уровня Linux дистрибутивов, и отчасти у них это получается, впрочем, даже в кривой Windows 11 моя сборка заработала:

Производительность на удивление получилась неплохая учитывая что ОС работает в виртуальной машине, и в диспетчере задач видно как загружены ядра на полную, ну хоть в этом плане Windows 11 отработала нормально:

Пожалуй с тестами хватит, сборка работает, явных проблем я не выявил, а значит можно паковать и загружать в GitHub, мучительно и долго через мобильный интернет... К слову, первая версия сборки была доступна только в варианте "всё в одном", но сейчас я загружу и вариант "NO_MODELS", что будет полезно людям которые предпочитают сами устанавливать нужные модели.

Точно, чуть не забыл, нужно же переименовать BAT файлы, зачем? Хм, как бы объяснить... Просто у меня есть некоторая задумка, я хочу сделать так, чтобы пользователь мог сложить две сборки в одну папку, например CUDA вариант и DirectML используя при этом одни и те же зависимости (Python, Git).

Но сейчас уже хватит, нужно наконец запаковать и загрузить в GitHub сборку.

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

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

Да и нет смысла в автоматизации, ведь достаточно просто распаковать файлы и скопировать их с заменой в папку с первой версией сборки.

Ну всё, на этом точно пора завершать статью и вторую версию сборки...

-

--

---

Заключение

Вот и завершена вторая версия сборки Stable Diffusion web UI Neuro, зависимость от браузера устранена, теперь сборка действительно пригодна для автономной работы на системах которые никогда даже не видели интернет.

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

Здесь повторю ссылку на репозиторий GitHub: ( https://github.com/Shedou/Neuro ).

P.S. Не надо в текущей статье искать вторую ссылку на GitHub...

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