3 ms·

Have you actually looked at what systemd does? Here's a handy chart curtesy of wikipedia: http://en.wikipedia.org/wiki/File:Systemd_components.svg http://en.wik

by pyalot2 13y ago

Have you actually looked at what systemd does? Here's a handy chart curtesy of wikipedia: http://en.wikipedia.org/wiki/File:Systemd_components.svg http://en.wikipedia.org/wiki/File:Systemd_components.svg That just seems insane to me, what do I know... (admittedly not much about init systems) Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such.

exDM69 13y ago
> That just seems insane to me, what do I know... (admittedly not much about init systems) > Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such. Traditionally the things that systemd does were either done by a huge mess of shell scripts or were not done at all. There's no shortage of people who insist on doing things the way they were done before but to me, systemd makes a lot of sense. It's true that it combines things that were previously done by cron, acpid, getty, pam, etc to deal with power management, network connectivity and login, etc. But I still find it a better alternative than having a lot of distribution specific shell scripts gluing all those individual services together. Besides booting faster, there are advantages like better fault tolerance and consistency.
- 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.
- teacup50 13y ago
  Perhaps you should look into how Mac OS X handles these things while still maintaining separation of concerns. Systemd is a joke of a software design by comparison.

by pyalot2 13y ago

exDM69 13y ago

> That just seems insane to me, what do I know... (admittedly not much about init systems) > Still, systemd tries to do everything under the sun, it just doesn't seem like an init system, it seems systemd basically wants to be an operating system and assume all responsibilities as such. Traditionally the things that systemd does were either done by a huge mess of shell scripts or were not done at all. There's no shortage of people who insist on doing things the way they were done before but to me, systemd makes a lot of sense. It's true that it combines things that were previously done by cron, acpid, getty, pam, etc to deal with power management, network connectivity and login, etc. But I still find it a better alternative than having a lot of distribution specific shell scripts gluing all those individual services together. Besides booting faster, there are advantages like better fault tolerance and consistency.

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.
teacup50 13y ago
Perhaps you should look into how Mac OS X handles these things while still maintaining separation of concerns. Systemd is a joke of a software design by comparison.