While it’s still early days and it’s not recommended for non-technical audiences, GNOME OS is now ready for developers and early adopters who know how to deal with occasional bugs (and importantly, file those bugs when they occur).
↫ Tobias Bernard
This is great news, and means GNOME OS is progressing nicely. I’m a proponent of this and KDE’s equivalent project, because it allows the people working on GNOME and KDE to really showcase their work in optimal, controlled conditions. While I don’t see myself switching to a Flatpak-based, immutable distribution because they tend to not align with what I want out of an operating system, they’ll serve as great showcases.
There is a risk associated with these projects, though, as I highlighted the last time we talked about them.
Once such “official” GNOME and KDE Linux distributions exist, the projects run a real risk of only really caring about how well GNOME and KDE work there, while not caring as much, or even at all, how well they run everywhere else. I’m not sure how they intend to prevent this from happening, but from here, I can already see the drama erupting. I hope this is something they take into consideration.
We’ll have to wait and see if my worries are founded or not.
While I hope everybody keeps collaborating and accepting contributions from outside their projects, I am kind of ok if projects “only care about themselves”.
The ideal of Open Source is one of community where each participant works on what is important to them for the benefit of all. Parties with different interests and priorities cooperate to create something greater than we would have gotten from any of them individually.
In my view though, we (the users) have become quite entitled. We now expect to get world class software completely tailored to our individual tastes and requirements. We act like volunteer developers “work for us”. I don’t love this.
In particular, it seems I am constantly running into projects with one or few many contributors and many users. We demand a lot from these people. If they were able to stick to the core and more of us were required to step-up to ensure compatibility and specific extensibility of these projects, they overall ecosystem would be far less fragile. The idea that the source project needs to accommodate everyone results in less collaboration overall in my view.
Setting aside the historical attitudes of the GNOME devs, what is wrong with them working to deliver only the incarnation of GNOME that fits their vision? We are free to take their work and modify it as we like. But why do they need to modify it to suit and support our preferences?
Flatpak allows developers to create a single build of their application that works they way they intend it to and to distribute it to Linux users regardless of distro. If we do not like the way they put the Flatpak together, well we have the code. At least, for Open Source apps we do. Flatpak can be a distribution channel for proprietary apps as well.
I rarely use Flatpak but I love the idea of Flatpak and hope that its existence attracts more developers to target Linux. If we unburden these devs from the “fragmentation” of the ecosystem, supporting Linux becomes more attractive. But while I am very thankful for Flatpak, I rarely use it.
My preference is for native packages as part of a distribution. I have been very attracted to Arch because of the depth of the repos and of course the AUR. When I use other distros, I install an Arch Distrobox so that I can enjoy the same package selection. I use Distrobox instead of Flatpak. But I do not consider it the job of any given application developer to get their application into my distro of choice (not even to Arch). That is the job of the distribution.
It is the job of the distro to make all the software work in the context of that distro. This can include different configuration preferences, compatibility with other software, or different compilers or libraries. As a user of a smaller distro, I know I may have to do some of this myself. I may even have to pay somebody for it (gasp).
How is a desktop environment different? Creating their own distro can be like an app developer using Flatpak. If the software works in their distro, it works. If it does not work in the context of a different distro or a different workflow or with different tools (compiled with Clang perhaps), why do we expect GNOME to fix those things? The community that wants those things should work on them. It can only make that community stronger. I frees that dev of the app or DE to focus on the value they add (features) instead of the maintenance we demand.
If Mint wants GNOME to work differently on their distro, well, they can do some work to make that happen. Which they are. My distro does not have Systemd and GNOME requires it (so my distro had work to do). And to me, that is not a bad thing.
Again, this all assumes collaboration of course. If project refuses to accept contributions from others, everything I am saying falls apart.
At the end of the day, the ultimate power in Open Source is to fork. If more people want things to be different than the parent project, well, then we can all just leave them behind. GNOME certainly has its share of examples. And having MATE, Cinnamon, COSMIC, and GNOME as a result seems like a very good thing to me.
[Full disclaimer, I am one of the many people that used GNOME daily until GNOME 3. I have used many desktops including Cinnamon and probably XFCE for the longest. I have used KDE / Wayland since the release of Plasma 6. COSMIC is looking good.]
LeFantome,
I agree with you about entitlements.
It’s a fair point, but also a bit of an oversimplification. Without good faith cooperation, what one project does, or does not do, can hamstring other projects. Theming is one such area. Technically Gnome are free to reject theming support, but at the same time the resulting criticism may be fair.
I don’t think flatpak is perfect by any stretch. But when I need to install something that’s not in the repo, that to me is when flatpak/snap/appimage shine. There are real cons to packaging everything together as a giant wad, but the upside is that it just works most of the time and saves valuable lost to chasing dependencies, which I have less patience for.
You’re not wrong, but…the centralized administration of packages is difficult to sustain at high quality and very often we see that the distros aren’t keeping up. This is why so many are trying to create new solutions. This is a good thing, but honestly I am also put off by the fragmentation. I don’t want a myriad of incompatible solutions to the same problem, not just distributing binaries, but also for libraries too (ala PIP/CPAN/etc).
It makes me wish they’d all put their differences aside and come up with a universal decentralized solution that everyone could us. Wishful thinking, I know.
Like you, I prefer to use native packages, but I do hate fighting with distro dependencies when I need to deviate from my distro’s builds for any reason. I think we should be in agreement it’s not something they handle well.
Yeah, agreed.
Forking makes me more squeamish than you. Sometimes forking is necessary and not a sign of anything bad, but sometimes I really wish we’d be more willing to work together first. Though again I understand this is wishful thinking. It’s just there’s so much duplication of work.
I also moved away after gnome 2, which I loved. I also use XFCE and KDE, although in my case without wayland, which has problems under KDE5. I’m willing to give it a shot again when I get on KDE6.
@Alfman
> a bit of an oversimplification. Without good faith cooperation, what one project does, or does not do, can hamstring other projects. Theming is one such area.
We agree. I tried to say that but perhaps not well. What I am suggesting is that the GNOME devs should be free to build their desktop without theming. However, I think we would both agree that somebody else should be free to build it in and GNOME should let them even if they want guardrails on it. Maybe it becomes a compile-time option. GNOME can build their OS with theming disabled (as per their vision) and Mint or Arch or Chimera or whoever can ship GNOME and GNOME applications with theming enabled.
> fighting with distro dependencies when I need to deviate from my distro’s builds
My primary reason for using Arch and now bringing an Arch Distrobox with me everywhere is exactly this. I want everything in the repos with the options and versions I need. It is the main reason I never really became a Debian or Ubuntu desktop user. At the very least, I need to be able to easily build or modify packages myself so that they still fit into the package ecosystem. I can modify an Arch package or a Chimera Linux cport. Even then I don’t like it. I had to override the build of ffmpeg in Chimera and it bothers me. But the resulting package at least plays well with the rest of the distro.
> Forking makes me more squeamish than you. Sometimes forking is necessary and not a sign of anything bad, but sometimes I really wish we’d be more willing to work together first.
Oh, we agree. All I mean is that, in the case that a project stops listening to its users such that most people disagree with the maintainers, forking is possible. My hope is that knowledge that forking is possible will encourage projects to collaborate instead of building empires. There are also forks that should never have happened or that we should all ignore. Home is where the community is.
> in my case without wayland
I am curious what you think when you finally get to try Plasma 6 under Wayland. You may be surprised how well it works.. If not, it would be interesting to know where you find it lacking. Sadly, the NVIDIA drivers are still pretty far behind in Trixie. I hope that does not screw it up. Mesa is fairly recent at least.
NVIDIA added explicit sync in driver 555 in June 2024. I think Debian 13 may ship with NVIDIA driver release 535. That may well cause problems.
This may be one time it is worth going outside the Debian repos:
https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#debian-installation
There will probably be a Debian 13 entry here soon:
https://developer.download.nvidia.com/compute/cuda/repos/
More of my comments are “awaiting moderation”…kurkosdr said something about this too. Have wordpress settings been tweaked to try and catch more comment spam?
Spam sucks. Although I think the auto-moderation feature is at fault here. IMHO long term users should not be subjected to it. Actual spammers using such old accounts would have been banned long ago. The auto-moderation is probably 100% wrong when it comes to old accounts.
Agreed
I am one of those “volunteer developers” and I feel like you are very right in general, but there is a problem in this with common foundation libraries:
a) Common foundation libraries and frameworks need to serve many interest far beyond the personal interest of its developers
b) If no such common foundation libraries exist, everyone has to re-invent the wheel on his own which wastes resources and also is failure prone
I can give a specific example: I am developing https://github.com/JSQLParser/JSqlParser since I needed a good SQL Parser for queries and DML statements while having ZERO interest in DDL statements. Surprisingly most of the feature requests these days are about DDL statements (because every RDBMS was in need to invent its own DDL syntax 🙁 )
I acknowledge that JSQLParser is useless for the people, when they won’t get all their DDLs and they would have to re-invent the wheel. Same time I really can’t be bothered working on annoying stuff in my spare time.
Solution would be more contribution and PRs but not every user has the spirit, most are just demanding.
My own workaround is sticking to SQL:2016 and maybe the big 4 RDBMS (while even those have shifted over the past years).
I can imagine that Gnome/GTK framework people face similar problem on much more complex levels.
Corporate sponsorship was needed to resolve this challenge of Open Source software.
@Andreas
I want to respond to this later but first thank you for the great project. JSQLTranspiler looks very cool as well.
I lurk around the KDE forums and their effort in this regard will be known as KDE Linux OS. It will be based on Arch and be an immutable distro. I’ve included a link to their project.
https://community.kde.org/KDE_Linux
From the link:
[KDE Linux OS] Differences from KDE neon/Prior art
KDE neon was KDE’s first version of a self-made OS. It fulfills the “distributed by KDE” requirement, but fails on the reliability angle due to the Ubuntu LTS base that ironically becomes unstable because it needs to be tinkered with to get Plasma to build on it, breaking the LTS promise. It is built on fairly old technology and requires a lot of packaging busywork — both of which are non-goals of KDE Linux.
I believe based on vibes and certain things that I see posted that the KDE leadership will have more to announce regarding their efforts in August at Akademy.