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

121–130 of 158 posts

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

#121

Post by teacup50 »

vidarh wrote: post #95
synchronise wrote: post #87

Earlier quoted context omitted.

Why?

Because the potential upside is tiny. There's nothing in FreeBSD that I can't get in Linux that I have any particular need for. I'm sure there are features that are important and valuable to other people, but that doesn't help me. That leaves near 0 benefit, and some unknown non-zero cost and risk associated with reduced experience with it, potential application incompatibilities and other unknowns, as well as a time…

In FreeBSD land, nobody wastes eons of time hacking out bad code experiments like systemd and then arguing between themselves on whether to distribute them.

It's a stable system you can rely on, year by year. That's not a small upside for a server platform.

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

#122

Post by craigyk »

vidarh wrote: post #77
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 can run without being pid 1. In fact, systemd can run without being root, and by default systemd now starts a systemd user instance when a user session is started (there's a pam module to do this), or you can run systemd with "--user". So if anyone wants to run systemd as a process monitor like Daemontools, separate from pid 1, they can do so. But there are technical reasons for systemd to run as init: A key…

It's funny you mention the systemd pam module. I just recently was configuring a new Linux mint install and enabled ldap and all of a sudden noticed logging in via the desktop or ssh would hang for over a minute. I tracked it down to the pam_systemd module. Not sure what the problem in there was though.

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

#123

Post by pipy »

Tuna-Fish wrote: post #103
pipy wrote: post #89

Earlier quoted context omitted.

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

You do understand that systemd is open source, right? If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it.

> If they decide to leverage their "control" into something the rest of the community doesn't like, we fork it.

I hope so. My concern is that when we'll see systemd grow in size and more and more software depend on it's interfaces and components (as in GNOME with logind) at the certain point it could take an insurmountable amount of resources to maintain the fork. At this point it might be easier to give up on Linux and build around some other kernel and userland, I hope this will never happen, though.

Also, there is a difference between steering the developments in the preferred direction and outright destructive actions. As in https://en.wikipedia.org/wiki/Boiling_frog.

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

#124

Post by teacup50 »

vidarh wrote: post #84
chrisbolt wrote: post #15

Earlier quoted context omitted.

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

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.

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.

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

#125

Post by teacup50 »

exDM69 wrote: post #44
pyalot2 wrote: post #40

Have you actually looked at what systemd does? Here's a handy chart curtesy of wikipedia: http://en.wikipedia.org/wiki/File:Systemd_components.svg 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 responsibilitie…

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

Perhaps you should look into how Mac OS X handles these things while still maintaining separation of concerns. Systemd is a joke of a software design by comparison.

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

#126

Post by d0 »

dschiptsov wrote: post #119
d0 wrote: post #75

Earlier quoted context omitted.

At least windows has a decent and stable init system though!

I think it is debatable whether or not a relation between words "windows" and "stable" makes any sense.

I disagree. The 400-odd Windows machines under my command are incredibly stable, reliable and well performing.

It's not Windows 98 any more.

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

#127

Post by sparkie »

drewcrawford wrote: post #79
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 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 savi…

"The Unix Philosophy" is what everyone outside of Unix calls good software design. Using modular, decoupled components is standard industry practice for most developers with just a few years of experience, and these practices have evolved from half a century of engineering experience, such that we know how not to do things, even if there's no right way.

You wouldn't make a "god object" in C++ or Java for example, and nor would you tightly couple every class in your OOP system by refusing to provide abstraction boundaries. Well, you might do if you're strapped for time, but you would probably consider it a "hack" that needs amending.

That's how some people see systemd, as a hack. It's tightly coupled to the kernel it sits on, and it's a leaky abstraction that exposes much of that to userland processes that depend on the systemd api. In turn, those applications are (or will be) tightly coupled to linux.

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

#128

Post by d0 »

teacup50 wrote: post #121
vidarh wrote: post #95

Earlier quoted context omitted.

Because the potential upside is tiny. There's nothing in FreeBSD that I can't get in Linux that I have any particular need for. I'm sure there are features that are important and valuable to other people, but that doesn't help me. That leaves near 0 benefit, and some unknown non-zero cost and risk associated with reduced experience with it, potential application incompatibilities and other unknowns, as well as a time…

In FreeBSD land, nobody wastes eons of time hacking out bad code experiments like systemd and then arguing between themselves on whether to distribute them. It's a stable system you can rely on, year by year. That's not a small upside for a server platform.

This is precisely why I recently trashed my last few Linux machines and moved them over to FreeBSD. Well to be honest it was because it's absolutely tiresome not having a cohesive well documented system to rely on without the politics and collection of dickhead advocates and pseudo-religious leaders around my ass like mosquitos. Oh and ZFS, MAC, audit, decent ACL support, binary upgrades etc.

However I agree that there is little motivation to move if what you have works. I did mine during a hardware refresh.

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

#129

Post by falcolas »

coldtea wrote: post #109
drewcrawford wrote: post #79

Earlier quoted context omitted.

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

> 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. Besides Linux is not UNIX either. And it's 2014 already, we found that some UNIX choices (like "don't dictate policy" in X Server were bad) and others led to underpowered tools. It's not like we're sti…

You just described both my development environment, and my production environment. Neither needs an overly complicated init system to work.

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

#130

Post by julie1 »

legulere wrote: post #92

Systemd is winning because it makes a Linux system to a modern one. The time where you compiled your own Linux kernel with the drivers you needed and got a static system are gone. The Linux kernel now works in a plug and play way. Block devices for instance can always pop up, not only after you wait and arbitrary amount of time at boot for all devices. The idea that the traditional unix process separation is enough i…

fallacy #23: argumentum ad novitatem
Post reply on HN