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

[intelfx]

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. <...> 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).

Yup. This. Almost as bad as the “I’m entitled to choice” cancer.

[sabian2008]

Getting flak from users on gitlab isn't nice, that's for sure. But the fact a sizeable amount of people take the time to create an account to complain comes to show the level of frustration your users have with your product. You have a very poor record at listening to user's feedback, or at least at communicating to users "look people, we know this is a problem, we're working on it".

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.

[aronwolf]

If most of the work that went into 3.34 was put into 3.30 in the state it was in, we'd end up with a shell with a ton of regressions. His work also touched on areas that was already being worked on.



That is a gross misinterpretation of what happened and a lie.

Only GNOME Developers (reminder, Daniel is not a GNOME dev) can attach labels to MRs, this is pretty normal and allows them to manage merge requests properly. He tried to go around this by placing labels in the title and attaching it to MRs that didn't impact performance, which put outside pressure on the GNOME maintainers to merge the request without proper scrutiny and testing, that wasn't fair.

GNOME Shell didn't have really any meaningful way of finding the cause of performance problems until fairly recent, his MRs often relied on checking CPU usage in top and trying to lower it, which he even admits in this post was a mistake.

One question. Is possible to contribute with acceptance tests? The real problem that I have see, is that they have a lack of tests. When I have enough tests, then I can merge a branch in days and not in a year. So I am thinking to contribute, but I have only seen unity tests in their code base and I would not like to be the first to add some acceptance tests.

[brent]

I don't think there's an reason to argue at this point. For the better or worse, I think it's fair to say that Daniel kickstarted an new focus on performance improvements within GNOME. There has been some friction in working together between GNOME and Canonical, but it's getting better.

Personally, I had pretty much stopped using GNOME due to lack of performance, and only started using it again after patchsets of Daniel's patches resulted in some major improvements. To this day I'm using a patched GNOME, but I might stop doing this with GNOME 3.34.

[Mario Junior]

Fine. When will you start to do it? :-P

Tomorrow

... in Rust!

Assembly and C. Are all you need.

PS: I'm not a programmer, developer or something, so I don't have no idea of what I talking about.

[sarmad]

Seems backwards. The LTS should be optimized for slow machines and 20.10 for fast machines.

Not really. It all depends on the user demographics. If most of their users are on modern machines (which is to be expected) then it makes sense to optimize for the majority first.

[royce]

Apologies, substitute "you" for "gnome".

[Britoid]

I'm sure you've had thousands of hours of academic discussions on how to improve performance in Gnome, but certainly with very little to show for it for years. Not until canonical, and specifically Daniel, got involved again did Gnome see any improvements whatsoever in that regard. Previous art isn't worth crap if it's a half baked idea or even a mere discussion months before in an IRC channel nobody's bothering to push through the finishing line. You either get results, or make way for people who do. The amount of crap and hostility the poor guy has put up from some core gnome devs for the last 2 years is painful to watch.

Getting flak from users on gitlab isn't nice, that's for sure. But it comes to show the level of frustration your users have with your product. You have a very poor record at listening to user's feedback, or at least at communicating to users "look people, we know this is a problem, we're working on it".

The move to Gitlab really helped in the last couple of years to speed up development. Before development took place with a mix of mailing lists, git repos and bugzillas that was fairly inconvenient. Gitlab moves that all into one place where code can be commented on, proposed, discussed etc.

I'm not part of GNOME and certainly don't speak on behalf of the GNOME Foundation. But I work on applications in the "GNOME"-sphere and keep track of development and I have spotted a few untruths that get shared a lot which aren't really true.

[royce]

You can't provide references because you're lying. Performance is regularly discussed on the GNOME Matrix/IRC channels, at GUADEC and the various Hackfests. He wasn't at them, so to randomly get a MR out the blue that works on something that was already actively being worked on, then to add fake [performance] labels to them without proper benchmarking and then have people creating Gitlab accounts to throw insults at the GNOME maintainers for not merging them isn't right. I give that the latter isn't Daniels fault, but the [performance] tags in the title didn't help.

GNOME devs do care about performance and do appreciate the work he does, he's great at finding problems and working on a compositor is no easy challenge. But GNOME is a community project that's ultimately deployed in commercial settings, MRs need to be scrutinized and work needs to be communicated.

I'm sure you've had thousands of hours of academic discussions on how to improve performance in Gnome, but certainly with very little to show for it for years. Not until canonical, and specifically Daniel, got involved again did Gnome see any improvements whatsoever in that regard. Previous art isn't worth crap if it's a half baked idea or even a mere discussion months before in an IRC channel nobody's bothering to push through the finishing line. You either get results, or make way for people who do. The amount of crap and hostility the poor guy has put up from some core gnome devs for the last 2 years is painful to watch.

Getting flak from users on gitlab isn't nice, that's for sure. But the fact a sizeable amount of people take the time to create an account to complain comes to show the level of frustration your users have with your product. You have a very poor record at listening to user's feedback, or at least at communicating to users "look people, we know this is a problem, we're working on it".

[bregma]

Maybe rewriting gnome from zero solves the problem.

... in Rust!