17 ms·

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice peo

by pdkl95 13y ago

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much" And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change. This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features. Yes, I understand that some people have needs that require more (or different) features in their init process. So they should use systemd or whatever else solves those needs. Requirements and uses for general purpose computers vary a lot, though - especially in an environment like UNIX that encourages customization. My needs, for example, were mostly met by OpenRC's reworking of sysvinit. Some minor customization solved that problem completely. I recognize that some people see systemd as a good fit for their needs. Why do the anti-choice people refuse to recognize that other people might have different requirements. Again, I'm fine with systemd, as an option. It's the bundling and takeover of all the other tools that is a large part of the problem. Blaming others because we didn't implement your made up requirements is another part. Acting like a monopoly and tying other projects together to force upgrade because of vertical integration is yet another part that makes me question motive in addition to the technical issues. You want us to support systemd? Disconnect it from other stuff like the INIT (pid=0), the logger, and IPC (dbus). Allow all those to remain as they were previously. Let systemd be just the process launcher/manager, and allow let all of those parts work stand-alone with existing tools. Note: providing more features when your tools are used together is fine (and expected). This way, the software can stand on it sown, and if it really is big of an improvement as the systemd supports suggest, the migration will happen naturally over time. If, on the other hand, using one tool continues to have the requirement of trading many other system-level tools that I already know and use, for unproven newcomers that seem to ignore the lessons of the past, well... I'm sticking with what already works.

colin_mccabe 13y ago
systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun. Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this. Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.
- chrisbolt 13y ago
  > I'm not sure what you mean by "disconnecting from dbus," dbus is a dependency of systemd itself, not just of the services that require it.
  - vidarh 13y ago
    With kdbus (dbus in the kernel) on its way it is largely moot anyway. "Disconnecting from dbus" at that point will not be very meaningful.
    - teacup50 13y ago
      Moot? Putting dbus in the kernel is demented. Creating a hard dependency between it and a monolithic set of interdependent systemd code is even more demented. It's like the Linux folks looked at Mac OS X and learned nothing. Hint: Mac OS X handles more that systemd does, and still does it in a way that maintains separation of concerns between service management, configuration management, logging, and IPC.
- throwaway092834 13y ago
  There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting. Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses. "Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.
  - awalton 13y ago
    You're really good at copying-and-pasting canned responses from previous comments... throwawayhugerandomnumber
  - 13y ago
rodgerd 13y ago
> Why do the anti-choice people refuse to recognize that other people might have different requirements. Go build your own LFS systems if you want ultimate choice. You don't get to force upstream authors (who like systemd) and distribution developers (who like systemd) to do what you want. > I'm sticking with what already works. sysvinit works only if you combine incredibly low expectations with a bad case of Stockholm syndrome.
- deleted 13y ago
  [deleted]
- pekk 13y ago
  But you get to force upstream authors and distribution developers who would like to be able to use something else? Sure. That is not a real argument on the merits of permitting this choice. It is just saying "nyah nyah I have the power and you do not."
  - vidarh 13y ago
    Where did he indicate he wanted to force anyone? Upstream authors are free to use whatever they like. It may impact which distributions wants to include their applications the more repackaging the distribution needs to do to include it, as a resource availability issue, but that's it. Distribution developers already often substantially rework or write init scripts from scratch anyway, and that is exactly one of the reasons systemd is attractive: It drastically cuts down the scripting boilerplate that otherwise has to be done or adapted to their distro for huge numbers of packages. It also contains most of the distro specific stuff outside of init.d, opening the door for lots more reuse. But if you're an upstream developer and wants to ship sys-v init scripts, nobody has the power to stop you. Downstream will either simply write a systemd init file, or you might choose to add one if you like, or if you put LSB comments in your sys-v init file downstream might opt to use that with Systemd if they want to. How exactly is upstream being forced to do anything? How exactly are distribution developers being forced? If they are against their distributions decision, then they have the choice to package something else anyway and either ship it separately or fork the distro.
  - 13y ago
pjmlp 13y ago
The main issue is like it ever was with the UNIX wars, now Linux wars. Cloning UNIX was not enough, now each distribution wants to "improve" UNIX on its own way.
- xorbyte 13y ago
  Not sure how you see progress and innovation otherwise. Much of what is good in Linux comes from experimentation and people/distros 'doing their own thing' which sometime improved the ecosystem, and sometimes resulted in abandoned projects. But things have not stagnated. As for UNIX, perhaps you're familiar with Plan 9? Some of the principal UNIX designers were unhappy with the result, so they went and worked on improving it. Nothing is good enough the first time around.
  - pjmlp 13y ago
    I lived through the UNIX wars, where POSIX doesn't mean a thing because each UNIX has its own version of standard and most complex applications still required OS specific APIs anyway.
- vidarh 13y ago
  None of the current UNIX descendants are all that similar to the original UNIX in the first place. Every single one have tried to improve on UNIX.
  - pjmlp 13y ago
    Hence the UNIX wars.
- rodgerd 13y ago
  If anything, systemd may help rein some of that in but making service files a bit more common across the distros than the various special snowflakisms of each lot of init scripts. Or so we may hope.
exDM69 13y ago
> This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features. This is the argument we've heard over and over again. The problem with traditional unix init scripts, together with cron, acpid, inetd, etc is that you need a big brittle mess of shell scripts to tie it all together to form a system that actually works. While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device. There may be changes in power (mains/battery/low power), network connectivity (ethernet, wifi, mobile) and connecting peripherals (including external disks) and lots of other things which need starting/stopping services or mounting/unmounting partitions. The amount of shell script glue to make these things work is unwieldy and doesn't really work that well. And distribution maintainers have to make a choice, supporting more than one init system is going to be a burden that will hurt end users in the long run. Finally, no one is forcing you to use a systemd based distribution. If OpenRC solves your problems, do go ahead and use Gentoo or another OpenRC based system.
- synchronise 13y ago
  You're forgetting the traction that OpenRC has gained in the past year, they have already implemented cgroup support and experimental process tracking and it's moving beyond simple shell scripts. It doesn't have feature parity with systemd, but it has portability and it's more permissively licensed, and factoring the speed of development I anticipate that it has a bright future ahead of it.
- cynicalkane 13y ago
  Not to devalue systemd, but I suspect that a lot of Unix problems could be solved if Unix offered a better general-purpose solution for gluing things together other than "big brittle masses of shell scripts". In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases.
  - CrLf 13y ago
    Granted, init-related scripts have become complex along the years, but we may argue that happened because of the same type of reasoning that's now justifying the move to systemd: the need to do everything in one place and automagically. You know, even if I would agree with you that "shell itself is an ugly mess of weird syntax, gotchas, and corner cases" that doesn't preclude init scripts from being redone in something other than shell. "People who don't understand unix are bound to reinvent it, badly." This has become the tag line for Linux, and unfortunately is starting to reach the previously sacred grounds of basic (server) infrastructure.
drewcrawford 13y ago
The dispute here is philosophical. You want a distribution that follows The Unix Way. Where init does its little job and dbus does its little job and so on. Small, simple tools. But there is another way. A way that believes that when you unite the core tools into one powerful process you can do cool things. These cool things have been proven, from the basics like faster boot times, to more advanced features like saving/restoring random seeds, automount, SELinix integration, and so on. You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point. These Linux distributions are not temporarily disoriented mountain climbers accidentally heading away from Mt. Unix. They are deliberately skiing away from it at a high rate of speed. What they will find at the bottom of the slope is an interesting question, but simply pointing out that their strategy is bad for mountain climbing is neither here nor there. What I am saying is, if you want to run an OS that believes in the Unix Philosophy, the shortest path is to install Unix. You are going to have about as much luck convincing Fedora that they ought to be Unix as you would convincing Redmond.
- nailer 13y ago
  There's also a huge amount of redundancy inside, and between: - SysVinit - xinetd - atd - crond - supervisor - syslogd and the other things systemd replaces. 'Small, single purpose tools' is Unix philosophy. But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors. One could also argue that 'doing one thing well' is handling services.
  - pipy 13y ago
    Systemd is controlled by Red Hat in a way in which critical system components including kernel haven't been controlled before. Not by single corporate entity. That's what we know about this company from an old (2007) article: > “When we rolled into Baghdad, we did it using open > source,” General Justice continued. “It may come as a > surprise to many of you, but the U.S. Army is “the” single > largest install base for Red Hat Linux. I'm their largest customer.” [1] It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government (especially the one that has a tendency to indiscriminately infect other people's systems [2]). Also, the Interface Stability Promise [3] by systemd team is just a promise, nothing more. Will Red Hat keep it if it is to decide at some point, that it no longer serves it's bottom line? I wonder if it can be considered legally binding. [1] http://archive09.linux.com/feed/61302 http://archive09.linux.com/feed/61302 [2] https://www.youtube.com/watch?v=vILAlhwUgIU https://www.youtube.com/watch?v=vILAlhwUgIU [3] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt... Originally posted in this thread: https://news.ycombinator.com/item?id=7210064 https://news.ycombinator.com/item?id=7210064
codex 13y ago
If you have a system made up of small and simple tools, it can only so small and simple things. Imagine designing an airplane this way. It would never get off the ground.

by pdkl95 13y ago

colin_mccabe 13y ago

systemd runs as pid 0 so that it can relaunch processes when they die. If it were not pid 0, something would have to be managing it, which just leads to a "turtles all the way down" scenario. I'm not sure what you mean by "disconnecting from dbus," but I do know that some services require the d-bus service to be started before they run. A good init system must handle that. Similarly, a good init system needs to handle logging. It's frustrating to try to start a service and be unable to, and not know why because a message dumped to stderr went to /dev/null. I've been in this boat before and it's not fun. Smart people at Red Hat spent a long time thinking about the problems faced by a modern init system. They looked at what had already been done, including the Mac init system, upstart, and the Solaris init system, and came up with something cool for Linux. I think it's sad that so many people are attacking this. Anyway, nobody is forcing you to use anything. You can use Slackware or even one of the BSDs if you don't want systemd.

chrisbolt 13y ago
> I'm not sure what you mean by "disconnecting from dbus," dbus is a dependency of systemd itself, not just of the services that require it.
- vidarh 13y ago
  With kdbus (dbus in the kernel) on its way it is largely moot anyway. "Disconnecting from dbus" at that point will not be very meaningful.
  - teacup50 13y ago
    Moot? Putting dbus in the kernel is demented. Creating a hard dependency between it and a monolithic set of interdependent systemd code is even more demented. It's like the Linux folks looked at Mac OS X and learned nothing. Hint: Mac OS X handles more that systemd does, and still does it in a way that maintains separation of concerns between service management, configuration management, logging, and IPC.
throwaway092834 13y ago
There is no "turtles" issue here. Pid 1 is special - if it dies, the system panics. It is good design to keep pid 1 as simple as possible and put the complex job logic in a sub-process. There are only two things on unix which init must do: reap any children it inherits, and start something else to do the heavy lifting. Even sysV init works this way. The current sysV init is very simple -- the invocation complexity lives in /etc/rc and the related rc.d scripts which operate as subprocesses. "Smart people" is a silly thing to say. We're all smart people and sometimes smart people make poor technical decisions. Let the matter lay upon its technical merit, not upon empty platitudes.
- awalton 13y ago
  You're really good at copying-and-pasting canned responses from previous comments... throwawayhugerandomnumber
- 13y ago

rodgerd 13y ago

> Why do the anti-choice people refuse to recognize that other people might have different requirements. Go build your own LFS systems if you want ultimate choice. You don't get to force upstream authors (who like systemd) and distribution developers (who like systemd) to do what you want. > I'm sticking with what already works. sysvinit works only if you combine incredibly low expectations with a bad case of Stockholm syndrome.

deleted 13y ago
[deleted]
pekk 13y ago
But you get to force upstream authors and distribution developers who would like to be able to use something else? Sure. That is not a real argument on the merits of permitting this choice. It is just saying "nyah nyah I have the power and you do not."
- vidarh 13y ago
  Where did he indicate he wanted to force anyone? Upstream authors are free to use whatever they like. It may impact which distributions wants to include their applications the more repackaging the distribution needs to do to include it, as a resource availability issue, but that's it. Distribution developers already often substantially rework or write init scripts from scratch anyway, and that is exactly one of the reasons systemd is attractive: It drastically cuts down the scripting boilerplate that otherwise has to be done or adapted to their distro for huge numbers of packages. It also contains most of the distro specific stuff outside of init.d, opening the door for lots more reuse. But if you're an upstream developer and wants to ship sys-v init scripts, nobody has the power to stop you. Downstream will either simply write a systemd init file, or you might choose to add one if you like, or if you put LSB comments in your sys-v init file downstream might opt to use that with Systemd if they want to. How exactly is upstream being forced to do anything? How exactly are distribution developers being forced? If they are against their distributions decision, then they have the choice to package something else anyway and either ship it separately or fork the distro.
- 13y ago

pjmlp 13y ago

The main issue is like it ever was with the UNIX wars, now Linux wars. Cloning UNIX was not enough, now each distribution wants to "improve" UNIX on its own way.

xorbyte 13y ago
Not sure how you see progress and innovation otherwise. Much of what is good in Linux comes from experimentation and people/distros 'doing their own thing' which sometime improved the ecosystem, and sometimes resulted in abandoned projects. But things have not stagnated. As for UNIX, perhaps you're familiar with Plan 9? Some of the principal UNIX designers were unhappy with the result, so they went and worked on improving it. Nothing is good enough the first time around.
- pjmlp 13y ago
  I lived through the UNIX wars, where POSIX doesn't mean a thing because each UNIX has its own version of standard and most complex applications still required OS specific APIs anyway.
vidarh 13y ago
None of the current UNIX descendants are all that similar to the original UNIX in the first place. Every single one have tried to improve on UNIX.
- pjmlp 13y ago
  Hence the UNIX wars.
rodgerd 13y ago
If anything, systemd may help rein some of that in but making service files a bit more common across the distros than the various special snowflakisms of each lot of init scripts. Or so we may hope.

exDM69 13y ago

> This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features. This is the argument we've heard over and over again. The problem with traditional unix init scripts, together with cron, acpid, inetd, etc is that you need a big brittle mess of shell scripts to tie it all together to form a system that actually works. While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever, it's not good enough for a desktop, laptop or mobile device. There may be changes in power (mains/battery/low power), network connectivity (ethernet, wifi, mobile) and connecting peripherals (including external disks) and lots of other things which need starting/stopping services or mounting/unmounting partitions. The amount of shell script glue to make these things work is unwieldy and doesn't really work that well. And distribution maintainers have to make a choice, supporting more than one init system is going to be a burden that will hurt end users in the long run. Finally, no one is forcing you to use a systemd based distribution. If OpenRC solves your problems, do go ahead and use Gentoo or another OpenRC based system.

synchronise 13y ago
You're forgetting the traction that OpenRC has gained in the past year, they have already implemented cgroup support and experimental process tracking and it's moving beyond simple shell scripts. It doesn't have feature parity with systemd, but it has portability and it's more permissively licensed, and factoring the speed of development I anticipate that it has a bright future ahead of it.
cynicalkane 13y ago
Not to devalue systemd, but I suspect that a lot of Unix problems could be solved if Unix offered a better general-purpose solution for gluing things together other than "big brittle masses of shell scripts". In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases.
- CrLf 13y ago
  Granted, init-related scripts have become complex along the years, but we may argue that happened because of the same type of reasoning that's now justifying the move to systemd: the need to do everything in one place and automagically. You know, even if I would agree with you that "shell itself is an ugly mess of weird syntax, gotchas, and corner cases" that doesn't preclude init scripts from being redone in something other than shell. "People who don't understand unix are bound to reinvent it, badly." This has become the tag line for Linux, and unfortunately is starting to reach the previously sacred grounds of basic (server) infrastructure.

drewcrawford 13y ago

The dispute here is philosophical. You want a distribution that follows The Unix Way. Where init does its little job and dbus does its little job and so on. Small, simple tools. But there is another way. A way that believes that when you unite the core tools into one powerful process you can do cool things. These cool things have been proven, from the basics like faster boot times, to more advanced features like saving/restoring random seeds, automount, SELinix integration, and so on. You are arguing "this isn't Unix!!!" but that is the whole point. You can win an argument with a mountain climber by pointing out he is going downhill, but not a skier; since for a skier, going downhill is the point. These Linux distributions are not temporarily disoriented mountain climbers accidentally heading away from Mt. Unix. They are deliberately skiing away from it at a high rate of speed. What they will find at the bottom of the slope is an interesting question, but simply pointing out that their strategy is bad for mountain climbing is neither here nor there. What I am saying is, if you want to run an OS that believes in the Unix Philosophy, the shortest path is to install Unix. You are going to have about as much luck convincing Fedora that they ought to be Unix as you would convincing Redmond.

nailer 13y ago
There's also a huge amount of redundancy inside, and between: - SysVinit - xinetd - atd - crond - supervisor - syslogd and the other things systemd replaces. 'Small, single purpose tools' is Unix philosophy. But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors. One could also argue that 'doing one thing well' is handling services.
- pipy 13y ago
  Systemd is controlled by Red Hat in a way in which critical system components including kernel haven't been controlled before. Not by single corporate entity. That's what we know about this company from an old (2007) article: > “When we rolled into Baghdad, we did it using open > source,” General Justice continued. “It may come as a > surprise to many of you, but the U.S. Army is “the” single > largest install base for Red Hat Linux. I'm their largest customer.” [1] It is better to go with a grass-roots solution, even the one technically inferior, that isn't being influenced by one single vendor or government (especially the one that has a tendency to indiscriminately infect other people's systems [2]). Also, the Interface Stability Promise [3] by systemd team is just a promise, nothing more. Will Red Hat keep it if it is to decide at some point, that it no longer serves it's bottom line? I wonder if it can be considered legally binding. [1] http://archive09.linux.com/feed/61302 http://archive09.linux.com/feed/61302 [2] https://www.youtube.com/watch?v=vILAlhwUgIU https://www.youtube.com/watch?v=vILAlhwUgIU [3] http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise/ http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt... Originally posted in this thread: https://news.ycombinator.com/item?id=7210064 https://news.ycombinator.com/item?id=7210064

codex 13y ago

If you have a system made up of small and simple tools, it can only so small and simple things. Imagine designing an airplane this way. It would never get off the ground.