Because nobody wants Canonical to control a critical part of their distro.
Better to have Red Hat in control of Debian, then?
Why systemd is winning the init wars and other things aren't
101–110 of 158 posts
Re: Why systemd is winning the init wars and other things aren't
#102Earlier 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.
> In particular, shell itself is an ugly mess of weird syntax, gotchas, and corner cases. Just like C! (syntax is mostly OK though). This is not coincidence. If your modus operandi is "works 95% of the time" then you end up with C, shell and sysvinit collectively known as Unix.
Years passed and we discovered a bunch of things. Everyone agree that Bash syntax could be better, and C is not perfect either (that's why new languages like Rust are being developed). We didn't reach perfection a couple decades ago, so if someone want to try and replace the good old tools, I say "go on!": it would be exciting to see something better.
Re: Why systemd is winning the init wars and other things aren't
#103Earlier quoted context omitted.
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 .
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.
Re: Why systemd is winning the init wars and other things aren't
#104Earlier quoted context omitted.
> 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.
And there you exactly pinpoint the problem. The FLOSS movement used to be about caring about other people and projects. RedHat* and its employees only give a damn about their use-cases and the rest of the "community" can go to hell. Which, of course is a logical stance to take for any corporation, however how easily everyone goes along with it is just appalling. *this, of course, goes for every corporate entity, thou…
How have I pinpointed the problem? I'm sorry - are you arguing that the RH guys should be covertly installing systemd in the parent posts servers?
Re: Why systemd is winning the init wars and other things aren't
#105Earlier quoted context omitted.
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.
I think what the parent is getting at is that, even though there are many daemons and tools that make up systemd (and even though they are each scoped to a particular concern it addresses), most of them are tightly coupled to one another. To run logind, for example, I need systemd to run as PID 1.
This monolithic architecture is unsettling in the long term--it raises the barrier to entry for independent innovation in the same space. At least before, the various daemons systemd replaces (atd, crond, xinetd, acpid, udev, dbusd, etc.) could be independently modified, disabled, or replaced without breaking each other, and without much hassle. Instead, improvements to systemd's daemons have to conform to a moving-target API in the same layer (other systemd daemons) and the layer beneath them (systemd PID 1), as well as the layer above them (i.e. the UI).
Re: Why systemd is winning the init wars and other things aren't
#106Earlier 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…
I am not seeing any justification for why these tools HAVE to be a single, monolithic tool. > script glue That's what shell scripts[1] are FOR - they are the minimal glue that binds the large applications together. Besides, "big brittle mess" is a matter of opinion. Are you trying to tell me that this OpenRC script is a "mess" that needs to be replaced, taken from /etc/init.d/cupsd my current desktop: #!/sbin/runscri…
So my cups.service is:
[Unit]
Description=CUPS Printing Service
[Service]
ExecStart=/usr/sbin/cupsd -f
PrivateTmp=true
[Install]
Also=cups.socket cups.path
WantedBy=printer.target
People continually spew the line about the UNIX philosophy. If you want to use Unix, use Unix.
Linux is [becoming] better than Unix.
Re: Why systemd is winning the init wars and other things aren't
#107Earlier quoted context omitted.
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 .
> There's also a huge amount of redundancy inside, and between, SysVinit, atd, crond, supervisor, syslogd and the other things systemd replaces. Such as? I'm pretty sure code shared between these systems lives in (or could easily be moved to) shared libraries, specifically to avoid this problem. But this is orthogonal to the design of the init system. > But DRY is engineering philosophy. Each repeated piece of logic…
> Specifically, DRY is not an excuse to forbid competing init system implementations
No-one is forbidding anything. You can run Debian with any init you choose. All we ("systemd proponents") want is that when upstream software decides to depend on something systemd provides, the debian maintainers don't have to (they can, if they feel like it) bend over backwards to replicate all systemd features for non-systemd platforms. Not demanding unpaid volunteers to do extra work is not the same thing as forbidding other init systems.
Re: Why systemd is winning the init wars and other things aren't
#108Earlier quoted context omitted.
Say something comes along at that point and kills systemd. Now everything below it is orphaned and has init as it's new parent. Sysv-init does not know what to do with those processes other than reap zombies. Now you have a system full of unmonitored processes, just as without systemd, and no standardized way of restarting the services. This is why systemd needs to run parts of its logic in pid 1 to be most compellin…
But if systemd was pid 1 and something killed it, you would have a kernel panic. How is that better than a system with a bunch of unmonitored processes? At least with the latter you can safely bring down the system, instead of having a hard crash.
Pid 1 is special - it can't be killed.
It can crash due to bugs it can't handle, or it can voluntarily shut down.
Try it:
vidarh@opus:~$ sudo kill -9 1
[sudo] password for vidarh:
vidarh@opus:~$
In the case of systemd, if it runs into a non-recoverable situation, crash() in core/main.c gets called, which then proceeds to try to create a core dump and spawn a shell as an absolute last resort to give an admin a chance to take corrective action, which is already a step up from your typical init assuming the manage to get the part of systemd that runs as pid 1 (by no means all of systemd runs as pid 1) as stable/bug-free as your usual init.
Of course there's an uncertainty there, and they'll have to prove they can keep that part rock solid or it'll be useless.
Re: Why systemd is winning the init wars and other things aren't
#109"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…
>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 still on text terminals, running 2-3 daemons at most, each with simple needs, and most of our work is constrained in the textual domain.
Re: Why systemd is winning the init wars and other things aren't
#110Earlier 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…
I would generally agree with this. This philosophy (along with it being Free Software) is why I chose to migrate to Linux in the first place, so long ago: it was Unix . Ya, ya, "Unix-like", technically, due to the trademark on Unix. That last statement is very strange: > Fedora that they ought to be Unix As somebody who wore an authentic Red Hat fedora for many years, this makes no sense. They've certainly called the…
>When the term "Linux" is used in general, we mean a unix. The distinction has only ever a trademark thing.
Not really. The implementation of the kernel, userland features etc are quite different between traditional derived unices and Linux.
But it sure is a full blown POSIX.