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

Ох уж эти 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

https://bugzilla.mozilla.org/show_bug.cgi?id=1801952 > Opened 2 years ago > Status: NEW

Недели две минимум состав вкладок не менялся, только графана графики рисовала да ютуп забытый в фоновых вкладках простаивал. И что бы вы думали? [unhandlable oom] Failed to mmap, likely no more mappings available /builds/worker/checkouts/gecko/memory/build/mozjemalloc.cpp : 1726ExceptionHandler::GenerateDump cloned child ExceptionHandler::WaitForContinueSignal waiting for continue signal... 26333 ExceptionHandler::SendContinueSignalToChild sent continue signal to child Смешно ещё, что форкнувшийся от него crashreporter на этом моменте напрочь завис и даже не показал окна «мы обосрались, поделись с нами дампом».

— Замечаем, что свободная память куда-то внезапно съёбывается. killall -STOP firefox-bin — Уходим с воркспейса с браузером. Память возвращается. Firefox всё ещё в T state. — Возвращаемся в предыдущий воркспейс. Память опять куда-то девается. — Дампим smaps_rollup всех процессов, сравниваем. Разница копеечная. Неважно, Rss, Pss, firefox-bin, Xorg, i3 — да вообще всех метрик и по всем процессам. — Дампим meminfo. Разница только в гигабайтищах, на которые похудели MemFree и MemAvailable. slabinfo и df -h /dev/shm на таком фоне даже нет смысла сравнивать (но всё равно сравниваем и не видим ничего интересного). Что, бля, происходит нахуй?!

Хуясе, впервые вижу whois не на английском. Ещё и маску сети сразу написали. 조회하신 IPv4주소는 한국인터넷진흥원으로부터 아래의 관리대행자에게 할당되었으며, 할당 정보는 다음과 같습니다. [ 네트워크 할당 정보 ] IPv4주소 : 183.96.0.0 - 183.127.255.255 (/11) 기관명 : 주식회사 케이티 서비스명 : KORNET 주소 : 경기도 성남시 분당구 불정로 90 우편번호 : 13606 할당일자 : 20091104

> I also got around to writing a Sway patch to gracefully handle GPU resets. This should be good news for users of a particular GPU vendor which tends to be a bit trigger happy with resets! Sway will now survive and continue running instead of being frozen. Note, clients may still glitch, need a nudge to redraw, or freeze. A few wlroots patches were also required to get this to work. А мог бы иксы попатчить! Штош, наконец-то появился повод посмотреть на эти поделки.

За 15 лет наконец-то найдены хорошие причины перебраться на tmux: — ^Bw показывает содержимое окон и список, листаемый простым ↑/↓. В screen нужно либо дрочить ^An^An^An для перебора, либо ^A" и бегать вслепую. А можно просто... — ...^Bf, чтобы поискать окна по содержимому их буфера. screen так до сих пор не может. — `tmux send-keys -l` не требует ёбли с экранированием, в отличие от `screen -X stuff`, где надо как минимум помнить про ^ и раскрывание переменных окружения в _некоторых_ версиях, и всё это внутри мелкого строкового буфера хуй пойми какого размера, иди ищи в нечитаемых исходниках. Но нет, все эти годы ширпотребные агититационные утюги засраны дрочкой не в ту сторону: тайлинг (во-первых, уже есть i3wm/xmonad, во-вторых, мне копипастить не только внутри tmux нужно), синтаксис для статусбара, лицензии... не то, не то надо рекламировать!

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

БЛЯТЬ ПИЗДЕЦ systemctl --user на хуй не работает после su, потому что в ENV не поменялось DBUS_SESSION_BUS_ADDRESS ДА КАК ВООБЩЕ МОЖНО БЫЛО ТАК ХУЕВО СДЕЛАТЬ

Bump each letter in nginx and we get.... ohjoy!

> 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 гигов памяти?

Решил наебать систему и заюзать podman. Во время сборки простого контейнера (совершенно ничего особенного, debian с моим сраным приложением) эта хуйня сожрала ТРИДЦАТЬ СЕМЬ ЕБАНЫХ ГИГАБАЙТОВ в пике, а когда закончила — занимает всего 19 GB. Реально, запустил podman build один единственный раз. Нету у меня слов, блять, нету их, нема, на хуй.

Команда journalctl (показывающая логи) на хуй уходит в задумчивость на неопределенный срок, если нажать клавишу «end» на клавиатуре. В то время как команда less на файлах на порядки больше моментально переходит в конец. Потом, правда, начинает свое «Calculating line numbers...» — но это прибивается по ^C. Ну я, блять, не знаю, что тут сказать. Прогресс, чо. Удобно, на хуй.

сдался костылям и задал Xft.dpi прикол: тулкиты ведут себя по-разному если его нет (одни используют нативный dpi, другие считают что у тебя 96dpi), но одинаково если есть

После `swapoff *` количество занятой памяти уменьшилось на (29,6+29,4)—44 = 15 ГБ. WTF? Для накладных расходов на поиск страниц соотношение 1:2 какое-то дохуя жирное. В SwapCached столько не было; точно не помню, но где-то меньше пяти гигов.

Кажется, я понял, откуда берутся эти охуительные `X11 error: BadValue` и `X11 error: 136`: эти говнюки на пару дожрали остатки видеопамяти на amdgpu! При том, что webgl.disabled = true и хардварные акселерасьёны якобы выключены. Нахуй вы такие обжоры вообще, а.

Дайджест тщетности компукторного бытия, серия 1.083e+17 - Ядро после смены монитора продолжает думать, что у меня по HDMI подключен монитор с другим EDID. Высокие разрешения приходится добывать дедовским способом, содой и уксу^W^W^W генерацией modeline. - Попробовал посмотреть на wayland в 2023. sway под qemu либо не запускается вообще, либо тормозит, мучая себя хвалёным на просторах инфернетов llvmpipe-ом, либо обсирается с `Atomic commit failed: Cannot allocate memory`, хотя свободны гигабайты и затребованное разрешение даже не 1080p. А ещё иногда глитчует и рисует курсор не там, где происходит клик. Wayland дохуя готов для десктопа! Но устарели, конечно, иксы, в которых ничего подобного не наблюдается, не перепутайте. - Распоследние ядра, впрочем, не отстают и живут со сломанной графикой на QXL: https://bugzilla.redhat.com/show_bug.cgi?id=1363850 — заброшен https://bugs.freedesktop.org/show_bug.cgi?id=98322 — заброшен https://bugzilla.redhat.com/show_bug.cgi?id=1957758 — якобы починен, но норот всё равно жалуется - Каждая новая вкладка с поисковой страницей гоогле жрёт 150–200 метров минимум, каждая вторая плодит iframe с youtube в недрах элементов с «display: none», а ещё они со временем пухнут, попутно делая миллион запросов то к /gen_204, то к /_/VisualFrontendUi/gen204, то вообще к play.google.com/log. Нахуя? - Распоследний firefox после выхода иногда часами тупит с RunWatchdog: Mainthread nested event loops during hang: --- CanvasManagerParent::Shutdown - Бля, а я уж было подумал, что ядро разучилось считать память, когда увидел VmRSS бо́льший, чем MemFree-MemAvailable при отсутствии свопа: https://github.com/htop-dev/htop/issues/1051