

Reporting every bit of noise in this statistic is kinda boring?


Reporting every bit of noise in this statistic is kinda boring?


sure, but how much memory? Here’s how I imagine it working (based on approximately zero knowledge):
So in my imagination it only takes two small blobs of data being swapped in - if kernel code and process information even can be swapped out; maybe it can be protected. Maybe you know something that ruins this picture though.


Do you actually know that the decision-making takes a long time? I would have assumed that it’s pretty quick as it doesn’t need to access much, and what it does need to access should mostly be staying in RAM even when thrashing. But I don’t know that for sure. I had assumed that essentially all the delay was other things happening very slowly, allocating more memory byte by byte before an actual OOM condition was met.


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.


the only reason to use or approve of unencumbered licenses is billionaires
– some tankie


Bahahahaha from the glass house of lemmy.ml! Good wheeze!


Free as in freedom :)


And on that day, coreutils (and uutils for that matter) will magically become unavailable?


Have you considered using your computer as a computer instead of configuring it?


Imagine finding satisfaction in bashing an operating system …
…
It took me about 30 seconds on linuxmemes to find this image



Mine is over 10 years old and the battery still lasts weeks. I don’t notice any degradation but… probably wouldn’t.


[sad voice] I knooowww


I said Threadiverse because as far as I know none of the threads I looked at came from anywhere except Lemmy and Piefed.


No it won’t. There’s a sensor that detects covering the LED.
This is the 3rd or 4th comment about this (across the Threadiverse) - why don’t people ask why this costs $60 - and then go and find out? It’s right fucking there in the article (before the paywall, even).


Even if you’re skeptical about the AI part, this is desperately needed. Preferential procurement though is probably not enough to make companies think twice about selling out to US big tech - I think we need governments to intervene and prevent such sales in key areas, and I don’t see anything about that in the summaries.


So (unsurprisingly) I modified the image to make my point. I don’t know whether you will find it convincing with this revealed: I flipped the image because I too understand now (I did not when these switches were first introduced) that right = on. And I also desaturated the image to mimic colourblindness (achromatopsia). (Indeed, when they were first introduced I remember them being two shades of grey…)


I believe that, but… why should that be the case? It’s a convention without a reference or motivation. I remember when they were new and I really had nothing to refer to and just having no idea whether they were on or off. The fact that I’ve got used to them now isn’t really that forgivable. In contrast, checkboxes not only have convention behind them, but mimicked filling in paper forms which many people were and are familiar with anyway. The idea that “filled” is on and “empty” is off seems inherently more intuitive even if you’ve never filled in a form if you just know that the concept of forms that you fill in exists.


GNOME settings pages don’t have “apply” buttons. When do you think a selection from a drop-down or numerical selector takes effect?
Yes, most settings now take effect immediately, and that’s great. (I think KDE still prefers a separate “apply” step though). That is (still) separate from the decision of how to style something which turns something on and off, which is what I’m complaining about. I don’t take any issue with having things apply immediately.
You raise visual impairment, which is exactly why I’m complaining. Look at the image and tell me, which of the controls is on, and which is off?



Taking effect instantly is not really indicated by the control shape; it’s indicated by whether or not the form has a button equivalent to “apply”. Settings pages with checkboxes that applied immediately have been common for years; this distinction is not nearly as clear cut as you make out. I suspect what is going on is that both toggle switches and the removal of a separate apply step has gone on gradually at the same time.
But a good thing to think about is all the other controls: drop downs, text entry boxes, date pickers - these have no second version which might apply instantly or not! So it’s a mistake to think that information is conveyed by the look of the control.
Fair point, let’s hope this is the end of it :P