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