Рассказываю об одном весьма необычном инструменте, способном удивить даже очень изысканную публику. Поскольку с его помощью можно быстро и безболезненно.. сменить пол любимой программе для Linux. Добро пожаловать, снова.
Вдумчивое чтение содержимого этих терминалов может привести в дурку, я предупредил.
The Witchcraft Compiler Collection
Сей замечательный проект — отличное доказательство существования черной магии и колдовства тому, как мало на самом деле мы знаем об устройстве собственных программ.
По крайней мере лично автор весьма смутно представляет, как эта адская штука вообще работает, несмотря на весь свой опыт и многолетнюю практику:
WCC is a collection of compilation tools to perform binary black magic on the GNU/Linux and other POSIX platforms.
Да да, "черная магия" тут дословная цитата из описания проекта, а не выдумки или особенности перевода.
Если вкратце, WCC это такой набор очень специфичных утилит для препари.. исследования чужих программ.
Информации об этой штуке в сети крайне мало, фактически помимо проекта на Github, существует лишь одна интересная презентация, показанная на конференции Defcon, слайды из которой также использовались в статье.
Так что материал получился весьма редким.
Сборка и инвольтация эгрегора
К сожалению проект успел немного устареть, хотя и присутствует в виде готовых пакетов во многих дистрибутивах Linux. Однако в Mageia, которую автор использовал ради колдовской ступы на логотипе в качестве тестовой среды, WCC почему-то не оказалось, так что пришлось собирать руками.
Согласно описанию, необходимо установить следующие пакеты:
capstone, glibc, libbfd, libdl, zlib, libelf, libreadline, libgsl, make
Однако libbfd ныне стал частью пакета binutils и отдельно более не поставляется, а binutils скорее всего уже установлен по-умолчанию.
для завершения сборки необходимо изменить паметры, передаваемые линковщику.
Что я и проделал в файле src/wcc/Makefile:
После исправления, сборка заканчивается успешно и в каталоге bin появляются готовые к использованию "колдунские" приложения:
Колдовской набор.
Теперь можно начинать плести заклинания.
Колдунство первое: превращаем приложение в библиотеку
Нет это не шутка и не прикол, это та самая "черная магия" от системной разработки, которой не научат на курсах по вайбкодингу.
Согласно описанию, все достаточно просто, хоть и необычно - примерно как обнаружить у девушки из Тайланда кадык:
Transforming an ELF executable binary into an ELF shared library.
Последовательность заклинаний шагов выглядит так:
Превращение утилиты cat в разделяемую библиотеку.
После вызова этих нечистивых команд, то что было рождено программой для Linux, внезапно становится разделяемой библиотекой. А узревший такое в живую быдлокодер уезжает в дурку, отсыпаться и отдыхать.
Теперь рассказываю как это колдунство работает, внимание на экран:
Из презентации WCC для Defcon.
На скриншоте выше видно, что по факту в файле изменился лишь один байт, точнее поле заголовка ELF64:
Из заголовочных файлов формата ELF.
Хотя назначение этого поля не является секретом и присутствует даже в Википедии, помимо официального руководства, до столь затейливого его применения никто на моей памяти не доходил. Кроме авторов WCC.
При вызове, первым шагом происходит откат работы линковщика:
The primary use of wcc is to "unlink" (undo the work of a linker) ELF binaries, either executables or shared libraries, back into relocatable shared objects. The following command line attempts to unlink the binary /bin/ls (from GNU binutils) into a relocatable file named /tmp/ls.o
Пример вызова:
wcc -c /bin/ls -o /tmp/ls.o
По идее уже на этой стадии должен быть получен «relocable file», с которым может работать обычный gcc. Например должна отрабатывать команда:
И в результате действительно получается разделяемая библиотека, которую можно спокойно линковать с вашим приложением:
file /tmp/ls.so /tmp/ls.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=68d93a1d888eb560b8842 55a59c37cd6be0adddd, not stripped
Пример использования такой библиотеки, созданной с помощью темного ритуала из чужой программы показан на этом слайде:
Вставляет покруче Некрономикона.
Но едем дальше.
Получение имени пользователя радикальным способом - через рефлексию в плеере VLC (!)
Колдунство второе: рефлексия для.. чистого С
Следующий уровень безудержного колдовского веселья показан на скриншоте выше, но разумеется нуждается в пояснениях:
The witchcraft shell accepts ELF shared libraries, ELF ET_DYN executables and Witchcraft Shell Scripts written in Punk-C as an input. It loads all the executables in its own address space and makes their API available for programming in its embedded interpreter.
Вообще этот абзац - один сплошной "майндфак" для всех, кто хоть немного знаком с языком С, в лучших традициях Лавкрафта погружающий разум несчастных быдлокодеров во мрак ультрахардкора.
Хотя авторы WCC на голубом глазу заявляют:
This provides for binaries functionalities similar to those provided via reflection on languages like Java.
до рефлексии уровня Java/.NET тут все же очень далеко и вызывать столь интересным образом методы в чужих библиотеках получается далеко не всегда.
Теперь рассказываю, как можно попробовать сие темное колдунство в действии. Интерпретатору wsh из состава WCC скармливается разделяемая библиотека или ELF-приложение:
wsh /usr/sbin/apache2
К сожалению стабильность работы вызывает вопросы, поэтому тут 50/50 — колдунство может сработать, а может выпасть segmentation fault. Если был передан бинарник — автоматически произойдет его «библификация», описанная выше.
Если сработало, появится сообщение зелеными буквами на черном фоне:
loading of libified binary succeeded
И можно будет пытаться вызывать:
a = ap_get_server_banner() print(a)
Код выше — отдельный язык, такая своеобразная помесь С и Lua, с весьма поэтическим названием:
The resulting API, a powerful combination of lua and C API is called Punk-C
Авторы решили не заморачиваться с типами данных, поэтому и родилась на свет эта дикая помесь ужа с ежом С и Lua.
Так выглядит более сложный пример использования:
#!/usr/bin/wsh
-- Computing a MD5 sum using cryptographic functions from foreign binaries -- (eg: sshd/OpenSSL)
Для демонстрации работы необходимо вначале загрузить одну из библиотек, реализующих функции MD5-хеширования, что и было немедленно проделано:
Считаем MD5-хеш с помощью метода, вызванного через рефлексию из бинарника sshd.
Как видите все работает и действительно отображается MD5-хеш для введенной строки, вычисленный с помощью вызова функции из бинарника sshd.
Без исходников и без линковки.
Но это далеко не все колдовские приколы, которые позволяет творить WCC.
Колдунство третье: восстановление флагов сборки
Хотя авторы WCC опять несколько преувеличивают, рассказывая про возможность восстановления абсолютно всех флагов сборки:
When compiling C code, it is often required to pass extra arguments to the compiler to signify which shared libraries should be explicitly linked against the compile code. Figuring out those compilation parameters can be cumbersome. The wldd commands displays the shared libraries compilation flags given at compile time for any given ELF binary.
На практике же речь идет только о библиотеках:
Ключи сборки mplayer.
Так что речь больше про удобство использования, чем про уникальный функционал.
Колдунство четвертое: генератор заголовков
Последнее в этой статье, но далеко не последнее по важности и применимости:
The wcch command takes an ELF binary path as a command line, and outputs a minimal C header file declaring all the exported global variables and functions from the input binary. This automates prototypes declaration when writing C code and linking with a binary for which C header files are not available.
Вот тут действительно респект и жертвоприношение уважение, поскольку столь мощное колдунство может сильно помочь в разработке:
Генерация заголовочного .h файла из бинарника sshd. Без исходного кода.
Но все же стоит помнить про ограничения технологии и не ждать 100% корректности получаемых заголовков.
В качестве иллюстрации, так выглядит небольшая часть заголовков методов, полученных этим генератором:
придется долго вычищать вручную, чтобы полученный заголовочный файл можно было использовать.
Резюмируя
WCC это по истине необычный и редкий проект, к сожалению (или к счастью) неизвестный широкой программерской публике.
Хотя его использование требует серьезной подготовки и определенных навыков, а работа утилит часто нестабильна - эффект в виде зарева полыхающих пердаков быдлокодеров простых разработчиков выходит эпический.
Если вы занимаетесь серьезной разработкой на C/C++ под Linux и ненавидите человескую расу, думаю стоит ознакомиться с этой штукой поближе, чтобы включить WCC в свои темные планы и нечестивые эксперименты.
Устроившись на новое место, одной из первых задач я себе поставил проверку резервного копирования серверов своего окружения.
Формально бэкапы существовали. За них отвечала команда администрирования виртуальной инфраструктуры. Доступа к гипервизорам, их настройкам и самим резервным копиям у меня не было. Проверить консистентность я не мог, сколько займёт восстановление — не знал, и вообще не был уверен, что в случае аварии сервер реально поднимется. Поэтому для себя вывел простое правило: пока не проверил восстановление — бэкапа не существует.
Первый эксперимент
Из локальных средств резервного копирования нашлась интересная практика: раз в неделю снималась SquashFS-копия файловой системы и складывалась на NAS. С неё и начал.
После нескольких итераций получилось поднять сервер вручную: загрузка с Live-CD, разворачивание файловой системы, переустановка GRUB — и система стартовала уже с восстановленного диска.
Даже если такой способ когда-нибудь не позволит восстановить сервер целиком, остаются конфиги, сертификаты, служебные данные — то, что обычно в самый неподходящий момент приходится собирать заново. Уже одно это делает такой бэкап полезным.
Чёрный ящик
Схема бэкапа была простой: Puppet раскладывал скрипт резервного копирования на сервер, cron запускал его по расписанию. На этом контроль заканчивался. Есть ли свежий бэкап? Не пустой ли он? Можно ли на него рассчитывать? Ответа на эти вопросы не было.
Написал небольшую утилиту проверки. Она подключается к хранилищу, ищёт резервные копии каждого сервера и прогоняет простые проверки:
существует ли текущий бэкап;
существует ли предыдущий;
не слишком ли маленький получившийся архив;
не отличается ли его размер от предыдущего больше допустимого порога.
Это не гарантирует целостность данных, но ловит большинство типичных ошибок. А они нашлись! На удивление, полностью исправных серверов оказалось меньше, чем ожидалось. Где-то cron запускал скрипт с неправильным окружением. Где-то не хватало прав доступа. На части серверов отсутствовали нужные пакеты. Встречались и банальные ошибки в настройках. После исправления резервное копирование стало заметно стабильнее.
Новая проблема
Исправив одну проблему, бонусом получил следующую. Все серверы запускали бэкап в одно и то же время. Десятки машин одновременно начинали сжимать данные и лить их на сетевое хранилище. Канал забивался, скорость падала, часть копий завершалась с ошибками.
Разводить время запуска вручную под каждый сервер — не вариант, это не масштабируется и рано или поздно снова сломается при добавлении новых машин. Вместо этого решил изменить сам подход.
Оркестратор
Появился отдельный сервер-оркестратор. На каждом клиентском сервере создаётся специальный пользователь, которому разрешено выполнять ровно один заранее определённый скрипт резервного копирования с повышенными привилегиями — и ничего больше. Оркестратор хранит список серверов, последовательно подключается к каждому по SSH и запускает бэкап. Пока один сервер не закончит, следующий не стартует.
Привязки к конкретным машинам нет. Через Puppet любому серверу можно назначить роль клиента резервного копирования, роль оркестратора или обе сразу. Пользователи, права, ключи, скрипты, расписание — всё поднимается автоматически. Благодаря этому оркестратор можно перенести на другую машину без ручной перенастройки инфраструктуры.
В результате конкуренция за сетевой канал исчезла, да и нагрузка на хранилище стала более равномерной.
Скрипт бэкапа
Заодно доработал сам скрипт резервного копирования. Теперь он:
автоматически удаляет собственные копии старше четырёх недель, не трогая данные других серверов;
проверяет размер созданного архива и сравнивает его с предыдущим;
кроме самого архива рядом сохраняется информация, необходимая для восстановления сервера;
по завершении пишет небольшой файл состояния — дата выполнения, размер копии, итоговый статус, диагностическое сообщение.
Zabbix просто читает из файла состояние последнего бэкапа и сигнализирует, если копия давно не обновлялась, завершилась с ошибкой или подозрительно похудела.
Итог
Резервное копирование стало отдельной системой, которая сама разворачивается через Puppet, следит за своим состоянием, проверяет результат, сообщает о проблемах в мониторинг и позволяет восстановить сервер даже при полной потере виртуальной машины.
Теперь легко отследить, в каком состоянии находится резервное копирование. Существующий процесс стал более управляемым, а уровень тревожности стал ниже.
Если считаете что я изобрёл велосипед, или есть советы как сделать бэкапирование более качественным, то пишите в комментариях, с удовольствием почерпну для себя ценную информацию!
Если вам неудержимо хочется использовать оборудование из музея для современной разработки — статья специально для вас.
Машины должны служить а не требовать ресурсы. И автор патча l9 об этом знает.
Эпический баг
Сейчас наверное некоторые читатели сильно удивятся:
с 2007 года в ядре Linux живет серьезный баг, приводящий к полному зависанию системы при работе под большой нагрузкой на память.
На дворе на момент написания статьи май 2025 года, так что баг успел отпраздновать совершеннолетие и открыть первую бутылку пива.
Оригинальный репорт выглядит так:
Разумеется разработчики ядра в курсе проблемы, но по ряду причин.. не считают этот баг важным.
Да, вы правильно прочитали:
«полное зависание системы под нагрузкой» и «разработчики не считают важным исправлять» — как вам такие реалии Linux?
Более того, недавно тикет с описанием этого бага вообще закрыли с эпической формулировкой «just become obsolete»:
С легким намеком, что некоторым стоит перестать собирать себе компьютеры по помойкам:
but now I don't bother with less than 32Gb of RAM for a desktop.
Теперь прокрутите обсуждение бага в трекере вниз и посмотрите на последнее сообщение о проблеме:
Специально сохранил картинкой для истории, вдруг не поверите.
Оно конечно все замечательно и у самого автора этой статьи давно 64Гб на одной из рабочих машин, а некоторые коллеги успели впихнуть даже 128Гб, причем в ноутбук — чтобы мы наконец увидели SUSE Linux, которая не тормозит.
Но к сожалению одними любителями компьютерного антиквариата данная проблема не ограничивается — на нынешние облачные времена типичное рабочее окружение Linux это виртуальная машина, с ограниченным обьемом памяти. Скорее всего даже ваш корпоративный сайт крутится на виртуальной машине с 4Гб памяти.
Так что на самом деле проблема касается практически всех пользователей Linux, а не только идейных нищебродов энтузиастов, собирающих себе оборудование по музеям.
Как так получилось
Если вы хоть немного понимаете в компьютерах, прочитав абзац выше и сопоставив масштаб проблемы и отношение к ней разработчиков Linux, думаю уже сделали определенные выводы:
либо команда разработки ядра Linux — поголовно некомпетентны, либо у автора контракт с рептилоидами в описании выше был упущен ряд важных нюансов.
Правда как обычно где‑то между — «особенных» среди современных разработчиков Linux действительно хватает, но ряд нюансов я все же намеренно упустил.
Опишу в какой момент проявляется этот баг:
надо долго и упорно увеличивать нагрузку на использование памяти, причем маленькими порциями и обязательно из нескольких разных процессов — чтобы OOM Killer не успел отработать.
На практике надо либо заниматься тренировкой нейросетей, либо непрерывно гонять тяжелые приложения на Java/Node (в первую очередь IDE) и постоянно запускать сборку больших проектов.
И все это на неподготовленном офисном оборудовании с 4-6 Гб памяти, представляющем историческую ценность, либо в виртуальной машине.
Патч l9ec
Уже давно существует неофициальный патч, решающий описанную проблему с зависанием квадратно-гнездовым радикальным способом:
The kernel does not provide a way to protect the working set under memory pressure. A certain amount of anonymous and clean file pages is required by the userspace for normal operation. First of all, the userspace needs a cache of shared libraries and executable binaries. If the amount of the clean file pages falls below a certain level, then thrashing and even livelock can take place.
По сути этим патчем формируется небольшой объем памяти (тот самый working set), которую запрещается перегружать даже самым хитрым приложениям, откусывающим память по килобайтам.
Разумеется патч заметили и тут находится архив эпической переписки в рассылке Linux Kernel длиною в год, где автор патча пытается объяснить окружающим что он не верблюд и проблема действительно есть.
Однако патч в мейнстрим так и не попал, что наводит на определенные нехорошие мысли.
История с Xanmod
Помимо основной версии ядра т. н. «vanilla», исходники которого выкладываются на широко известном kernel.org, существуют «васянские сборки» — наборы патчей ядра, собранные энтузиастами под конкретную задачу.
Одна из таких сборок называется Xanmod и посвящена работе современного ядра на desktop-системе с минимальными визуальными задержками:
XanMod is a general-purpose Linux kernel distribution with custom settings and new features. Built to provide a stable, smooth and solid system experience.
Так вот на момент появления l9ec патча, он был включен в сборку Xanmod:
Но в последних 6.х версиях Xanmod его уже нет, на что есть формальная причина — появление вот этого патча, вроде как окончательно решающего проблему c зависанием:
На данный момент MGLRU в mainline и скорее всего работает прямо сейчас и у вас в системе, если конечно у вас современный линукс и MGLRU не отключен вручную.
К сожалению принцип работы MGLRU другой (см. комментарий выше про 32Гб памяти на десктопе) и тестировался его функционал тоже в другом месте:
On Android, our most advanced simulation that generates memory pressure from realistic user behavior shows 18% fewer low-memory kills, which in turn reduces cold starts by 16%.
Как нетрудно догадаться, «realistic user behavior» на мобильном Android несколько отличается от тотальной перегрузки тяжелыми средствами разработки на дохлом десктопе или еще более слабой виртуальной машине.
Поэтому «продвинутым пользователям Linux» в очередной раз придется заботиться о себе и своих проблемах самостоятельно.
Эта история — еще одна причина, по которой стоит использовать *BSD. Реклама.
Портирование на 6.х ядро
К сожалению автор патча l9 видимо устав бодаться с идиотами, не стал переносить свой замечательный патч в 6.х ветку ядра, решив что раз более умные ребята из Google выкатили MGLRU — от его решения толку больше не будет.
Как ни странно, но это не так и l9 патч куда более предсказуем и надежен как удар ломом, в отличие от цирка с аж 14 патчами MGLRU:
These initial multi-generational LRU patches amount to 14 patches at the moment and in a patched kernel can be enabled via the LRU_GEN Kconfig switch
Собственно эта статья появилась на свет после того как автор опять словил зависание под нагрузкой во время работы над большим проектом, из-за чего и решил откопать дедовский пулемет портировать известный патч в 6.х ядро.
За основу был взят последний патч для 5.х ветки без учета MGLRU: le9ec-5.15.patch а его логика добавлялась в Xanmod-версию ядра 6.14.5.
Ниже по шагам объясняю как выполнить перенос логики патча, чтобы процедуру можно было повторить и на более новых ядрах и на «vanilla» версиях.
Скачиваем архив с Xanmod ядром и l9-патч по ссылкам выше и распаковываем.
Стоит сразу предупредить, что размер текущей версии ядра Linux в распакованном виде ~1.8 Гигабайт, а для сборки понадобится еще ~28 Гигабайт.
Вот такие нынче ядра.
Разумеется применить готовый diff автоматически для ветки 6.х не получится, так что будем переносить логику патча по шагам.
Всего в рамках патча изменения происходят в пяти файлах:
Поскольку исправлять документацию нам не очень актуально, первый файл можно пропустить. Таким образом первое актуальное исправление находится в файле include/linux/mm.h, куда добавляются глобальные переменные, отвечающие за настраиваемые лимиты:
Все что нужно сделать — вставить строки в файл include/linux/mm.h:
/* * Force-scan anon if clean file pages is under vm.clean_low_kbytes * or vm.clean_min_kbytes. */ if (sc->clean_below_low || sc->clean_below_min) { scan_balance = SCAN_ANON; goto out; }
Следующая правка в этом же файле должна быть вставлена в этот же метод get_scan_count, но ниже по коду — ориентируйтесь на строку nr[lru] = scan;благо она такая одна:
Я вставил логику проверки сразу над ней:
/* * Hard protection of the working set. */ if (file) { /* * Don't reclaim file pages when the amount of * clean file pages is below vm.clean_min_kbytes. */ if (sc->clean_below_min) scan = 0; } else { /* * Don't reclaim anonymous pages when their * amount is below vm.anon_min_kbytes. */ if (sc->anon_below_min) scan = 0; } nr[lru] = scan;
Следующей правкой добавляется новая функция prepare_workingset_protection, которая должна вызываться из существующего метода shrink_node_memcgs:
Так что вам надо найти функцию shrink_node_memcgs (она такая одна) и вставить новую функцию prepare_workingset_protection над ней:
static void prepare_workingset_protection(pg_data_t*pgdat, struct scan_control *sc) { /* * Check the number of anonymous pages to protect them from * reclaiming if their amount is below the specified. */ if (sysctl_anon_min_kbytes) { unsignedlong reclaimable_anon;
/* * Check the number of clean file pages to protect them from * reclaiming if their amount is below the specified. */ if (sysctl_clean_low_kbytes || sysctl_clean_min_kbytes) { unsignedlong reclaimable_file, dirty, clean;
reclaimable_file = node_page_state(pgdat, NR_ACTIVE_FILE) + node_page_state(pgdat, NR_INACTIVE_FILE) + node_page_state(pgdat, NR_ISOLATED_FILE); dirty = node_page_state(pgdat, NR_FILE_DIRTY); /* * node_page_state() sum can go out of sync since * all the values are not read at once. */ if (likely(reclaimable_file > dirty)) clean = (reclaimable_file - dirty) << (PAGE_SHIFT - 10); else clean = 0;
Собственно последняя правка это вызов новой функции из существующей shrink_node_memcgs:
После внесения всех этих исправлений, запускаем один из вариантов настройки ядра:
make xconfig
И наблюдаем новые поля настройки:
Цепочка сборки и установки ядра совершенно стандартная:
make && make modules && make modules_install && make install
К сожалению это еще не все и прежде чем патч заработает надо будет отключить MGLRU, который как я уже описывал — успели внести в основную ветку ядра:
cat /sys/kernel/mm/lru_gen/enabled
Должен показать 0x0007 если MGLRU включен, отключить можно командой:
echo 0 | sudo tee /sys/kernel/mm/lru_gen/enabled
Вот тут у автора патча лежат готовые скрипты для автоматизации всего этого цирка. Я же просто добавил строчку с отключением в /etc/rc.local.
Пруфы
Для тестов портированного патча, был взят один из моих боевых ноутбуков Lenovo Z580 2012го года выпуска, с 8Гб памяти:
На нем постоянно творится всевозможная дичь — тут пять разных операционных систем и куча проектов и инструментов для разработки на каждой.
Поэтому без особого труда были одновременно запущены:
PostgreSQL с реальной базой
MySQL тоже с реальной базой
Intellij Idea
VSCode
Сборка проекта на Node.js с Webpack и hot reload
Сборка достаточно крупного Java-проекта (~3000 исходных файлов)
Chromium с 20 вкладками
Напоминаю что все это на 8Гб реальной памяти и на ноутбукe. Причем в качестве ОС в этот раз была обычная Ubuntu:
Как-то так это выглядит в действии:
Через неделю после публикации я решил пойти еще дальше и поставил пропатченное с l9 ядро на ноутбук 2007 года с 3Гб памяти. И повторил тесты с нагрузкой. Видео тут.
Все более чем работает и пропатченное ядро замечательно отрабатывает свою пайку.
Эпилог
Можно сколько угодно стебаться с пожеланиями «купи себе наконец нормальный компьютер», скажу что намеренно и давно использую старое железо — в первую очередь для оценки производительности создаваемого ПО.
И это одна из причин, по которой у нас получаются технические чудеса вроде Телепорты.
Если вы пока не дошли до столь глубокой стадии просвещения в разработке — все равно стоит знать, что мы ловили подобные зависания и в виртуальных машинах с Linux, например на CI‑сервере при сборке нескольких проектов одновременно.
Так что актуальность описанного все же высокая и как получилось, что столь простой и очевидный патч, который гарантированно решает проблему до сих пор не используют активно — ума не приложу. Ну и разумеется автору патча лучи респекта, благо это лучший представитель отечественной инженерной школы.
Статья была опубликована на Хабре, оригинал, в котором автор статьи себя не сдерживал и в красках рассказал все что думает о разработчиках ядра Linux как обычно можно найти в нашем блоге.
Телеграм, ВКонтакте, Дзен, Макс — площадок становится все больше, а вот внимание аудитории по-прежнему ограничено. Что делать? Продвигать!
На Пикабу можно рекламировать свои каналы прямо в лентах сайта. Находите новую аудиторию и получайте живые переходы без сложных рекламных кабинетов.
Подойдет для:
авторских и экспертных блогов
бизнеса
медиа и новостных каналов
мемных и развлекательных сообществ
Запускается просто: добавляете ссылку, пишете заголовок и краткое описание и выбираете географию для показов. А дальше о вашем канале узнают тысячи пользователей Пикабу!
Несколько запоздавший пост. Посмотрел несколько обзоров и отзывов на Steam Machine, в которых как обзорщики, так и рядовые пользователи топчутся на детище Гейба.
Ящик
Хотелось бы вставить свои пять копеек. Что если я скажу, что эта железяка не для вас?
Как-то так приблизительно
Объясню на максимально простом примере. Вы собираете дома вечеринку, у вас большая гостиная и телек, человек 10 гостей. Вы сидите, пьете коктейли, гости начинают возиться в телефонах. И тут вы внезапно выдаете окружающим что-то типа "кто хочет проиграть в мортал комбат"? И тут важный момент. Вам НУЖНО иметь приставку, уже подключенную к телевизору и с заранее запущенной игрой. Вариант "пойти за ноутом (или упаси б-г за системником) и 5 минут пыхтя подключать его к телеку, пока все молча на это смотрят" прославит вас как максимально душного задрота. Интерес к задумке очень быстро улетучится.
Так вот, концепция "компьютера для гостиной" именно в этом - иметь небольшой, нешумный и максимально неприметный комп, на котором уже запущена игра, и который можно почти мгновенно разбудить просто нажатием на геймпад. Гости не ждут. Дети не возятся в вашем личном компьютере. При этом у вас ГОРАЗДО больше свободы действий по сравнению с обычными приставками.
Так вот. Стим машина - это лишь РЕФЕРЕНС такого компьютера. Эталонная реализация. Вместе с его релизом вышла SteamOS 3.8, поддерживающая установку на любой компьютер, что намекает: теперь другие могут посоревноваться и попробовать сделать лучше.
Гейб дал вам потрясающую идею, а вы хотите его за это распять. Неблагодарные.
Еще одна поучительная история из жизни с Linux, специально чтобы вы потеряли сон и покой, узнав что такое вообще возможно.
Тот самый баг, смотрит на вас с экрана.
Вводная
Эмм с чего бы такого начать, чтобы не испугать раньше времени и не заставить устанавливать *BSD.
Есть на свете одна компания, которой мы помогаем с ИТ и есть у нее несколько виртуальных серверов на Ubuntu Linux, используемых для половых утех разработки и тестирования.
Ubuntu там использовалась нормальной (для сервера) LTS‑версии, но в какой‑то момент — в погоне за патчами безопасности ее обновили до текущей.
Не совсем «текущей-текущей», которую используют разработчики Ubuntu для обкатки новых версий дистрибутива, а просто без долгой поддержки — примерно то, что ставят себе обычные пользователи Ubuntu Linux на домашние компьютеры.
Все происходило летом 2025 года, поэтому речь про версию 25.04 Ubuntu Linux, которая использует ядро 6.14 (запомните этот важный момент):
Баг
Однажды сисадмин компании-заказчика заметил слишком частую и сильную нагрузку на CPU, создаваемую процессом snapd, который является частью пакетного менеджера Snap.
Скриншот был взят из сети, поэтому «шакальего» качества;)
Эта проблема с перегрузкой CPU для snapd мягко говоря не нова — «проклятый snapd» гадил линуксоидам с момента своего появления на свет и вообще видимо был не придуман а ниспослан свыше, в качестве кары за грехи.
Нет, это не осеннее обострение, дело происходило летом.
Разумеется первым делом были опробованы стандартные методы решения, вроде снижения частоты проверок обновлений или полного отключения проклятого сервиса:
Отдельно порадовал ответ ИИ:
Дословно «снести и использовать что-то другое» — первый разумный совет от машины за всю историю развития искусственного интеллекта.
Дальнейшие изыскания привели в багтрекер snapd к упомянутому багу, где уже третий комментарий от разработчика snapd, с приложенной трассировкой вызовов показал что проблема именно в ядре:
Тут стоит добавить, что почти сразу встал вопрос проверки бага на локальной машине, поскольку на момент изучения ситуации локально все успело неоднократно обновиться, а отлаживать ядро Linux на сервере заказчика все же не очень хорошая затея.
Чуть ниже по переписке видно, что баг особо ярко проявляется на ноутбуке, работающем от батареи:
Так что решено было пробовать отловить именно в таких условиях.
На счастье, на машине осталась сборка 6.14 версии ядра с патчами от Xanmod, которая использовалась для статьи про l9ec.
В последние годы в проекте ядра Linux выпускается сильно много промежуточных релизов, поэтому на какой именно версии внутри 6.14 ветки что-то пошло не так еще пришлось выяснять:
Обратите внимание на загрузку CPU и блокировку выхода из приложения
Как видите, в очередной раз проблема прикладного сервиса уперлась в ядро операционной системы.
Патч целиком находится тут, место исправления выглядит как-то так:
Да, как видите ситуацию радикально исправляет буквально пара символов логической конструкции, главное знать где исправлять.
Текущее состояние
Формально проблема была решена еще летом этого года, патч попал в mainline и пакет с обновлением ядра от команды Ubuntu:
На осень 2025 года даже стабильная версия ядра Linux уже имеет версию 6.16 — т. е. паровоз разработки уехал очень далеко вперед от описываемых проблем:
Так что на момент написания данной статьи вы (по идее) не должны столкнуться с данной проблемой, а если и столкнетесь — все легко решается банальным обновлением версии ядра из пакетов дистрибутива.
При подозрении на описанный баг — попробуйте собрать тестовое приложение (см. выше) и запустить в своем окружении.
Если начнется 100% загрузка CPU запущенным процессом — проблема точно есть, поскольку в ядрах с патчем поведение тестового приложения отличается:
В исправленном ядре тестовое приложение немедленно завершится.
Что касается заказчика, поскольку решение а затем и патч были опубликованы довольно оперативно — раньше чем нам сообщили о проблеме, на время разборок с согласованиями и попаданием в mainline ядра, мы банальным образом перенесли патч вручную в ту версию ядра, которая использовалась на сервере.
Позже обновили уже штатными средствами дистрибутива до текущей актуальной версии.
Эпилог
Если вы не являетесь разработчиком ядра и не пишете патчи каждый день, засыпая в обнимку с отладчиком — т. е. далеки от реалий системного программирования, то из этой статьи сможете вынести несколько интересных выводов и внезапных открытий:
1. Linux — могила, *BSD - сила
Шучу, разумеется неподготовленным пользователям в BSD-системы лучше не лезть совсем, но задуматься (или хотя-бы просто знать) о реалиях функционирования Linux все же стоит. Чтобы факт выноса мозга ядру из прикладного ПО не стал для вас неприятным сюрпризом.
2. Граница между прикладкой и системной разработкой весьма абстрактна
Проще говоря — ее нетсовсем и в любой произвольный момент времени у вас есть неиллюзорный шанс наткнуться на баг ядра, даже программируя на JavaScript в браузере.
3. Любой уважающий себя сисадмин и DevOps должны знать С
Пусть на самом примитивном уровне, но хотя-бы собрать и запустить тестовое приложение, демонстрирующее проблему надо уметь. К сожалению все глубокие изыскания по теме «где оно тормозит» или «почему оно упало» рано или поздно приводят к коду на С и отладчику ядра.
И поверьте моему печальному опыту:
изучать эти штуки лучше днем и в спокойной обстановке, а не в режиме аврала и поздно ночью на работе в выходной день.
4. Считайте деньги, хотя-бы иногда
Описанная в статье проблема случилась в локализованном окружении (на собственных физических серверах компании), но точно такая же Ubuntu используется и облачными провайдерами вроде Amazon, где есть тарификация за использование ресурсов, в первую очередь CPU.
Как нетрудно догадаться, 100% загрузка процессора с интервалом в пять минут в облаке, если ее вовремя не заметить и не исправить — больно отразится на счете, который вам потом выставят.
Так что проверяйте загруженность, пиковых 100% в современных системах быть не должно, если только вы целенаправленно не занимаетесь вычислительными задачами.
Подробное руководство по ускорению любимого браузера подручными средствами. В помощь домохозяюшкам, студентам и высшему руководству — всем у кого нет под рукой топового железа с 64Гб памяти для работы в современном интернете.
В качестве демонстрации. FreeBSD и ноутбук 2007 года, но ниже будет и про ваши любимые Windows c Linux
❯ Хром
Браузер Chrome, созданный и разрабатываемый корпорацией Google давно стал главным инструментом для большинства пользователей компьютерной техники:
в вашем телефоне, планшете, телевизоре, ноутбуке и стационарном компьютере в подавляющем большинстве случаев будет установлен именно этот браузер, либо что-то на его основе.
Два вечных конкурента в виде браузеров Opera и Internet Explorer сдались в попытке угнаться за прогрессом и ныне используют под капотом движок от Chrome.
Так что Google это мировой монополист в области браузеростроения, Chrome — его самый популярный продукт и фактически главное приложение для большинства современных пользователей.
Даже эта статья создавалась с помощью браузера Chrome:
❯ Скорость
Конечно высокооплачиваемые разработчики самого популярного браузера на планете, щедро финансируемые «корпорацией добра» — не полные идиоты и разбираются в вопросах производительности собственного продукта гораздо лучше автора.
Но только проблемы производительности на дешевом, устаревшем и тем более неподдерживаемом оборудовании сотрудников Google... мягко говоря не очень волнуют.
Поэтому в очередной раз простому пользователю, не желающему продавать почку ради современного компьютера, придется заботиться о себе самостоятельно. Чем мы сейчас и займемся.
Применимость
Описываемые ниже инструкции — для десктопной версии браузера Chrome и с учетом специфики трех разных операционных систем: Windows, Linux и FreeBSD.
Мобильная версия браузера довольно сильно отличается, но также поддается подобной настройке. Однако чтобы не раздувать статью — про тюнинг мобильной версии расскажу в следующий раз.
Замечу также, что эта статья — далеко не самый возможный максимум оптимизации и если Господь наградил вас знанием языка С++, дав в руки компилятор, то сотворить с браузером можно гораздо больше.
Но тут все же для обычных людей, не обезображенных высшим техническим образованием и навыками системного программирования.
Производительность
Я использую браузер Chrome на ноутбуках с момента его появления и часто работаю «в поле» — от батареи и без подключения к розетке. Помимо браузера на машине постоянно присутствуют еще несколько тяжелых приложений — в первую очередь среды разработки и разнообразные редакторы.
Все это в итоге формирует следующий набор требований:
браузер не должен нападать на человека забирать на себя все доступные ресурсы;
браузер не должен «сжирать» батарею ноутбука;
браузер должен продолжать работать с современными сайтами, сохраняя отзывчивость интерфейса.
Время «холодного запуска» и скорость отрисовки страниц при таких вводных разумеется могут пострадать, но будут оставаться в пределах разумного.
Версии и названия
Чтобы не было путаницы, стоит сразу прояснить ряд нюансов с названиями продуктов и используемыми терминами.
Официально браузер от Google называется «Chrome» и поставляется (даже для Linux) в виде готовой сборки с инсталлятором, т.е. это закрытый коммерческий продукт, хотя и бесплатный для пользователя.
Именно эта версия доступна для скачивания с официального сайта и имеет максимальную интеграцию с сервисами и другими продуктами Google.
Открытая часть браузера Chrome называется «Chromium» и с точки зрения обычного пользователя никак не поставляется, поскольку Chromium предназначен в первую очередь для технических специалистов, участвующих в процессе разработки и тестирования.
Именно Chromium а не Chrome чаще всего установлен по-умолчанию в различных дистрибутивах Linux, в виде сборки от ментейнеров дистрибутива.
Наконец существует проект «Ungoogled Chromium», авторы которого постарались удалить из Chromium абсолютно все интеграции с сервисами Google и все закрытые инструменты сборки.
Ungoogled Chromium за последние годы набрал популярность, поэтому активно используется в BSD-системах и дистрибутивах Linux, ориентированных на безопасность.
Поскольку использование сервисов Google в наше непростое время может приводить к непредсказуемым проблемам и сбоям подключения, я буду использовать для всех описываемых оптимизаций Ungoogled Chromium либо просто Chromium, но не официальный Google Chrome.
Тем не менее для простоты повествования, в статье используется термин «Chrome» в качестве обозначения браузера, поскольку описываемые методы оптимизации полностью совпадают и частично применимы и к другим браузерам на основе Chromium.
Тестовая среда
Для статьи использовались современные 64-битные сборки браузера, с версиями начиная с 147 и выше:
147.0.7727.101 (Official Build) (64-bit)
Ungoogled Chromium имеет свою собственную нумерацию версий, отличную от оригинальной, для этой статьи использовались версии 137 и выше:
Под различными операционными системами использовались разные версии браузера, но во всех случаях — самые последние из доступных на момент написания статьи. Замечу также, что описанные оптимизации постоянно используются на всех моих ноутбуках, как мощных и современных, так и откровенно.. винтажных.
Поскольку разницу лучше всего видно на устаревшем оборудовании, в качестве тестовой среды будут использованы два настоящих «боевых пенсионера»:
Эти весьма устаревшие по любым меркам (особенно второй) машины станут отличным тестовым полигоном для демонстрации результатов всех описываемых вивисекций оптимизаций.
❯ Оптимизация
Поскольку целевая аудитория статьи — обычные пользователи, не владеющие с пеленок компилятором и отладчиком, ограничусь тремя вариантами оптимизации браузера, доступными без залезания непосредственно в код:
хитрые настройки, хитрые плагины и хитрое окружение.
Все ради того чтобы крутить ленту каких-нибудь Reddit/LinkedIn без зависания браузера и 100% загрузки процессора.
Так выглядит работа браузера со всеми оптимизациями на Ubuntu Linux и ноутбуке 2012 года
❯ Chrome и Linux
Так исторически сложилось, что я использую много разных Linux-дистрибутивов в своей непростой деятельности:
Сразу уточню, что Calculate Linux (на базе Gentoo) использует OpenRC вместо systemd, поэтому трюк с systemd-run тут не используется, но все остальные инструкции отлично работают на всем этом зоопарке и по своей сути применимы для любого окружения на базе Linux, везде где есть браузер Chrome.
Начнем со скрипта запуска браузера, в котором специальными параметрами включаются или отключаются разные хитрые опции, а также используется специальное окружение:
Сохраняете текст выше в какой-нибудь /opt/own/bin/chrom, выставляете бит запуска:
chmod +x /opt/own/bin/chrom
И используете этот скрипт для первого запуска браузера.
Стоит напомнить, что символ \ отвечает за перенос строк, т.е. для программы весь набор параметров выше это одна длинная строка.
Если при копировании текста что‑то сломается — просто удалите все \ и сведите все в одну длинную строку — так тоже запустится.
Переназначать обработку всех HTML-страниц в рабочем окружении на этот скрипт не стоит, поскольку процессы браузера Chrome умеют общаться между собой и пока есть хоть один работающий процесс — его настройки будут использоваться для запуска новых копий.
Теперь рассказываю страшную сказку про «прожорливый» Chrome и пропавшую память, точнее про эту интересную строку:
Дело в том, что у браузера Chrome есть дурная привычка считать весь компьютер своей собственностью и захватывать максимум доступных ресурсов — всю свободную память и все доступные процессоры и ядра.
Пока вы работаете на сервере современной машине с кучей памяти, не держите открытыми сотни вкладок с графикой а конкуренцию браузеру за доступные ресурсы составляет только офисный пакет — проблемы нет.
Но стоит лишь немного просесть по мощности используемого оборудования или доступным ресурсам для более прожорливых программ (привет Davinci Resolve) и любимый браузер от «корпорации добра» немедленно показывает звериный оскал свое истинное лицо.
В случае ноутбука (тем более мощного) немедленно проявляется еще один дурной эффект:
скачки бесконтрольной нагрузки, создаваемой браузером очень быстро разряжают батарею.
Так что становится жизненно необходимым сажать браузер на ресурсную диету с помощью systemd и функционала cgroups.
Делается это в современных Linux-дистрибутивах довольно просто, для начала создаем файл ~/.config/systemd/user/chromium.slice со следующим содержимым:
Помимо очевидных лимитов на объем используемой памяти (MemoryHigh и MemoryMax), тут еще задается квота на загрузку процессора (CPUQuota), что не дает поднять ее выше заданного лимита — 100% загрузку CPU от процессов Chrome вы больше не увидите.
Теперь самое важное:
все указанные лимиты применяются ко всем дочерним процессам, которые запускает Chrome во время работы.
По сути этим создается специально ограниченный по ресурсам контейнер, внутри которого запускается браузер.
Ну и сам запуск с помощью черной магии systemd-run и указания слайса:
Аналогичным образом можно ограничивать по ресурсам любые другие «жирные» приложения, например Telegram, который в последних версиях повадился генерировать 100% загрузку процессора по любому поводу.
Замечу, что сей хитрый трюк работает и с приложениями, работающими внутри AppImage или snapd-пакетов, так что с его помощью замечательно урезаются аппетиты версий Chrome/Chromium в Ubuntu/Manjaro, управляемые snapd.
Отключение анимации в действии
❯ Отключение анимации
Существует одно интересное расширение для Chrome, позволяющее отключать анимированные картинки на всех страницах:
вместо мигающей хтони анимации будет отображаться один статичный кадр.
Нетрудно догадаться, что этим сильно снижается нагрузка на CPU/GPU (особенно в случае устаревшего оборудования), с чего происходит серьезная экономия заряда батареи.
Так что очень рекомендую к использованию.
Ungoogled Chromium и установка расширений
К сожалению для установки расширений из официального магазина для «левого» Ungoogled Chromium необходимо специальное расширение, без которого вас обрадуют ошибкой:
CRX_REQUIRED_PROOF_MISSING
А кнопка установки в интерфейсе магазина окажется скрытой.
В качестве альтернативного варианта можно использовать специальный сайт от авторов расширения, который позволяет скачать пакет с расширением .crx и установить его локально в вашем браузере.
Теперь переходим к самому интересному — к параметрам запуска.
❯ Параметры Chrome
У браузера Chrome есть огромное количество разнообразных параметров запуска, как документированных так и не очень. Часть из них дублируется во внутреннем служебном интерфейсе chrome://flags/, часть — нет.
Так выглядит служебный интерфейс с настройками браузера Chrome
Поскольку прямого соответствия именований между параметром запуска и названием опции нет, не стал описывать в статье вариант настройки через переключение опций.
Тем более что ряд опций, доступных через служебный интерфейс не имеют отдельного параметра запуска.
Этих самых параметров настолько много, что был создан отдельный сайт, посвященный только лишь их описанию, регулярно выгружаемому непосредственно из исходного кода браузера.
Так выглядит небольшая часть параметров в динамике:
Тут показано менее 1% всех параметров запуска браузера
С учетом постоянного устаревания и регулярных ломающих изменений в функционале браузера, нет ни возможности ни особого смысла описывать абсолютно все, поэтому ниже только те параметры, которые постоянно используются на моих машинах в целях оптимизации.
Параметр --enable-features= как нетрудно догадаться из названия используется для принудительного включения опций браузера.
В данном случае принудительно включаются кодеки для аппаратного декодирования видео, работающие на базе Video Acceleration API (VAAPI).
По-умолчанию, если библиотека VAAPI в системе не установлена либо работает неправильно, браузер автоматически переключится на медленный программный кодек, с чего будет сильно нагружаться процессор при проигрывании видео.
С данной настройкой, при проблемах с VAAPI браузер либо перестанет запускаться совсем, либо покажет явную заглушку вместо видео — таким образом появится однозначный сигнал о серьезной проблеме.
Комфортно смотреть видео даже на современном железе без работающего VAAPI вряд ли получится из-за сильной загрузки процессора, поэтому настройка актуальна для всех пользователей.
Chrome 37 introduced a GPU rasterizer. When enabled, some paint workloads can go from 100ms/frame to 4-5ms/frame.
Несмотря на то что опция является «экспериментальной» и вроде как работает не во всех случаях — ее включение это единственный вариант комфортного использования современного браузера на устаревшем железе.
Запрещает браузеру использовать фоновые сетевые запросы, например проверку обновлений для установленных расширений.
--disable-client-side-phishing-detection
Отключает фоновую проверку сайтов на фишинг.
Этот параметр вроде как удален в новых версиях браузера, но все еще часто встречается в различных руководствах и материалах.
Фоновое обновление этих баз отнимает ресурсы а сама проверка плохо работает в современных реалиях разделенного интернета, поэтому отключаем.
--disable-prompt-on-repost
Отключает дурацкое предупреждение о повторной отправке формы:
--disable-sync
Отключает облачную синхронизацию учетной записи Google.
Актуально только для обычного Chromium, для ungoogled-версии не используется, поскольку функционал глобальной учетной записи там вырезан.
--metrics-recording-only
Указывает браузеру только записывать отчеты с метриками производительности, но запрещает отправлять их на сервера Google. Отчеты сохраняются в текущем профиле, актуальны при поиске проблем с медленной работой браузера или отдельных сайтов.
--no-first-run
Отключает приветственный диалог при первом запуске браузера.
--safebrowsing-disable-auto-update
Отключает автоматическое фоновое обновление баз для «Safe Browsing» — специального сервиса Google для защиты от фишинга и подозрительных сайтов. Актуально для обычного Chromium, поскольку в ungoogled‑версии функционал «Safe Browsing» удален.
--ignore-gpu-blocklist
Натурально заставляет браузер «работать на дровах» — использовать неподдерживаемое и устаревшее оборудование для аппаратного ускорения.
Очень важная опция, без указания которой браузер тихо и цинично включит программную отрисовку ничего не сказав пользователю, с чего скорость отображения страниц сильно упадет.
--renderer-process-limit=2
Еще один «магический» параметр, критически влияющий на производительность браузера и потребляемые ресурсы:
именно с его помощью переопределяется лимит на количество запущенных процессов отрисовки страниц — самых тяжелых процессов браузера, создающих основную нагрузку на систему.
Количество таких процессов напрямую влияет на потребляемые ресурсы, поэтому в случае ограниченных ресурсов стоит выставить какое-то небольшое число.
--disable-smooth-scrolling
Просто «имба» за которую вы потом будете благодарить — параметр отключает плавную прокрутку в браузере, которая очень сильно влияет на скорость при работе на слабом или устаревшем оборудовании.
Влияет настолько сильно, что разницу становится видно визуально после перезапуска.
--wm-window-animations-disabled
Отключает практически всю анимацию во внутренних интерфейсах браузера — там где опции настроек, закладки и расширения.
--animation-duration-scale=0
Переопределяет длительность воспроизведения CSS-анимации, значение 0 означает полное отключение, но работает к сожалению только для элементов интерфейса самого браузера, не для страниц.
--disable-spell-checking
Отключает фоновую проверку правописания, которая серьезно влияет на скорость работы браузера (вплоть до подвисания страниц).
--enable-unsafe-swiftshader
Еще один важный параметр, который разрешает использование «небезопасного» программного рендера WebGL, что позволяет использовать 3D-графику в браузере даже на устаревшем оборудовании, которое не поддерживает современное Vulkan API.
Данный параметр по прямой аналогии с описанным в самом начале --enable-features= переопределяет опции браузера, которые необходимо отключить.
В данном случае отключаем встроенную рекламу новых фич браузера, которые вылезают при обновлениях и очень сильно бесят отвлекают.
Актуально только для обычного Chromium, поскольку в ungoogled-версии все эти радости вырезаны целиком.
Теперь рассказываю для самой широкой аудитории — про оптимизацию браузера под Windows.
Прокрутка ленты Reddit в качестве демонстрации, поскольку Reddit — один из самых «тяжелых» популярных сайтов, известных автору
❯ Хром и Windows
Я использую Windows 11, 10 и 7 на рабочих станциях а также множество разных виртуальных машин с серверными версиями Windows.
Поскольку оптимизации актуальны только при использовании браузера на рабочей станции (мало кому интересно работать из браузера прямо с сервера, правда?), поэтому в качестве тестовой среды будут выступать только три пользовательских версии Windows: 11, 10 и 7.
Технические характеристики машины из ролика с лентой Reddit
Сохраняете текст выше в файле run.cmd, кладете в каталог рядом с chrome.exe и используете для первого запуска.
Используемые параметры браузера и их логика полностью совпадают с описанными выше для Linux, шаги по установке расширения для отключения анимации также полностью аналогичны.
Замечу, что символ ^ — аналог \ в UNIX-мире и используется для переноса длинных строк в командных скриптах под Windows.
Если что‑то перенесется неправильно — просто удаляете символы ^ и сводите все в одну длинную строку.
Также добавлю, что в последние версии и Chrome (и даже Chromium) под Windows авторы напихали AI-фич под завязку, поэтому на моих рабочих станциях с Windows ныне используются только и исключительно Ungoogled-сборки.
Ungoogled Chromium на Windows 7 со всем тюнингом. Справа менеджер задач и загрузка памяти
Chrome и старые Windows
Официально Google перестала поддерживать Windows 7 для Chrome/Сhromium еще в 2023 году, поэтому если у вас осталась живая «семерка» и есть необходимость использовать современный браузер — будут определенные сложности.
Обратите внимание на версию браузера и дату сборки
Цитируя одну известную шутку: чем бы вы ни занимались — обязательно найдется азиат, который сделает еще круче. В случае с портированием Chrome на устаревшие версии Windows именно так и произошло:
стоило только начать изучать вопрос и доступные варианты — немедленно нашелся репозиторий со сборками последних версий Chrome... под Windows XP!
Windows XP вышла в далеком 2001м году и процесс портирования под настолько старую ОС был весьма непростым занятием. Вот тут выложены готовые сборки браузера под Windows XP с поддержкой аппаратного ускорения (!) — невероятный хардкор.
Теперь переходим к разделу для самых ярых фанатов своего дела.
Да, это современная сборка браузера Chrome, летающая на антикварном оборудовании. Без записи с экрана все работает еще быстрее
❯ Chrome и FreeBSD
Наконец последним разделом описываю то, с чего началась эта статья в далеком 2023-м году:
оптимизация работы браузера Chrome под FreeBSD на очень сильно устаревшем оборудовании.
«Очень сильно устаревший» — про тот самый Asus F3KE из 2007 года, спасенный автором от достойного погребения за долгую службу.
Так выглядит вывод fastfetch с описанием оборудования:
Конечно же для столь мощного колдунства пришлось провести немало нечистых ритуалов оптимизаций (начиная с кастомного ядра), но как минимум половина производительности — результат подбора правильных параметров браузера.
на самом деле скрывает портал в ад отдельный механизм повторного использования сессии DBus, подключаемый тут файл ~/.exports.sh создается вот таким специальным скриптом:
#!/usr/local/bin/bash
FF=0
if [[ -z $DBUS_SESSION_BUS_ADDRESS ]]; then lines=$(pgrep "dbus-daemon" -u "$USER" | (while read -r line do echo $line exp=`procstat -h -e $line` if [[ "$exp" == *"DBUS_SESSION_BUS_ADDRESS="* ]]; then echo "DBus session found" exp2=`echo $exp |sed 's/.*DBUS_SESSION_BUS_ADDRESS=\([^ ]*\).*/\1/'` echo export DBUS_SESSION_BUS_ADDRESS="$exp2" > ~/.exports.sh FF=1 break fi done; echo $lines) ) echo $FF if [[ "$FF" = 8 ]]; then echo "DBus session not found, starting.." dbus_out=`dbus-launch` echo $dbus_out > ~/.exports.sh fi if [[ -f ~/.exports.sh ]]; then source ~/.exports.sh fi fi
Этот скрипт натуральным образом ворует сессию работы с DBus, забираясь в окружение другого запущенного процесса (да, так можно было) — все ради того чтобы не запускать процесс dbus-launch повторно.
Помимо приседаний с параметрами, в версии для FreeBSD также используется описанное выше расширение браузера для отключения анимации, но вместо изоляции через cgroups используется более простой вариант со сниженным лимитом на количество запущенных процессов рендера:
--renderer-process-limit=2
Чего вполне достаточно для комфортной работы.
❯ За кадром
В качестве небольшого бонуса, ряд дополнительных параметров запуска браузера Chrome, которые остались за кадром. Они также применимы ко всем версиям и вариациям браузера и работают на всех операционных системах.
Актуально в первую очередь для тестов, но может влиять на системы защиты от ботов, поскольку данный ключ часто используют системы автоматизации, работающие поверх браузера.
--single-process
Заклинание чудовищной силы, которое заставляет браузер работать в одном единственном процессе:
Браузер Chrome, работающий целиком в одном процессе. Шок-контент
Этот весьма опасный (во всех смыслах) параметр переключает Chrome в нестандартный режим работы, при котором браузер не порождает отдельные процессы на каждую вкладку.
К сожалению такой режим работы является весьма нестабильным и браузер будет падать, особенно на сложном контенте и с большими расширениями вроде AdBlock.
Тем не менее, это единственный известный мне способ заставить Chrome работать без порождения дополнительных процессов.
--disable-features=UseSkiaRenderer
Отключает бекэнд Skia Renderer, используемый для отрисовки практически всей графики:
Chrome uses Skia for nearly all graphics operations, including text rendering. GDI is for the most part only used for native theme rendering; new code should use Skia.
К сожалению этот параметр является обязательным если вы собираетесь использовать --single-process, думаю очевидно что скорость отрисовки страниц при этом упадет.
❯ Эпилог
Мой опыт оптимизации браузера весьма специфичный и далеко не глобальный, поскольку решаемая задача касается производительности на устаревшем оборудовании и не самых популярных операционных системах.
Поэтому с радостью почитаю про ваш опыт и применяемые практики.
я сидел на Винде, выжимал все соки, и ставил 2 винды и Линукс как на попробовать, потом решил удалить 2 Винду и оставить только Винду и Линукс (я знаю что Линукс это ядро а дистрибутивы это система и бла бла бла) а удалить 2-рую Винду решил через винпе с дискпарт, в итоге удалил разметку диска... 3 дня восстанавливал, и восстановил только диск C и так с поломаной fs (файловой системой), решил установить систему которая была, а на флешке с Ventoy был только тот Линукс на потестить, в итоге поставил, был как пример 2+2=5, тупо и не понятно, всё спрашивал у ии, потом начал осваиваться, пользоваться терминалом чаще, изучал TTY и русский язык в нём, долго настраивал систему, потом залез в винпе и снова случайно переразметил диск... (да, я не учусь на ошибках) решил снова накатать Линукс, сделал всё почти так же, сделал даже свой сайт, и полез в загрузчик (grub) в итоге загрузки системы не было, а было только grub recap, и строка, я загрузился через команды в грабе и сделал sudo update-grub, всё заработало, потом установил граб на хдд, старый но рабочий, сам начал прописывать всё через пункты menuentry, не без помощи ии но я только обучался, и после 3 системы через пункты и загрузки ИСО (через loopback) я начал подозревать себя в дистрохопинге, я угадал, 13 систем это не "просто покатать" а потом и 17, начал изучать и устанавливать систему через ручную настройку и filesystem.squashfs (в исо файле) распоковывал на диск и делал базовые настройки, загружался и настраивал уже не через chroot, всё давалось тяжело, но я быстро запоминал команды и начал пользоваться TTY даже для выключения ноута (poweroff), даже взломал брата через локальную сеть и авто загрузки скрипта, сделал "хоррор" сообщения основные на песне по кинито пет, управлял его ноутом, а сейчас настроил и собрал другой слабый ПК который теперь выдаёт 80-100 фпс в 1.21.8, я мало играю в игры, больше пытаюсь найти новые ИСО образы и прописать их в граб (grub.cfg), а вот главная часть, мне было 11 когда слетела винда, а сейчас 12, да, я прошёл это за год, и много деталей умолчено так как я их не особо помню
если попросите могу скинуть сюда конфиг из grub.cfg
ладно скину сразу: insmod ext2
insmod ntfs
insmod fat
insmod part_gpt
insmod part_msdos
insmod loopback
insmod chain
insmod search_fs_uuid
insmod chainloader
menuentry "MX-23.3 ISO Custom Persistence" {
set isofile="/MX-23.3_x64.iso"
search --no-floppy --fs-uuid --set=root 2A82-F516
loopback loop ($root)$isofile
linux (loop)/antiX/vmlinuz fromiso=$isofile buuid=2A82-F516 boot=live persist_all home=2A82-F516 quiet splash
initrd (loop)/antiX/initrd.gz
}
menuentry "Tiny Core Pure 64 (Graphics-RAM)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/TinyPure64.iso"
loopback loop ($root)$isofile
linux (loop)/boot/vmlinuz64 loglevel=3 tce=UUID=2A82-F516 waitusb=12
initrd (loop)/boot/corepure64.gz
}
menuentry "Core Pure 64 (Console-RAM)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/CorePure64.iso"
loopback loop ($root)$isofile
linux (loop)/boot/vmlinuz64 loglevel=3
initrd (loop)/boot/corepure64.gz
}
menuentry "Tiny Core Pure 64 (ext4-Graphics)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/TinyPure64.iso"
loopback loop ($root)$isofile
linux (loop)/boot/vmlinuz64 loglevel=3 tce=UUID=48a15c2f-33d7-4573-9147-c0c7cb03d22d waitusb=12
initrd (loop)/boot/corepure64.gz
}
menuentry "l24amd64" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/l24amd64.iso"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile rootwait quiet splash
initrd (loop)/casper/initrd
}
menuentry "l18amd64" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/l18amd64.iso"
loopback loop ($root)$isofile
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile toram rootwait
initrd (loop)/casper/initrd
}
menuentry "debian (LXDE)" {
search --no-floppy --fs-uuid --set=root 2A82-F516
set isofile="/d-live-13-64l.iso"
loopback loop ($root)$isofile
linux (loop)/live/vmlinuz-6.12.73+deb13-amd64 boot=live findiso=$isofile toram rootwait
В качестве базы планируется использовать ChimeraOS, а поверх неё создать собственную консольную оболочку.
Ищу разработчика, которому было бы интересно поучаствовать в создании интерфейса и лаунчера системы
Основные задачи:
автозапуск оболочки после включения;
управление только геймпадом;
библиотека игр;
экран запуска игр;
настройки системы;
поддержка будущего обновления интерфейса.
По ощущениям интерфейс должен быть близок к современным игровым консолям (PS4, PS5, Steam Deck), но без копирования их дизайна.
Проект сейчас некоммерческий и создаётся на энтузиазме. Главная цель на ближайшее время, собрать работающий devkit и показать его на каких нибудь игровых мероприятиях. А после выйти на краундфандинговые площадки.
Если интересно, можно обсудить текущий план развития @stat_kry
