• 0 posts
  • 15 comments
Joined 1 year ago
Cake day: October 16th, 2025
  • I see it more positively: there are more games than ever. I can play loads of amazing indie games, and I can also play the blockbusters; nothing seems to be holding back my enjoyment. I don’t really give a shit if an individual studio collapses under the weight of its own need for ever-greater sales, since I’m still going to get new stuff to play. If a big game is more-of-the-same and runs poorly, I won’t play it. So what if it’s the sequel to a really good game? If anything that sets the bar higher for me - a new game is more interesting and exciting so I’d rather play something completely new than a sequel. If a sequel is shit, then it’s time to abandon that series.

  • Isn’t this article essentially wrong because of this line:

    Ubuntu 26.10 also stops systemd-oomd being able to kill user sessions

    systemd-oomd works completely differently from the kernel OOM killer. Unless it’s changed, it just ranks everything by how much memory they’re using and picks the biggest memory hog that isn’t manually deprioritised by some config rule, and kills that. The OOM killer has a much smarter heuristic to deprioritise processes which are being actively used.

    As far as I understand, systemd-oomd was always a shoddy implementation because of this, and when it first started being used in Fedora (I don’t know about Ubuntu) also had insanely aggressive settings so that it would nobble something when you still had 20% free memory.

    The problem it was trying to solve was that Linux’s behaviour under memory pressure is actually abysmal. I have no idea if other OSes are any better, but basically once your computer starts thrashing, you’re better off rebooting it because it’ll be up again in a minute, whereas if you wait it’ll probably be half an hour if you’re lucky. The OOM killer detects actual out-of-memory, not thrashing, and so you can spend days slowly grinding your way through operations that should have taken seconds without ever triggering it. Hence systemd-oomd is designed to kick in before you actually run out of memory… and as a consequence it somewhat frequently does so too early.