Flatpak will depend on systemd
41 points by stilic
41 points by stilic
It's frustrating how the whole thing was started by not even flatpak developer through a misinformation, triggered an emotional response and fueled even more by bold statements as the original thread was going while everyone was piling on repution of flatpak project and developers, which in turn affected emotionally actual flatpak developers to the point where they would like to disassociate with the angry mob (not surprising).
My plea for everyone would be to calm down, stop amplifying this, if you have doubts or concerns, talk to (actual) maintainers, show support to them, that you want to reach a middle ground, show that this is an isolated incident of particular individuals that doesn't represent whole community, even the niche ones such as those not based on the systemd project.
Just like the whole idea of depending on systemd wasn't set in stone and was just that, an idea - the same way hopefully maintainers can still reconsider supporting more diverse projects (though IMO that's still not off the table).
maintainers can still reconsider supporting more
I think a generous paid support contract would go a long way towards convincing them to support niche systems.
I hope people can get along well enough to still support systems that don't run on systemd. Flatpak and other container approaches do help users run packages that are not readily built on a target platform, it's nice to run Flatpak on top of such a system when the need to run a specific piece of software comes up.
Containers do this too, but it is annoyingly tricky to get e.g. x11docker behaving with a sufficiently weird setup.
I've been a happy void user for over a decade now. I don't remember the last time I had to worry about init systems or systemd integrations. Thank you for all the work on void, it's greatly appreciated.
As someone who runs Void on his laptop, I find the distro efficient to work with and pretty well documented. I'm grateful for all the work the devs had done and can only hope that the Flatpak evolution won't be too much trouble.
I do not understand, why do people hate systemd so much? IMHO it provides a very useful set of features through an easy to work with API and a sane system for dependency and conflict management.
I really do not understand, all the people who don't like systemd just give vague and nebulous reasons about how its not unixy or it's centralized or the systemd-journald file format is not plain text or something similar.
I encourage systemd opposers to actually give concrete reasons and also concrete solutions to those problems and why $INIT_SYSTEM is a better choice and I will tell you why rc scripts are a terrible horrible hacky messy idea and why they should never be used.
A lot of the opposition in the mastodon arguments linked aren't inherently anti-systemd but anti-centralisation - Flatpak moving to depend on systemd means Linuxen that depend on other init systems lose access to flatpaks. The philosophy of Linux has always been (at least to me) fundamentally about choice, and Flatpak necessitating some init system does reduce the choices the user can make in configuring their system if they want xyz result.
It has been… about the wrong kind of choice, by far. The prioritization of endless choice between unimportant nerdy details has been, ironically, obstructing progress towards making Linux itself a viable choice for most people versus proprietary OSes.
Perhaps worth noting that Linux/*nix represent 70-95%+ of server OSs, vs 2-4% of desktop usage. "Endless choice" matters when Linux is containerized or virtualized, or running on an embedded system.
Linux is more than just a "viable choice" instead of proprietary OSs for desktop end-users.
I'll drop this article about how deeper systemd support assumption/integration is forcing Alpine to build compatibility shims everywhere. They've had to do it for glibc/musl already, so not necessarily an insurmountable maintenance burden, but worth noting.
Also, as a maintainer of code that will run in wider *nix contexts, OpenRC is closer to rc.d than systemd.
Linux, over the last 10 years, has not been "prioritizing endless choice". They've been deliberately centralizing around certain init systems & system interfaces because that reduces maintenance burden/allows deeper integrations. That coupling offers both advantages and costs for largely disparate group of users.
I'll drop this article about how deeper systemd support assumption/integration is forcing Alpine to build compatibility shims everywhere. They've had to do it for glibc/musl already, so not necessarily an insurmountable maintenance burden, but worth noting.
FYI that article you linked is entirely AI-generated. There is no primary source for its core claims, none that I could find. The site is also banned on lobste.rs for the same reason.
systemd was a a "gift" for people running alternative desktop systems. Previously, many services were bundled with GNOME and you had to go through many hops to use them on a non-GNOME desktop (for example, GNOME Power Manager). systemd replaced many of these GNOME-only piece of software that were constantly breaking when you tried to use them outside of GNOME. Alternative desktop environments didn't need to write their own version of system-related tools.
So, while this may be seen as centralization, I don't think we would have seen so many desktop environments without systemd. In the past (15+ years), systems were simpler and there was not many things to abstract.
That's gift in German, right?
The number of desktop environments I've seen has gone down in the last 25 years of using Unix, not up.
Systemd does not come with a power manager.
Nor does it really come with any other desktop environment related tool?
logind handles some of the tasks, like sleeping when idle, sleeping when closing the lid, preventing sleep if you are watching a video. It was an example. Another example is the udev integration granting you access to your local devices without putting yourselves in many groups. Since it mostly works without any special configuration, this is now a bit invisible.
I thought you mean battery management and power profile management.
This could have been handled with new APIs which didn't integrate so deeply with the rest.
The udev integration is seat management. And honestly not something that should be so deeply integrated with everything else.
Everything could have been different but until systemd took over this, each desktop environment was reimplementing it. We'll never know what would have happened if there was no systemd. For me, nothing.
Flatpak moving to depend on systemd means Linuxen that depend on other init systems lose access to flatpaks
Then such Linuxen should start depending on systemd.
I really do not know what else to say. What reasons are even there to use any other init system apart from like,,,, toy or experimental systems?
The philosophy of Linux has always been (at least to me) fundamentally about choice
Yes but also apps targeting just plain linux also depend on arbitrary things just being there like, for example: sysV shm and sysV semaphores. Yet I don't see anyone complaining about how pervasive sysV is >:(
sometimes forgoing choice in lieu of standardisation is a good thing
What reasons are even there to use any other init system apart from like,,,, toy or experimental systems?
The "what reasons are there to even use other operating systems" argument.
Yeah you got me I will punish myself appropriately for this.
Pray tell though, do you have any reasons to use any other init system?
systemd doesn't work outside of Linux, broadly a dependency on systemd is a dependency on Linux, from a software development side, I don't like artificially restricting my support matrix (even if I don't plan to actively test for support) to just Linux.
From the user side, troubleshooting systemd is certainly not nightmarish, but the front-loaded enterprise grade complexity makes it harder than it needs to be. The declarative syntax and the defaults often mean that I have to maintain a lot of patches over service files to get things working reliably (try having sshd listen on a specific IP address on a stock archlinux system, ponder afterwards why you can no longer log in after a reboot).
This is not to say that the declarative syntax is bad, but rather that it's always incomplete, which is why basically all nontrivial daemons have a shell script running in ExecStartPre.
Some parts of scripts are hard coded, it's true that most people don't need to change them, but at this point most people use systemd to either launch gnome or kubelet.service depending on whether they are on a desktop or on a server. I am not most people. To change these parts I would need to recompile systemd, which is annoying. On my system I can change these things by modifying a shell script, modifying a config file, or writing or recompiling a small component.
And then to achieve certain things, programmatically, I end up needing to deal with systemd's weakly documented and expansive APIs. That go over DBus.
In short:
Lastly, I think it's strictly a mistake to have such a deeply integrated component that lots of things depend on. If we do ever want to replace it for any reason, it will be harder than replacing Linux init scripts.
The declarative syntax and the defaults often mean that I have to maintain a lot of patches over service files to get things working reliably (try having sshd listen on a specific IP address on a stock archlinux system, ponder afterwards why you can no longer log in after a reboot).
I don't understand both concerns
One part of this is overriding services, that's built in per systemctl edit sshd.service. If you don't specify --full, you will get an override file instead.
Typically applications that are made around changing things like launch flags will offer you an environment or config file instead. Tailscaled for example has a $FLAGS env var that you edit using /etc/default/tailscaled
That certain applications aren't easily modifiable isn't a fault of the service manager, that's something you need to figure out with your app dev / packager / package manager!
I'm on Arch, and listening to a specific IP is just adding ListenAddress 192.168.178.27 to sshd's config, then restarting sshd.service.
I don't think sysd changes anything here besides some conveniences like sshdgenkeys.service starting before sshd to ensure the server has a key before booting up.
Some parts of scripts are hard coded, it's true that most people don't need to change them, but at this point most people use systemd to either launch gnome or kubelet.service depending on whether they are on a desktop or on a server.
Any given system will run a bunch of critical daemons like journal, bluetooth, networking and let's not start with what happens when you go down to the user level (systemctl --user will tell you, but the answer is very flavorful on Plasma). The service manager is doing its job managing these, I don't think it's a huge help to throw these into scripts / let the DE manage these.
I agree on DBus though, but I think the problems with DBus have been chewed through in writing already. systemd hasn't documented them but they do also offer more Varlink APIs nowadays if you prefer communicating with JSON objects.
I think you're looking for NixOS honestly (though admittedly I haven't used it)
I don't like artificially restricting my support matrix
Sorry, just for my understanding, it sounds like you’re saying that you don’t like the fact that the maintainers of free software don’t want to support niche platforms? And you haven’t considered getting a paid support contract with them?
I interpreted it as, "as a developer, I won't actively test on non-Linux, but I don't want to intentionally introduce a dependency that will guarantee it can't run on non-Linux."
Which, since I prefer BSDs for server duty, I appreciate.
Maintainers would really appreciate a paid support contract in exchange for supporting niche platforms, but we don’t live in an ideal world.
Mind you I don't dislike systemd, but here are my reasons to prefer other inits:
On my laptop: runit boots faster; on Void, the boot font is readable on my laptop whereas its unreadbly tiny on Debian and other systemd-based systems I've used; I can remove the ugly boot colors, tweak boot messages, all without running my own fork; service scripts are almost always just #!/bin/sh\nexec X, I reuse the same posix knowledge I already know.
On my server: I have a custom user space written in Go, and a small init called nitro for booting the system. The entire system (ignoring the application it runs) is statically compiled and around 8000 lines of code. I don't have any rc-scripts, I just drop static binaries as /{service}/run and nitro handles the rest. The full system has a Linux kernel + 2 config files + 5 static binaries. I like that the full source code is small enough that a person can reasonably read and understand it. Compiling and bootstrapping the system is relatively simple too, I think systemd would have ballooned the complexity.
OOOOOOOOOOoooooooooooooooooOOOOOOOOOOOOOO I cannot even imagine the amount of effort that took to set up. It sounds so interesting
Other operating systems than what? Do you really need me to enumerate reasons to use another operating system than Windows? macOS?
No?
I was just pointing out that the argument is flawed on principle. There was a time that Linux was strictly inferior to all other options, but people still used it because they preferred it for whatever personal reason. An argument in favour of systemd should not rely on it being less painful to use anything else.
What reasons are even there to use any other init system apart from like,,,, toy or experimental systems?
I'm a keen systemd user (and have a trivial contribution), and thinks there's lots of value in toy/experimental approaches. This is a part of how innovation works.
As an example, I like the idea of capability-based security, and so am excited to see inits based on that idea: https://nlnet.nl/project/DistributedShepherd/ and https://spritely.institute/news/shepherd-goblins-update.html
I am open to trying to such init/service layers, and would like to use those with systemd-journald and systemd-networkd. But my understanding is that these are dependent on systemd. Perhaps shims could be written, but if the projects don't expose a stable/defined API, it's a risky dependency.
The systemd project are doing a great job at modernising Linux distributions, and they are of course free to develop great projects like systemd-networkd that depends on systemd, but every time it happens, I fear it's one more hurdle that someone will have to surpass when developing whatever will succeed systemd.
sometimes forgoing choice in lieu of standardisation is a good thing
Yes, when there is a well documented, unchanging standard that many implementers can adopt across many posix-like operating systems, that is be a good thing. I'm not aware of any standards like that coming out of systemd.
I’m not aware of any standards like that coming out of the Linux kernel either, and yet people seem to think that being able to use Linux is a good thing?
Much of the posix effort these days is exactly that. Beyond that, many Linux technologies like fuse, futex, OCI containers, etc are available across many actively maintained unix variants.
And now you're aware.
And yet Linux itself started as a project that didn't want to deliberately tie itself to POSIX, choosing to implement whatever made sense for them in their userspace instead of having to rigidly conform to someone else's standard. And that flexibility is what users loved and it's what propelled Linux into its current success. Its standardization efforts today are just a downstream effect of that.
From what I read, Linus wanted to tie Linux to Posix, but couldn't get a copy of the spec. Instead, he ended up using a minix version of glibc as the standard, so that he could get software that was written portably to run on his system.
A happy accident that ended up making Linux an innovative success instead of a stodgy relic.
What, because it followed a library that followed posix? What a strange thing to say.
It's not that strange if we take a look around and ask ourselves how many wildly successful operating systems today precisely follow the POSIX spec.
But they do follow posix, and you can get posix certified Linux distros from vendors that cared enough to pay for it.
Yes, vendors aka as long as you are willing to shell out the money for it. No one is giving out POSIX-compliant OSs for free. Standardization is expensive, and the people calling for it may not always be willing to pay for it.
Linux is conforming to the standard whether they're paying to get a stamp of approval or not. The vendors are just paying so that they can get in to some government procurement process selling the same stuff everyone else uses.
I'm not sure why you find the concept so confusing. Linux started conforming to the standard so that third party software would run on a niche hobbyist system without much commercial backing. The strategy has served them well.
linux does not conform to posix.
It's mostly following the std, but it deviates in several syscalls (specifically the edge cases/ atomicity guarantes etc).
It conforms well enough that there are linux distros that had posix certifications. I could be wrong, but I don't think it took an appreciable amount of patching.
I'm a happy systemd user but for something like flatpak in particular I can see why there's pushback. flatpak is inherently a "make stuff work on any Linux distro" kind of thing so this reduces its utility somewhat.
make stuff work on any Linux distro
Any linux distro as long as it has FUSE ¯\_(ツ)_/¯
Linux is holding to mechanism-not-policy and userland-stability well enough (and what tey do not consider «true userland», you need to handle if you use it at all) that requiring a Linux feature to be enabled is a significantly smaller constraint.
Here's my unedited gripes about sd:
– journald's implementation is meh (I don't mind the idea)
– job queueing -- the actual abstraction sd uses to manage units -- has weird corner cases that aren't documented. Or maybe they are but IDK where.
– it should be easier to put it in a container image
– users' sd should have read API access to system instance, at least to schedule units using After, Requires, and friends.
I still think it's the best thing that happened to linux since HAL removal, and shook Lennart's hand while thanking him for the project.
I agree notably with your last point. For example, executing something on sleep or resume is difficult with users' systemd.
Thank you for some real concrete critique of sd.
Most of it is probably mentioned in https://blog.darknedgy.net/technology/2015/10/11/0 Yet, until something better arrives, I'll keep using it. It's better than any competition.
and also concrete solutions
Unlike the people who actually do implement credible alternative stacks (such as Chimera) —who don't spread any FUD and are very friendly and humble— the online outrage mob explicitly does not and will not have any solutions.
What the "opposers" effectively argue for is for solutions not to exist at all. They are the Linux HOA, effectively doing reactionary politics by trying to obstruct progress towards an actually solid, usable, competitive system that could dethrone the technofascist-oligarch-controlled proprietary ones.
The comparison to HOA cuts deep. There are a lot of people in the Linux community who have found refuge and are now seeking to "protect" Linux (and... their way of life). All they actually do is pull up the ladder behind them. It's nowadays harder to ditch proprietary operating systems than it was ~10 years ago, because the requirements users have towards their OS became stricter (whether they know it or not) and some parts of Linux refuse to catch up.
Your competitor isn't Windows anymore, it's MacOS, Android and iOS. All of them have better permission systems for apps and all of them have appstores.
It's nowadays harder to ditch proprietary operating systems than it was ~10 years ago, because the requirements users have towards their OS became stricter (whether they know it or not) and some parts of Linux refuse to catch up.
This is very debatable. Witness the increase of Linux usage in Steam.
Also, some of the things that are locking in people into proprietary OSes are using technology in evil ways, like attestation preventing you from using certain software if you want to control your device.
This is very debatable. Witness the increase of Linux usage in Steam.
The means by which Steam succeeded on Linux was to support exactly one distro and let the community handle the rest. Do you see that as a role model for Flatpak?
I'm just arguing against your "nowadays harder to ditch proprietary operating systems", I do not know enough to pontificate about how to make Linux used by more people.
There is a difference between supporting one distro by maximally using all the things specific to it, and supporting one distro by using the widely shared basics and testing with the versions shipped by that distro. It looks like Steam is doing the latter; yeah, that's a fine role model.
"Linux" has had appstore since before the word was even coined?
No it doesn't, that's like comparing Dropbox to curlftpfs. Completely different user experience, different distribution model.
A big list of apps you can search and when you click one it installs and you can run it. Which part of the user experience is different?
which distro's GUI does that? I'm mainly familiar with the synaptic experience where searching for "email" gives you random stuff no end user is ever looking for.
Any distro that defaults to Gnome (so Debian, Fedora, RHEL and derivatives, Ubuntu... too many to enumerate). And most of them have FlatHub on by default, which might be a better sandbox.
Any distro that defaults to Gnome (so Debian, Fedora, RHEL and derivatives, Ubuntu... too many to enumerate).
which distro has an experience comparable to modern appstores like FlatHub when using its own package manager?
I'm not talking about Flatpak. I'm talking about this claim, which I interpret to be equivalent to "Linux package managers are basically appstores, before there were appstores":
"Linux" has had appstore since before the word was even coined?
Gnome Software on Debian, RHEL, Fedora (haven't checked others) does not differentiate much between native distro packages and FlatHub; when some software is available in both forms, you'll get a dropdown to choose between the two.
There are different solutions.
But everyone depending on systemd the way they do means any alternative solutions that can come later will have to inherit the architecture and warts of systemd.
Most people (like me) who have been sounding warning alarms are waiting for the next iteration of init. Personally I like the ideas of SMF (but without the XML); and I'd work on making that a reality, but it's a moving target and systemd's surface area requires that I'm bug compatible with that or I'll end up being just another BSD.
.. oh yeah, also, this dependency on SystemD sort of destroys opensolaris and the BSDs for compatibility. POSIX is no longer enough, you need libsystemd and libxz and so forth.
...only to become the new technofascist oligarchic regime in their stead.
How, exactly? What is this idea even based on?
The idea is based on my lived experience, you are free to reject it.
As to how, exactly -- it's not exactly hobbyist devs and independent tech cooperatives clamoring for more linux monoculture and centralization, but your usual suspects who love to See like a State ;)
"based on your lived experience" in the sense that... you were a victim of fascism enacted by systemd?
Interesting point, because the autocratic nature of the project and the fact that they don't take notes would directly lead in to the notion that: any time that systemd does something against your wish that it means you're being victimised.
"Nobody says you need to use systemd."
Unless you want to use a modern linux distro, or gnome, or krdp, or snap, or flatpak..
For me personally: I don't hate systemd! In fact I quite like it and use it on several of my systems.
But I also really like Guix, and the Shepherd init system it uses - when everything in Guix is extensible with Guile it's useful to have an init system that is too. And I also really like Flatpak, in part because it's helpful for running applications that aren't yet packaged in Guix. I hope I can continue to do so.
I do not hate systemd when exclusively used on systems which are predominantly intended to serve webpages or to display webpages via a GUI browser. I am fine hand-writing systemd units for stuff I deploy to my VPS (where I use whatever barebones Debian setup OVH provides with IP/DNS/etc. preconfigured, get most daemon binaries from Nixpkgs, and write scripts/units on top). Although if it still were SysV init or upstart instead, I would be just as fine with it.
What I want on my laptop, though, is different (and for the local buildbox I run the same setup because it is easier to prune the laptop setup).
I have ideas how I want my personal environment to function. I want conveniences normal Linux users apparently do not want, and I want some things not to happen without explicit request. While I often rethink these ideas, I get improvements from «there is a new bunch of functionality I could use now» or «I should use a different tool» or maybe even «I should write this script already» but approximately never from «the new version does the same thing differently and it's better». I am much more tolerant of «yeah, it's an effort to make it happen» than of «yeah, it's an effort to make it not happen».
What really annoyed me into abandoning NixOS because of systemdBasically, ever-growing scope with opinionated defaults made it a chore to maintain a fixed baseline of functionality if systemd is involved.
screen)At that point I snapped and decided that absolutely minimal init (currently sinit — I wouldn't want to ever talk to the upstream, but it also is a finished short pile of C so why would I want to talk to upstream anyway) and no service supervision at all is superior to that. So I wrote my own boot scripts in shell (well, somewhat templating them using Nix), eventually put some system-level functionality into shell code and some into Common Lisp code. Both shell implementations and Common Lisp implementations are good at stability. On a laptop, something like PostgreSQL once launched will keep running, and if it stops, I will notice, and if restart is enough, it will be trivial to do, and if restart is not enough, service supervisor won't be capable to help and it is not even its fault. PostgreSQL failing mid-flight is rarer than once-per-multiple-years multiple-major-version jumps, which are rarer than systemd scope creep creating new defaults I need to investigate to set to the state as it was before.
Nowadays I have some extra conveniences, like «I don't want to know how tmux and SSH interact with the notion of the local session, I want an option to authorise some stuff by real physical presence check» — which is implemented via grabbing a VT, which I do not want to learn to do systemd way — and, more annoyingly, then to update once in a couple dozen systemd releases.
I am not sure how my «nsjail a lot of things» tooling would interact with systemd; hopefully, not at all, but can I trust it (no, although that's a me-running-out-of-trust thing).
What makes me not trust systemd in terms of predictable code behaviourtail on text log (I'd say no worse than twice as slow, but OK maybe there are reasons). From reasonable software, I expect this operation to be within a single-digit-factor of running cat on the binary log files to /dev/null then running the operation on warm cache. journalctl did some random-read thing that took forever to get any lines of output at all. I do not know how long would it take on that HDD: it took 10 seconds to warm the cache and less than a second afterwards, I gave up waiting on cold-cache journalctl after a few minutes.nohup
Note that all my gripes are old. There is an obvious reason — once I observed that systemd solves some problems and creates others, and neither are the problems I have otherwise, I switched to writing shell scripts for boot and the amount of running-to-stay-in-place is now so low that why would I even try to run systemd on my laptop again, and on my VPS systemd is used close to the middle of Debian's comfort zone.
(There is some running-to-stay-in-place about nsjail, but I want to block things people normally want to enable by default, so there would be some maintenance in any case; with nsjail it fails-closed)
Did you really just say "everyone doesn't like systemd just gives a reason" as though having a good reason to dislike it discounts one's opinion automatically?
"This is modern linux, there's only systemd."
Stark reminder that the Linux community is less of a community and more of a WeWork, where everyone around you has a salary dependent on the existence of Redhat even if you're there hacking away on GNU readline for free
The article certainly wasn't wrong about these things...
drawing in the rabid anti-systemd Red Hat conspiracy lunatics (and worse)
I'm not a "Red Hat conspiracy lunatic". I like the services Red Hat provide to enterprise users that keep Linux viable in that enterprise space, especially during the 2000s and early 2010s. I use Systemd, somewhat happily. It's just an honest evaluation of the space.
Well, it's still odd that you keep mentioning Red Hat when none of the systemd core developers have been employed by Red Hat in years…
I honestly wouldn't know, it's just an example of one of the corporations driving Linux development. Maybe I should've used a hip young competitor as an example, like VA Linux Systems
I think Linux fully went over to the "this is the new standard Unix environment for enterprises" when RedHat IPO'd. IBM buying them a few years later just cemented that.
Let's not forget that famously, Linux is just a kernel. Linus went for the GNU userland for whatever reason (BSD too legally encumbered) and GNU was just a superset of POSIX + random add-ons from whatever Unix vendor was popular at any given time.
A system like systemd is a natural outgrowth of Linux running almost everywhere, and if you have 10s of thousands of servers, apparently init scripts don't cut it anymore.
What I find interesting is that the title is much more definitive than the article. A lot of the comments clearly are purely responding to the title(not all of them luckily). Something that's not new to the internet, but it worries me how often I see this happen on lobste.rs recently.
People responding to just titles, one sentence in a longer comment, etc, etc. Often with no allowance for any other interpretation than the (often combative) one they start out with.
Reading the article, something similar seems to have happened around the flatpak 2.0 discourse. It seems like they were trying to build in allowance for other init systems, but the discourse around that turned so hostile rather quickly that they basically gave up on it.
That's incredibly frustrating for those of us on alternative init systems. I run one of my laptops on Alpine Linux, and have been using flatpak to run software that only works with glibc. This is going to force me to move away from it.
I don't hate systemd—all my Gentoo systems are systemd based. I do dislike how it's making FOSS software increasingly dependent on GNU/Linux though.
I'm sure those who want Flatpak 2 work on their non-systemd setup will put work into it. Except the internet hate mob, of course.
Many things that supposedly rely on Systemd seem to work just fine on my Alpine box, so someone (presumably not a member of the internet hate mob, ofc) must be putting some effort in.
Exact. Gardenhouse and Chimera Linux comes to mind in terms of projects that reimplemented and ported systemd utils respectively.
That's a good thing, obviously.
systemd is made of dæmons with stable, well-defined APIs, so I'm confident that whatever parts of systemd it will come to depend on will be cleanly reimplementable from scratch, should someone decide to spend effort in that direction.
This is the best possible outcome: we get less fragmentation, and people with unusual requirements get a stable target for their reimplementation efforts.
systemd is made of dæmons with stable, well-defined APIs, so I'm confident that whatever parts of systemd it will come to depend on will be cleanly reimplementable from scratch, should someone decide to spend effort in that direction.
I started reading this thinking it was satire but no...
The APIs are often defined in man pages, and vaguely.
They're not bidirectionally stable, or versioned, as you are not expected to implement them from the systemd side.
I'm the case of the notify socket API they're actually even unidirectionally stable in the opposite direction. The addition of vsock support basically broke all daemons that didn't rely on libsystemd to implement it.
Why didn't you hear about this breakage? Because the vsock stuff was only really intended for systemd to systemd communication across a virtualization boundary. If this API was being designed sanely you would do this as an extension which is only used at that boundary.
Moreover, the "daemons" you talk about are basically just logind and systemd. The composability is limited by the fact that those two expose the entire API surface area. And they do so through a couple of dbus interferences, now also via varlink, and finally via a single library.
If I want to replace systemd, I either have to do so wholesale, either working hard to figure out how to translate whatever internal model I have to be exposed in a systemd way via their APIs, or I first have to spend a lot of time working to create an interlayer to disentangle systemd's API design choices and provide a pluggable backend so you can combine multiple different parts to implement the different things.
This is not a simple problem, but it could have been much simpler had the APIs been separable, stable, and well defined.
I've been working on precisely this problem for years, because while I think that many of the design principles behind systemd are sound, the design front loads complexity that most people don't need, and I can see a design which is more modular and interchangeable. It's relatively easy to come up with designs which are this modular, it's relatively easy to come up with (or in many cases, just re-use) designs for separable interfaces that are simple.
The problem you run into, though, is software which has chosen to depend on system's APIs. To make it work with anything else, you either need to:
All in all, I don't know if this was the intent, although if you read what systemd developers say, it was at the very least intentionally not a concern, but it's incredibly nontrivial to write a systemd replacement without a complex interlayer or just writing systemd again. You really can't just write a replacement for a piece of systemd, even if the application only depends on a part of the API which could be served by such an isolated piece.
whatever parts of systemd it will come to depend on will be cleanly reimplementable from scratch
Is that true now in practice? The article talks about elogind as an example.
There is also https://gitlab.gnome.org/noe/gnome-session-shepherd, which Guix uses to be able to run Gnome, after they added a dependency on systemd's userdb.
Is that true now in practice?
I am not aware of any counterexamples.
The article talks about elogind as an example.
As an example of what?
A counterexample I can think of is postmarketOS, which is a Linux distribution for phones/handhelds based on Alpine Linux. They're having to add systemd support downstream because KDE and/or Gnome decided that a hard dependency on systemd was a good idea. Which means those desktop environments are less usable on non-systemd systems like Alpine Linux, some Gentoo systems, and every BSD.
There's superd which is designed to provide some compatibility for systemd's service management under other init systems, but it's incomplete and probably will never be complete.
The scope and complexity of systemd is such that it can only really be managed by a large organization like Red Hat, which means if systemd is a hard dependency for the Linux desktop, they now control the whole ecosystem.
“The scope and complexity of systemd is such that it can only really be managed by a large organization like Red Hat, which means if systemd is a hard dependency for the Linux desktop, they now control the whole ecosystem.”
Can you explain what this means?
For the record, Lennart and other systemd folks haven’t been employed by Red Hat for years. Lennart and a few others recently kicked off a startup. The desktop isn’t a huge focus for them, I don’t believe.
Could you and maybe a couple of buddies make a replacement or some kind of compatibility shim for systemd so that programs that depend on it can be used in it's absence? Like, as an easy to medium scale project?
I don’t have a clown in this circus, but there is nothing here that reduces my unease about the ever-increasing levels of unnecessary complexity and abstraction in Linux systems.
Linux is rapidly becoming the Java of operating systems. It’s sad, really.
I don't like how much control Red Hat has over the Linux ecosystem.
Me neither. But I don’t know how much control redhat has over systemd these days.
Not a lot. Lennart left years ago and now is part of a startup. One of the other systemd devs that was still at Red Hat left and joined the startup at the beginning of this year. I don’t know if there are any systemd maintainers at Red Hat now, or even any regular contributors.
Red Hat’s overall influence is waning a bit, sadly, because core contributors to various projects are leaving faster than they’re being replaced.
People who don’t like Red Hat’s “influence” are slowly getting their wish, but the thing is, I don’t see a lot of other companies filling the gap to pay maintainers to do FOSS work. Instead of “ugh, I don’t like the way this work is being done” we’re going to see more “hey, nobody is doing this work at all now.”
That's such a mixed bag, isn't it? Centralizing that control is bad. But paying people to make FOSS is good. And the variety of control they get mainly comes from paying people to make FOSS.
I guess I think their embrace of Free Software has mitigated some of my concern about the level of influence they get to exert. If you look at some of the tech they've acquired over the years, they've even opted to create FOSS upstreams for themselves where none existed before. Dogtag PKI and 389 directory server stand out to me in particular, because I worked with all of their proprietary predecessors, RedHat-created FOSS upstreams and RedHat commercial FOSS downstreams. But I've observed the pattern in other things they've touched, from greater distance.
On balance, I believe they've been mostly not-bad for the ecosystem, and have advanced it more often than they've impaired it.
I too wish my employer would just pay me money to work on my niche hobby projects that I enjoy. But alas they pay me to work on things that make money for them.
Even though he’s not involved in Flatpak development, enough people assumed that he was
Likely because the talk was given by and from the perspective of Flatpack developers, and he referred to it as »his« talk.
I guess more reasons for containers? I can keep the systemd poison safely contained outside of my main system! Maybe it's freebsd for me? A. I guess incos will keep it safely out of my universe too