Linux Desktop Environments System Usage

And I think the point was more that many of us don't care how it is fixed. If that takes a new application, so be it. If it can be done on the older one, also so be it.

This is why I went for 32" 2560x1440 when I got a larger monitor. Very similar pixel pitch to the 24" 1920x1080 units that I had before (one of which stands beside it in portrait, so 1080x1920). I didn't need more smoothness, just wanted more on screen without needing to make things smaller.

Personally I understand the criticism of GNOME 3, but I liked it a lot more than the GNOME 40 series. I've switched to KDE Plasma around this summer, I think from GNOME 42.

> And battery life ... Holy hell, Mac is so great and Windows is shitting the bed with their smart suspend.

On Linux you can get close to what Mac does. I believe what the Macbook does is it has a hybrid hibernate/suspend. Suspend, for me, only lasts 2-4 hours and then my battery dies. I think there is another suspend setting that improves this, but there is actually a hybrid suspend that will hibernate after X hours of suspend. My laptop can be closed for a week or more and still have battery.

If you use Wayland the answer is Yes. There's a "Scrolling speed" configuration in the Mouse settings.

In KDE, I have no idea, because the last KDE that I have used was 3.5, which was the best desktop environment that I have ever used, including in comparison any Windows or MacOS version (while KDE 4.0 was the worst).

Unfortunately KDE has gone full stupid in this regard. From the numerous bug reports, I think they decided that you can't please everyone so they should please nobody. Scroll speed is not deterministic to humans, who are not calculators. The intuitive thing is to scroll a consistent a amount per wheel tick. They used to do this but now it's a percentage of the content so sometimes it scrolls 14 lines and sometimes it scrolls 8.

I guess the behavior is different in Wayland because "x11 is dead" therefore only breaking changes make it into the x11 version. Some day they'll make the x11 version suck as bad as Wayland and then people will make the right choice. /s I'd be a bit less salty if I wasn't being asked to chose between two different sets of broken. I need LibreOffice to work so I'm using x11.

> (hint: the reasonable expectation, IMHO, would be to "open System Settings, go to Mouse Settings, and change a slider")

Yes. This is more or less what KDE does everywhere the upstream software stack supports it, and probably also what it already did the last time you tried it. This comes down to your distro's display server configuration.

On Xorg, mouse scroll speed is up to your X11 input driver, not your desktop environment. If the X11 input driver you're using for your mouse supports setting the scroll speed, that setting shows up in System Settings in your Plasma session. Libinput doesn't support this feature, so if you're on Xorg and you want it, don't use libinput as your mouse driver.

Under Wayland (which also uses libinput), the compositor mediates all input and so the KDE folks have worked around the issue and implemented the feature themselves.

See the upstream issue in libinput here: https://gitlab.freedesktop.org/libinput/libinput/-/issues/74...

I have tried it, in fact I just rolled out Fedora 37 w/ KDE Plasma on Wayland to my new i7 box ... but I have only used it for a few hours as it is more of a toy project than a daily dev machine.

You can’t easily do that because every Linux program expects different things. The hack to make it work is to switch keyboard configs when you switch the application, I think. It’s far from ideal.

You bet, but do you have any experience of any kind to back this up or is it just a vague hunch?

In my anecdotal experience, the snappiness of a DE is given almost exclusively by the compositor and amount of CPU cycles and disk I/O ops used by the DE, and less about the RAM used. Of major importance is the input lag of the compositor, with Wayland feeling far more snappier than X11 in most cases.

So I wish more of these tests would investigate CPU usage and disk I/O, rather than these RAM tests where users come to the premature "oh look, DE_1 at idle uses 200MB less RAM than DE_2, so it must be faster" conclusion, which couldn't be more false in the real world usage scenarios of how human users perceive snappiness. There's much more to this than just idle RAM usage.

So to contradict you, no, idle RAM usage does not in any way always directly correlate to perceived DE snappiness.

Gnome does a lot more, and is a lot easier to extend given the JS support, but that has an impact on resource usage.

The perceived slowness is due to window effects in KDE. Disable these and window appear before you lift your finger from your mouse or enter key.

Lastly, KDE's memory usage comes from the facilities it provides. Disable them if you don't need them, and save a lot of memory. KWin (window manager + compositor) uses ~180MB on a 4K screen, while file manager needs another 57. That's not much.

So consider you are right and memory usage after boot correlates to being less snappy. That might be just a coincidence, with N being so small, and not a cause. Or maybe there is an interesting, unmentioned cause for both.

Or maybe the higher memory usage is due to features that most users actually want, for example better file indexing for search or whatever. It is not surprising to me that offering less features result in faster systems. In this case the comparison doesn't really make sense.

But it would also not surprise me if a system that uses a lot of memory is faster, if it uses that memory for caching for example.

So we don't know what 'free memory after boot' is a signal of and we don't really know if that is even important. Maybe it is to some who have 4gb or less memory. I have 64gb in my laptop, why should I care? (honest question, I can think of reasons).

If you are going to measure a signal, it is only going to be useful if you have a sound story about what the signal represents and why we should care about it. Otherwise its just a blind ranking game, kind of an e-sports competition, which will perversely incentivize useless investments (of time) and choices.

one way to probably look at this is as follows: optimising on memory usage f.e. by packing/encoding more information in a limited space, results in reduction of running time of programs. this is because, you reduce the amount of 'stuff' that needs to be moved around in memory (and programs are always doing that).

And my primary desktop is i3, if that tells you anything. OTOH, even when running KDE I tend to use small tools such as leafpad, konsole, vim, etc.

https://www.enlightenment.org/download

https://www.bodhilinux.com/moksha-desktop/

    > If a desktop environment is using a lot
    > of memory, this means the same memory is
    > not available to my other apps.

Your mental model of a how an OS allocates and manages memory is stuck in the 60s. Nowadays getting a handle on "real" memory use is increasingly illusive.

Probably the best metric is to ignore it altogether, and instead look at memory churn. I.e. how much the OS ends up having to evict some pages from memory to make space for others.

Even that is only meaningful if it's happening on an ongoing basis. I.e. if your DE allocates 1GB that it uses once (or never) having to evict those pages once generally isn't a problem.

It's only a problem once there isn't enough memory to go around for those pages that are in active use.

How does that work if you run 2 virtual machines, each running Linux?

Well, i'm obviously in the minority (despite this kind of system programming being my day job for the past 30 years), but JIT'ed Garbage collected languages should never be part of the core system toolkit for actual technical reasons.

gjs (and the kde equivilant) should have been kept as end user system scripting languages, rather than having shipped parts of the DE written in them. Its a large reason why lxqt is significantly lighter than KDE.

It all comes down to the fact that no one has really solved the triumvirate of low latency, reasonable performance, and high collection rates, with a GC that aggressively returns unused ram back to the OS. Its a hard problem when the end application isn't known. For something like a generic control panel the (excluding event/loggging) the upper memory footprint can be bounded by the programmer, and the GC will be more aggressive as it approaches that limit, and the final result is a reasonable compromise. That said the hardcoded limit is likely 2X+ what would have been required by a non GC'ed environment.

But for a general anything goes environment, the GC's are tuned towards performance and largely unbounded GC regions. Which means in order to maintain reasonable performance they will just keep reserving address space from the OS, touching parts of it temporary and then avoiding compacting it because those operations are very expensive. Plus with mozjs/spidermonkey (another whole set of problems for gjs due to the lack of a stable API) if the GC+JIT are aggressive about memory minimization then there can be frequent noticeable application lags as the memory is freed then reacquired from the OS/etc.

Then because your desktop isn't under memory pressure, its not going to page out the fragmented bits of address space by default. Until it is under pressure, then the whole system goes laggy because while the LRU like algorithms the kernel is using to take the memory back work well, the GC is completely unaware of which bits of the address space it thinks it owns are suddenly going to respond much more slowly than it expects, and since its shotgunned (or worse is actually heap compressing everything) stuff all over the address space your taking a lot more pagein requests than one might expect. So the problem gets compounded.

The end result (like with java on the server) is that what benchmarks well in a trivial sandbox by itself on a machine, starts to have longer term negative consequences when its sharing a machine with another application (or dozen) also written under the assumption that address space is free and the OS will just take care of the problem.

So, javascript DE bindings are a good idea, but should have been reserved for windows macro recorder, or vba types of use cases rather than having parts of the default installed runtime env rewritten to use it.

However I might have skipped some problems because I've been on GNOME Flashback for a while, from 2014 to 2020, while I waited for enough extensions to appear to recreated the saner (for me) environment before GNOME 3.

Most of us are slumming it with non-ECC memory I'd wager. In a very real sense, more memory usage corresponds to a larger target for a bit to get flipped by an stray cosmic particle collision.

I think the real reason why XFCE feels so stable and reliable, is that it is old. Old software that doesn't undergo frequent revolutions has a longer time to catch bugs, and doesn't introduce them at the same pace.

Also, it's running on a VM, and I assume under software rendering. It might not make a dent for others, but if you add fancy effects like KDE does, then I don't think this is a fair comparison.

The only times it has lacked memory were when GHC autoconfigured into using 2 threads for each CPU core and when I install some memory hungry add-ons on Kerbal Space Program. I never noticed the memory limit on normal usage.

So, you end up having to do it yourself. Run a tab discard plugin, and then keep an about:memory window open and click the minimize memory utilization button on a regular basis (probably a plugin/etc to do that, but I just trigger it manually every once in a while). And that is on machines that have 32-64G of ram.

I know a lot of people who open many many tabs and I believe it can certainly take up to 40-50% of their ram or more, especiallly on 2/4GB machines that are still ubiquitous for people who do not buy a new machine every 3 years.

This is the first I am hearing about this. Source?

I haven't used it for a while, but I found that for certain audio controls, or to allow certain window layouts, I've needed to install extensions. I also found the information it provides about wifi to be less than adequate, and I'd imagine that you'd need to install extensions to fix that. KDE provides a running graph of traffic to/from a Wifi endpoint, and other information that you might not have considered.

I also added Openweather and Wobbly Windows, just because :).

Then for comfort I have Pop shell and hot edge.

Edit: they used fedora, I see it now.

800x600px @32b was my favorite resolution & depth for a long time. 800x600x32/8 (800 pixels x 600 pixels x 32bits per pixel / 8 bits per byte) = ~1920000 bytes. Call it just under 2MiB. But 4K? 3840 x 2160 x 32b / 8 = 33177600 ... or just around 32MiB... around 16x the size. No, it does not require 1000 times the memory. It requires only about 16x the memory.

Where memory is being lost is in massive amounts of inefficient languages copying and duplicating huge swaths of images (and tons of other datas too) that will never or rarely be used. Want a transparency on the window? Well now you have your image, the background image, and the real blended image. Want to show bunches of pretty little custom images? Each of those comes in, and some of them aren't even visible! But they still need to be loaded up.

And that doesn't even talk about the slowness of the application. Tons of IPC communication going on to enforce sandboxing, instead of just directly doing whatever it is that needs to be done. In-process multi-threading models with inefficient languages exacerbate it. Inefficient design with huge layers of abstractions to support a fifty bajillion different ideas for how a user might want those pictures shown (oh, you want big icons but another user wants little pictures; you want light colors, another wants dark colors, and a third wants custom colors...; different fonts, different etc...).

And that's just looking at images. What about datas? Gotta hold all of those APIs and telemetry somewhere. Gotta cache them so you don't have to request it again. Gotta hold it in memory because disks are slow. Gotta keep all of the metadata too. Might as well put it into a sqlite3 database and make it easier to manage! Or maybe the developer can just store it all in a linked list and look it up as needed... And what happens when you run out of memory? Goodness that's annoying and difficult, especially in a terrible language, so just don't worry about it. Just allocate something new and let the garbage collector... collect your garbage that you've strewn all across the user's machine. Who cares if it's "slow" as long as your application doesn't crash? Need to render a new image? Best to render it from a template image, so now you're holding even more images and also allocating new ones every time you need to render stuff. Except that it's all done in CSS by the kids these days, so the template image isn't even an image... it's text... to be rendered by the CPU. Yes, cool. No, not fast.

All of that ends up being on top of terrible "cross-platform" frameworks to make it cheaper (to the developer) to build the damned software.

Why are computers so slow and bloated these days, anyway? It's certainly not because computers are slow and bloated.

Sure today you can do 4k, but a not insignificant number of people are still running 1080p displays, which are actually fewer pixels than I had 20+ years ago.

What you get with a modern machine is aero peak functionality, and transparency, but the ram usage doesn't magically go down if you turn it off on something like win7 where the option existed. Also, its funny that we could realtime repaint windows on a 486 with barely noticeable (if at all) lag, but we can't do it for a few dozen applications on a 5Ghz machine with dozen cores if there happens to be a requirement to repaint part of a window under a transparent one? Even so, if a full scale image (not that its even required for a peek type function) of a occluded window is needed, whats the storage requirements? A few dozen MB per application? But, that's not really how these applications work, when you peek/zoom/etc a window its getting redrawn in realtime. Otherwise you would see stale versions of windows that aren't visible, and if you notice that isn't what happens. Depending on settings (at least in KDE) there is a couple accuracy options that can be tuned which affect the repaint lag during zoom/peek/etc functions.

That's HD! Slightly better in fact: https://en.wikipedia.org/wiki/720p

And, for what it's worth, as I recall 1600x1200 CRT monitors were high end but not unusual at all in the mid-2000s, and Win2000 and XP drove plenty of them in their time.

It ran like crap in 64M, 256M was about right IIRC, although I had some servers with multiple GB (you really wanted to keep it under 512M for a desktop though because that kept PAE off and the kernel would then keep everything mapped, which sped it up a lot IIRC).

In the USA you were seeing people with 1024x768? I suspect a lot of your friends weren't installing graphics card drivers. I can't tell you how many PC's I saw stuck at 1024x768x16 (or maybe it was x256) whatever the max VESA res that windows ME/etc supported. I would go to peoples houses, install their video card drivers and set their monitors at 1280x1024, or frequently higher for people with bigger monitors and then tell them to upgrade to win2k. And then they would be shocked at how much smoother their PC would run. I also would adjust the menushow delay and a couple other things. I got a reputation for making peoples computers way faster, but also sometimes setting the resolution to high... laugh

It was 128MB (and XP doubled that. Which was on of the reasons I abandoned Windows XP for Linux)

I tried 2000 on a 486 with 64MB. It installed and ran fine without crashing, except for the unholy slowness. I suspect the CPU and ancient HD were bigger culprits than the 64MB though.

Very very very few people had HD displays back then. I had a 19” display that could do 1024×768 and I was the envy of a few of my friends. Higher resolutions came a little later.

1024x768 was doable on 15" and some higher refresh 14" monitors in the mid 90s, but kinda hard on the eyes.

by 1997 though I had a coworker running 1600x1200 on a 19" or 21" with NT4 - that took some squinting. I suspect he liked people not being able to see what he was up to unless they got real close.

1280x1024 was pretty good on a 17" or 19" back then - 1024x768 felt a bit lores on a 19".

So of course I would expect fluxbox to use less memory than KDE, because fluxbox doesn't do anything if I press the volume keys (please correct me if I'm wrong, I haven't used it in a decade)

Does that mean that fluxbox and all of its associated tools are going to be as snappy during real usage? You can't certainly know by just analysing the RSS and shared memory size of the fluxbox process.

We're lucky we are unable (AFAICT) to have real stats on L2 and L3 cache recency utilisation.

I have a 4k laptop and the usual dell dock with 2 regular monitors.

I like using arandr cause I got used to it when things weren't working so well, but the built in monitor switcher works good now as far as I can see.

True, but Delphi with its VCL showed it didn't have to be.

IceWM is far more advanced/usable than Windows 98 wrt window management (and better than modern Windows, since things like the TaskBar have regressed heavily).

http://www.linuxfocus.org/English/July1998/article52.html

Compared to windows 3.1, the default theme flew, and visually, it was way ahead of Win 98. I remember getting pseudo transparency working, but I think that was in the pentium 100Mhz days. Other than that, it checked all the other boxes on your list.

I haven't bothered with Win 95/98 emulation, since I mostly use that setup for games, and Steam already has modern-ish windows games covered.

Since then, I've never had a PC/OS combo as fast as that. Need to work on that now...

FWIW, after baloo_file_extractor finished indexing new files on my Steam Deck, it exited, and KDE RAM usage was down to ~600MB.

Better for DNS/db/key servers, if you aren't allowed to use *BSD because "reasons".

Sometimes a hardened system is not ideal when you are trying to debug something complicated already. Something like alpine-linux is also intended for specific uses-cases.

There are a dozen reasons things may be glitched, but usually it is the lack of active cooling causing the pi4 to thermal throttle. Also, mate-tweak tool can save time digging for settings.

Also, if it is the Ubuntu distro rather than Raspbian, than there is a lot of missing software to get things working well.

Best of luck =)

I think you mixed up bits and Bytes there. 1920px * 1080px * 4 Bytes/px = 8294400 Bytes = 8100 MiB. For 4k it's the quadruple.

Systray is a wart, abused by too many applications. They should take the android approach, background tasks that cannot have UI and have to communicate with a frontend, which for a change cannot be left hanging in background.

In other words, if you want something in background, make it systemd user service, so the user can use standardized tools to enable/disable/start/stop it. None of that nonsense, where apps keep running after closing all of their windows and resisting to quit (like Skype does).

At first I used RES column from FreeBSD top(1) command.

Here are results for the same desktop environments from other tools:

                | htop(1) | conky(1) | freecolor(1)
    ------------+---------+----------+-------------
        FreeBSD |  112 MB |    - -   |  157 MB 
        Openbox |  237 MB |  460 MB  |  382 MB 
           MATE |  508 MB |  778 MB  |  788 MB 
           XFCE |  533 MB |  794 MB  |  829 MB 
    helloSystem |  585 MB |    - -   |  830 MB 
          GNOME |  625 MB |  990 MB  | 1000 MB 
     KDE/Plasma |  730 MB | 1659 MB  | 1167 MB

So as You see depending on the used tool you may get REALLY different results while having the same components started.

Regards.

XFCE is not suppose to start/load KDE components and vice versa ...

- Fedora plasma ca. 1.4 GB (matching your numbers) - MX Linux plasma ca. 600 MB - EndeavourOS plasma ca. 800 MB

Considering the significant difference you either have to go into more details or make that disclaimer prominent.

Since you helpfully posted the source images I checked to see what you did :)

I saw that you used the output of "free", which I think is not what most people think of as RAM usage (IIUC it reports the total virtual memory in use). I usually look at the output of `smem -atk` and look at total PSS. See https://lwn.net/Articles/230975/ for a clearer explanation on that.

Source 1: https://en.wikipedia.org/wiki/LXDE

Source 2: https://en.wikipedia.org/wiki/LXQt

This actually surprises me, I have three screens, and a fair few applications open..

Which - is entirely reasonable, in my opinion.

> That's a nonsensical sentiment. What's the point in using RAM "you paid for" for something useless/wasteful - you're not getting your money's worth whether the RAM is idle or wasted.

It's not being "wasted" it's resulting in faster IO for anything that happens to be in it. Given the choice of having your RAM full or empty... you should pick full every time. You just need to make sure that "full" can be adjusted to make space for whatever application you might want to open next.

So... swinging back around to Gnome - as far as I can tell, they're trying to do exactly that (full disclosure, I can't speak for how well this is adopted).

The blog post outlining the goal is here: https://www.hadess.net/2019/12/gmemorymonitor-low-memory-mon...

The implementation and docs are here: https://docs.gtk.org/gio/signal.MemoryMonitor.low-memory-war...

It seems to me like sanctions miss the point of what propaganda on the affected side can turn it into.

The very top of your page is a big ad - if that was an inoffensive "support the author and this work", it might get you more than that top ad does

Your site seems to provide a interesting set of views and importantly a evidence / research based set of views. I can imagine there being 50 questions (which DE uses most memory in VM, which config settings can minimise windows footprint) - essentially best practise settings for mid sized installations.

Monetising that might be tricky, but building an audience of people who have that problem set is building an audience of people with problems and money.

Personally I am just revamping my personal docker workstation and just use XFCE because ... I might have a rethink thanks to you.