[tytso]

KDE has solved the problem for me by providing 2-D workspace as a core feature, and not relegating it to the slums of "you want it, write your own d*mn extension".

GNOME has chosen not to do this. And so, GNOME is not for me, because I consider a 2-D workspace a "must have" feature. And so I will choose KDE over GNOME, because as a user (and I'm not interested in becoming a Desktop developer, sorry; I'm also not a web browser developer, or word processor or spreadshet developer, either. We can't be developers for everything), KDE meets my needs as a user. GNOME does not.

My main complaint with GNOME is that their answer for "you don't support feature X" is not, "yeah, sorry, we have an opinioned design, and go f*ck off", but rather, "Stop complaining, we have an extension for that". And so they don't understand that unstable extensions is not an answer to a user complaint that a feature doesn't exist. If they don't want to support a feature, that's fine. But don't try to use the lame excuse, "there's an extension for that", since they don't want to admit that they are asking users to rely on something that will randomly break.

If someone wants to use ZFS, I'll tell them that this is not supported by Linux. If you really want ZFS, use Illumos or FreeBSD. If you use Linux with ZFS, and it breaks, that's not my problem, and I'll be first to disclaim that Linux support ZFS. Because it really doesn't. There may be 3rd party developers who are trying to make that work, but I would never recommend to a user that they use Linux/ZFS, since if they need newer hardware support which is in a kernel not supported by Linux/ZFS, or their distribution has updated their default kernel to a version that doesn't support Linux/ZFS, they shouldn't come complaining to the Linux kernel community. Unfortunately GNOME is trying to have things both ways.

[zxzax]

That's great, I support you using KDE. But the fact is, if you really wanted that feature in core Gnome, someone would have to advocate for it, implement it, and then get that feature upstreamed, and then someone will have to maintain it upstream, indefinitely. An alternative to that would be for someone to write the extension, and then maintain it by tracking upstream, indefinitely; both are about the same amount of work. So it's not clear to me why you're complaining about having to write your own extensions -- this is just how open source works. You have to do the same thing in KDE if you decide you want to add some new non-default functionality that doesn't exist there too. It's not any different because it's a desktop and not a kernel, or a web browser, or a spreadsheet, or whatever. I'm happy that you could use KDE and that it works for you, but from my perspective Gnome is not doing anything weird or strange that KDE is not doing, other than having a different default design of what workspaces are supposed to be.

[tytso]

My only real complaint is advocates like you who try to claim that an extension is a valid solution to a feature request. Because it really isn't. People spend a lot of time customizing their environment to meet their needs. And they often don't have a choice not to update some package like a GNOME Shell. The problem is that there are huge numbers of dependencies, and if you hold back on updating GNOME Shell, you can't update a potentially huge number of other packages, and you risk your desktop or laptop installation becoming unstable.

So the "just a few clicks and you can install an extension" is really a very weak, naive argument. One might even say, one made in bad faith. I don't tell people to use out-of-tree kernel modules either, because that's not really a solution for exactly the same reason. Instead, I tell them, yeah that sucks, I suggest that you not buy Nvidia hardware. :-)

[zxzax]

Please don't assume bad faith. Extensions can be a solution to some problems, but they're obviously not perfect -- I'm not saying they are.

>The problem is that there are huge numbers of dependencies, and if you hold back on updating GNOME Shell, you can't update a potentially huge number of other packages, and you risk your desktop or laptop installation becoming unstable.

So just to be clear, that same problem propagates to upstream, which is exactly why the extensions break. If they wanted the extensions to not break so much, the alternatives there that upstream has would be:

- Hold up the release so that everyone gets a chance to update their extensions. This causes sweeping problems because now everything else is delayed if an extension developer is slow, and this may not even help if the extension developer has truly vanished, because then nobody will be around to update the extension. Gnome switched to time-based releases a long time ago to get away from those problems.

- Merge the extension upstream. There are a large number of extensions, and some of them conflict with each other, so this is sadly not feasible to do with every extension that everyone wants, and some people will still be unhappy because their extension was not popular enough to get merged.

- Limit the extension API to a small group of stable functions. This will reduce the total number of extensions, and people will still be unhappy because some things will not be part of this API (e.g. it's unlikely you'd get the full lower-level workspaces API that allows you to implement something like 2d workspaces).

- Don't allow extensions at all. Now if you want to change the shell's behavior, you have to do a hard fork.

So yeah, I agree extensions are sometimes not a valid solution to a feature request, but the problem is that every other solution is even worse, at least for Gnome anyway.

>I suggest that you not buy Nvidia hardware.

If you want to play this game, I could suggest that you just not use 2d workspaces. But I won't -- I think you deserve to use that feature if you want it. And if I did buy nvidia hardware, I would use nouveau :)

[tytso]

This big difference between the Kernel Modules and GNOME Extensions is that we in the kernel community do not encourage out-of-tree modules. Indeed, they are strongly discouraged. So they out-of-tree modules are never considered an answer to anything.

The kernel interfaces which are supported forever, and for which we will never break userspace, are the system call interface. We don't break that, because to do that would be to break faith with our users.

With GNOME, features are removed, and the lack of features are excused, by saying, "there's an extension for that". That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable. If the extensions API is not stable, then you shouldn't be encouraging out-of-tree users of that API. Because you're effectively promising that you will break them, all the time.

There are times when we in kernel land will say, that belongs in userspace; it's insane to put that functionality in the kernel. But when we do that, we offer stable system call interfaces so that you can do it in userspace, and users can trust that it won't break.

The bottom line is if the API is not stable, then there should be no external users of that interface. Which is why you shouldn't use Nvidia drivers. They are a bad idea. Similarly, people should not use GNOME extensions, unless they like being randomly broken at a distro upgrade.

And yes, I will not use 2d workspaes with GNOME, because I refuse to trust in extensions. My solution is to simply not use GNOME. Xfce and KDE support 2-d workspaces as core features. If GNOME can't, then to hell with it.

[zxzax]

>This big difference between the Kernel Modules and GNOME Extensions is that we in the kernel community do not encourage out-of-tree modules. Indeed, they are strongly discouraged.

It's not different, it's mostly the same with extensions. They're strongly discouraged unless you're able to track upstream and follow the release. If someone can't do that, then don't depend on them to make an extension. You wouldn't make such a person a kernel maintainer of a key feature either.

>That might be a fine answer, if the extensions API were treated like the system call interface, where we do keep things stable.

That comes back to what I was saying earlier. The system call interface is very small and very limited compared to the total size of the kernel's API. It's not the same as the GS extension API, which is a huge API that allows access to various internals. The equivalent to create a "syscall API" in GNOME shell would be one of the options I said earlier -- "Limit the extension API to a small group of stable functions" which would not please you either, because that would essentially be removing APIs and would cause even more extensions to break and become impossible to implement.

Of course if you decided to stabilize everything then you would be stuck with a project where you can't refactor anything -- imagine a future for Linux where you have eBPF hooks across every function and internal structure, and you can't change any of them ever, because those kernel structures are now external API accessed by userspace. If you want GNOME to stabilize their internal API, that's really what you're asking them to do. Is that a good explanation of the problem? I'm trying to explain here why this is actually a really nasty technical minefield, and ultimately has little to do with release policy, or with any particular architectural decisions made by GNOME. There are basically zero active open source desktops that have a comprehensive and stable plugin API. KDE doesn't do it here either -- these particular areas are not even possible to change there with plugins, you're just lucky enough that the core workflow works for you.

>unless they like being randomly broken at a distro upgrade.

This is not strictly true. Just FYI, I've seen some GNOME-based distros that are starting to bring certain extensions into their release cycle, and make those part of the upgrade. But of course that falls on the distro to support the extension and do the testing before they ship, so the extension has to pass a certain quality and usefulness threshold first for that distro's users. If you get stuck using a GNOME-based distro in the future, you may want to check what their policy is there, you may be surprised (although I don't think any are shipping 2d workspaces).

>Xfce and KDE support 2-d workspaces as core features.

That's great, you should use those if those are what you like. But here is my perspective: If some XFCE or KDE developers (who know how to implement 2d workspaces) wanted to spare some time to revive the 2d workspaces extension in GNOME, and keep it working during distro upgrades, and support you doing what you like, I don't think any GNOME people would have a problem with that. Similarly, if it were possible in a reliable way, I don't think anyone in KDE or XFCE would have a problem if some GNOME developer maintained an optional XFCE or KDE extension to make those use a GNOME-style workspace overview, for those who prefer that design.

[tytso]

I was using GNOME when 2-D workspaces was a supported feature, and when it was removed, people told me, "don't worry, use an extension; the feature isn't really gone". The problem is then the next time my distribution updated to a new version of GNOME, things broke, and I had to scramble to figure out how to get a working desktop environment again.

Fool me once, shame on you. Fool me twice, shame on me.

[zxzax]

I think the suggestion there would be to find someone who is willing to maintain the extension when upstream does a new release.

[tytso]

Or just switch to a DE that is willing to be receptive to the needs of its users. Again, GNOME used to support 2-d workspaces. This feature was removed, deliberately, by the GNOME developers. That's their prerogative, but don't try to fool users by claiming that extensions are the solution. Because extensions break. Frequently. Often. And so they can't be depended upon. If it's a critical part of your workflow and usage model, and the DE doesn't support it except via an extension API, then run away. Run far, far away.

More generally, GNOME has been in the feature removal business for a long time. So even if something is in the supported feature set today, there is no guarantee that it won't be removed tomorrow. And that's one of the ways in which it's not like kernel development. Once a userspace visible feature lands, it won't get removed. Linus will yell at you and revert your changes if you break users in that way. GNOME is frequently removing features, and so as a result, they can't be trusted. Moving something to an extension is a negative value add to users. Worse, it breaks trust with your user base. Because GNOME has done this to me, it's going to be a long, long time before I trust GNOME again.

[zxzax]

Hi Ted, thanks for replying. Those statements you've made are untrue. Just like kernel drivers, extensions don't break when someone is maintaining them. To be clear, the issue here is not that the DE was not receptive, the issue is that the extension developer disappeared. All the hundreds of GNOME developers didn't get together and collectively decide to get rid of that extension, the one person who was working on it likely just lost interest. Nobody stepped up to fill the space, so now it becomes a manpower issue. That's the way it goes in open source. It would be the same issue if the feature was upstream and the maintainer disappeared.

What you're saying seems to me the equivalent to saying "If a kernel driver is a critical part of your workflow and usage model, then then run far away, the kernel driver API is unstable and the driver maintainer might get hit by a bus." Because as I have said before, the shell extension API is really not similar to kernel's userspace -- it's closer to the kernel's driver API, in that you get complete access to the shell's internals, you can muck it all up and crash things if you're not careful, the API is unstable, you have to follow upstream closely to really take advantage of it... but if you do all that then it's a very powerful tool, and you can do things that are not possible in "userspace" (i.e. outside the shell).

And the fact is, the kernel does remove old and broken and unmaintained driver APIs. That's your prerogative to do to that, as it is GNOME's (and KDE's) prerogative to remove legacy APIs and features that are not pulling their figurative weight in usefulness. I'm not trying to convince you to use or trust GNOME, I'm happy that you're using KDE and it works for you. But I wish you would not say these falsehoods without an understanding of how GNOME is actually developed, because from my perspective the technical process is extremely similar to that of the kernel, and heavily inspired by it. So please don't forget, the apple never falls far from the tree. If you have some insights on how to plug this maintainer gap that you think GNOME is suffering from, then let's talk about that.

[tytso]

This is incorrect. 2-D workspaces used to be part of the GNOME core feature set. It was removed from the core feature set, and the excuse was, "oh, if you really want that, you can develop an extension". That's not an answer, and that's not allowed in the Linux kernel development paradigm.

As far as we are concerned, out-of-tree modules do not exist. The module interface is only for in-tree users, which are fully supported. GNOME takes the position, or at least apologists like you, that out-of-tree GNOME extensions are a good thing. As far as Kernel developers are concerned, out-of-tree modules are never an answer. Device drivers should live in the kernel. Period. If Nvidia chooses to do otherwise, that's their problem. But we didn't kick Nvidia out of the kernel.

GNOME kicked 2-d workspaces out of the core DE, because they didn't want to support it. They think that they want to keep things "simple" for their users. Google "GNOME Feature Removal" and look at the history. They took perfectly working features and ejected them from GNOME. We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.