It seems the GNOME team is getting quite serious about turning GNOME OS into an end-user focused Linux distribution, similar to a project KDE is working on.
GNOME OS is GNOME’s development, testing, and QA distribution. It’s not designed to be useful as a general-purpose system, and so it hasn’t been the center of attention. However, that makes it a convenient place to experiment, and ultimately through sheer coincidence the GNOME OS team ended up developing something that follows my vision using the same technology that I was. The only real difference was intent: carbonOS was intended for mass adoption, and GNOME OS was not. In essentially every other aspect, the projects had the same roadmap: following Lennart Poettering’s “Fitting Everything Together” proposal, providing a stock GNOME experience, and even using the same build system (BuildStream).
↫ Adrian Vovk
The goal with GNOME OS is to showcase the best GNOME has to offer, built on top of an immutable base system, using Flatpak as the means to install applications. Basically, we’re looking at something very similar to the immutable Fedora GNOME variant, but probably with even less modifications to stock GNOME, and perhaps with few more newer things as default, like perhaps systemd-boot over GRUB. KDE also happens to be working on a very similar project, with many of the same design choices and constraints.
I think this is an excellent idea, for both GNOME and KDE. This allows them to offer users a very focused, simple, and resilient way of showcasing the latest and greatest the two desktop environments have to offer, without having to rely on third-party distributions to not make silly choices or mess things up – for which GNOME and KDE developers then tend to take the heat. Systems like these will, of course, also be a great way for developers to quickly spin up the latest stock versions of GNOME and KDE to test their applications.
Still, there’s also a downside to having official GNOME and KDE distributions. If users find bugs or issues in these desktop environment when running other distributions, like Fedora or Ubuntu, GNOME and KDE developers may be tempted to just shrug them off and point them to the official GNOME and KDE distributions. It works there, so obviously the cause of the bug lies with the unofficial distribution, right? This may be a tempting conclusion, but may not be accurate at all, as the real cause could still lie with GNOME and KDE.
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.
Immutable distributions are not for me, since I prefer the control regular Fedora and RPM gives me, and I don’t want to give that up. It also doesn’t help I really, really don’t like Flatpak as it exists today, which is another major barrier to entry for someone like me, and I assume most OSNews readers. However, there are countless Linux users out there who just want to get stuff done with whatever defaults come with their operating system, and for them, this newly proposed GNOME OS and its KDE counterpart are a great choice.
There’s a reason Valve opted for an Arch-based immutable KDE distribution for the Steam Deck, after all.
KDE and gnome are risking a lot with this tactic. Not so much with bringing themselves into direct competition with their revenue streams, but more spreading themselves to thin.
Running a distro is hard. And a Lot of work. DE only have so much revenue coming in to support improving their core systems, then there is the app ecosystem, adding a whole distro.. That’s risky.
It feels like the Mozzila approach, keep adding new systems and services while not investing in the core product they exist for in the first place.
Revenue?
At first, I thought the ideas for Gnome to evolve into an OS [aka Linux Distribution] along with the parallel KDE project were just a waste of time and resources. But then to read that they are inspired by plans of Poettering [Microsoft] to bind the Linux world into an over complicated mess of systemd bloatware, I smelled a rat. There are ideas that would improve the Linux hinterland, but NO.
You mean the guy who also invented pulse audio? I think he has contributed enough to the community to Not be called a rat…
Also, remember that Systemd brought us parallelism when SysV was still suffering from decade old issues and was becoming impossible to maintain. It was basically stuck in the X11 / Wayland world. Basically every major distro switched away from it for a reason. But obviously, FOSS being FOSS some remain.
Adurbe,
SysV was antiquated eons ago, reliance on init levels, tons scripts spawning tons of process, etc, but your post seems to suggest there was nothing else. There were tons of other alternatives and virtually all init systems were superior to sysv. Systemd was just one of many init systems that successfully booted services in parallel (including my own).
IMHO an init system should follow the Keep It Simple Stupid principal. I would have preferred *nix to standardize on a simple less invasive init system.
The problem with those other init systems that booted services in parallel was that you had to micromanage the whole thing, with SystemD you just declare your service’s dependencies and SystemD figures it all out. Also, you get to see the status of a process, and it doesn’t need hacks like PID files.
kurkosdr,
That’s not at all true. Whether it’s systemd or not loading a service at startup works pretty much the same way, you just define the parameters of the process and the init system handles it.
I hated those PID files too, but those were relics of sysv, most init systems don’t need them. That’s not unique to systemd.
“smelled a rat” is not to be read literally. But “the guy” brought us systemd [and its parallelism], which was touted as being faster than sysvinit, but wasn’t ever [I compared their respective init times in 2015, and they were the same]. Anyway, I get much faster init times with “tiny” Runit, which begs the question: what is the 2 million line systemd init system actually doing? Has anyone looked at the code?
The reasons that every major distro switched to systemd are hidden by a mixture coercion, politics and indifference. The same will happen with Wayland.
The Wayland situation is not at all the same.
Years from now, there will remain those that dislike the design of Systemd and many distros will use alternative init systems, session managers, boot managers, network managers, and everything else that Systemd intends to take over. In 5 years, it will be very, very hard to find a Linux distro that is not using Wayland as its default ( and perhaps only option ).
Enough people disagree with the core design of Systemd that, at some point, Systemd itself is likely to be replaced and will become “legacy”. While lots of people dislike the way Wayland has been rolled out, there are not many real devs that think X11 is a better architecture.
It is interesting that distros like Chimera Linux that want “no legacy” ships without X11 but also without Systemd.
I think we need some perspective here. First, systemd currently has 1,170,831 lines of code (I just measured this using cloc), while the PorteuX distro’s custom SysV init system has 3,472 lines (also measured with cloc). If these numbers represented minutes, PorteuX would take less than three days, while systemd would take 694 days. My point is that no one can argue that systemd is simpler than SysV.
Another myth concerns performance. SysV can definitely execute services in parallel, and that’s exactly what PorteuX does. With all its simplicity and versatility, this SysV implementation manages to boot in 3 seconds to a modern desktop environment like LXQt, or 7 seconds using KDE Plasma.
The fact that major distros have adopted systemd doesn’t mean it’s better. It’s worth noting that most of them have also adopted GNOME, which is arguably one of the worst desktop environments ever made: https://medium.com/@fulalas/gnome-mess-is-not-an-accident-4e301032670c
If we take popularity as an indicator of quality, then Windows would be amazing, which, as we know, is not the case.
The whole move to Flatpaks worry me, as owner of a Librem 5 with a measly 32GB of storage. I constantly struggle with storage space and Flatpak programs take just so much space. If they are not updated by their developers I end up with 5-6-7 versions of the same libraries on my phone.
I wish there was a way to force Flatpaks to test-run on shared libraries and, if it works, to keep using them this way and releasing storage space.
Shiunbird,
I concur.. Centralized repos have the advantage of coordinating dependencies and reusing the same dependencies,. but at the same time they’re often inflexible with regards to 3rd party updates. I find that self contained flatpak are a practical solution to the problem of updating packages independently. I’m often stuck on official repositories with old versions of software lacking bug fixes and feature updates that are available upstream.. Centralized repos require just a huge amount of work, so in the long run decentralized packages will probably win out, despite there being some cons.
This is an interesting idea. Although I think it would be problematic because it’s a variation on the DLL hell problem. More times than not when I try to download and build the latest software I end up discovering that it needs a whole slew of other dependencies that I need to download and build recursively. Sometimes these new builds are incompatible with other system expediencies, Everything sucks when API are tightly coupled to specific releases. IMHO this is one of the most frustrating aspects of building & running 3rd party software. Flatpaks solve this by leaving the responsibility with the upstream project.
What you are proposing might solve the plethora of redundant shared libraries, but it regresses on the DLL hell issue. If you can think of a way to solve both simultaneously, maybe we could get somewhere with it. This is the type of problem that AI might be suited for: given the before & after source code for an API dependency, create a patch to make the software compatible with the version of the API that’s installed on the system. Generative AI might be able to handle this “API glue” problem.
Some have argued that this problem solves itself with more modern filesystems that do block deduplication, since in those cases the identical .so’s across flatpaks conceivably share space on disk despite being distinct files.
anevilyak,
While I’d agree that de-duplicating blocks is solvable, the bigger problem is getting every upstream project to agree to use the exact same build of every dependency at the same time. Each project is going to have different release schedules and often they don’t coordinate with one another. This is one of the difficulties that the centralized repos maintainers have to deal with.
These same difficulties end up translating into flatpaks that don’t share the exact same dependencies, which is the OP’s problem stated by the OP “If they are not updated by their developers I end up with 5-6-7 versions of the same libraries on my phone.”
This is one of the reasons that I prefer distros with large, up-to-date, package repositories. On my main systems, I do not have a single Flatpak.
Honestly, even if my base system is one with older packages or a smaller package library, my own preference is to use Distrobox to get access to something like the AUR instead of Flatpak. I might like something like Nix if I ever took the time to figure it out.
I am not trying to dump on Flatpak. I think they are a huge step forward for Linux in general. That said, I do still vastly prefer the idea of a cohesively managed package ecosystem ( repository ).
I just want an official KDE repository for Debian Stable.
The base system doesn’t change for like, two plus years. Just give us a repo with the newest KDE built on that.
Right now I think Fedora is the closest thing to good balance between stability and latest versions.