Хуясе, впервые вижу 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

То Xorg.0.log пухнет гигабайтами из-за сотен [885918.408] _XSERVTransSocketUNIXAccept: accept() failed [885918.408] _XSERVTransSocketUNIXAccept: accept() failed [885918.408] _XSERVTransSocketUNIXAccept: accept() failed [885918.408] _XSERVTransSocketUNIXAccept: accept() failed в секунду с нихуя, то The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 90421532 error_code 2 request_code 148 (unknown) minor_code 4) The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 86008 error_code 2 request_code 148 (unknown) minor_code 4) с такого же нихуя одновременно в совершенно рандомных приложениях. Какой ещё, нахуй, parameter? Хуле ты принимать клиентов разучился? Полтора года аптайма всё нормально было, ёпт! Пойду куплю память с ECC... а, стоп, она уже с ECC. Где мои иксы на Ada Spark? inb4 заговор разработчиков вяленого

###!!! [Parent][DispatchAsyncMessage] Error: PCompositorBridge::Msg_PAPZCTreeManagerConstructor Value error: message was deserialized, but contained an illegal value ###!!! [Parent][DispatchAsyncMessage] Error: PCompositorBridge::Msg_PAPZConstructor Value error: message was deserialized, but contained an illegal value И всё повисло к хуям. Как они этого добиваются?

https://orib.dev/gefs.html Надо же, чувак не побоялся мутных (в смысле нечитаемых) токутековских патентов вокруг Bε-деревьев! (Ну или ему никто о них ещё не рассказал.)

Я много всякого прожорливого говна видел, но в vm.max_map_count на моей памяти ещё не упирались. Сраный интернет скатился в сраное говно, эпизод 5500. [Parent 8455, Compositor] WARNING: Call to mmap failed: Cannot allocate memory: file /builds/worker/checkouts/gecko/ipc/chromium/src/base/shared_memory_posix.cc:515 [unhandlable oom] Failed to mmap, likely no more mappings available /builds/worker/checkouts/gecko/memory/build/mozjemalloc.cpp : 1504

И ЭТО ТОЛЬКО ПОЛБЕДЫ! Я рассказал вам только про то, как они сделали опции для ./configure компилятора. А еще для компилятора бывают ПАТЧИ. Знаете, как их сделали? Отдельным пакетом для каждого набора патча! ocaml-variants.4.11.1+fp ocaml-variants.4.11.1+fp+flambda ocaml-variants.4.11.1+musl+flambda ocaml-variants.4.11.1+musl+static+flambda То есть они пытаются сделать ДЕКАРТОВО ПРОИЗВЕДЕНИЕ всех возможных патчей! И каждый результат — в виде директории и файлика! И все — в одном git-репозитарии!

История про то, как академики изобрели USE-флаги. Я только что увидел самое больное дерьмо, что когда-либо выдавали кудахтерные инженеры. Есть пакетный менеджер opam для языка программирования OCaml. Входит во множество так называемых «велосипедных пакетных менеджеров». Кроме установки пакетов-библиотек он занимается еще и установкой самого компилятора нужной версии. Вообще в этом главная проблема opam — у его создателей очень хуево с реляционным мышлением, и они очень плохо понимают, что именно они делают. У них просто есть какие-то проблемы, и они хуярят в свою поделку что-то, чтобы они решились. Вот и все проектирование. Ближе к делу. Если набрать opam switch list, то тебе выдадут все доступные версии комплятора OCaml. Но каждой версии будет две: одна подписана как ocaml-base-compiler, другая как ocaml-variants. В чем разница — понять очень сложно, так как гуглить по запросам "ocaml variants" и "ocaml options" одно удовольствие (выдаст все что угодно, кроме нужного). Покопавшись в исходниках, начинаешь понимать, что вскрывать эту тему не стоило. Итак, у компилятора OCaml есть свой ./configure, где можно включить всякие опции. Есть разработчик opam’а. Он хочет, чтобы по команде opam switch create можно было устанавливать компилятор с нужным набором опций. Как он это делает? Он засовывает в репозитарий пакетов (библиотек) пакет ocaml-variants. Туда он срет СОТНИ (на текущий момент 566) версий объявления пакетов. Вот вам для примера: https://github.com/ocaml/opam-repository/blob/master/packages/ocaml-variants/ocaml-variants.4.14.1%2Boptions/opam Обратите внимание на секцию build. Теперь, чтобы пользователь мог поставить OCaml, допустим, с опциями bytecode-only и musl, он дожен сделать opam switch create 4.14.1 --packages ocaml-option-bytecode-only,ocaml-option-musl Вообще-то опция --packages нужна была для того, чтобы сразу ставить нужные пользователю пакеты. Но тут при помощи какой-то ебаной магии эти пакеты — которые тоже реально существуют, посмотрите в репе! — считаются установленными, на них триггерятся флаги в opam-файле, и делается нужное ./configure Занавес, блять. Справедливости ради хочу отметить, что эта поебень делалась не совсем академиками. Кроме академиков, есть еще и полтора бизнеса, которые пользуются окамлом. Так вот, они выдают код в три раза хуже, чем у академиков. Вот это вот мастерили люди из бизнеса. Пожалейте меня, пожалуйста. Я серьезно. Я в шоке, у меня руки трясутся, у меня потеряна вера в человечество и я хочу мой 2022 год назад.