In late June 2024 I got asked to take over the work started by Jerry Wu creating a systemd-sysupdate plugin for Software. The goal was to allow Software to update sysupdate targets, such as base system images or system extension images, all while respecting the user’s preferences such as whether to download updates on metered connections. To do so, the plugin communicates with the systemd-sysupdated daemon via its org.freedesktop.sysupdate1 D-Bus interface.
I didn’t know many of the things required to complete this project and it’s been a lot to chew in one bite for me, hence how long it took to complete.
↫ Adrien Plazas
This new plugin was one of the final pieces of moving GNOME OS – which we talked about before – from OSTree to sysupdate, which in turn is part of GNOME OS’ effort to have a fully trusted boot sequence. While I’m not sure GNOME OS is something that will find a lot of uptake among the kind of people that read OSNews, I think it’s a hugely important effort to create a no-nonsense, easy-to-use Linux system for normal people to embrace. The Steam Deck employs similar implementations, and it’s easy to see why.
Many of us have long said that systemd is a parasitic OS that will someday finish eating its host and assume complete control over all aspects of the system. That was the intention from the beginning. “GnomeOS” is really a misbranding of this fully formed SystemdOS.
No surprise that this final phase began after Poettering took up residence at Microsoft. I would imagine that MS’s ultimate goal is to make future versions of Windows be a completely proprietary SystemdOS with an NT kernel, while at the same time killing off the ability to maintain any non-systemd GNU/Linux distro.
I also wish it would stick to being an init system and not grow tentacles into the heart of everything. One of the things I like & appreciate most about unix is the “keep it simple, stupid” philosophy. Simple tools that go together in clever ways is one of the great contributions unix brought us. Yet I feel like systemd’s kitchen sink approach tarnishes this aspect of unix. Look at what’s been done to log files, now we need systemd specific commands to access binary files. For better or worse, this tight systemd coupling is making linux work more like windows.
This is why I keep coming back to Void Linux no matter how many improvements are made in the bigger distros that use systemd. I prefer simplicity over complexity, and systemd is anything but simple. I do like certain parts of systemd, but it’s a kitchen sink approach and I don’t want to be forced into all of systemd just for the few parts that are nice.
Void with runit is my idea of how a Linux operating system should be: Lean, efficient, simple, powerful, and understandable by mere mortals like me.
There are some horrible realities. Reason why Systemd is designed to absorb stuff has nothing todo with Microsoft. Comes from a Fedora audit where they found to their shock horror that many upstream projects were suffering from the bus factor problem. Even worse many where missing their maintainers and no body had noticed.
Systemd is not NT compatible.. andyprough remember WSL1 failure. WSL1 Microsoft attempts to put Linux syscalls and operations on top of NT kernel design. That right it does not work you run into solid issues where the Linux Design and the NT design are without question 100 percent incompatible.
https://learn.microsoft.com/en-us/windows/wsl/compare-versions
Yes the one thing that WSL1 never could get to work is systemd and Microsoft documents that. Yes WSL2 that running a real Linux kernel in a hyper-v hypervisor is because of the incompatibility.
We have seen Microsoft make hyper-v support Linux has host OS for there cloud based services.
Please note the incompatibility looks one directional. Linux kernel has many cases in history of running Windows NT designed drivers and the wine project.
Yes the future version of Windows by what Microsoft does in the cloud with hyper-v running on host Linux with many Windows VM under sounds very different right. Yes possible future version of windows in fact be a Linux distribution with closed source virtual machines for compatibility. Remember Windows 7 having Windows XP virtual machines for legacy compatibility so this is not even out side of prior precedent.
Yes TPM being pushed by Microsoft could be so end users cannot be altering their provide Linux OS and still use the Microsoft provided VMs. Basically make Linux open source behind a look but don’t touch shield is a higher probability than systemd on Windows NT style kernel .
>” Even worse many where missing their maintainers and no body had noticed.”
This appears to be a big problem inside the Fedora project – orphaned packages. One good reason to avoid anything that’s under the purview of Fedora/IBM/RedHat.
>” Yes possible future version of windows in fact be a Linux distribution with closed source virtual machines for compatibility. ,,, Basically make Linux open source behind a look but don’t touch shield is a higher probability than systemd on Windows NT style kernel ”
Yes, use hypervisor virtualization for all the legacy support, I could see MS doing that. Very interesting insights @oaiohm. Nice to see your writing this morning, I’m used to reading things from you on the antiX forum.
–This appears to be a big problem inside the Fedora project – orphaned packages. One good reason to avoid anything that’s under the purview of Fedora/IBM/RedHat.—
One of the big ones at the start of systemd was sysvinit at gnu.org had been missing maintainer at gnu.org for 2 and half years and no body noticed. Udevd before systemd has been left upstream maintainless for 8 months and the list goes on. All the early items that got pulled into systemd all had issue of being left without upstream maintainer/developer for at least some time frame without being noticed.. Yes this was the projects fedora was importing from being unmaintained not the package made for fedora unmaintained.
Yes there is a lot of orphaned packages with Fedora. But there is a very big issue with core projects that tones people depend on being left without upstream maintainers and developers.
Systemd absorbing projects is an attempted fix to a problem. Yes the bus factor problem with open source projects is not fixed.
We do need to understand what caused Systemd early behavior. and that we have not in fact solved that problem we still have massive used bits of software end up with nobody developing/maintaining them. Some of this is a open source developer funding problem.
So the real reason for SystemD (and Wayland) is:
“OMG! This working, stable piece of software has no maintainer! We’d better fix things so that it’s no longer stable! OMG!”