3 ms·

I think what the parent is getting at is that, even though there are many daemons and tools that make up systemd (and even though they are each scoped to a part

by jude- 13y ago

I think what the parent is getting at is that, even though there are many daemons and tools that make up systemd (and even though they are each scoped to a particular concern it addresses), most of them are tightly coupled to one another. To run logind, for example, I need systemd to run as PID 1. This monolithic architecture is unsettling in the long term--it raises the barrier to entry for independent innovation in the same space. At least before, the various daemons systemd replaces (atd, crond, xinetd, acpid, udev, dbusd, etc.) could be independently modified, disabled, or replaced without breaking each other, and without much hassle. Instead, improvements to systemd's daemons have to conform to a moving-target API in the same layer (other systemd daemons) and the layer beneath them (systemd PID 1), as well as the layer above them (i.e. the UI).

Narishma 13y ago
You could say the same thing about the Linux kernel, yet it hasn't stopped improving.
- jude- 13y ago
  First, the boundary between Linux and the rest of the system is very well-defined. I can run my userspace on top of multiple different kernels, since my userspace is loosely coupled to Linux (yes, there are exceptions, but not so many that it prevents GNU/kfreebsd or GNU/solaris from working, for example). This is not the case with systemd, which over the past several years has been subsuming larger and larger swaths of userspace, introducing all sorts of tight couplings and inter-dependencies that weren't there before. Second, the pace of innovation in Linux is definitely slower than in userspace, and getting your patches adopted is more difficult relative to most userspace programs (this is the high barrier to entry I spoke of). Your patches either have to get approved by Linus et al., or you have to host them out-of-tree and hope your users know how to apply them and compile the kernel themselves (and if you want to do this for them, you have to do it for every kernel you need to support). If you're lucky, your patches can be isolated into a kernel module, in which case you "only" need to keep it up-to-date with the kernel API (which is a moving target). Contrast this to working on a program like, say, xinetd. While the option for submitting patches still reduces to "go through the maintainer" or "host them yourself", the "host them yourself" option is much more tenable, since the codebase is smaller, and the "don't break userspace" policy Linus enforces ensures you aren't coupled to a moving-target API. The lower barrier to entry brought on by loose coupling explains why Gentoo can get away with forking udev, but not large swaths of the Linux kernel. Systemd has the effect of making innovation in the plumbing layer (xinetd, syslog, udev, cron, etc.) a lot like innovation in the Linux kernel. Can you imagine the absurdity of having to maintain a version of xinetd for each separate systemd API change?

by jude- 13y ago

Narishma 13y ago

You could say the same thing about the Linux kernel, yet it hasn't stopped improving.

jude- 13y ago
First, the boundary between Linux and the rest of the system is very well-defined. I can run my userspace on top of multiple different kernels, since my userspace is loosely coupled to Linux (yes, there are exceptions, but not so many that it prevents GNU/kfreebsd or GNU/solaris from working, for example). This is not the case with systemd, which over the past several years has been subsuming larger and larger swaths of userspace, introducing all sorts of tight couplings and inter-dependencies that weren't there before. Second, the pace of innovation in Linux is definitely slower than in userspace, and getting your patches adopted is more difficult relative to most userspace programs (this is the high barrier to entry I spoke of). Your patches either have to get approved by Linus et al., or you have to host them out-of-tree and hope your users know how to apply them and compile the kernel themselves (and if you want to do this for them, you have to do it for every kernel you need to support). If you're lucky, your patches can be isolated into a kernel module, in which case you "only" need to keep it up-to-date with the kernel API (which is a moving target). Contrast this to working on a program like, say, xinetd. While the option for submitting patches still reduces to "go through the maintainer" or "host them yourself", the "host them yourself" option is much more tenable, since the codebase is smaller, and the "don't break userspace" policy Linus enforces ensures you aren't coupled to a moving-target API. The lower barrier to entry brought on by loose coupling explains why Gentoo can get away with forking udev, but not large swaths of the Linux kernel. Systemd has the effect of making innovation in the plumbing layer (xinetd, syslog, udev, cron, etc.) a lot like innovation in the Linux kernel. Can you imagine the absurdity of having to maintain a version of xinetd for each separate systemd API change?