So, Red Hat project GNOME relies on Red Hat project systemd, and Red Hat employees won't allow systemd to be portable to competing platforms. Convenient.
You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk.
As far as I know, Gnome does currently have fallbacks (with reduced functionality) on non-systemd systems, so it's not the case that they just ignore things. However, I perfectly understand why they would not bother with duplicating code just to support systems that aren't good enough.
EDIT: I'm apparently not able to respond to the reply below me for whatever reason, but... It's been said many times that making systemd portable makes no sense, which is why it provides interfaces. And regarding the interfaces, which part of them, exactly, are not stable? There's a very reasonable interface stability promise, which to my knowledge has held, so far.
> You can of course make the case that the interfaces provided by systemd are substandard, but so long as you don't have an alternative to offer, it's just talk.
The problem isn't that the interfaces are particularly bad, it's that they're not standardized. If systemd would offer standardized interfaces that let me offer a compatible alternative that would be fine. But they don't. Trying to remain compatible with software that will make no effort to provide compatibility from its side is a mug's game.
"That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces. For a few one might find replacements on other kernels, some features one might want to turn off, but for most this is nor really possible. Here's a small, very incomprehensive list: cgroups, fanotify, umount2(), /proc/self/mountinfo (including notification), /dev/swaps (same), udev, netlink, the structure of /sys, /proc/$PID/comm, /proc/$PID/cmdline, /proc/$PID/loginuid, /proc/$PID/stat, /proc/$PID/session, /proc/$PID/exe, /proc/$PID/fd, tmpfs, devtmpfs, capabilities, namespaces of all kinds, various prctl()s, numerous ioctls, the mount() system call and its semantics, selinux, audit, inotify, statfs, O_DIRECTORY, O_NOATIME, /proc/$PID/root, waitid(), SCM_CREDENTIALS, SCM_RIGHTS, mkostemp(), /dev/input, ..."
It's not just cgroups.
"uselessd is planned to work as a primitive stage 2 init (process manager) on FreeBSD. Stage 1 is inherently unportable requires a total overhaul in regards to low-level system logic (with systemd assuming lots of mount points and virtual file systems that aren’t present, is designed with an initramfs in mind and many other things). Stage 3 can always be achieved by having a sloppy shim around the standard tools like shutdown, halt, poweroff, etc.
So far, uselessd compiles on BSD libc with a kiloton of warnings, with lots of gaps and comments in the code, and macros/substitutions in other places. All in all, it is an eldritch abomination. A slightly patched version of Canonical’s systemd-shim is provided and works well enough to emulate the org.freedesktop.systemd1 D-Bus interface. Some of the binaries provide diagnostic information, but at present we are trying to find ways to bring up the Manager interface in the whole buggy affair, in order for systemctl to send method calls. Nonetheless, you are absolutely welcome and encouraged to play around with it in its present state, and we hope to get somewhere eventually."
I could write patches that reimplement the functionality that Gnome gets from systemd using lower-level functionality, in a cross-platform way. But those patches would be rejected; the Gnome project has decided to use systemd and would not want to duplicate its code. If I were to maintain my own gnome fork I would have to convince distributions to adopt it.
I could write patches that add FreeBSD support to systemd. But those patches would be rejected - again, as a policy decision, systemd doesn't want to support FreeBSD. Thankfully in this case there is a fork, uselessd, but again, we need to convince distributions to adopt it or it's meaningless.
The claim that Gnome "independently" relies on systemd is specious; there was a lot of lobbying and politics from the systemd side. My only practical option is to counter at the same level, and lobby Gnome (and linux distributions) to make the political decision to move away from systemd.