GNOME has announced it’ll be increasing its dependency on systemd, the popular init system used by most (popular) Linux distributions. While GNOME already had a few relatively inconsequential dependencies on systemd, it was effectively not a huge problem to run GNOME on operating systems that don’t have systemd, which most notably includes the various flavours of BSD. That’s going to change.
There’s going to be two changes, one of which is relatively minor, and one of which will pose much bigger problems. The minor change involves GDM becoming dependent on systemd’s userdb infrastructure in order to clean up a lot of GDM’s code involved in multi-seat setups and remote login. Currently, this works through a series of hacks that the GDM developers are going to clean up, switching to using systemd-userdb to “dynamically allocate user accounts, and then runs each login screen as a unique user”.
To aid non-systemd environments during this transition, GDM will get a temporary alternate code path that enables you to run GDM without systemd-userdb. So if you compile GDM against elogind, GDM will use an alternative trick to enable multiple graphical sessions under the same user. This trick will remain in place at least until GNOME 50, but its future after that is uncertain.
The second change is much more involved.
Next, the bigger change. Since GNOME 3.34, gnome-session uses the systemd user instance to start and manage the various GNOME session services. When systemd is unavailable, gnome-session falls back to a builtin service manager. This builtin service manager uses
.desktopfiles to start up the various GNOME session services, and then monitors them for failure. This code was initially implemented for GNOME 2.24, and is starting to show its age. It has received very minimal attention in the 17 years since it was first written. Really, there’s no reason to keep maintaining a bespoke and somewhat primitive service manager when we have systemd at our disposal. The only reason this code hasn’t completely bit rotted is the fact that GDM’s aforementioned hacks break systemd and so we rely on the builtin service manager to launch the login screen.Well, that has now changed. The hacks in GDM are gone, and the login screen’s session is managed by systemd. This means that the builtin service manager will now be completely unused and untested. Moreover: we’d like to implement a session save/restore feature, but the builtin service manager interferes with that. For this reason, the code is being removed.
↫ Adrian Vovk
Mitigating this change will be a lot more involved for operating systems that don’t use systemd, and the blog post goes into detail into what, exactly, needs to be done in systemd-less environments. There’s quite a few systemd components and other little tidbits that you will need to find or create alternatives for, and considering you’ll need to have all of it in place roughly by GNOME 50, roughly a year from now, I can imagine this causing quite a few headaches for platforms like the BSDs and Linux distributions using init systems other than systemd.
With these changes, GNOME further solidifies itself as a Linux desktop only – and lest anyone forget, that’s entirely within their right to do. Systemd haters can jump up and down all they want, but in the end, they have no right to demand that GNOME developers spend precious time and resources testing GNOME on and developing it for platforms that they themselves do not use. They’re clearly targeting the trifecta of Linux, system, and Wayland, and that’s their choice to make, not anyone else’s.
Still, if operating systems like OpenBSD and FreeBSD, or Linux distributions without systemd intend to continue offering a fully functional GNOME desktop, they’re going to have some work to do.
With this move I feel it would be better for the BSDs to drop GNOME support rather than try to keep up using hacks and workarounds. MATE and Xfce exist and (for the time being) have no dependencies on systemd or Wayland, and I would imagine most *BSD users prefer standalone window managers anyway when using it as a desktop OS.
XFCE and MATE are more sane GUIs than GNOME(3+) anyway. So yes, I completelly agree.
MATE and XFCE are moving to Wayland, so the end is nigh.
The writing has been on the wall for a while for the BSDs. They need to build their own GUI ecosystem separate from Linux. This is easier said then done considering doas doesn’t support persistent passwords on FreeBSD. :\
Well they did, Lumina is a thing but it seems to have stagnated for the past few years.
That’s because doas is an OpenBSD thing, yes it’s been ported to FreeBSD, NetBSD, and Linux, but it’s not the default for any of those other OSes and fittingly so as it isn’t designed for them.
I feel that FreeBSD will eventually cave to the Wayland push, which means it will also eventually port systemd and all of its baggage. This direction has been hinted at for years at conferences and in mailing list discussions. Meanwhile, OpenBSD will likely continue to avoid dependencies on any of that stuff for the foreseeable future. Considering I’m typing this from an OpenBSD desktop, that’s fine with me!
> doas is an OpenBSD thing
TIL. Chimera Linux uses doas as well (no sudo by default). It supports password persistence on Chimera.
> Well they did, Lumina is a thing
I guess Lumina started on BSD with the TrueOS push but when that fell apart (corporate change of direction) the only OS that defaulted to Lumina was Project Trident (a Linux distribution).
When Project Trident stalled (lost its lead dev), Lumina was basically abandoned as well. Too bad really. You can still find it in the AUR. I built the Insight file manager not long ago.
Considering the crew behind Lumina was the PC-BSD crew, I didn’t have high hopes for it. They made odd decisions that didn’t really pan out with both PC-BSD, TrueOS, and Trident.
It’s my understanding no one has bothered to add the syscalls doas needs for password persistence to the FreeBSD kernel. It’s possible, but no one has done it.
OpenSSH is designed for OpenBSD, yet it’s in base for the other BSDs. I feel doas should be added to base in the other BSDs. Something like doas/sudo is a fairly common feature at this point in *nix OSes.
The BSDs will have to switch to Wayland at some point since it’s the successor to X11, but I don’t think Wayland depends on systemd since it’s a protocol. Some DEs or WMs might have systemd dependencies, but I don’t think Wayland itself specifies systemd.
If FreeBSD wants Gnome and probably KDE, they will have to figure out a way to work around systemd, and they probably will. FreeBSD implemented the OCI format for jails, FreeBSD has ported the graphics drivers and Wi-Fi drivers from Linux via a driver shim, and they implemented large parts of Solaris for ZFS support. Some systemd compatibility isn’t outside the realm of possibility.
> The BSDs will have to switch to Wayland at some point
I agree completely
> If FreeBSD wants Gnome and probably KDE, they will have to figure out a way to work around systemd
KDE does not rely on systemd at all as far as I know
As for BSD figuring out systemd, there is this:
https://github.com/InitWare/InitWare
Do any non-systemd people even use Gnome? I’m on most of the non-systemd distro forums, and I don’t really recall anyone bothering to try to run Gnome in recent years.
Are you sure anyone on the BSDs really cares about Gnome? Gnome doesn’t give you anything you can’t easily get with other desktop environments, and many Gnome programs are half-baked, crippled versions of real programs from outside of Gnome. They only exist to put the “G” in front of another program name.
Alpine linux has an install script for gnome, so *someone* over there may be using it.
But the point of Alpine is to be small, and Gnome is not small, so I doubt that this Alpine Gnome script is terribly popular. Sounds like more of a special use case scenario.
I think Chimera-Linux uses Gnome as its main/target DE.
But Chimera is doing a lot of unusual things. It seems nice, but kind of experimental.
I would say more unconventional than experimental. The system is very well thought out and very stable (despite still being in beta). That said, there are a few bleeding edge items.
The memory allocator, mimalloc, performs well but is a bit memory hungry. Version 3, which claims to improve things, is in beta and not yet used in Chimera. Chimera uses Alpine Package Keeper (apk) version 3 which is unreleased on Alpine itself. Apk is rock solid though. I am such a huge fan of apk now. And the “systemd replacement” which is dinit + turnstile + seatd is a work in progress as turnstile is in its infancy. I believe turnstile is what will be needed for what GNOME / GDM needs in this article.
>”I believe turnstile is what will be needed for what GNOME / GDM needs in this article.”
Well then, there you have it – Gnome still isn’t a huge problem even for Chimera, who has a wise developer who has been planning ahead. That being said, I still just don’t believe that using Gnome is an important issue for nearly any of the folks who are concerned enough about init freedom to be using Devuan or antiX or other more popular non-systemd distros. I can’t think of any of them that use it, and I can’t think of any reason they would want to use it. Usually when a person is trying to avoid the big corporate-backed systemd structure, they are also not interested in the corporate-backed strange UI paradigm that Gnome has turned itself into.
Usually the opposite happens, such as non-systemd users abandoning systemd’s elogind and using things like seatd instead, or abandoning systemd’s udev for Alpine’s eudev or for Jude C. Nelson’s vdev, making it even harder to be compatible with Gnome.
GNOME is indeed the “default” DE on Chimera Linux. It is what the founder and lead developer uses. I used it very early on buy I use Plasma 6 myself.
It really gives credence to all the predictions about systemd turning linux into an increasingly monolithic system with tight coupling of components creating more headwinds for untangling and customizing linux. Some people don’t care about interchangeability or the fate of alternatives, but for others it’s disappointing to witness these kinds of power plays taking over linux. I’m not a fan of it.
As a BSD fan, I’m here for it. 🙂 Become base. Let it ripple through the OS. Feel its power! LOL
@Alfman,
Although I am not a big fan of systemd either (always have preferred OpenRC) I feel like this is a difficult discussion without clear sides:
– SystemD just works for 99% of the users and stays out of my way
– obviously the Gnome developers like it and want to leverage on it
– the BSD folks have access to all the code and are free to adopt and or writing compatibility layers or adapters
– the BSD folks have not managed to attract enough user and corporate interest and funding to keep up (similar like the Mercural VCS has lost against GIT, very unfortunately)
So yes, I would welcome more independence, openness and interoperability too. But I also know that all of this comes at a cost and effort which obviously nobody is willing to take on.
I can’t blame that on SystemD or Gnome since I don’t even know any better solution.
Andreas Reichel,
I think that the cost and effort of de-tangling systemd, are a direct result of systemd being designed that way. We can and should fault it for that. Most init system alternatives are cleaner and don’t suffer from this type of pressure. Alas linux is going with the solution that forces you to use it the most, which is the way it goes. Alternatives are getting weakened, I hope they don’t die out. I predict this isn’t going to stop: going forward more system components not tethered to systemd are going to loose out to those that are. It’s not going to have anything to do with merit, being tethered to systemd is going to bring it to the forefront.
@Alfman,
I agree with you and I found OpenRC the better solution. I also found Mercurial the better solution. Unfortunately SystemD and GIT have won and seem to have hit the markets demand just better. I do not really know why but I clearly see it every day.
SystemD was heavily sponsored by RedHat, a company that is interested in selling Linux SLAs. Why on earth should they care about BSD? Why can’t BSD people attract enough investment and interest to care about BSD?
Don’t get me wrong: I see the problems and I share your wishlist. But I do not have any feasible idea how to improve the situation realistically.
Andreas Reichel ,
I was a mercurial user too. I stopped using it because everyone else uses git and I didn’t want to paddle up stream.
Sometimes I think consolidation and monocultures are inevitable. Markets tend to consolidate around the players at the top. Having a balance between parties, though idealistic, isn’t stable. The feedback loops reward those at the top for being more popular.
@Alfman
> Some people don’t care about interchangeability or the fate of alternatives
> I’m not a fan of it.
I care very much about interchangeability and the viability of alternative implementations. I am ok with GNOME requiring a service manager. What bothers me is if GNOME insists that it must be systemd. It goes deeper than that though as systemd itself resists working with anything other than glibc and glibc itself does not care if it compiles using anything other than GCC. They only care about compatibility with themselves.
Obviously I am biased as my distro does not use gcc, glibc, or systemd. But wanting a less bloated, more modular system is what led me here to begin with.
I know you are a happy Xorg user and this is not meant to recruit anybody but one of the reasons I am ok with Wayland is that it seems like the smaller, more modular solution to me. Xorg is mature but it feels like Systemd in that it is the universal monolithic solution that we are all expected to adopt all or nothing. On Wayland, instead of just the single Xorg display server, you have smithay, wlroots, louvre, libmutter, swc, and kwin to choose from. When you look at a project like Niri (a scrolling / tiling compositor), you can see this modularity and re-use. Niri relies on Smithay (server), xdg_desktop_portal_gnome (portal support), Satellite (Xwayland), and Waypipe (network transparency). Any of these can be swapped out.
As a thought experiment, I imagine that systemd had been around for decades and then dinit appeared. In my mind, there would be “dinit breaks everything” articles using examples like how it lacks per session service management required by GDM / GNOME. Users would be frustrated until turnstile matured to work with dinit and seatd. Perhaps I am the only one that sees this this way.
Xorg has become more modular over time, ditching its own drivers for direct rendering, kernel mode setting, mesa, and libinput. Wayland reuses all of those. This makes it easier for Wayland and Xorg to co-exist. Of course, DRI and KMS are examples of the “Linux platform” evolving away from BSD and BSD having to chase compatibility (what we are complaining about here).
> and lest anyone forget, that’s entirely within their right to do.
Maybe so, but that also means that devs from other projects are more likely to exercise that same right, with the gnome team at the receiving end.
Oh nice. I’ve been saying systemd is a great desktop init. Gnome plus systemd is a good pair, and I’m glad their integrating the two more. systemd user services, in particular, is an improvement.
good at what? Phoronix has lots of data saying that neither gnome nor systemd is very good in comparison to the alternatives.
Being a DE and system init.
Where is this data coming from, the Phoronix forums? Don’t take the forums as any source of truth. They’re called the Moronix forums for a reason. Every once in a while there are some quality posts, but most posts there are garbage. LOL
I like Gnome 3 and couldn’t stand Gnome 2. Gnome 2 rubbed me the wrong way for some reason, and Xfce was my preferred DE.
Systemd is a mixed bag. I would have made different decision, especially in regards to servers, but it works well as a desktop init. The decisions make much more sense there. Running a message bus between all the application a person is running and using it to control the system was the correct call for a desktop.
Aren’t Gnome developers IBM developers these days?
Being disabled [one usable hand], I have little choice but to use XFCE, as most other, if not all, Desktop Environments do not support Accessibility [ie Sticky Keys] in any useful way. So, GNOME+systemd is not an option. I look forward to find out how Wayland supports Accessibility.
While the systemd cancer continues to extend its metastasis TDE confirms to be the only decent DE for *nix.
No wayland, straightforward to use w/o systemd, and no features removed.
Gnome was useless when it was at the alpha stage but became completely out of control when decided to macos, and decided that their users had the same IQ as the average iDiot.
I want to BSDs to remain Wayland-free, systemd-free, Flatpak-free and soon also GNOME-free. No need to eat everything that IBM serves.
Perhaps it is time to abandon GNOME completely.
I did that in 1999 or so, albeit initially I hoed that they sooner or later evolved enough to be a viable KDE alternative,
Not only it didn’t happen, they made Gnome dumber on each release.
What a waste of coding time…
I agree, i liked gnome2, gnome3 looked awful and i never liked the workflow or the performance. GNOME always perform worse than all other DE’s in games ever since gnome3 was released.