У 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 так, чтобы оно работало как надо.

Отвечаю самому себе на #793J1I: надо было ебануть bgwriter_lru_maxpages = 0 в постгресе.

Интересный факт: в тестировалке webrtc в firefox кино с камеры показывают без задержек, а mpv av://v4l2:/dev/video0 - с задержкой где-то миллисекунд 400. Чтобы mpv не тормозил, надо ему сказать --cache-secs=0 --demuxer-readahead-secs=0 --untimed