7 ms·

"if you do an init system but still invoke all the shell scripts and all the other things needed to bring up the system, you’ve only solved part of the problem.

by nurb 12y ago

"if you do an init system but still invoke all the shell scripts and all the other things needed to bring up the system, you’ve only solved part of the problem." That's exactly what I think is wrong with systemd. If a script bring a speed issue on start up, it should fixed by optimizing the script, use/create another script language with parallelism and higher pref, or even turn it into a compiled program. This is not supposed to be the problem of the init system developper. In fact the only purpose of an init system is to start executables in a defined order, not more. This is going to be like X, a huge pile of unmaintainable code, and that's definitely not the UNIX philosophy.

elwin 12y ago
> In fact the only purpose of an init system is to start executables in a defined order, not more. That's where the disagreement lies. I see the purpose of an init system as being to transition the machine from one state to another. Sometimes this means starting executables. Sometimes it means stopping them. Sometimes it involves more complicated tasks. > This is going to be like X, a huge pile of unmaintainable code That is exactly my opinion of the shell scripts that previously handled networking.
- sethrin 12y ago
  Yes, "init" is a bit of a misnomer, given that it also handles shutdown/runlevel transitions. I see the big difference here as being between the people who think that the job of the OS is to provide a simple base for executing user-defined scripts, and well, everyone else. I think that an appropriate analogy would be handcrafted goods versus mass production. Linux has been transformed into a wide variety of products at various times, and while I don't think the init scripts played a very large role in any of that, the idea that the OS is what you choose to turn it into does have strong credence in this community. The other side of the debate, I think, are the people who feel like a collection of init scripts should be refactored somehow, and mostly this seems to involve rewriting things in C, adding dependency annotations to init files, and implementing support for cgroups. At least that's what OpenRC has been doing. Systemd unit files go a step further, but it's a good step in my opinion. Anything that any two scripts do should be refactored into a common method or library, and hopefully that process leaves very little for the init script or unit file to do. It doesn't matter to me personally whether this stuff gets done in Bash or C; I can't really maintain either. I could probably write a unit file if I had to. I understand there are lots of people who have put lots of time into writing Bash scripts. Some sysadmins may even think that their job is to write scripts. These people should continue to write all the scripts that they want, because Linux is all about that, but maybe they should also let other people write a decent plumbing layer for Linux, because modern OSes are all about that.
_delirium 12y ago
> In fact the only purpose of an init system is to start executables in a defined order, not more. A good init system should also do process supervision and integrate with the OS's resource-management subsystem (on Linux, cgroups). You could do that with an even bigger pile of shell scripts, of course, and some Linux distros towards the end of the sysvinit era have been trying to. But at some point a giant tangle of shell scripts which are full of copy/paste boilerplate and frequent bugs starts to look like not the best solution. It's not like systemd is the first system to come to that conclusion, either. Solaris dropped sysvinit 10 years ago, and OSX dropped its BSD-ish init in the same year. Earlier than that, djb also wrote an init replacement called daemontools, which was a bit of a step in that direction, though a smaller one. That got some uptake but was hampered by some of the oddities of being djbware (e.g. for years it was "license-free software", and it was only intermittently maintained).
- lawl 12y ago
  Process supervising is for process supervisors. Init's jobs is to be able to start a process supervisor.
  - _delirium 12y ago
    Are there any examples of a process supervisor that isn't also intended to replace the traditional init system? Even systems less ambitious than SMF/launchd/systemd, like daemontools and runit, aim to replace sysvinit, because otherwise you'd have to specify twice, in different ways, how each service should start and stop (though it's possible to set up configurations where that works).
    - Wilya 12y ago
      Supervisor, god, monit, circus, etc. And even though it can handle both init and process supervision, runit has a clear separation between the two tasks. The "runit" program handles init tasks. The "runsvdir" program handle process supervision. And each one is completely functional without the other.

by nurb 12y ago

elwin 12y ago

> In fact the only purpose of an init system is to start executables in a defined order, not more. That's where the disagreement lies. I see the purpose of an init system as being to transition the machine from one state to another. Sometimes this means starting executables. Sometimes it means stopping them. Sometimes it involves more complicated tasks. > This is going to be like X, a huge pile of unmaintainable code That is exactly my opinion of the shell scripts that previously handled networking.

sethrin 12y ago
Yes, "init" is a bit of a misnomer, given that it also handles shutdown/runlevel transitions. I see the big difference here as being between the people who think that the job of the OS is to provide a simple base for executing user-defined scripts, and well, everyone else. I think that an appropriate analogy would be handcrafted goods versus mass production. Linux has been transformed into a wide variety of products at various times, and while I don't think the init scripts played a very large role in any of that, the idea that the OS is what you choose to turn it into does have strong credence in this community. The other side of the debate, I think, are the people who feel like a collection of init scripts should be refactored somehow, and mostly this seems to involve rewriting things in C, adding dependency annotations to init files, and implementing support for cgroups. At least that's what OpenRC has been doing. Systemd unit files go a step further, but it's a good step in my opinion. Anything that any two scripts do should be refactored into a common method or library, and hopefully that process leaves very little for the init script or unit file to do. It doesn't matter to me personally whether this stuff gets done in Bash or C; I can't really maintain either. I could probably write a unit file if I had to. I understand there are lots of people who have put lots of time into writing Bash scripts. Some sysadmins may even think that their job is to write scripts. These people should continue to write all the scripts that they want, because Linux is all about that, but maybe they should also let other people write a decent plumbing layer for Linux, because modern OSes are all about that.

_delirium 12y ago

> In fact the only purpose of an init system is to start executables in a defined order, not more. A good init system should also do process supervision and integrate with the OS's resource-management subsystem (on Linux, cgroups). You could do that with an even bigger pile of shell scripts, of course, and some Linux distros towards the end of the sysvinit era have been trying to. But at some point a giant tangle of shell scripts which are full of copy/paste boilerplate and frequent bugs starts to look like not the best solution. It's not like systemd is the first system to come to that conclusion, either. Solaris dropped sysvinit 10 years ago, and OSX dropped its BSD-ish init in the same year. Earlier than that, djb also wrote an init replacement called daemontools, which was a bit of a step in that direction, though a smaller one. That got some uptake but was hampered by some of the oddities of being djbware (e.g. for years it was "license-free software", and it was only intermittently maintained).

lawl 12y ago
Process supervising is for process supervisors. Init's jobs is to be able to start a process supervisor.
- _delirium 12y ago
  Are there any examples of a process supervisor that isn't also intended to replace the traditional init system? Even systems less ambitious than SMF/launchd/systemd, like daemontools and runit, aim to replace sysvinit, because otherwise you'd have to specify twice, in different ways, how each service should start and stop (though it's possible to set up configurations where that works).
  - Wilya 12y ago
    Supervisor, god, monit, circus, etc. And even though it can handle both init and process supervision, runit has a clear separation between the two tasks. The "runit" program handles init tasks. The "runsvdir" program handle process supervision. And each one is completely functional without the other.