86 comments

[ 2.8 ms ] story [ 54.8 ms ] thread
Reminder that gnome has a donations page: https://www.gnome.org/donate/

I'll be donating today because gnome has been my favorite DE for the last few years and the changes they made to gnome 40 are awesome.

same, setting up a recurring donation.

I have a lot of qualms about a lot of stuff, but I feel like there is a lot of great payoff for GNOME to continue being able to maintain/improve stuff, especially as its my daily driver.

(I know this is anathema to a lot of people but I would gladly support something like Canonical having an OSS fund that it pushed patreon-style on its desktop OS, though to be honest I don't know what the admin costs for something like that would be)

I will not be donating for the foreseeable future, because Gnome has repeatedly shown contempt towards their software's userbase by ignoring their feedback and releasing software that has poor quality and usability.
The gnome devs have built something almost exactly how I want. If the gnome devs listened to most of the feedback I see on HN, I would no longer like the DE.

Consider that different users have different preferences. I have tried almost all of the DE/WMs and have found gnome to be the most stable/best looking/best defaults.

I have the same feeling that you do. But for some reason some stuff has been broken on GNOME that did not require breaking. My three biggest pain points (both personally and for the non-tech people i provide tech support with) is alt-tab not switching between all open window in recent order usage, the disappearance of the venerable systray, and .desktop files not proposing to be executed (at least on Debian).

These three points are contrary to every other desktop environment there is, and it's confusing the hell out of people. I really wish GNOME the best and i really like some aspects of it (it's pretty and it's well-integrated) but over the years they've dumped core features like this, and made the overall experience super slow. If you've tried to run GNOME on second-hand hardware with HDD (not SSD) you know what i'm talking about.

A good reasoning. But rather negative in tone of voice.

Gnome is not for you; good! Because there's lot's of choice: POPos, Mint, KDE, LXDE, iwm, and so forth and so on. This is what OSS en Linux is all about: choices! freedom!

Why not use one of the alternatives that fits your requirements better and praise that alternative?

Clarification: At least until the next release, PopOS is still very much GNOME.
Certainly. As is Mint, IIRC.

But those may solve grandparents' issue with "ignoring their feedback" or "poor quality and usability.".

No, cinnamon is a fork of gnome but it's a heavy fork that has been diverged for a decade now. It's not really gnome anymore.
I think you are saying that only positive feedback is acceptable? If this is the case, I disagree. As for "just go make your own/ use your own", well, many people do. Personally I do use a different WM when I can, but still have to use GNOME from time to time.
What projects do you donate to?
Can you expand on what you like about Gnome 40? I recently upgraded to Fedora 34 and hence have Gnome 40 installed, but I haven't really explored much.
It might sound a little silly but in the expanded mode where all windows are shown, the desktop wallpapers have a huge border radius on them and it makes me happy every time I see it. I have also had non GNOME using coworkers comment on this detail as well as how the windows sit slightly outside of the wallpaper in this mode. I also remember seeing a number of minor UI tweaks around the place but I have forgotten which ones as they just look normal now.
Maybe they finally support server side decorations
Or a way to turn off vsynch/change the compositor. I've found nvidia drivers have their own vsynch, and gnome adds some on top of it, netting a microstuttery experience. May be wrong, but I find xfce without compositing to perform better.
Gnome has non-smooth animations on Intel GPU as well. It does not bother me too much, but it would be nice to have 60 FPS for simple animations like opening/closing activities.
They continue to improve on it and it is actually smooth when I have like 2 windows open, but it stutters with more. Not sure why is that, plasma always felt buttery smooth compared to that. It is fancy to blame everything on js, but perhaps the animation is indeed initialized inside js?
I've noticed GNOME is way snappier on a SSD than a HDD. But of course i'll join you in blaming JS for all the slowness and memory leaks of GNOME ;)
(comment deleted)
OT: what a jump in time this is https://ramcq.net/2005/03/ Interesting really to read and see how some things have changed and others not.
Is this the correct link? It does not seem to do anything with gnome.
They claimed it was off-topic. It's a link to the same blog in 2005, they were just interested by the glimpse into the past.
Hm, no mention of free software? Just open source?

I know it's the same software, but the way it's referred to gives me pause.

> The goal is to find projects and funding that allow us to both invest in the GNOME community and find new ways for FOSS to benefit people who aren’t already in our community.

The statement of their specific goal for the future refers to FOSS.

Given that the mission statement of Gnome is explicitly "to create a computing platform for use by the general public that is completely free software." I'm not sure why it would.
Yeah, the whole article reads very...coroprate-y.

I'm not sure if I'm happy with it, but I haven't used Gnome in multiple years, so my opinion doesn't really matter here. I do however, wish that Gnome foundation remains healthy. Having competition is always good, even in FLOSS.

Open source as defined by the OSI is literally identical to free software as defined by the FSF.

And no, open source does not include things like unreal engine which you can view the source but not use freely. This is called Source Available software.

I would like to see a focus on making linux desktops secure. Just because we are usually running non-evil code, it doesn’t mean that it doesn’t process evil data that can easily exploit the numerous bugs (especially with the everything in C mentality) found in open-source software. And frankly, flatpak is not a good direction (especially written in C), it is no solution to the dependency hell problem, nor to proper sandboxing.

A new userspace should be built similar to Android with proper capability-based sandboxes.

Slightly joking: https://github.com/ansuz/RIIR

(EDIT: I'd not propose to actually rewrite existing infra in Rust, but at least flatpack 3.0 or whatever the next version would be, would benefit from this)

The android design from a usability perspective is garbage that has been made over with enough money and effort to be semi acceptable in the same fashion as a garbage truck would be able to fly if you attached enough rockets to it.

If the Linux desktop started with a design just as good I don't think I would live long enough to see it rendered acceptable.

Still better than not having any sort of security…

But I agree that ios has it better.

Yeah I'll happily take "not any sort of security" Debian over the android situation any day of the week.
(comment deleted)
> A new userspace should be built similar to Android

Why do poeple always forget that Plan9 exists? The Android way is the wrong way to do it.

Why do you think it has a feasible solution to security? Just because everything is a file, files themselves have inadequate permission-levels. Eg, how is the case of a USB device handled? A user can’t mount it based on file permissions, but can with a more flexible security model that looks at what is it that we are trying to mount.

But my knowledge of Plan9 is not extensive so correct me if I’m wrong.

I think that from the security perspective, the more important change in Plan 9 was dropping the notion of a privileged "root" account. This forces you to redesign your system from the ground up. No more "root" to mount devices in the filesystem means that unprivileged users need to be able to mount things. But allowing users to mount things in the global namespace can mess things up, so instead we need to implement private per-process namespaces that users can mount and bind stuff in. Bam - containerized applications are the norm, there's no Docker, there's no Flatpak, there exists something like Kubernetes that can handle orchestration but doesn't concern itself with containerization and sandboxing.

When you plug in an USB device it shows up in the list of devices. Then you can mount it as your unprivileged user in the private namespace of your own shell, no issues there with permissions. If that USB device has a filesystem that supports user/group permissions, then you have access only to the files that you own.

I don't think it's that easy. I'm really am not familiar with Plan 9, but I assume /dev 's analog folder is a privileged directory, where the new USB device will appear dynamically. On what basis will my user have permission to do anything with it? You need some logic there for eg. a block device available through these USB ports can have a less privileged owner. But just because it is a file/namespace, it is not a solved problem at all.
According to the Plan 9 Desktop Guide[1], when you plug your USB stick and the OS supports the filesystem, it will be mounted in the /shr directory. From there you can bind-mount stuff you need to wherever. Alternatively, you can mount the disk using the fileserver (dossrv for DOS, etc.) wherever you need.

Your user will have access to devices when it's included in the required system groups, 'sys' IIRC. It might get added to that group when it is created by the "hostowner" user, usually "glenda".

If you don't know Plan 9, you should check out the linked user guide, it's an excellent introduction to the concepts.

[1]: https://pspodcasting.net/dan/blog/2019/plan9_desktop.html

In general, how do control mounting - the fact that I plugged a USB device into a shared computer doesn't mean anyone should be able to mount it. Root allows me to trust one person, rootless seems to require me to trust everyone?

Also, the major threats to my security from my laptop are not other users. I'm not scared of the other users of my laptop. Who even are they? they're people who've already taken advantage of security holes in applications to break in. The people who I am concerned with are the authors of the applications that run. It's more like reading the file I want to publish vs data exfiltration: I want the application to engage in this class of actions - but only the members of this class that I authorise, not everything.

I want Firefox to be able to read and write within my home directory, but under no circumstances should a bug in Firefox allow a website to read a file I haven't given it.

But I also don't want my private file to be somehow in the private namespace of a certain program. Private files are not the property of a foreign program, they're my property. I want to know where they are so I can back them up, replace them atomically for all programs that use it etc. The Android approach of making my private information the property of some semi-trusted application author is crazy.

To me, it seems like a secure system would not give a program access to global namespaces like the filesystem nor to be able to enumerate local resources. The program could have its own state and configuration stores, but when it wants to access a file, it asks for permission to read a file, the system asks me how to fulfil that (i.e. pops up a file selection interface), I make a choice, the system passes a file descriptor, the program knows that it uses 7 to read and write. But the system doesn't know that it's getting /home/me/downloads/ketchup-and-mayo.jpg. Likewise, the system asks for my location, and I get a few buttons "give current location, give stored location, spoof".

Does plan9 address this? Android I know is too course-grained. It has enough of this to be annoying but in reality you can either give the program full power over this or that feature or you can give it no power and it probably just won't meaningfully run. I'd love to run every program in a sandbox, but I want to be able to own my files.

> In general, how do control mounting - the fact that I plugged a USB device into a shared computer doesn't mean anyone should be able to mount it. Root allows me to trust one person, rootless seems to require me to trust everyone?

The Linux "root" account, or UID 0, is the same everywhere, and this becomes a problem when you start working in a clustered environments with multiple computers sharing resources. Look at NFS and its multiple versions and that huge fight to protect access via 'root' account.

In Plan 9 there's a concept of a "hostowner" account, by convention named "glenda". It's the account that the system is started with, and it only concerns itself with resources on that host, there's no sharing with other systems. The 'glenda' account owns resources of the host and can give access to them to other accounts, either via filesystem permissions or via the "factotum" authentication service. Combine this with the fact that on Plan 9 you can change process privileges and capabilities dynamically, unlike in Linux where this can happen only when process is created, and this creates a really nice and secure environment to work in.

> Also, the major threats to my security from my laptop are not other users. I'm not scared of the other users of my laptop. Who even are they? they're people who've already taken advantage of security holes in applications to break in. The people who I am concerned with are the authors of the applications that run. It's more like reading the file I want to publish vs data exfiltration: I want the application to engage in this class of actions - but only the members of this class that I authorise, not everything.

> I want Firefox to be able to read and write within my home directory, but under no circumstances should a bug in Firefox allow a website to read a file I haven't given it.

Before you start Firefox, you can clean up its private namespace and unmount the sutff you don't want to give it access to. Or create a new private namespace and only mount specific directories from your home directory in it, like /home/user/Downloads. This is basically whitelisting access to the filesystem instead of having to blacklist everything but specific directories which will never be foolproof.

> But I also don't want my private file to be somehow in the private namespace of a certain program. Private files are not the property of a foreign program, they're my property. I want to know where they are so I can back them up, replace them atomically for all programs that use it etc. The Android approach of making my private information the property of some semi-trusted application author is crazy.

Then create the process namespace from scratch, mount only the files that program is supposed to access and then start that program in there. It will not be able to mount anything else because your home directory or other shared resources will not be reachable by the process.

> To me, it seems like a secure system would not give a program access to global namespaces like the filesystem nor to be able to enumerate local resources. The program could have its own state and configuration stores, but when it wants to access a file, it asks for permission to read a file, the system asks me how to fulfil that (i.e. pops up a file selection interface), I make a choice, the system passes a file descriptor, the program knows that it uses 7 to read and write. But the system doesn't know that it's getting /home/me/downloads/ketchup-and-mayo.jpg. Likewise, the system asks for my location, and I get a few buttons "give current location, give stored location, spoof".

You can just unmount /dev to disallow access to devices. You can unmount /net to disallow access to the network.

> Does plan9 address this? Android I know is too course-grained. It has enough of this to be annoying but in reality you can eith...

Whilst I agree that more security would be great, and a capability based sandbox for applications would be cool, this is not something that Gnome can do on it's own. There should be a inter-project initiative to get this to work, as ideally this should be done at the kernel and userspace level and be DE agnostic. Flatpak kind of could do that, but I'm skeptical for now.

On the other hand, maybe Gnome should copy qubes or everyone should just make qubes ready for everyday use.

Of course it should not be desktop-dependent, but it should be very well integrated into the DE, because it is the trusted party that can manage most of these permissions.

As for Qubes, it is cool, but I don’t think that such a massive performance degradation/requirement is feasible. Also, I’m not sure how great it is from an everyday usability point of view. If the user will rather run everything in a single vm, because it doesn’t work otherwise, we are back to where we are now.

The performance isn't inherent in the design. It's perfectly feasible to have hardware accelerated graphics without passing through a whole GPU, since we have virtualization ready mesa vulkan drivers. And since you control the guest, you can dynamically scale memory use (if only one way), and everything else has negligible performance impact. As such, I think the only thing that's preventing running every application in a VM for me is the user experience, and this is by far the hardest thing to get right, but this will eventually be the gold standard.
I agree with you, though if we raise the bar for our threat model, running a not-too secure vm image is still not the best option.
That's an issue with the hypervisor and not the image then, but I do agree that the GPU virtualization is a large and complex attack surface. Regardless, I see these as problems that can be solved with effort.
I don't want this, I wouldn't use this. I guess I'm just not optimistic enough to see this work:

Flatpak, snap, etc don't work as they just try to make the current desktop philosophy secure, without the application and the rest of the OS really being aware of it. Android and ios have been designed to offer native features for fine grained access control and isolation. For a desktop os, you need the same, from the ground up, and every app needs to be tailored to this. You'll start with a desert and tumbleweed.

This will never work, because it's simply too late: The web. A Chromebook pretty much does all the isolation you want on a different level, and is enough for the vast majority of people. I know you can now list a thousand things you cannot do in a browser and whatnot, but consider that the folks here on HN are a very rare breed.

And again, as you even said, for such a hypothetical sndboxing desktop os, user space needs to be rebuilt in large parts from scratch. Not in a hundred years. There so many things that are still lacking on the linux desktop today that this would at best be yet another experimental toy OS with no real world usability.

For me it's simply two separate, physical machines, one for online banking and sensitive stuff, the other for dev work, games, goofing off, and one or two android devices for other random crap. That's my sandboxing.

It would be a hard change, especially with the die-hard love for C, but I don’t think that it would be impossible to make it possible, with a backward compatible escape hatch.

Also, Linux user space is not famous for being binary backwards compatible, and everything being source available, I think with a clever abstraction it could potentially work.

> And again, as you even said, for such a hypothetical sndboxing desktop os, user space needs to be rebuilt in large parts from scratch. Not in a hundred years. There so many things that are still lacking on the linux desktop today that this would at best be yet another experimental toy OS with no real world usability.

From the several toe dips I did with Linux desktop over the years, 99.9% of all user-space GUI programs will not be missed by more than 5000 hardcore fans anyway.

Rust, Zig, Nim, D -- all fine languages, and all gradually travel to having a proper UI toolkit (or solid bindings to the existing ones, more often).

I happen to believe that when the solid foundation gets created we'll see an explosion of high-quality Linux desktop programs. But various problems with Qt and GTK are preventing it (licenses included)... for now.

But this is the Linux desktop, if you're not getting paid to use it, and you're not ignoring it to do everything on the command line, you're probably a hard-core fan of some odd niche app
Almost every application that supports Linux has been ported to other platforms. Linux is the one big platform no one is forced to use.
That's true. It's also true you can make almost any desktop environment and theming with it which I dig quite a lot but never have time for.

IMO desktop Linux has a future -- and I am saying this as a vocal critic of it. But there are some obstacles that haven't been overcome yet.

Before the CORBA->DBus rewrite, the AT-SPI and related projects (read: the GNOME Accessibility infrastructure) was really looking promising. The Sun Accessibility office did great work to make GNOME a useable platform for people with disabilities and developers working on accessibility. The sudden death of the sun accessibility office combined with a big rewrite of the communication infrastructure pretty much set us back for some years. GNOME Accessibility is short on developer staff really actively working on the topic, and those which have managed to persist over the years are almost burnt out.

When GNOME is apparently growing right now, it would be great to divert some of the new resources towards more accessibility development. When GNOME started to support accessibility back around 2003, it was leading the way. It was the first toolkit to do so on FLOSS platforms, and this was even before commercial vendors have started to include accessibility by default. These days, all commercial vendors of desktop and mobile OSes have accessibility built-in by default. Which shows that GNOME was on the right track starting early. It would be great if management could acknowledge that this is an important topic which needs more work to achieve excellent results.

Diverting funds and attention into "Accessibility infrastructure", sounds like it fits very well with what Robert McQueen explains to be an important goal of GNOME foundation:

> try to do more in the world and bring the benefits of GNOME to more people. We want to take our message of trusted, affordable and accessible computing to the wider world.

Next steps? How about:

1. Break GNOME's hard dependency on systemd. I don't mean refuse to use it, just don't force people to have to do so.

2. Fix that damn file picker dialog we've been groaning about for 20 years. Specifically, put the full path in an editable textbox. I'm not kidding! This step alone would be sooo much of a usability improvement for me!

I don't mind if you guys take a year-long hiatus and just do those two things.

Doesn't Ubuntu's logind shim solve the first point already?
I'd say that shim and elogind are third-party workarounds. The type of kludge you usually only need for proprietary software.
Not as far as I am aware.

I'm not 100% familiar with the nitty-gritty of this, but it forced the Devuan folks to fork Debian rather than just remove some packages and install others. Obviously if the solution did not require altering the source code of some of the existing packages (including GNOME ones AFAICR) - nobody would have gone and forked a distro.

They need to repackage at least the user and system service packages which in Debian now carry .service files rather than other init configuration.
Since the decision made by Debian was that systemd will be the only supported init system, they had to fork to maintain alternative versions of packages depending on the init system, so I don’t think it’s fair to say it is on GNOME.
You can use CTRL+l to edit the full path in the file picker dialog. But I agree with your point, it could be improved. My personal gripe with the file picker is that backspace does not go to the parent directory anymore.
Ctrl+I? I'm using Cinnamon 3.8.8 (and, say, gedit 3.30.2) and that doesn't work.
(comment deleted)
> 2. Fix that damn file picker dialog we've been groaning about for 20 years.

Hell, yes, please.

The way I mostly deal with the open filepicker is just drag and drop a file in there. In Windows, this tries to copy the file to the location, which is an insane thing for a filepicker to do: in gtk, this just shows the file and selects it.

Most file managers have better facilities to find and manage files, so you can paste the path into it or use a command like `rox -s (paste)` to get the file you want. It also works if you drag and drop a folder in it to switch to the folder.

Improving the filepicker to make it work for everyone is a fool's errand. Much better off making it integrate with filemanagers adequately.

As for the systemd dependency, I think this is firmly a case where the only way to change their minds is to make the changes yourself, maintain a rebase fork[1] for several years, and show that the demand is there and the complexity is worth it. Considering the major Linux distributions default to systemd and it has a variety of features not included in traditional init, I can understand why they wouldn't want to do it unless it was proven to be valuable in advance.

[1] Do not give it a different name: it's just "the gnome fork that takes full advantage of systemd when it's present but does not require it". Do not increase or decrease its scope: no fixing filepickers or adding traditional menubars. Either of those will cause Gnome to say "It's a different product" rather than "it proves the demand for non-systemd" amongst gnome users.

> is just drag and drop a file in there

So you're saying you need another file picker / explorer just to use GNOME's ... :-(

Improving UX, including usability testing with actual users, should be a top priority. Today Gnome has some pointless mobile-device-like UI concepts that don't make much sense on a desktop (like "swipe" away the start screen to be able to log-in). Then there are way too much ridicoulus limitation in the UI. In certain aspects Gnome was better 10 years ago.
That “swipe” will happen just by starting typing/pressing any button — so I think it is exactly a good example of convergent UX.

It is exactly my gripe with windows where you have to separately press one key just so to make the locker locker disappear.

> That “swipe” will happen just by starting typing/pressing any button

True. But people usually don't KNOW that. It would help if it was written out. "Swipe to unlock or type your password" is less confusing than a weird arrow-like animation going up.

Yeah, or even add a conditional to not even mention touch on a non-touch capable device.
But the whole first screen is pointless. Why not show the log-in prompt directly on the first screen? This is counter intuitive and an example of "function follows form" (and not the other way around).
I quite like it. It’s function is to showcase a large clock and notifications, similarly to how it is on phones. I don’t necessarily want to unlock it when it’s visible, but when I want it will seamlessly disappear.
The GNOME Project manged to finally do away with the prejudice that Open Source means bad UX. Great job!
In the specific case of my mom and a few other neighbors, it's the KDE project that did just that, well over a decade ago. But i agree with your point that GNOME design is really nice.
I had a bad feeling the comments section would be filled with dorky, off-base rerun complaints and whining about UX and the "oh it's all mobile design" tropes that has barely been true for years.

Imagine anyone working on GNOME stuff reading this! There have been leaps and strides in making Gnome stuff stable and work out of the box. I remember using Linux 5 or so years ago, and if I wanted to do GUI configuration of X/Y/Z, almost all the time it was some random app that someone just uploads to sourcefourge, with random likelihood of working. Now I have basically all the coverage I need just from out of the box Gnome stuff (I'd love for pavu-control to get brought in but...)

So much stuff just works. Someone needs to do an indiegogo about the file picker, but it _also_ basically works, and the design of gnome stuff in general has transitioned well to widescreen monitors etc.

Not to mention insanely neat stuff like the Gnome Builder [0], even if that doesn't affect my day-to-day.

Y'all are ungrateful, and really discounting how well stuff works now compared to how it used to (Yes, even in Gnome 2!). Gnome's been great to me

[0]: https://wiki.gnome.org/Apps/Builder

I do not recognize any of the difficulties you mention. I was a Gnome 2 user since 2.4, 2.6, right up until the end. Around 2.10 things stabilized, wel before 2010. I loved it, and I still like Gnome 2's fork. I tried to like 3, but unfortunately I don't see how the mobile-criticism isn't valid, or how it made things easier or better. I wasn't and am not someone who tweaks and tunes, but Gnome 3 was too much simplification, for me.

I can imagine it's tough to read if you're a Gnome committer, but I would hope the points raised are seen (although evidence seems to indicate it isn't), not the fact that there is criticism.

The way I see it, Gnome now is a bit of an anti-gui: it seems to be in retreat of actually providing GUI for doing things. This may be what some people want, mobile guis are the same (and I protest that too), but whereas before I had the impression Gnome was big enough to suit different sorts, now it seems those who don't like the narrower goal Gnome has set for itself just need to move on. And I have, in a great reversal of history, KDE actually feels like the modern Gnome 2 that never was (I disliked KDE 3 and 4 with a passion).

I don't think modern Gnome is the right DE to be the default in nearly every distro, because it has become so opinionated. There are other DEs that to me seem better suited to that role.

Then again, I couldn't tell you why Android-iOS (I barely see any difference) is what it is, so maybe I'm just old, different or some sort of UI-minority.

>Then again, I couldn't tell you why Android-iOS (I barely see any difference) is what it is

Because you're trying to analyze the technology rather than the social/power structure wielding it.

For what it's worth as a person who just uses Linux as a development platform and does not want to tinker and wants something that works out of the box and feels as polished as Windows or macos, gnome by far comes closest and I'm very happy with it.

These days I can just run the latest Fedora release and it simply works.

Gnome is great. It’s easily m favorite desktop environment (including vs OSX and Windows). It works. It is consistent (unlike most other Linux DEs). Its UI gets out of my way. Its keyboard-driven workflow is quite nice. I’m a fan.

I’m running Fedora 34, and my only complaint is the clean-start memory usage of which Gnome is a big part, but unnecessary Fedora services also take their fair share.

> Its UI gets out of my way.

If you want the UI to get out of your way, why are you using a desktop environment instead of just a window manager?

I've been through this back and forth, the devil is in the details. I'm sure with enough customizations and configuration, a tiling window manager can do all of the following, but I just don't have the time or energy anymore, and Gnome does most of these well enough that it doesn't matter.

- Works well with 1, 2 or 3 screens as I hop around between desk, laptop, and home office

- Seemlessly allows me to share screen with Zoom, Teams, and Discord.

- Easily allows me to select microphone and speakers on the fly, and connect and disconnect bluetooth headphones.

- Modify network settings easily and quickly as I hop between wired and wireless networks.

I've found the best compromise to be Gnome with the MaterialShell, which gives me back the tiling I need without removing the ease-of-use from a full desktop environment.

https://github.com/material-shell/material-shell

You always use a desktop environment, either a premade one or one you assemble yourself starting with a window manager.
I think this is a legitimate question! Saying you want the UI to get out of the way _can_ mean that you still want the DE for the 10% of the time you need it, but for the 90% of the time you don't, you want it to be unobtrusive.

Classic example for me is how Mac will fuse the top bar and a maximized app's toolbar. I want the top bar sometimes! But I like it not being a permanent fixture if the app I'm using needs it.

A lot of people want the DE for when they need it, and want it to not be in the way when they don't. That's what a lot of people mean by that IMO.

I submitted a few patches but got turned of having to deal with Vala and C. Tooling and docs feel ancient compared to whats available in .Net/Java/js etc.

Thats said I really admire how ambitious they tried to be and all the stuff they have managed to produce with such few resources.

(comment deleted)