App Launching From GNOME Shell Now More Robust Under Memory Pressure & Faster

[Zan Lynx]

Interesting.

The last time I tried to use posix_spawn it didn't actually help my problem, because the library implementation wasn't using vfork(). I guess they must have fixed that.

I had to write my own process launch function using vfork. Otherwise I couldn't launch helper programs from my library when it was linked via JNI into gigantic Java services.

[perpetually high]

GNOME isn't exactly the first thing that comes to mind when someone mentions "running a VM with limited resources" though.

I know and I think that's why this thread and why they're trying to fix it. Look, admitting you have a problem is the first step. GNOME doesn't really try to hide it, it knows what it is.

It's like complaining a Rolls Royce feels like a tank, well then don't buy the f*cking RR. (cue "ARE YOU COMPARING GNOME TO A ROLLS")

I'm not looking to argue, just making an observation. I run GNOME, but not biased and can see what people mean, but I have 16GB of RAM, so I'm okay (for now).

[starshipeleven]

I know and I think that's why this thread and why they're trying to fix it. Look, admitting you have a problem is the first step. GNOME doesn't really try to hide it, it knows what it is.

One thing is having a DE that strives to be light on resources, and another is having a DE that has memory leaks or is handling RAM poorly.

I personally don't think GNOME can aim at the "low resources DE" category due to how it is made (and what its priorities are), but this is mostly a case of fixing bugs, it's not large usage of RAM because of its design.

I mean the difference between bugs in the code and problems at the design level.

[perpetually high]

One thing is having a DE that strives to be light on resources, and another is having a DE that has memory leaks or is handling RAM poorly.

I personally don't think GNOME can aim at the "low resources DE" category due to how it is made (and what its priorities are), but this is mostly a case of fixing bugs, it's not large usage of RAM because of its design.

I mean the difference between bugs in the code and problems at the design level.

Then as much as it's not what people want to hear, if your system can't meet the minimum requirements, then you shouldn't run it. Plenty of other free and excellent alternatives. I'm sure they're working hard to improve the DE (you do realize they use it themselves?). And to be fair, with the right extensions and tweaks, I absolutely love my GNOME DE so to each their own.

2008: "Can it run Crysis?"

2018: "But can it run GNOME?"

[JeansenVaars]

One thing is having a DE that strives to be light on resources, and another is having a DE that has memory leaks or is handling RAM poorly.

I personally don't think GNOME can aim at the "low resources DE" category due to how it is made (and what its priorities are), but this is mostly a case of fixing bugs, it's not large usage of RAM because of its design.

I mean the difference between bugs in the code and problems at the design level.

+1 this is what I meant when speaking about current state of memory consumption. I am all okay if it uses 2g of ram at boot if its full of features and targeting a user scope. But it's definitely wrong if memory is leaking out over time and free ram not coming back after closing programs.

[dkasak]

My son's hand-me-down laptop - from about 10 years ago, with 8GB of RAM - runs Gnome and does so smoothly and without issue. He suspends the OS when not in use, so he typically has a browser with 20+ tabs open, steam client, BOINC client, and a handful of other things running. I wonder how other people manage to get into these situations with high RAM usage, poor performance, etc. My bet is that they don't.

[Pajn]

Finally, however this should have been there from the start.

> Right now on systems with low amounts of available system memory.
I ask myself if 8gb of Ram is enough for just the Gnome-Shell ?

Maybe. I have 12GB and it works but it is obvious that it's constrained. 8GB would probably work pretty bad when you start a few programs thst will have to battle gnome-shell for the available RAM.

[nanonyme]

Interesting. So there are limits to how far Linux goes with the overallocation trip. Well, I guess it's reasonable since unlike with malloc where the call can cleanly say ENOMEM, having errors during CoW'ing forked process memory might result in really confusing results since it might be triggered by things C does not allow to fail. Good that userland was taught to use same assumptions as kernel.

[starshipeleven]

2008: "Can it run Crysis?"

2018: "But can it run GNOME?"

Nah, from what I'm seeing, GNOME's actual RAM usage is in the same ballpark of KDE, where it goes overboard is when there are obvious memory leaks ("obvious" to an observer, not necessarily obvious to find and fix) or errors in memory management like in this case.

[starshipeleven]

My son's hand-me-down laptop - from about 10 years ago, with 8GB of RAM - runs Gnome and does so smoothly and without issue. He suspends the OS when not in use, so he typically has a browser with 20+ tabs open, steam client, BOINC client, and a handful of other things running. I wonder how other people manage to get into these situations with high RAM usage, poor performance, etc. My bet is that they don't.

That's because they are bugs, it's not part of GNOME design to just throw GBs of RAM out of the window, maybe on that laptop they don't trigger for some reason or there is something else going on that mitigates them.