5 ms·

They have fear of systemd becoming the mainstream init system. It's more easy for a project to become obsolete if we start to forget about it. Although sysvinit

They have fear of systemd becoming the mainstream init system. It's more easy for a project to become obsolete if we start to forget about it. Although sysvinit still has an chance to evolve.

gtaylor 12y ago
> Although sysvinit still has an chance to evolve. You'd probably have some of the same people complaining if you tried to "evolve" SysV. I guess things are pretty good right now in the Linux world if this is the thing to argue over.
- rogertux 12y ago
  Well... In fact it's alredy happening with the init wars
- e7620 12y ago
  Not really, remember daemontools? There are almost a hundred init systems very superior technically compared to sysv and systemd, the truth is that sysv has NEVER been considered the best.
- digi_owl 12y ago
  Depends on how it was to evolve. Parallel boot, sure. But you can always drop runit or openrc or something similar on top and get it already. socket based service start, (hardware) event based, pass. Frankly the core of sysv, the init binary, does very little. It sets up virtual terminals and fires up one or more processes (that it will keep an eye on and maybe restart). The latter processe(s), most commonly a shell script of some kind, are what do the actual starting of "services" and managing of runlevels etc. This is a very flexible system, as most of the logic involved is easy to get at. It is housed in interpreted scripts rather than compiled C code. you can even run the scripts directly in a root shell if you have the need to do so (or perform the scripted commands manually). Basically the scripts do little more than what someone would do manually if they were presented with a bare shell after kernel boot.
Alupis 12y ago
not to mention all of the good things systemd actually provides. I'm particularly excited about socket activation for my servers, as well as auto-remounting of network shares if connectivity is lost (my laptop on/off wifi or traveling, etc). I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it". systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument). It can be replaced as per this article and if software projects don't explicitly bake in hard-dependencies (but even then there are ways around it like shims and what-not that several people have built). Distros are looking around at all the available init systems, and a large amount are deciding systemd offers something more than the rest, and then going with it. (you can review the debian debate for gritty and technical details). There really is no reason to be so angry at systemd.
- deong 12y ago
  As another article I read just today pointed out (in a completely different context), the point of Unix isn't the number or size of the tools. It's the composability of the tools. systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence. And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".
  - chr15p 12y ago
    Serious question: in what ways would you want systemd commands to be composable? I'm struggling to think of a use case for being able to pipe a service name into systemctl (or "service" for that matter) and its output is reasonably grepable for running|failed etc (and more consistant the old SysV scripts) I'm guessing you want more then that though right?
    - VLM 12y ago
      Conceptually composable. The logging in systemd sucks, sorry but true. Binary logs? LOL. Someday if rsyslog could speak raw systemd language as an input, that wouldn't be quite as awful. Then you could have systemd talking to a real logging platform. Just like "ls" can talk to "grep". Doesn't mean the talking can only be in the format of a pipe or whatever.

They have fear of systemd becoming the mainstream init system. It's more easy for a project to become obsolete if we start to forget about it. Although sysvinit still has an chance to evolve.

gtaylor 12y ago

> Although sysvinit still has an chance to evolve. You'd probably have some of the same people complaining if you tried to "evolve" SysV. I guess things are pretty good right now in the Linux world if this is the thing to argue over.

rogertux 12y ago
Well... In fact it's alredy happening with the init wars
e7620 12y ago
Not really, remember daemontools? There are almost a hundred init systems very superior technically compared to sysv and systemd, the truth is that sysv has NEVER been considered the best.
digi_owl 12y ago
Depends on how it was to evolve. Parallel boot, sure. But you can always drop runit or openrc or something similar on top and get it already. socket based service start, (hardware) event based, pass. Frankly the core of sysv, the init binary, does very little. It sets up virtual terminals and fires up one or more processes (that it will keep an eye on and maybe restart). The latter processe(s), most commonly a shell script of some kind, are what do the actual starting of "services" and managing of runlevels etc. This is a very flexible system, as most of the logic involved is easy to get at. It is housed in interpreted scripts rather than compiled C code. you can even run the scripts directly in a root shell if you have the need to do so (or perform the scripted commands manually). Basically the scripts do little more than what someone would do manually if they were presented with a bare shell after kernel boot.

Alupis 12y ago

not to mention all of the good things systemd actually provides. I'm particularly excited about socket activation for my servers, as well as auto-remounting of network shares if connectivity is lost (my laptop on/off wifi or traveling, etc). I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it". systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument). It can be replaced as per this article and if software projects don't explicitly bake in hard-dependencies (but even then there are ways around it like shims and what-not that several people have built). Distros are looking around at all the available init systems, and a large amount are deciding systemd offers something more than the rest, and then going with it. (you can review the debian debate for gritty and technical details). There really is no reason to be so angry at systemd.

deong 12y ago
As another article I read just today pointed out (in a completely different context), the point of Unix isn't the number or size of the tools. It's the composability of the tools. systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence. And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".
- chr15p 12y ago
  Serious question: in what ways would you want systemd commands to be composable? I'm struggling to think of a use case for being able to pipe a service name into systemctl (or "service" for that matter) and its output is reasonably grepable for running|failed etc (and more consistant the old SysV scripts) I'm guessing you want more then that though right?
  - VLM 12y ago
    Conceptually composable. The logging in systemd sucks, sorry but true. Binary logs? LOL. Someday if rsyslog could speak raw systemd language as an input, that wouldn't be quite as awful. Then you could have systemd talking to a real logging platform. Just like "ls" can talk to "grep". Doesn't mean the talking can only be in the format of a pipe or whatever.