Recently, GNOME announced stronger dependencies on systemd. Mainly userdb and gnome-session.
I’m looking into porting gnome-session to the GNU Shepherd for the Guix System. However, apart from one vague paragraph in the blog post, there is not a lot of guidance available to me. Not even a contact link!
I would like to collaborate with the upstream GNOME contributors on this, and also with the other distros that will have very similar goals as me.
I understand that GNOME wants to rely on stable interfaces instead of old hacky code, but this doesn’t have to be dropping a huge part of the user base! I’m ready to develop and maintain alternatives, but collaboration is key.
Could it be possible to setup a discussion channel, and maybe a guide for non-systemd distros?
Again, I really want to collaborate to bring a nice experience to our users instead of having to come up with hacky solutions on my own.
Have you tried contacting the author of the blog post—who is also a member of the GNOME release team?
I don’t think “a huge part of the user base” is actually running a non-systemd-based distribution, in 2025. You’re, of course, welcome to bring data supporting your statement.
If you want to implement an interface provided by a systemd component, my suggestion is to read the systemd code, and/or ask the systemd authors as well.
I don’t know how Shepherd works, so I can’t really give specific advice. However, you’ll need to replace the following with a Shepherd integration:
the systemd user service unit files. These are spread across all the different packages: localsearch, gnome-settings-daemon, gnome-disk-utility, and of course gnome-session itself
leader-main.c, which currently does some basic environment setup and then asks systemd to start gnome-session-${XDG_SESSION_TYPE}@${SESSION}.target and then handles session shutdown (SIGTERM → tell systemd to stop the service, services stop → quit the leader)
tools/gnome-session-ctl, which is called by various systemd checkpoints to communicate to the service and the leader when things happen
As for userdb, reach out on the systemd mailing list with questions. I’ll be happy to assist there
The Shepherd is great, since it can run as a standalone user daemon. It’s written in Guile, so it can easily be interfaced in C code.
I realized I was rude in my first message, I’m sorry! Thank you so much for being willing to help and your work on gnome-session, it means a lot!
I will be starting the hacking next week, so expect some good activity
Since the Shepherd can run standalone just for gnome-session, do you think it would make sense for me to replace/adapt the builtin startup with a Shepherd one? Of course, I’m willing to maintain it forwards in time.
Void linux, Gentoo, Guix, Artix, Alpine. There are a lot of non systemd distros! Not all of the users will use GNOME of course, but even if its 0.1% of all GNOME users, I still think its a huge part. Because GNOME is for everyone, after all
Since the Shepherd can run standalone just for gnome-session, do you think it would make sense for me to replace/adapt the builtin startup with a Shepherd one? Of course, I’m willing to maintain it forwards in time
It makes sense to do this if your distro is using the Shepherd as its init system and you’re packaging it anyway. As far as I know GUIX is the only one doing this.
Anyway, you can’t really “replace” or “adapt” the builtin startup. Really all that there is to do is remove it completely, then re-implement it. But at that point, I’d rather just stop at removing it, and then leave it be. Put the service management where it belongs: in your system’s service manager. On most systems that’d be systemd --user, and on GUIX that’d be the Shepherd.
In other words: there’s really no need for any service manager to be built into gnome-session.
The Shepherd can run as an init system, but for user services another one is started. Completely standalone!
You’re right, I can see that now that I’ve looked more into the code. I think I will end up with mostly a collection of shepherd services and the replacement for the leader process. I guess I was wondering if the Shepherd leader could be upstreamed, but we can discuss it once I have a cool working fork!
I was wondering if the Shepherd leader could be upstreamed
I would rather not have all the different init systems’ leader processes upstreamed, sorry. If I upstream Shepherd, I’ll have to upstream all the other init systems. And if I upstream the leader, then I’d have to upstream the configuration files as well. That turns into a mess very quickly.
If there are other distros using Shepherd and you’d like to share this configuration between them, you’d also probably want to share the service definitions. Thus, the Shepherd leader + the Shepherd service definitions would belong together in a gnome-session-shepherd package that’s shared somewhere between Shepherd-using distros.
If there’s something you’d like me to do to make the leader smaller (and thus easier to implement), I’d be happy to consider it.
For instance, right now I’m thinking of splitting the leader between the “set environment variables and re-exec in a login shell” part and “talk to systemd” parts. The leader would simply exec from one to the other. Then, theoretically, it’d be possible to make a gnome-session subpackage where the systemd leader (and systemd unit files) are pulled out (call it gnome-session-systemd), conflict it with whatever other init systems’ packages (gnome-session-openrc or the aforementioned gnome-session-shepherd). This would reduce the pain for distros like Gentoo where the user can select their init system, at least.
Also, I want to make it clear that my goals is to make the gnome-session-shepherd usable with any linux distro, no matter the init system. Shepherd is used as a services manager in this case in a separate process.
Sounds like a great idea!
My main worry right now is how I can keep up with the services’ updates if they are in many projects. It would be nice to have a centralized list or something else where I can easily keep up.
Hi everyone! I have a good update for today, my implementation of GNOME session on the shepherd (gnome-session-shepherd) can now successfully boot on Guix!
Adrian, I ended up making a leader to Guile scheme that starts a Shepherd instance for the user, and a collection of shepherd services that act like the systemd services.
Spectacular! Thanks for validating that this works and is possible!
I’ve still yet to separate the session worker between the generic environment handling part and the systemd-specific part. I’m planning on doing that still, if it’s useful to you. Is it useful?
By session worker, do you mean leader-main.c? I’ve made my own version of it in scheme so it wouldn’t impact me, but if you want to have a shared leader and make it easy for me to plug in my initialisation code at the end then I can go back to it!
I have been using Linux as my main OS (also at work if it is possible) for nearly 30 years. I was a Debian Linux user, but a few years ago, I changed to Artix Linux and installed and configured my system by typing commands: “the hard way.” Perhaps I’m becoming too old, but I left my loved Debian because I thought it was becoming too complicated to manage, and I prefer simplicity. My desktop environment was GNOME. As far as I remember, I started to use GNOME about the year 2000. I also adopted GNOME 3, although it was a complete change, and I hate JavaScript. But this is a subjective little detail. I also didn’t understand GNOME 4x numeration. As I said, I must be terribly old. But I decided not to pay attention to names.
I’m grateful to the GNOME Team because of their beautiful desktop.
However, GNOME 49 news is terrible. I’m very, very sad. But, finally, I have left GNOME and chosen KDE which is the default Desktop Environment on Artix Linux.
Do you remember your origins? GIMP is still systemd free. I think you would have kept GNOME KISS.
It’s a pity. Thank you for those wonderful 25 years.
Yes, it is the GNU Image Manipulation Program, which was developed by two students at the University of California in 1995. They developed GTK at the same time because they were reluctant to use Motif due to potential copyright issues. GNOME adopted GTK in 1997 to avoid the restrictive licence of Qt at that time.
Thanks to GTK, GIMP and GNOME evolved wonderfully.
What forbids GIMP from using systemd? Nothing. GIMP can use systemd for timers, to detect cameras, and to register errors. However, it is not a good idea if you want to keep it simple and develop multiplatform software.
What forces GNOME to use systemd? Nothing.
I think it’s a matter of personal preference. It’s not easy to know what the best approach is. I prefer a modular system to a monolithic one. I don’t like systemd. That’s all.
The GNOME Team certainly know what they are doing. I think it’s a waste of time to discuss which is better because both have their pros and cons.
Every distro (that actually matters) adopted systemd. Why? Because it actually works and doesn’t rely on dirty hacks. It’s kinda crazy that in 2025 some people are still on holy wars against systemd. Nothing even forbids you from just using systemd init system. People use all of them because they work.
It’s hilarious people saw one of the most uncontroversial changes ever - systemd and wayland and lost their minds over it.
