Короткие заметки из жизни, 1-3 предложения.
Короткая заметка по теме локальной библиотеки. Как уже писал в прошлой заметке, сделал интерфейс для работы с ZIM-файлами с архивами Википедии. С архивом «Флибусты» в Linux обычно работал через Myrulib, которая уже больше десятка лет не развивается — уже не помню, вроде были какие-то проблемы со сборкой, но где-то нашел то ли готовую сборку под современные системы, то ли переделанную, которую получилось собрать — в общем, тем и пользовался.
Сейчас захотелось большего. Что было найдено:
Собственно, сабж. Архив с fb2-книгами с «Флибусты» я давно у себя на NAS держу, а тут на глаза попался проект Kiwix. Оказалось, держать у себя на диске оффлайн-копии Википедии, Викисловаря и некоторых других сайтов не просто, а очень просто. Есть читалки для самых разных устройств и систем (в том числе в репозитории Debian). Все, что надо — скачать ZIM-файл (к слову, если добавить к нужному файлу расширение .torrent — можно качать через торрент) нужного проекта (либо воспользоваться встроенной библиотекой в некоторых читалках) и под нужный язык и открыть его в этой читалке. И есть kiwix-server, который можно развернуть, например, на NAS и с помощью которого можно через веб-браузер работать с этими оффлайн-копиями:
docker run -d -v /storage/info/zim/:/data -p 8080:8080 --restart unless-stopped --name kiwix-server jamescherti/kiwix-serve *.zim
В этой копии «Википедии» не будет истории правок и всякого такого. Это просто слепок проекта на определенную дату, позволяющий читать его без доступа в Интернет. Поэтому maxi-версия (да, там есть разные варианты, с полным и сокращенным набором статей, с картинками и без) английской «Википедии» весит всего 116 ГБ, еще 39 и 27 займут русская и украинская. В общем, на копеечной флешке сейчас на планшете легко и просто держать огромную базу знаний.
И это круто.
Update: конкретно от Wikimedia можно загрузить ZIM-файлы по этой ссылке.
Про игры я тут еще вроде не писал 🙂
Спустя более, чем 2 десятка лет, как я активно играл в RRR на Sega Mega Drive 2 — открыл для себя, что при апгрейде бампера в Air Blade (машинка, которую стоит сразу же покупать на замену дефолтным, как только появятся 70к) снижается мощность ракет.
Играл на эмуляторе (купил даже на Али джойстик под что-то этакое), прошел целиком все на Warrior и с Air Blade, у которого из апгрейдов были только ракеты/мины/ускорители: сначала держал деньги ради покупки Havac в нужный момент (кстати, после 1 млн. $ счетчик переполняется, но «внутри» значение остается верным), потом был спортивный интерес уже доиграть так.
Потом решил ради фана поиграть с последнего сохранения (Slash, division A), но уже проапгрейдившись. Начинаю — а противники-то выносятся не так активно. Проверил — да, без апгрейдов было лучше: 2 ракеты и готово; выпустил полный запас — и на время вокруг тихо. Перебрал по очереди обновленные компоненты — таки бампер. С апгрейдом пропорционально слабеют ракеты, на максимальном уровне уходит (вроде) 4 штуки на противника.
Неожиданно 🙂
Update: проверил изменения при апгрейде бампера (защиты, если быть точным) — меньше потери на минах. Без апгрейда выходит 35% потерь на статичной мине (наезд на 3 мины — и все), с полным апгрейдом — 15-20%.
Мораль — не наезжаем на мины и не пользуемся защитой 🙂
Решил тут сделать стату в Munin для каждого PHP-FPM-пула в отдельности, на глаза попался (ок, гуглоИИ подсказал) плагин multips. Плагин в итоге не подошел (толку мне с простого числа процессов, я хочу подробную стату, как в proc), но суть не в том. В процессе разбора того, как заставить эту хрень работать — дошел до основного кода за неизвестным авторством:
for name in $names; do
***
PGREP=$(command -v pgrep)
if [ -n "$PGREP" ] && [ -x "$PGREP" ]; then
"$PGREP" -f -l "$name" | grep "$REGEX" | wc -l
***
else
ps auxwww | grep "$REGEX" | grep -v grep | wc -l
fi
done
Т.е., если у нас в системе есть pgrep — значит, имя в конфиге должно строго соответствовать процессу, который ищешь. А если нет — ты волен называть сущность в конфиге как хочешь.
В итоге конфиг вида:
[multips]
env.names jw_wiki
env.jw_wiki php-fpm.*jabberworld.info
не работал прежде всего из-за наличия pgrep.
А всего-то надо было сделать что-то в стиле "$PGREP" -a -c -f -l "$REGEX"
Только что игрался с апдейтами ollama на своем ИИ-хосте — выяснилось, что свежие версии перестали использовать CUDA и работают только на CPU.
Если заглянуть в journalctl:
msg="NVIDIA driver too old" device="NVIDIA GeForce GTX 1080 Ti" compute=6.1 driver=550 required_driver="570 or newer"
И, собственно, да, в репозитории Debian stable есть только 550-й драйвер. В бэкпортах чего-то более нового не вижу. Так что или ставить драйвер вручную, или пока что сидеть на старой ollama. Последняя «рабочая» версия — 0.24. Поставить определенную версию можно так:
curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.24.0 sh
В свете максимального снижения потребления от внешней сети уже весьма заметным стало даже потребление от выключенных стабилизаторов Элекс Герц v3. Сейчас решил это тем, что поставил автоматы (и чуть позже поставлю смарт-модули для удобного включения) прямо перед ними. Попутно померял потребление в разных режимах:
Это все с ВЫКЛЮЧЕННЫМ автоматом на корпусе стабилизатора.
Включенный стабилизатор (в режиме стабилизатора, конечно) потребляет 17W.
С учетом того, что требовалась регулировка (даже не регулировка, а просто давать выдержку хотя бы в минуту — против штатных и нерегулируемых 5 секунд у стабилизатора) времени включения нагрузки, для чего поставил отдельно реле времени + пускатель — общее потребление без нагрузки выходит 20W.
Заметка между делом.
Давно уже мигрировал код модуля контроля параметров сети главного щитка на базу ESP Home. В основном все работает, но какое-то время назад добавлял «красивости» — хотелось регистрацию максимальных значений мощности по каждой из фаз, суточный объем потребленной энергии и тому подобное.
Читать далее Скользящее окно в filters у ESP Home и переполнение
Заметка между делом.
Столкнулся с тем, что на домашних серверах (на данный момент один обновил до Debian 13) стало мало места в /boot/efi. initrd занимал 47 МБ, что как-то неприлично много, особенно с учетом MODULES=dep в /etc/initramfs-tools/initramfs.conf.
Оказалось, что у xen-tools свое мнение на этот счет в /etc/initramfs-tools/conf.d/xen-tools: «To make the Dom0’s initramfs working inside DomUs, too, most modules need to be included». В моем случае initrd из dom0 никак не использовался для domU, поэтому копировать все доступные модули в образ для dom0 было излишним.
«Не отходя от кассы» протестировал и одну из своих mini ITX-материнок на APU AMD C60, для которой официально поддерживается только 8 ГБ.
Всю ночь гонял Мемтест, без ошибок. Когда докуплю еще планок — проверю и на 32 ГБ.
Скорость обмена небольшая — 2,386 GB/s (с двумя планками получилось 2,645 GB/s). Но при достаточном объеме памяти вполне можно стараться компенсировать хилость процессора активным кэшированием всего чего только можно для каких-нибудь домашних применений — Home Assistant, сидбокс, ejabberd, веб-сервер с легкими сайтиками, etc.
Update 2026-04-18: AMD C60 видит и 32 ГБ ОЗУ:
…а также поддержка >32 GB RAM.
Заказал себе такое счастье с Али — DDR3 1X16GB 1600 MHz. В свете возни с ИИ-хостом решил попробовать поискать и более емкие модули, чем имевшиеся 8 ГБ. Официально FX-8320 поддерживает максимум 32 ГБ (т.е., как раз только 8 ГБ модули). 16 я никогда в руках не держал и в хозяйстве таких не было. Решил провести эксперимент. Вышло около 32$ на распродажах.
И ведь таки работает. Прошел Мемтест как в соло-варианте, так и в паре с имевшимися Team’ами.
В отличие от Team с XMP на 9/9/9/24@1600, тут было только 11/11/11/27 для такой частоты. На 9/9/9/24 запускаться отказывались. НО. Что интересно, соло-модуль с Али давал чуть более высокую скорость (4,06 ГБ/с), чем соло-модуль с XMP (3,83 ГБ/с). Полный комплект Team в двухканальном режиме, конечно, давал ощутимый прирост — примерно 5,5 ГБ/с.
В общем, надо будет на следующих распродажах набрать себе еще таких модулей. Можно набрать внушительный объем (пусть далеко не новой и быстрой памяти) за относительно недорого и дать вторую жизнь старым платформам.
Update 2026-04-18: получил еще 3 планки. Все ок, FX-8320 корректно видит 64 ГБ ОЗУ:
И сразу после теста оказалось, что именно такие планки разобрали. Хотел еще парочку отдельно под C60 🙁