Google has a swath of PR people, devs are always going to be less socially inclined. Devs at google aren’t the ones making the decisions. But yeah gnome does throw its weight around, both for good and bad.

I’ve interacted directly with gnome devs and they were entirely reasonable and respectful.

But they’re so nice, friendly and engaging! (lol)

What does that even mean?

Android’s Material You is absolutely disgusting though with it’s bizarre theming choices and piss-like pastels and fucked notification shade and the dark mode circle jerk and it frankly seems to be an attempt to assassinate material design and everything that made it a defining tech aesthetic of the late 2010s

Okay? Did I say anything about that being owed? They’re also not owed a community using their community project, so acting like that just makes no sense and seems counter to a goal of building or maintaining an active community of users

I didn’t say they aren’t allowed to do that so maybe go have that argument with someone who did.

There’s a proposal to make KDE the default in Fedora, I really hope this gets accepted.

If not, Fedora isn’t that great anyway. Universal Blue-based distros like Bazzite or Aurora are much better nowadays.

I disagree with this, personally. There’s a lot more to initial usability/discoverability, than Windows-compatible visuals. If anything, when i’ve switched a couple of my family members off Windows, they asked me for something that doesn’t look like it, because they could never navigate through the desktop properly

You can use a different theme with GTK 4 (not that you would want to)

Yes

You could argue that Cinnamon is not really a “fork” per se. It is more of an alternative interpretation.

MATE is a true fork. When GNOME abandoned GNOME 2 for GNOME3 3, MATE picked up the GNOME 2 code and continued.

Cinnamon took GNOME 3 and built a different desktop experience on top of it. Specifically, they rejected the controversial GNOME Shell to present a more traditional desktop. The earliest attempts at Cinnamon tried to provide a traditional desktop in GNOME Shell itself. By the time Cinnamon 2 came out, GNOME Shell was completely gone.

Cinnamon also provides X-apps which is a suite of GNOME applications adapted to work with Cinnamon ( but also MATE and XFCE ). These really are forks.

Cinnamon was forked off a very early Gnome 3.x version. It diverged a lot since then.

You’re talking about two different kinds of stability. They are talking about development stability. You are talking about runtime stability.

One thing is to not break applications that use your library because of changes you introduce to it. Specifically changes that go against the standard you’re supposed to be following.

Another thing altogether is to not go outside the memory limits of the application so it doesn’t get yeeted by the kernel.

I’ve had growing pains for KDE on Wayland in the past but it’s been chill in recent times too, I can’t remember having any issue related to that for a long time

In that case, you implement the old API or other interfaces so older things will continue working, while having the new one alongside it, and then phase the old one out when nobody is using it anymore. It’s not that hard to emulate an older API with a newer subsystem. Just a shitload of function wrappers and things so that the things your program used to call now transparently use the new system while the program is unaware anything changed from its perspective.

That’s what happens with the Linux kernel. Linus would go apeshit if one of the devs straight up broke a ton of user programs with a change. He’s already demonstrated his commitment to not doing that in one of his mailing list rants. Because unlike GNOME, the kernel is running some pretty critical things all around the world.

GNOME seems to be treating their DE like their own little pet project that they’re tinkering with alone in the basement without caring that millions are relying on it every day. Breaking a large portion of programs on a regular basis is what I do in the evenings. Not professionals.

Linus Torvalds is author and maintainer of one of the most successful pieces of software ever written ( software that is decades old and still growing in popularity ).

What does Linus says about your philosophy that “Sometimes you do need major changes that break stuff to upgrade the base”? I think his first sentence explains where he stands but he expands on his initial point.

https://lkml.org/lkml/2012/12/23/75

Implementing old standards does not magically result in unstable software. I can create software today that implements decades old standards using whatever whiz-bang tech is in vogue.

I do lot accept that “old bases” have to succumb to any of the things you suggest either. Refactoring is a thing. You can remove dead code, you can adopt new patterns, you make code modular, you can even extend using new tech if you want.

Linux is 30 years old ( the basic design is decades older ). Should we throw it out? I vote no but allowing Rust into the kernel seems like a good idea. How old is GCC? How old is Microsoft Office? How old is Firefox? This is software you may use every day. Trust me, your life relies on software that is much, much older. How often do you think they rewrite air traffic control systems or core financial software to to make it more “stable” as you suggest?

I mostly hear your argument when devs want to try new tech and cannot justify it any other way. Most often the result is something that is far buggier and missing many features. By the time the features return, the new code is at least as bloated as the original. Around then, somebody usually suggests a total rewrite.

Old architectures are a different story. Sometimes things are not worth fixing in place. In my experience though, this is fairly rare. Even then, in-place migration to something else often makes more sense.

In my view, if you cannot modernize an old code base, it is a skills issue.