603 karma · joined April 19, 2021
I disagree, for an example: global menus do not work well at all with focus-follows-mouse. It's not really possible to design a good system that has both. I've seen various attempts to try to make focus-follows-mouse work on macOS, and the usability is very poor. Similarly, you will have bad usability trying to plug global menus into a system that isn't really focused around the concept of menus.
But I think you're right that in the end it doesn't really matter, someone can get used to doing it either way.
I agree, I've seen lots of open source projects get stuck and suffer from this issue where it's hard to get certain things done, it's hardly anything new, that's why I tend to focus on how to reach solutions to the problem. If you know someone who is capable of fixing these issues who needs some support, or if you have some technical insights here, let's talk about that. Otherwise, the issue is not one of being controlled -- the issue is actually because nobody has enough control to get the thing done. So let's see what we can do to give the right people a handle on the situation and empower them to do the right thing.
>Affects developers, and GTK itself when used.
I'm not sure what you mean, the developers of other wayland implementations don't have to worry about GNOME's implementation, unless they are aiming for feature parity. GTK can of course receive patches to support other implementations.
Does that help? I don't think those are issues where you're being controlled into an unfixable situation, so I can try to help offer some solutions.
https://github.com/golang/go/issues/31908
https://github.com/libuv/libuv/pull/2322
https://github.com/tokio-rs/mio/issues/923
>have to deal with their bullshit on a daily basis because they control a lot of unrelated stuff.
Can you please elaborate what you mean here? If there are some bugs that are causing issues, you should consider reporting those.
The solution there would be to make clear what constitutes a personal attack. No reason to bikeshed over it.
Also in my experience, the attack surface cannot be strictly reduced by removing features -- if users want a specific feature, they will just get it from something else, so at some point one needs to have code on the machine somewhere that does it.
Do you want a real comprehensive answer to this? You can just skim through the code to systemd to see what it's doing. Just in my experience, systemd has a lot more features than openrc; you could also read their respective documentation to get a full picture of what they do differently. All the other additional lines are for other optional daemons.
I have been using systemd in debian for years and nobody I know has needed to pay Red Hat. That's just not really how open source works at the distro level. To the contrary, I've seen a good number of debian users/developers contributing their expertise upstream to systemd, as well as fedora users, arch users, etc.
>If you don't want North Koreans hacking your server you would do better to opt for non-systemd.
This seems to be fear-mongering and doesn't seem to follow at all from what you said either. There are a lot of other large projects used by the various Linux distributions, systemd is not out of the ordinary here. For an example of what you're looking at here, debian bullseye has 1.17 billion lines of code in total: https://sources.debian.org/stats/
Of course you would have to do a deeper dive to see just how much of that is expected to run as root or with CAP_SYS_ADMIN, or in kernelspace.
>Lennart just keeps adding to systemd and refuses to say when he will finally stop adding to it.
I'm not sure I understand, most projects only stop adding code when development is done. So the answer would probably be "when people stop using it." Are you a distro maintainer? If you want a stable version with fixes backported, you can use this: https://github.com/systemd/systemd-stable
>How many skilled humans on this planet are available to audit those 600k+ lines of systemd code and are actually auditing it? (And how many work for intelligence agencies?)
I'm not sure I understand this either, are you asking how many C programmers there are in the world that are able to perform code review on a C program for Linux, like systemd? And what subset of those C programmers work for intelligence agencies? It might be worth answering those questions, but I'm not sure how that is related to systemd specifically. If you look at the systemd github (or the github for any other big C program), you will see a good number of people already publicly reviewing patches, so you could get started there.
WSL is probably very similar to other containerized Linux scenarios, where you might want a small init to function as a sub-reaper within the container. I don't think that is much of a specialized case at all, as far as inits go anyway.
I personally would describe that approach as actually more lacking in configurability, because with that you're limited to only the built-in settings. In my opinion all those could be improved with further improvements the extension system. In general I also see the line between "third party" as being blurry in these open source projects, because any random person can contribute something. But in the end, you deserve to use something that is to your preference.
>I'm not asking the shell to act any particular way, nor am I asking for changes in Gnome.
Sorry, I guess I'm confused as to why you'd be talking about technical issues with GNOME, if it's been totally irrelevant to your interests for the last 10 years, and you don't even use it. If you're not interested to give constructive feedback or try to fix the issues, or try to describe different ways of achieving your workflow, then I would say I'm not really interested to discuss complaints about these things.
It's a bit odd to read this sentence. GTK2 got its last minor release over 10 years ago, and was EOLed 6 months ago. It's a dead project. GTK3 is also feature frozen as of 6 months ago, and will not see any features brought back from GTK2. If you want to get some of these issues fixed, it would be best to start submitting patches to GTK4, or trying to find other solutions that will work there. Or, you could try to revive some of that GTK2 code yourself, although I wouldn't recommend it -- a lot of that code is very obsolete.
>Horrible GTK3 / GNOME UI design is leaking into Ubuntu Mate applications in 20.04
This is a design decision made independently by the MATE developers to update their app to a different design, no? I don't see what GNOME has to do with this. Regardless of your feelings on it, at least one person seems to have thought it was the right decision.
>And then you have the terminal Termite
I remember this issue from last time it was discussed, I think the Termite maintainer overreacted as a result of a very normal technical disagreement. I don't really witness them rejecting patches any more than any other project. I also disagreed with that developer's decision to fork on a technical level, I thought that was unnecessary and could have been avoided.
>But the negatives in short are poor documentation, memory leaks, you end up only using the approved plugins (if you don't like to restart your desktop more than once a day) which of course negates the whole idea of a plugin system.
Some people are actually working on the docs, please contribute if you are able: https://gjs.guide/
There have been issues with memory leaks in the past, but those are bugs that can pop up with any garbage collected language. I'm not sure what you'd expect them to do, besides do the normal thing, and fix the individual bugs whenever possible.
I hate that I always have to say this, but there is no alternative to only using approved plugins, on any plugin system. I don't know what you mean it negates it. In Javascript the crashes and hangs are usually from unhandled exceptions and infinite loops -- This is even worse with a C or C++ plugin system, because those are memory unsafe and can cause bad segfaults. If the javascript is causing segfaults then that's probably a bug that should be reported.
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.
This is not really true, and has not affected anything that I've seen. Basically every GTK desktop (including GNOME) has another separate widget library on top of GTK, to include its own widgets specific to that desktop. Also GTK3 is currently release frozen and will not be adding any more features, GTK4 is the current version.
>hopefully by avoiding Gnome 3 because it constantly changes workflow and uses buggy JavaScript plugins,
I haven't seen any desktop system that doesn't change workflow over time, or doesn't have some bugs in the plugins. That's a sad fact of life when you have hundreds of plugins made by various people, with varying quality. FYI KDE is also using javascript as a plugin language for the desktop, and for a number of other QML things, so it makes no sense to single out GNOME for use of javascript: https://develop.kde.org/docs/plasma/scripting/
>And then of course the entire X vs Wayland situation.
The situation with compositing should improve over time with Wayland, the idea there is to not ever turn off compositing (though the Wayland implementations are still optimizing this for the various edge cases).
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.
If somebody has said something that is outright rude and condescending to you, that would probably be a code of conduct violation, and the foundation would probably want to hear about it.