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

51–60 of 158 posts

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

#51

Post by hactually »

CrLf wrote: post #49
exDM69 wrote: post #39

Earlier quoted context omitted.

> 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, it's not good enough for a desktop, laptop or mobile device." Sorry for sounding like a troll, but what you're saying is that the traditional approach works alright for setups where unix is actually good, and doesn't for setups where unix is actually crap. Lets exclude mobile devices from this p…

> I don't object to systemd itself, but I do object to systemd invading my servers that work just fine without it.

I think the Lennart and the Red Hat engineering team have more important things to do than covertly install systemd on your server. Please quit with the hyperbole.

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

#52

Post by icebraining »

mercurial wrote: post #37
throwaway092834 wrote: post #29

Earlier quoted context omitted.

Your assertion is strictly false. All features of this new process invocation system could be implemented without making a "new init system." That's my primary point in commenting here. It is a false dichotomy.

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

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

#53

Post by vidarh »

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.

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.

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

#54

Post by vidarh »

CrLf wrote: post #49
exDM69 wrote: post #39

Earlier quoted context omitted.

> 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, it's not good enough for a desktop, laptop or mobile device." Sorry for sounding like a troll, but what you're saying is that the traditional approach works alright for setups where unix is actually good, and doesn't for setups where unix is actually crap. Lets exclude mobile devices from this p…

As someone responsible for dozens of servers and 100+ vm's: The "tried-and-true" init solution is utter shit. It's duct-tape and band aid.

The current init solution does too much. Not in initd, but in the massive mess of scripts piled on top of it to get a working system.

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

#55

Post by Aissen »

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.

Yeah, except systemd is a more a collection of daemons and tools under the same umbrella (and project repository), than a huge monolithic PID 1 daemon. It's even described in the chart you linked.

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

#56

Post by pjmlp »

vidarh wrote: post #53
pjmlp wrote: post #24

Earlier quoted context omitted.

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.

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.

Hence the UNIX wars.

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

#57

Post by dschiptsov »

dschiptsov wrote: post #20

The same way any other crap (such as Windows, Java, PHP, NodeJS, Docker - you name it) wins - its winning is due to a "catchy meme" about it, which triggers an automatic, ignorant snap-judgement of an unsophisticated consumer. Look, with Java you don't have to think about hardware and OS - a greatest meme ever (and you have to pay for tons of hardware because Java = waste). NodeJS - you could code server-side apps th…

I forgot "the web-scale database" with stop-the-world write locks and syncing-buffers-is-not-my-problem and other innovations.

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

#58

Post by pjmlp »

xorbyte wrote: post #38
pjmlp wrote: post #24

Earlier quoted context omitted.

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.

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

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.

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

#59

Post by [deleted] »

krakensden wrote: post #33
throwaway092834 wrote: post #5

This article is a bit off the mark. Daemontools and runit didn't replace init because they weren't designed to replace init, or to be exclusive technical choices in general. Non-exclusivity means no displacement, just happy co-habitation. Daemontools and runit work great under sysv init, BSD init, or under systemd. There's a little piece of insight which seems to escape many: there is no serious technical reason why…

> Systemd is winning this war because it created the war, by conflicting with sysv init Except Upstart also has config files instead of shell scripts. And both of them support all your old sysv init scripts. And writing the config files is so much easier to get right the first time than rolling your own goddamn shell script by default. On a sort of related note, I have never had an interaction with daemontools that w…

[deleted]

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

#60

Post by vidarh »

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…

The problem is not that they're shell scripts. The problem is that they are not constrained in a way that makes it possible to parse them easily and know what the state of the system is expected to be before and after processing.

Instead you're forced to blindly execute them, and hope the script handles all the appropriate corner cases. In 20 years of maintaining Linux servers, it rarely goes more than days between situations where I come across init scripts that fails to account for some situation in ways that causes me aggravation.

It's not uncommon to come across init scripts that regularly fails to stop a service because it has no proper way of determining which pid the process has, for example.

Just the other day I had to deal with a server where the init scripts happily let 3 instances of a server process trying to operate on the same dataset; thankfully the app locked the files in questions and were just screeming bloody murder in its logs, but they were also all three competing for various resources. The init system of course had absolutely no way of telling that something had gone wrong.

The only solution to have a sane server setup with SysV-init is to not use it for anything but the basic tasks and to start a proper process monitor. Then I'd rather just get rid of init entirely, since you're pulling in a bunch of other code that can do almost all of init's tasks anyway.

Post reply on HN