I’m pretty sure most of you are familiar with KDE Neon, the distribution KDE maintains to provide easy access to the latest KDE technologies. However, did you know GNOME has something similar, called GNOME OS? It’s been around for a while, but has a far lower profile than KDE Neon does, and it seems they want to change that and put more of a spotlight on GNOME OS.
GNOME OS is an immutable distribution using OSTree, the same technology used by the various popular immutable versions from the Fedora family. It seems GNOME OS is working to leave OSTree behind, and move to systemd-sysupdate instead, which has been available since systemd 251, released in May 2022. The developers claim this will bring the following benefits:
↫ Martín Abente Lahaye, Sam Thursfield
- Provide a trust chain from the bootloader, all the way up, both online and offline;
- Achieve a closer integration with systemd;
- Advance our support for image-based design and its benefits, e.g., immutability, auto-updating, adaptability, factory reset, uniformity and other modernised security properties around image-based OSes.
To complete the move from OSTree to systemd-sysupdate, a few things need to be completed. First, the boot process and root filesystem had to be migrated, which was done last year. Second, sysupdate needs to integrated into GNOME, as for now, you can only use it via the command line. This work is ongoing, and requires a new D-Bus service and polkit integration to allow GNOME Software to manage the update process. Of course, there’s more work that needs to be done to complete this migration, but these are the main tasks.
All of this work is part of the project’s goal to make GNOME OS nightlies viable for daily-driving for quality assurance purposes, and I’m sure all this work will also make GNOME OS more attractive to people outside of the developer community. It’s basically GNOME/systemd taken to the extreme, and while that will surely make quite a few people groan, I personally find it great that this will make GNOME OS a more capable choice for everyone.
That’s what open source is all about, in the end.
Hrm… thats what I want, but with KDE…
Gnome OS and KDE neon both feel in an odd place for me.
Conisdering how cash strapped so many oss projects are (especially Gnome!), why are the DEs duplicating the work of distros?
Having a distro involves not only the building of a distro, but the support, the patches, the marketing(!) and multiple other facets all draining time/resource/money out of the core project.
KDE Neon isn’t duplicating the work of a distro. It’s just Ubuntu + updated Qt and KDE.
That same argument could be made of any Ubuntu derivative. Xbuntu/Kbuntu included.
Teams need to integrate the work, port patches, maintain repos, support user questions.
This all takes time and effort that isn’t being spent on the DE itself.
My understanding is that KDE Neon is a dogfooding distro, intended to make it easier for KDE contributors to daily-drive and find bugs in the newest KDE package releases while sitting them on top of an Ubuntu LTS base so they won’t have to spend too much time identifying breakages that trace back to updates in components outside their purview.
It really can’t. One is raw code directly from the project repo to test the code before a release, and the other is meant for daily use and subject to the distro release cycle. Debian is especially bad about carrying patches and diverging from the upstream project.
GNOME OS is for developers. It’s raw Alpha software. It has bugs, fixes, and weird experiments which may, or may not. be in in the next release. It exists in the liminal space between GNOME releases.
The GNOME OS website says it all.
“GNOME OS Nightly
Try the latest and greatest GNOME software in a VM or on real hardware”
Bear in mind that OSTree is the “git for your OS” engine underlying Flatpak and, if they’re not using it for the OS, you’ll probably either be paying in added disk space or be paying for any deduplication between the system image and installed Flatpak runtimes as a runtime cost of using a deduplicating filesystem instead of as an install-time cost paid by the package managers.