Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd is winning the init wars and other things aren't

utcc.utoronto.ca

Post reply on HN
Print view View original

61–70 of 158 posts

Re: Why systemd is winning the init wars and other things aren't

#61

Post by FooBarWidget »

CrLf wrote: post #50
cynicalkane wrote: post #46

Earlier quoted context omitted.

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.

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 somethi…

I argue that shell scripts became more complicated because of quite the opposite of what you're claiming. The original Bourne shell already supported, piping, control structures, etc. So people thought, hey, why design a new init system that does everything properly when we can just push all this logic to shell scripts and have them act as glue?

It's the perfect example of "worse is better". They chose to keep the core init system simple, but as a result everything else became a complicated mess that doesn't handle corner cases properly. vidarh's comment is spot on.

Re: Why systemd is winning the init wars and other things aren't

#62

Post by rodgerd »

pekk wrote: post #32
rodgerd wrote: post #14

Earlier quoted context omitted.

> 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 Stockho…

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."

> But you get to force upstream authors and distribution developers who would like to be able to use something else? Sure.

How is any upstream developer forced to rely on systemd?

How is any distribution developer forced to rely on systemd?

The only people who are forced to use it are people (like me) who aren't prepared to put in the work of doing something else.

Re: Why systemd is winning the init wars and other things aren't

#63

Post by rodgerd »

exDM69 wrote: post #39
pdkl95 wrote: post #7

"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 ty…

> 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 o…

> While the traditional approach may work alright for a static setup like a server that is booted once and stays on forever,

Actually, it's not. Unless the server also has no dynamic resources and nothing in userland ever changes.

Re: Why systemd is winning the init wars and other things aren't

#65

Post by rodgerd »

pjmlp wrote: post #24
pdkl95 wrote: post #7

"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 ty…

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.

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.

Re: Why systemd is winning the init wars and other things aren't

#66

Post by FooBarWidget »

icebraining wrote: post #52
mercurial wrote: post #37

Earlier quoted context omitted.

> All features of this new process invocation system could be implemented without making a "new init system." Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse. If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency s…

I think the point is that you could have the old init system launch systemd, which would then work as it pleased.

Then you have two init systems. That's even more complicated than having only systemd.

Re: Why systemd is winning the init wars and other things aren't

#67

Post by FooBarWidget »

pyalot2 wrote: post #48
exDM69 wrote: post #44

Earlier quoted context omitted.

> 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 shor…

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.

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.

Re: Why systemd is winning the init wars and other things aren't

#69

Post by mercurial »

icebraining wrote: post #52
mercurial wrote: post #37

Earlier quoted context omitted.

> All features of this new process invocation system could be implemented without making a "new init system." Er, no. A major feature of systemd is that it is declarative. You have hooks for running custom commands, but a unit file is declarative and easy to parse. If you want to acquire more intelligence about an init script, you have to resort to disgusting hacks like parsing comments in order to get a dependency s…

I think the point is that you could have the old init system launch systemd, which would then work as it pleased.

I'm not sure this was the point of parent, but anyway, why would you want something like that? It's not like sysvinit has any redeeming feature, and you would still want to have systemd .service files. I could understand an argument like "/bin/systemd does too many things and ought to be split up more", but the rationale for having bad old sysvinit launch /etc/init.d/systemd.sh escapes me. Not to mention that you definitely don't want both systemd and sysvinit to attempt to launch scripts in /etc/init.d, when they don't have a .service...

Re: Why systemd is winning the init wars and other things aren't

#70

Post by awalton »

throwaway092834 wrote: post #18
colin_mccabe wrote: post #13

Earlier quoted context omitted.

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 handl…

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 li…

You're really good at copying-and-pasting canned responses from previous comments... throwawayhugerandomnumber
Post reply on HN