https://www.phoronix.com/scan.php?page=news_item&px=Apple-M1-Gallium3D-glmark2

baby steps для Mesa на Apple M1. Удивительно, но что-то уже начинает работать.

———
https://www.phoronix.com/forums/forum/software/desktop-linux/1322382-system76-releases-v1-1-scheduler-for-optimizing-linux-desktop-laptop-responsiveness #ananicy

Наткнулся на красивое, пока читал про new rust popos scheduler.

Конерктено - на https://gitlab.com/ananicy-cpp/ananicy-cpp.

Это с++ вариант моего скриптеца, который выставляет приоритеты и тип шедулера для процессов системы.

С++, event-driven(то есть, не пересканирует каждый раз дерево процессов, красота).

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

Программуля - простая, как 5 копеек. Загружает 100 json, в которых для определенных названий процесса есть настройки nice, ionice, scheduler, etc.

Но намучался я с ней, что пиздец.

* Автор настаивает, что его код надо всегда собирать с -fsanitize=undefined. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L46 Товарищи, вот в тот момент, когда я написал workaround для фикса этого "ценного мнения", я уже понял, что мне предстоит интересный вечер. Очень редко когда у коллеги есть ценное мнение по одному такому поводу, и нет ценного мнения на любой другой вопрос.

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L49 - автор расставил nodiscard почем зря, а вот проверить, что оно работает хотя бы в clang - нет, не проверил.

* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L75 - очень вольно обходимся с включением заголовков. Настолько вольно, что я не стал патчить исходники, и, наконец-то, разобрался, как в clang включить какой-нибудь заголовок везде, принудительно.

* Коллега считает, что очень хорошо знает С++(нет), поэтому везде использует самые последние фичи. Но он, типа, позаботился о тех, у кого компилятор не позволяет последние фичи, и написал пару библиотек-оберток.

https://gitlab.com/ananicy-cpp/stl-polyfills

Если stl-format просто прокcирует std::format -> fmt::format, то с stl-jthread я намучался.

В какой-то момент я понял, что коллега просто не осилил написать работающий код, и забил на это дело. https://gitlab.com/ananicy-cpp/stl-polyfills/std-jthread/-/blob/master/src/stop_source.cpp#L24 - вот тут неустранимый segfault.

Но я не отчаялся, и просто заменил std::jthread на "new std::thread". Ну, да, утечет 2 треда, не столь важно для демона.

(#reboot Минутка мудрости от старого меня - не пытайтесь написать корректный graceful shutdown, просто пишите exit(0) по месту. Все равно оно никогда верно работать не будет, только замучаетесь чинить)

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L58

* на musl это никто никогда не собирал, в Alpine пакетов нет https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L79

Оно скомпилировалось, и даже заработало - выставило правильный nice процессам.

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

Знаете, я, когда гуглил вот это вот - https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 уже знал, что столкнусь с особым ценным мнением Ричарда Фелкера(автора musl). И, конечно, я не ошибся.

Он пишет, что Linux не может posixly correct выполнить эту задачу, поэтому мы вернем ENOSYS.

На этом я уже взвыл, место начало казаться таки проклятым.

Но решил не сдаваться.

Сначала я попробовал собрать связку uclibc-ng + libc++, так как в uclibc эта функция реализована ожидаемым способом. Но так не вышло, потому что в uclibc какая-то не такая поддержка локалей.

В итоге, реализовал syscall сам - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/gnushim/sched.c, и, кстати, нашел ошибку в коммите от Фелкера, https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getschedparam.c?id=1e21e78bf7a5c24c217446d8760be7b7188711c2 , там лишний & у param. Пппц, коммитят, вообще не проверяя свой говнокод.

Оно завелось, работает, 2 треда утекают, ну и хрен с ними. Отдельный вопрос, зачем в этой программе вообще треды.

https://keunwoo.com/notes/rebooting/ #reboot

Хороший, только очень длинный текст, в котором написаны 2 простых мысли:

* В любой системе нарастает энтропия. По другому - в системе есть https://ru.wikipedia.org/wiki/Гейзенбаг.

* Перезагрузка(VM, хоста, программы) - это простой способ вернуть систему из состояния с накопившейся ошибкой в состояние без такой ошибки.

Люди, которые меня знают поближе, знают, что я люблю давать пару странных архитектурных советов:

* Периодически рестартовать свои программы на кластере. Обычно достаточно обновления версий, если оно регулярное.

* Несколько более странный совет - вставлять в свою программу abort() в случайные места. В проде, именно в проде.

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

———
https://hpdevone.com/

Какой-то странный forced mem от HP и ноутбук на PopOS. Написали про это поделие на 5 форумах, которые читал сегодня.

Расскажу вам такую историю.

Я очень странно отношусь к своей технике. Например, экран и клавиатуру ноутбука я могу не протирать по несколько месяцев, потому что зачем? И потому что лень.

Однажды я ехал на переднем сиденье такси, с ноутбуком. Водитель половину поездки пялился на мой ноут, потом достал из бардачка спиртовую салфетку, протянул мне, и сказал: "Протирай!". Больше за всю поездку мы не перемолвились ни словом.

К чему я клоню?

Я, с полгода назад, рассказывал, какой охуенный ноут я купил - #Xiaomi, Ryzen, OLED, 4K. https://aliexpress.ru/item/1005002697829975.html?sku_id=12000027107974063&spm=a2g0o.search.0.0.4f227153dK0TN4

Стоит дешевле, чем собрат от HP, начинка лучше, и просто божественный OLED экран!

Он настолько крутой, что я завел себе привычку вытирать его 3 раза в неделю спиртовой салфеткой! Никогда в жизни такого не делал, а тут делаю.

Это не реклама, ноут реально офигенный. Stal/IX я разрабатываю на нем, его 8/16 ядер не простаивают ни секунды.

В продолжении темы #reboot #stal/ix

https://www.phoronix.com/news/Fedora-38-Shutdown-Timer-45

"Last month a change proposal was filed for aiming to yield faster reboots and shutdowns of Fedora Linux by shortening the time window that services can block the shutdown process"

У меня, конечно, shutdown - моментальный процесс, даже процессы не убиваю.

Если каким-то сервисам нужно сохранять состояние, то это надо делать регулярно, во время работы, в момент изменения этого состояния. А откладывать это на стадию shutdown - так себе затея, потому что это будет кривой, косой, и неотлаженный кусок говнокода, реально срабатывающий один раз из 10.

Знаете, такой подход дает результаты. Например, я так нашел отсутствующий вызов sync в пакетном менеджере - иногда, после reboot, система просыпалась со старым system #realm, потому что переключение симлинки откатывалось файловой системой. А не нашел бы - был бы странный https://en.wikipedia.org/wiki/Heisenbug

#rant #gold #reboot

Никогда, никогда не пилите graceful shutdown.

Нажали на кнопку exit/ctrl-c, программа сохраняет все открытые файлы, если это gui программа, а дальше просто exit(0) _exit(0).

Нет, вот зачем-то люди хотят корректно финализировать все инициализированные подсистемы, завершить треды, и так далее.

Нахрена? Какой в этом физический смысл?

Это было важно в OS без защиты памяти (DOS/Windows 95-98-Me), но сейчас-то зачем?

Этот код:

* Никто и никогда нормально не тестирует

* Имеет тенденцию вызывать graceful shutdown от зависимых библиотек, а в нем его тоже никто и никогда не тестирует!

* Имеет тенденцию работать в странных контекстах (signal handler (никто не умеет писать корректные sighandler!!!), atexit, и так далее), а не в обычном flow выполнения программы. (сука, а если там кто-то еще пытается выводить stack trace - то обычно это леденящий душу пиздец по умолчанию)

Вот есть такая https://github.com/WerWolv/ImHex

Она зовет graceful shutdown от библиотеки glfw, причем НЕОЖИДАННО делает это несколько раз - при каждом открытии и закрытии splash screen - https://github.com/WerWolv/ImHex/blob/master/main/gui/source/init/splash_window.cpp#L545

И что бы вы подумали?

Код очистки glfw, в каком-то сраном коде по очистке данных для linux joystick, который никто и никогда не вызывал, не отлаживал, и вообще, всем посрать, что он делает 1 раз при выходе из программы, содержит double free, в вызове regfree() - https://github.com/glfw/glfw/blob/e2c92645460f680fd272fd2eed591efb2be7dc31/src/linux_joystick.c#L337-L348 !

(в транке, кстати, пофикшено уже)

Мораль?

* Не надо маниакально пытаться позвать все cleanup функции, а еще лучше, кладите на них с прибором, OS разберется.

* Всегда нужно рассчитывать на самый плохой вариант, что комп будет выключен по hard shutdown, и писать код соответствующе. А это значит, что нельзя рассчитывать на то, чтобы хоть какой-то cleanup был вызван.

Я вот как-то писал про свою личную OPS практику - периодический #reboot программ в проде (https://t.iss.one/itpgchannel/370)

Вот, хороший текст, подтверждающий эффективность такого подхода:

https://pushtoprod.substack.com/p/netflix-terrifying-concurrency-bug

"We created a rule in our central monitoring and alerting system to randomly kill a few instances every 15 minutes. Every killed instance would be replaced with a healthy, fresh one"

И я, кстати, совершенно не кривил душой, говоря про это.

Вот, например, я периодически рестартую свои #haproxy и ssh туннели для обхода блокировок (https://t.iss.one/itpgchannel/2262) в своей #lab #home_lab - https://github.com/pg83/lab/blob/master/lab/cg.py#L455-L457

https://matt.blwt.io/post/regular-restarts-are-good-actually/

TL;DR - еще один взгляд на тему "почему регулярные рестарты - хорошо".

#reboot

https://archive.is/rlrm8

https://www.reddit.com/r/privacy/comments/1gmz9m8/apple_quietly_introduced_iphone_reboot_code_which/

https://www.404media.co/apple-quietly-introduced-iphone-reboot-code-which-is-locking-out-cops/

Вот, эппол тоже понимает толк в #reboot !

https://t.iss.one/tech_b0lt_Genona/4960

Я для себя проблемы #haproxy (а это то еще глюкавое поделие!) решил очень просто - https://github.com/pg83/lab/blob/master/lab/cg.py#L460

Если совсем коротко:

timeout 3600s haproxy

Впрочем, я так решаю не только лишь проблемы с haproxy:

https://t.iss.one/itpgchannel/370
https://t.iss.one/itpgchannel/2401
https://t.iss.one/itpgchannel/2262

#reboot

https://www.opennet.ru/opennews/art.shtml?num=63075

Не пойму, является ли эта техника регулярным #reboot, или нет.

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

Мне это напоминает историю с kernel mode setting, когда случается несколько переключений из одного режима в тот же самый, просто потому, что два режима невозможно сравнить на равенство, не имея весь их state на руках, а он размазан по всему ядру.

https://techcrunch.com/2025/04/15/for-security-android-phones-will-now-auto-reboot-after-three-days/?guccounter=1

Теперь и Google тоже понимает толк в #reboot!

#herobora

В итоге, мой #runsvdir у меня прижился, и, как понятное следствие, я окончательно отказался от ошметков #runit:

* https://github.com/pg83/ix/blob/main/pkgs/bin/ix/init/ewontfix/main.c - свой элементарный init.

* https://github.com/pg83/ix/blob/main/pkgs/bin/ix/init/rc/ix.sh#L9-L11 - клей между моим init, и схемой загрузки "как в runit", чтобы можно было заменять туда-сюда.

* https://github.com/pg83/ix/blob/main/pkgs/bin/ix/init/halt/main.c https://github.com/pg83/ix/blob/main/pkgs/bin/ix/init/reboot/main.c - реализации halt/reboot, они, как ни странно, тоже часть init. Если такой способ (без graceful shutdown) кажется странным - читаем мои заметки про #reboot, https://t.iss.one/itpgchannel/1572.

* https://github.com/pg83/ix/blob/main/pkgs/bin/ix/pid1/m.cpp#L157-L175 - пришлось перенести в runsvdir код, который убивает orphane процессы, в runit у меня это был cron job на shell (https://github.com/pg83/ix/blob/main/pkgs/bin/sched/stale/procs/scripts/staleprocs.sh), но в новой схеме так не получается, потому что сервисы сразу начинают наследоваться от pid 1, а не от pid > 1, поэтому инвариант "все, что подвисло к pid 1, но не runsvdir - мусор" перестал работать.

Так что теперь у меня официально полностью велосипедный in house init!

С точки зрения скриптов инициализации ничего не поменялось, ага.