4 ms·

All those components that systemd manages, that's easily, I don't know how many millions of lines of code, and it all runs as pid 1, which, when it crashes, tak

by pyalot2 13y ago

All those components that systemd manages, that's easily, I don't know how many millions of lines of code, and it all runs as pid 1, which, when it crashes, takes the whole system with it. Just doesn't seem terribly smart.

Aissen 13y ago
Yeah, except systemd is a more a collection of daemons and tools under the same umbrella (and project repository), than a huge monolithic PID 1 daemon. It's even described in the chart you linked.
FooBarWidget 13y ago
Do you have any idea how much code is in the kernel? If any line crashes it takes the whole system with it. Doesn't seem terribly smart, does it? And yet the whole world uses Linux instead of Minix. Systemd is splitted out into multiple processes.
- pyalot2 13y ago
  > Do you have any idea how much code is in the kernel? Yes I do, and that's kind of my point. It's a Kernel. I.e. it's the proverbial operating system. It's written as an operating system. Systemd wants to be the operating system, obviously, which is fine. Just call it the Systemd OS and provide the kernel and user shell as well, and you won't need linux anymore.
- 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?
lucian1900 13y ago
It's actually quite small, even including all those components. Its components are quite granular, as well. Compared to the reams of code in existing init systems + all the shell scripts out there related to init and/or management, systemd has a tiny amount of code. Also, there are useful features that can't be achieved without being pid 1.

by pyalot2 13y ago

Aissen 13y ago

Yeah, except systemd is a more a collection of daemons and tools under the same umbrella (and project repository), than a huge monolithic PID 1 daemon. It's even described in the chart you linked.

FooBarWidget 13y ago

Do you have any idea how much code is in the kernel? If any line crashes it takes the whole system with it. Doesn't seem terribly smart, does it? And yet the whole world uses Linux instead of Minix. Systemd is splitted out into multiple processes.

pyalot2 13y ago
> Do you have any idea how much code is in the kernel? Yes I do, and that's kind of my point. It's a Kernel. I.e. it's the proverbial operating system. It's written as an operating system. Systemd wants to be the operating system, obviously, which is fine. Just call it the Systemd OS and provide the kernel and user shell as well, and you won't need linux anymore.
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?

lucian1900 13y ago

It's actually quite small, even including all those components. Its components are quite granular, as well. Compared to the reams of code in existing init systems + all the shell scripts out there related to init and/or management, systemd has a tiny amount of code. Also, there are useful features that can't be achieved without being pid 1.