Комар, просыпайся, тут очередная замена ансиблу на шелле: https://github.com/space-sh/space (ну и что, что 3,5 года коммитов не было)

Ебучий cups сохранил сертификат принтера год назад и отказался печатать сегодня с загадочным поведением (принтер просто паузился при попытке что-либо сделать), полчаса пердолился пытаясь понять что с этим делать, в итоге починил удалением старого сертификата. Хуй знает что произошло, принтер вроде тот же самый, и mitm в локалке особо не эцсамое. Короче ipps не готов для десктопа!

У screenfetch еще с июня висит PR https://github.com/KittyKatt/screenFetch/pull/797, который убирает багу, которая бесит меня уже год и актальна. screenfetch-dev не обновлялся уже год, поэтому в дистрибутивах лежат пакеты, которые содержат багу. Бесит. И да, надо, чтобы об этом знали все.

>«Чухонец разбушевался, будем успокаивать»: Медведев ответил на антироссийский выпад Торвальдса и предложил национализировать Linux можна впринцыпи их воще нах поцлат как с исходнекаме мсвс поцлале))))

https://lore.kernel.org/all/CAHk-=whNGNVnYHHSXUAsWds_MoZ-iEgRMQMxZZ0z-jY4uHT+Gg@mail.gmail.com/ Так-то, рашн троллз!

https://github.com/l29ah/ficlone Наговнякал небольшую утилитку для создания reflink'ов от кусочков файлов. К сожалению похоже линукс в обозримом будущем будет уметь только кратно размеру блока файловой системы делать их. Надо было нейронку просить написать наверное.

Ох уж эти sysv-семафоры: $ ipcs -s -i 426007 Semaphore Array semid=426007 ... semnum value ncount zcount pid 0 0 0 0 580473 $ stat /proc/580473 stat: cannot statx '/proc/580473': No such file or directory $ stat /proc/*/task/580473 stat: cannot statx '/proc/*/task/580473': No such file or directory

что-то кути охуели любое нажатие мыши и любой скроллинг в любом месте любого окна пробуждает все кутишные софтины что-то там поделать

predictable interface names my ass, в 2024 году они всё ещё меняются с ens3 на enp0s2 после ребута

> the Linux kernel Dirty page flush algorithm does not scale to large memory sizes, so anytime the Dirty page in /proc/meminfo exceeds around 1GB the writeback speed slows down progressively and eventually the /proc/sys/vm/dirty_ratio or /proc/sys/vm/dirty_bytes limit is exceeded and the kernel starts throttling all writes to keep the Dirty pages from growing any further. > > To maintain high write speed (in OPs case up to 800Mb/sec, can easily be 2 Gb/sec for a hardware RAID controller with cache) you need to counter intuitively lower the /proc/sys/vm/dirty_bytes and dirty_background_bytes to 256M and 64M respectively > > Make sure you do a sync first otherwise the system will freeze on writes for several hours until the Dirty page value in /proc/meminfo drops below the new value in /proc/sys/vm/dirty_bytes. The sync will also take several hours, but at least the system will not be frozen during this time. https://serverfault.com/a/995658

OOM всё чаще стал приходить в момент, когда памяти, казалось бы, ещё дофига. Кажется, я начинаю догадываться, почему: MemFree: 1940452 kB MemAvailable: 3082928 kB Buffers: 30792 kB Cached: 7696368 kB Dirty: 256 kB Writeback: 0 kB С каких пор Available стал меньше Free+Buffers+Cached-Dirty-Writeback? Кто и зачем спиздил у меня эти 6,5 гигов памяти?

Удалось выяснить, что: — vm.dirty_background_ratio работает независимо от vm.dirty_writeback_centisecs. То есть даже если ты настроил выписывалку из кеша на запуск раз в год, то после достижения background_ratio она все равно запустится. — vm.dirty_expire_centisecs ни хуя ни на что не влияет. Почему — непонятно. Исходники прыщей мне читать лень.

Похоже, постгресовые буферы были сделаны из-за того, что никто в мире не знает, как настроить https://docs.kernel.org/admin-guide/sysctl/vm.html так, чтобы оно работало как надо.