Ubuntu 20.04 LTS To Optimize GNOME For Fast/Modern PCs, Ubuntu 20.10 For Slow/Older PCs

[finalzone]

finalzone It’s just another KDE user throwing a tantrum. Let him sit it out. Eventually he will reread the blog and actually understand it.

Hopefully.

[Britoid]

The problem with every FOSS projects is that everyone feels entitled to flame a technical opinion, no matter how fucking nonfactual (or sometimes nonsensical) it is. How many times lots of knowledgeable people have shared here that GJS isn't a problem (or at least an important one). You would however have tons of people shitposting here that the problem with Gnome is that it uses JS, day in, day out. Gnome developers (or systemd developers, or whatever) could have a friggin online PhD program about the shortcomings of their software. People would still complaint in the most unfounded ways. I rather read a Windows user hating on windows just calling it crap that a Linux user hating on some component of his OS because the problem is that the reference counting of the symbols used to translate the move instructions to the GPU via shared objects written in OCaml is stupid (or some other nonsensical comment like that).

DVG seems to be doing a great work and I am happy for it. But if you ever developed even a 300 lines python script, just reading at the Gitlab's discussion you can tell the guy is difficult to work with. Even more, the tone of his blog post, although incredibly interesting (and educational), is a really big PR stunt, written from the perspective that the only improvements for Gnome were the ones Canonical (i.e. him) contributed. Gnome developers had already started taking performance as a priority since, I think, 3.30. There were several articles here at Phoronix about that.

I hope the guy can become a better fit for the community, then we'll all benefit even more. And I also hope that he (or Georges, or whoever) manage to fix the idling bugs soon.

Look clearly GNOME devs are lying when they say Javascript isn't the problem for GNOMEs performance issues and people who don't use GNOME Shell know better, duh.

[finalzone]

Meanwhile, I can reassure you that i5-8400 with GNOME is laggy even when no applications are running. Animations drop frames all the time, which is distracting and looks bad.

Which distribution was used to run Gnome Shell? Switch to another major one and see the same specification will have no problem running it. Another possibility is your test was done through virtualization using LLVMpipe as a fallback. The two laptops I mentioned earlier i.e. 2007 Sony VIAO and 2005 LG Tabet PC much older than your I5-8400 powered device have no problem on Fedora Workstation.
I am writing from the soon to be launched Fedora 31Workstation based running on HP Envy x360 Ryzen 2500u at 1.3 GHz frequency according to lscpu command. Therefore the claim that Gnome Shell needs at least 5GHz cpu is invalid.

[GrayShade]

Not sure how they do it, but Intel's Clear Linux it's on top of most benchmarks and not like Canonical, who want to separate users on LTSs and ordinary Ubuntu releases.

Intel uses more aggressive optimization options and function/library multi-versioning, as opposed to most distros that compile for CPUs from the 2000s (for 64-bit) or 1990s (on 32-bit). They also work on improvements for the kernel and other software, and while their patches might hit upstream, that's going to take more time. And I think they might be switching to newer compiler versions faster than others.

[onicsis]

Not sure how they do it, but Intel's Clear Linux it's on top of most benchmarks and not like Canonical, who want to separate users on LTSs and ordinary Ubuntu releases.

[pal666]

just imagine how much could've been done if canonical was doing this from the start

A 2007 Sony VIAO Core Duo laptop with 4 GB RAM and a 2005 LG Tablet PC run Gnome Shell smoothly as long not too many heavy 3D applications got involved due to the limit of hardware.

Meanwhile, I can reassure you that i5-8400 with GNOME is laggy even when no applications are running. Animations drop frames all the time, which is distracting and looks bad.

[finalzone]

You probably need at least a 5GHz modern CPU to have GNOME run at bearable speeds anyway. If Cannonical wants people to hate GNU/Linux, using GNOME is a great way to accomplish their questionable goals.

A 2007 Sony VIAO Core Duo laptop with 4 GB RAM and a 2005 LG Tablet PC run Gnome Shell smoothly as long not too many heavy 3D applications got involved due to the limit of hardware.

[calc]

The problem with every FOSS projects is that everyone feels entitled to flame a technical opinion, no matter how fucking nonfactual (or sometimes nonsensical) it is. How many times lots of knowledgeable people have shared here that GJS isn't a problem (or at least an important one).

See below, there was a huge issue just last year in Gnome 3 with garbage collection due to not properly doing refcounts on objects.

DVG seems to be doing a great work and I am happy for it. But if you ever developed even a 300 lines python script, just reading at the Gitlab's discussion you can tell the guy is difficult to work with. Even more, the tone of his blog post, although incredibly interesting (and educational), is a really big PR stunt, written from the perspective that the only improvements for Gnome were the ones Canonical (i.e. him) contributed. Gnome developers had already started taking performance as a priority since, I think, 3.30. There were several articles here at Phoronix about that.

Actually I believe it was 3.28 which was when Canonical switched to Gnome for 18.04 and the resulting large increase in users immediately exposed that there was a huge desktop killing memory leak related to javascript use in gnome-shell, of which Phoronix has an article.

So the performance issues have been being worked on for a while but its mostly due to the large increase in users, and complaints, due to Ubuntu's switching from Unity to Gnome 3.

[miabrahams]

I'm just glad to see Canonical working on optimizing GNOME over the next year instead of duplicating their labor working on Unity.