37 ms·

0) That's not the init systems job. 1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html 2) Less modular than any init sy

by lawl 13y ago

0) That's not the init systems job. 1) That's not the init systems job. Use something like http://cr.yp.to/daemontools.html 2) Less modular than any init system out there. Having *everything* (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. 3) See 1. 4) Never bothered me, but fair enough. 5) That's not the init systems job. 6) Not if the path's differ. E.g. are debianized. 7) So was sysvinit. 8) That's not the init systems job. 9) It actually is. Edit: And if you downvote me, at least add an explanation please. Thanks. I'd like to know if I'm factually wrong or you just disagree.

cnvogel 13y ago
> 2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false. dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd). chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd -rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd -rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd chris@raspberrypi /usr/lib/systemd $ ./systemd --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR
RVuRnvbM2e 13y ago
You clearly don't understand systemd. It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition. systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite. Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.
zokier 13y ago
I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.
- makomk 13y ago
  Various core system bits that are tightly integrated using undocumented APIs and assumptions about what the other parts are doing internally which are subject to change at any time. I think you can replace some, though not all, of the non-PID-1 bits with a little development work, but replacing the core parts is unsupported.
  - zokier 13y ago
    That is beside the point. The argument was "That's not the init systems job." to which I presented the counterargument that systemd is not just an init system. Beside that, I recommend you'd take a look at http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... and possibly http://www.freedesktop.org/software/systemd/man/ http://www.freedesktop.org/software/systemd/man/.
    - makomk 13y ago
      See my comment at https://news.ycombinator.com/item?id=7639730 https://news.ycombinator.com/item?id=7639730 - those are the external APIs used by software that isn't officially a part of systemd but still depends on it. The APIs between different parts of systemd are undocumented and subject to change. In fact http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... says as much itself and exists in part to convince people this isn't a big deal because in theory someone could write their own components that implement the same APIs. (Except that in practice no-one has reimplemented anything beyond the most trivial APIs, and in fact that page claims some critical stuff like logind cannot be independently reimplemented or used without systemd.)
- 13y ago
skrause 13y ago
You failed to mention why it's not the init system's job. An init system which is aware of what's going on can have a lot of advantages. In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?
- deleted 13y ago
  [deleted]
- pmahoney 13y ago
  > daemontools are nothing more than an init system on top of an init system What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine). http://www.skarnet.org/software/s6/index.html http://www.skarnet.org/software/s6/index.html I've been using s6 to manage a few things, and some features I like are: - allow a group to manage (stop/restart) certain processes using Unix file permissions - arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.
  - aktau 13y ago
    Have you tried runit? If so, could you tell me how it differs from s6? I like runit, but if it's better, it's better.
    - pmahoney 13y ago
      I have not tried runit. s6 is actively maintained; I don't know about runit (on the other hand, runit is in Debian while you must compile s6 yourself). The author of s6 has a (very biased of course) comparison or various supervisors: http://skarnet.org/software/s6/why.html http://skarnet.org/software/s6/why.html The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.
deleted 13y ago
[deleted]
dkhenry 13y ago
If over half your critique is that systemd does _more_ then its predessor and all of those are valid services, that it can do well, then I don't see the real complaint here. I mean are you upset because its different.
- e12e 13y ago
  It's only better if it does a better job than the tools it replaces. I have working dhcp, cron and logging on all my systems (well, those that need dhcp anyway). I can replace them fairly independently. Why would I want to entangle them? And not only does the the tool need to do a better job at all these things, but it also needs to remain flexible, and easily tunable -- for it to be overall better. I'm not saying that isn't possible -- ZFS is an example of a tool that gobbled up lots of others, and it's almost better -- for my use-cases not being able to grow a raid-array is a bit of a deal-breaker, as is the requirment of having roughly 4GBs of RAM available -- for many use-cases it isn't. But having disk management, filesystem management and managing disk encryption in one tool is great.
Tuna-Fish 13y ago
>> 0) it is hotplug capable > 0) That's not the init systems job. For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.
- felixgallo 13y ago
  From a desktop Linux perspective, you're totally right. However, if anything is evolving fast, it's the recognition that desktop Linux has never worked and will never work, and is in any case the extreme minority case in modern Unix systems (which, population-wise, are essentially all embedded systems, servers and phones). From that perspective -- the perspective of systems which boot once, and boot again maybe next year if the UPS didn't keep them up when the power flickered, and the perspective of the systems where there are definitely not usb drives or random pieces of unknown crap plugged into user accessible ports, the idea of hotplug at all is the least of concerns, and the idea of boot time is laughable. Essentially, it seems like systemd is chasing Windows of 16 years ago, where computers took 5 minutes to boot Windows, where device drivers and such were a mess, and things were constantly entering and leaving systems.
  - Tuna-Fish 13y ago
    > the idea of hotplug at all is the least of concerns No, you don't understand me. Even if actually hotplugging things is completely uninteresting to you, your init system still has to somehow be able to deal with the fact that on a modern box, all your devices show up in essentially random order with random delays. sysvinit currently handles this by putting a completely arbitrary sleep call in the beginning of the boot process. Just last week I had to deal with a server where due to circumstances that sleep wasn't enough, which lead to the ethernet devices getting initially wrongly named, which was bad because the mountains of script doing network configuration there happily treated the external network as the internal one and the internal one as the external one. Even if hotplug is a feature you don't care at all about, due to design decisions made by the Kernel team, if you want to run a modern Linux kernel your machine will have to fully support hotplug properly or it's going to (rarely and non-replicably) fail in interesting and imaginative ways.
VMG 13y ago
> Edit: And if you downvote me, at least add an explanation please. See other replies.
- VMG 13y ago
  What? That's my explanation after all.

by lawl 13y ago

cnvogel 13y ago

> 2) Less modular than any init system out there. Having everything (including a dhcp deamon soon) in PID 1 is not modular just because you can configure it. I can understand the issue that people have with systemd swallowing more and more functionality, but this fact is just false. dhcp is in /usr/lib/systemd/systemd-networkd, which is not the systemd binary running as PID 1 (/usr/lib/systemd/systemd/systemd). chris@raspberrypi /usr/lib/systemd $ ls -la systemd systemd-networkd -rwxr-xr-x 1 root root 907340 Apr 14 23:10 systemd -rwxr-xr-x 1 root root 329604 Apr 14 23:09 systemd-networkd chris@raspberrypi /usr/lib/systemd $ ./systemd --version systemd 212 +PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR

RVuRnvbM2e 13y ago

You clearly don't understand systemd. It is a suite of tools for managing the system state. Going from runlevel 0 to runlevel 3 is just one such transition. systemd is referred to as monolithic because it is developed in a single repository, but it is in fact extremely modular. "PID 1" is only one of the ~70 binaries which make up the systemd suite. Saying "That's not the init systems job" seems dogmatic and short sighted when there's currently no other approach which offers the hotplug, service management, security and performance features that systemd brings to the table.

zokier 13y ago

I think you are missing the forest for the trees. Systemd is not just PID1, it is an umbrella project for various core system bits and pieces. Most stuff in systemd project do not run in systemd PID1.

makomk 13y ago
Various core system bits that are tightly integrated using undocumented APIs and assumptions about what the other parts are doing internally which are subject to change at any time. I think you can replace some, though not all, of the non-PID-1 bits with a little development work, but replacing the core parts is unsupported.
- zokier 13y ago
  That is beside the point. The argument was "That's not the init systems job." to which I presented the counterargument that systemd is not just an init system. Beside that, I recommend you'd take a look at http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... and possibly http://www.freedesktop.org/software/systemd/man/ http://www.freedesktop.org/software/systemd/man/.
  - makomk 13y ago
    See my comment at https://news.ycombinator.com/item?id=7639730 https://news.ycombinator.com/item?id=7639730 - those are the external APIs used by software that isn't officially a part of systemd but still depends on it. The APIs between different parts of systemd are undocumented and subject to change. In fact http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ http://www.freedesktop.org/wiki/Software/systemd/InterfacePo... says as much itself and exists in part to convince people this isn't a big deal because in theory someone could write their own components that implement the same APIs. (Except that in practice no-one has reimplemented anything beyond the most trivial APIs, and in fact that page claims some critical stuff like logind cannot be independently reimplemented or used without systemd.)
13y ago

skrause 13y ago

You failed to mention why it's not the init system's job. An init system which is aware of what's going on can have a lot of advantages. In the end djb's daemontools are nothing more than an init system on top of an init system. So why not include it in the main init system?

deleted 13y ago
[deleted]
pmahoney 13y ago
> daemontools are nothing more than an init system on top of an init system What do you mean by that? That it isn't PID 1? Apparently it can be made to run as PID 1. But you can keep the (in my opinion) brilliant design of daemontools and use successors such as s6 are designed to run either as PID 1 or as a plain old daemon (which is nice if you've not got full control of a machine). http://www.skarnet.org/software/s6/index.html http://www.skarnet.org/software/s6/index.html I've been using s6 to manage a few things, and some features I like are: - allow a group to manage (stop/restart) certain processes using Unix file permissions - arrange things in a tree. My toplevel s6-svscan starts a second s6-svscan which starts a handful of related processes. These all inherit the same user and environment vars which makes config easy.
- aktau 13y ago
  Have you tried runit? If so, could you tell me how it differs from s6? I like runit, but if it's better, it's better.
  - pmahoney 13y ago
    I have not tried runit. s6 is actively maintained; I don't know about runit (on the other hand, runit is in Debian while you must compile s6 yourself). The author of s6 has a (very biased of course) comparison or various supervisors: http://skarnet.org/software/s6/why.html http://skarnet.org/software/s6/why.html The big feature s6 has that runit lacks seems to be the ability to wait without polling on some event (process started). I haven't used this much myself, but even given that some process has started, it doesn't necessarily mean that it's initialized and ready to do what you expect.

deleted 13y ago

[deleted]

dkhenry 13y ago

If over half your critique is that systemd does _more_ then its predessor and all of those are valid services, that it can do well, then I don't see the real complaint here. I mean are you upset because its different.

e12e 13y ago
It's only better if it does a better job than the tools it replaces. I have working dhcp, cron and logging on all my systems (well, those that need dhcp anyway). I can replace them fairly independently. Why would I want to entangle them? And not only does the the tool need to do a better job at all these things, but it also needs to remain flexible, and easily tunable -- for it to be overall better. I'm not saying that isn't possible -- ZFS is an example of a tool that gobbled up lots of others, and it's almost better -- for my use-cases not being able to grow a raid-array is a bit of a deal-breaker, as is the requirment of having roughly 4GBs of RAM available -- for many use-cases it isn't. But having disk management, filesystem management and managing disk encryption in one tool is great.

Tuna-Fish 13y ago

>> 0) it is hotplug capable > 0) That's not the init systems job. For modern Linux, there is nothing but hotplug. And I mean that very literally. Oldest Unices only worked on systems where all the hardware was brought up on boot, before the rest of the system. Then hotplug was added on top of this. Init systems didn't evolve to accommodate this, instead different systems were developed to handle it. However, the Linux kernel has constantly evolved towards eliminating old-style static boot, with right now, on normal bootup, almost all devices are hotplugged. This is why sysvinit doesn't work properly anymore. Being hotplug capable is definately the init system's job.

felixgallo 13y ago
From a desktop Linux perspective, you're totally right. However, if anything is evolving fast, it's the recognition that desktop Linux has never worked and will never work, and is in any case the extreme minority case in modern Unix systems (which, population-wise, are essentially all embedded systems, servers and phones). From that perspective -- the perspective of systems which boot once, and boot again maybe next year if the UPS didn't keep them up when the power flickered, and the perspective of the systems where there are definitely not usb drives or random pieces of unknown crap plugged into user accessible ports, the idea of hotplug at all is the least of concerns, and the idea of boot time is laughable. Essentially, it seems like systemd is chasing Windows of 16 years ago, where computers took 5 minutes to boot Windows, where device drivers and such were a mess, and things were constantly entering and leaving systems.
- Tuna-Fish 13y ago
  > the idea of hotplug at all is the least of concerns No, you don't understand me. Even if actually hotplugging things is completely uninteresting to you, your init system still has to somehow be able to deal with the fact that on a modern box, all your devices show up in essentially random order with random delays. sysvinit currently handles this by putting a completely arbitrary sleep call in the beginning of the boot process. Just last week I had to deal with a server where due to circumstances that sleep wasn't enough, which lead to the ethernet devices getting initially wrongly named, which was bad because the mountains of script doing network configuration there happily treated the external network as the internal one and the internal one as the external one. Even if hotplug is a feature you don't care at all about, due to design decisions made by the Kernel team, if you want to run a modern Linux kernel your machine will have to fully support hotplug properly or it's going to (rarely and non-replicably) fail in interesting and imaginative ways.

VMG 13y ago

> Edit: And if you downvote me, at least add an explanation please. See other replies.

VMG 13y ago
What? That's my explanation after all.