Next Steps for the GNOME Foundation
ramcq.net
ramcq.net
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
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.
Because you're trying to analyze the technology rather than the social/power structure wielding it.
These days I can just run the latest Fedora release and it simply works.
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.
If you want the UI to get out of your way, why are you using a desktop environment instead of just a window manager?
- 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.
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.
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.
> 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.
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.
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)
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.
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.
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?
But those may solve grandparents' issue with "ignoring their feedback" or "poor quality and usability.".
A new userspace should be built similar to Android with proper capability-based sandboxes.
(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)
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.
But I agree that ios has it better.
Why do poeple always forget that Plan9 exists? The Android way is the wrong way to do it.
But my knowledge of Plan9 is not extensive so correct me if I’m wrong.
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.
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
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.
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 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.
Yes, the notion that privileged access does not exist at all might seem crazy at first, but when you think about it, and imagine how currently "privileged" actions like mounting filesystems could be done without it, it starts to make sense.
On the other hand, maybe Gnome should copy qubes or everyone should just make qubes ready for everyday use.
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.
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.
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.
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.
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.
It is exactly my gripe with windows where you have to separately press one key just so to make the locker locker disappear.
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.
Thats said I really admire how ambitious they tried to be and all the stuff they have managed to produce with such few resources.
I know it's the same software, but the way it's referred to gives me pause.
The statement of their specific goal for the future refers to FOSS.
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.
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.
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.
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.
Hell, yes, please.
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.
So you're saying you need another file picker / explorer just to use GNOME's ... :-(