Comment by tytso | Hacker News Reader

Comment by tytso | Hacker News Reader

Parent Full thread

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.

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.

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.

Please stop making these insulting comments calling me apologist, this is rude and unhelpful; you're a better person than this. I've respected your kernel expertise for a long time and it's disappointing to be treated this way. This is the kind of behavior that pushes people away from open source. I'm only here to help explain how this works and to help get the issue fixed, I would do the same if you were making such statements about KDE.

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

GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.

>Device drivers should live in the kernel. Period.

It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.

First of all, apologist is not a dirty word. Per the Meriam-Webster dictionary the definition is "one who speaks or writes in defense of someone or something".

Secondly, extensions are not the answer, because extensions are inherently unstable. If you think the answer to supporting features is via extensions, then of _course_ GNOME doesn't have enough developers. Some featuers need to be in the core DE --- as 2-D workspaces was once a core feature. Ejecting features from the core feature set, and trying to implement them as extensions, is a receipe for P-A-I-N. It certainly isn't how KDE and XFCE handles 2-D workspaces; there it is implemented in C++ or C, and not in some Javascript extension language using unstable primitives that randomly change from GNOME version to GNOME version.

My Goal is to use a Linux Desktop Environment which meets my needs. And part of my needs is certain well-defined feature set which includes 2-D workspaces, and that they **NOT** be implented as an extension. Because extensions break. All. The. Damn. Time. I've been around since the very early days of GNOME, and GNOME had 2-D workspace support for years and years, and it was not a big deal. It was ejecting features from the core, and implementing them in unstable Javascript which is what caused the problems.

If GNOME simply said, F-U to certain classes of users, we don't think certain features deserve to exist, I'd probably respect them a bit more. I still wouldn't use GNOME, but at least they'd be honest. My complaint is trying to assert that extensions are an answer, and they're not, because it's really unfair to trick users into relying on something which is ultimately built on quicksand. Better to have a small feature set which you can support well, rather than a randomly fluctuating feature set which arbitrarily breaks across distro upgrades.

Reply on news.ycombinator.com