
Why systemd is winning the init wars and other things aren't - onestone
http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdWhyItWon
======
ChuckMcM
Interesting follow-up, this stuck out for me:

 _" To start with and as usual, social problems are the real problems."_

This really resonates with me. Once any organization gets to a certain size,
getting change to happen is more "social problem" and less "technical
problem." When you don't select for people at that stage who can move an
entire organization over to a new way of doing things, your organization will
stagnate and die. It used to really annoy me at Google when technical
evaluators who dismiss those "soft qualities" in candidates. I had a fairly
famous Googler tell me point blank that anyone could change the organization
by shouting loudly enough. Which I tried to explain was just as false as
saying anyone can solve a problem if they write enough code. But alas, they
were not ready to hear that at the time.

The author makes an excellent point that much of the root of the
"disagreement" can be summed up with a strong sense of "I wouldn't have done
it that way." Which is no doubt true, but it has to be combined with "I would
do it like this, and I'm willing to spend the next 3 - 5 years listening to
the community and addressing their concerns." I certainly see that is a much
bigger commitment.

~~~
theophrastus
yes indeed social problems. or as one of my favorite quotes goes: "Trust no
one! The minute God crapped out the third caveman, a conspiracy was hatched
against one of them!" \--Col. Hunter Gathers, OSI (Venture Bros parody of
Hunter S. Thompson)

~~~
teddyh
More likely, _three_ conspiracies were hatched, one against each one of them.

------
throwaway092834
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 must run as init_. Systemd could have
been written to coexist in a number of various ways following previous models,
running under init and doing things for init.

Systemd is winning this war because it _created_ the war, by conflicting with
sysv init.

~~~
vacri
The article specifically says what you're saying: _I don 't think any of them
have really been developed with replacing SysV init in Linux distributions or
elsewhere as a goal. DJB daemontools certainly wasn't_

 _Systemd is winning this war because it created the war, by conflicting with
sysv init._

Upstart predates Systemd, systemd just has more traction.

~~~
throwaway092834
Sure. What I think is unclear that I intend to highlight is that systemd (and
yes, upstart) have intentionally and unnecessarily created this technical
conflict.

~~~
vacri
well, I wouldn't call the technical conflict unnecessary - if there wasn't a
need for a more featureful init system, then there wouldn't have been a motive
to write a new one. As for the social conflict, that's just what you get with
social groups experiencing change.

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

~~~
mercurial
> 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
system working. And socket-based activation? Sysvinit is a dead end. It's the
counter to "keep it simple, stupid": when you fail to capture enough
information in your "simple" model, you are going to end up with more issues
than if you had created a slightly more complex system.

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

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

~~~
throwaway092834
We already do. I think most people in this discussion aren't realizing that
the current sysV init system is an extremely small pid 1 /sbin/init, and most
of the logic in external rc scripts. Moving rc scripts to systemd declarative
syntax is fine.

The important part with respect to software architecture is less complexity in
pid 1. Subprocesses of init can be safely updated and restarted. More code in
init is a real problem -- that's why systemd as pid 1 is controversial.

~~~
mercurial
At the same time, there is a point to be made for having things in a single
process - this makes it much easier to ensure that the crucial parts of the
init system are available and working.

~~~
throwaway092834
Can you elaborate? I don't understand this perspective.

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

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

~~~
pdkl95
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 themselves a unix (in the generic, no
trademark), and alternative to Unix (tm, aka Solaris, HP-UX, and others
derived from Bell Labs IP) [http://www.redhat.com/solutions/migration/migrate-
from-unix-...](http://www.redhat.com/solutions/migration/migrate-from-unix-
platforms/)

Wikipedia, on fedora: "OS family: Unix-like"

etc

When the term "Linux" is used in general, we mean a unix. The distinction has
only ever a trademark thing.

So yes, refugees from Windows coming over to distros that have _always_ been
unix(-like) and trying to change them into the some sort of Windows-like junk
is a problem. Some of us left that world of bad design little choice a long
time ago, and have no intention of returning.

~~~
drewcrawford
> They've certainly called themselves a unix (in the generic, no trademark),

At one point, they probably were a Unix. But Unix as a _place_ and Unix as a
_goal_ are two very different things. Both skiers and mountainclimbers find
themselves at the tops of mountains.

> When the term "Linux" is used in general, we mean a unix.

 _You_ mean a Unix. I mean Linux. There is no "we".

> So yes, refugees from Windows coming over to distros that have always been
> unix(-like) and trying to change them into the some sort of Windows-like
> junk is a problem.

I don't believe you. Where are these vanguard Unix-style Linux distros? RHEL?
Adopting systemd. Debian? Adopting systemd. SUSE? Adopting systemd. These are
distributions from the days of old. They have formed a consensus that systemd-
style Linux is the future.

I mean I think it is fair to say that the Linux community is divided on this
issue. But characterizing the systemd/dbus/ufs folks as "Windows refugees" is
totally inaccurate. Systemd has the backing of important community members of
the Linux community.

------
spartango
Petty politics aside, it seems to me that the comparisons between Systemd and
Upstart are analogous to those between launchd and Solaris' SMF.

The crux of the comparison is whether init should explicitly follow a
dependency tree or resolve dependencies dynamically.

The other complaints fall out of that concern: in following the launchd model
of dynamic resolution, systemd is forced to bundle in complex features. On OSX
launchd serves as a hub from day one, so coordinating IPC and mount-watching
is not so foreign. Similarly, this hub functionality restricts modularity,
although launchd doesn't subsume autofs fully.

The reality here is that we're looking at a philosophical difference. While
religious wars start over which is the "right" view, I'm unconvinced there is
one. Much as SMF and launchd are comparably functional, so will upstart and
systemd be.

------
wila
I read his article and didn't see anything besides "it is better because
well.. it is better" without much technical explanations on the why. Then read
over it again and saw a link to his earlier article.

[http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight](http://utcc.utoronto.ca/~cks/space/blog/linux/SystemdRight)

which does help defend his position even while I don't share his opinion.

------
bifrost
This seems like a solution in search of a problem. Yes, restarting broken/dead
processes is handy, but this is not the job of init.

I can't wait to run regedit.py to fix my broken box...

------
pyalot2
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](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 responsibilities as such.

~~~
exDM69
> 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 shortage of people who
insist on doing things the way they were done before but to me, systemd makes
a lot of sense.

It's true that it combines things that were previously done by cron, acpid,
getty, pam, etc to deal with power management, network connectivity and login,
etc. But I still find it a better alternative than having a lot of
distribution specific shell scripts gluing all those individual services
together. Besides booting faster, there are advantages like better fault
tolerance and consistency.

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

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

~~~
jude-
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).

~~~
Narishma
You could say the same thing about the Linux kernel, yet it hasn't stopped
improving.

~~~
jude-
First, the boundary between Linux and the rest of the system is very well-
defined. I can run my userspace on top of multiple different kernels, since my
userspace is loosely coupled to Linux (yes, there are exceptions, but not so
many that it prevents GNU/kfreebsd or GNU/solaris from working, for example).
This is not the case with systemd, which over the past several years has been
subsuming larger and larger swaths of userspace, introducing all sorts of
tight couplings and inter-dependencies that weren't there before.

Second, the pace of innovation in Linux is definitely slower than in
userspace, and getting your patches adopted is more difficult relative to most
userspace programs (this is the high barrier to entry I spoke of). Your
patches either have to get approved by Linus et al., or you have to host them
out-of-tree and hope your users know how to apply them and compile the kernel
themselves (and if you want to do this for them, you have to do it for every
kernel you need to support). If you're lucky, your patches can be isolated
into a kernel module, in which case you "only" need to keep it up-to-date with
the kernel API (which is a moving target).

Contrast this to working on a program like, say, xinetd. While the option for
submitting patches still reduces to "go through the maintainer" or "host them
yourself", the "host them yourself" option is much more tenable, since the
codebase is smaller, and the "don't break userspace" policy Linus enforces
ensures you aren't coupled to a moving-target API. The lower barrier to entry
brought on by loose coupling explains why Gentoo can get away with forking
udev, but not large swaths of the Linux kernel.

Systemd has the effect of making innovation in the plumbing layer (xinetd,
syslog, udev, cron, etc.) a lot like innovation in the Linux kernel. Can you
imagine the absurdity of having to maintain a version of xinetd for each
separate systemd API change?

------
legulere
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 is from the
same time as the gets function. The Linux kernel here offers cgroups for
better seperation.

~~~
julie1
fallacy #23: argumentum ad novitatem

~~~
legulere
I'm not claiming that hot-plug is better, but that hot-plug is the status quo
of the kernel. Modern here means that it integrates well with a modern linux
kernel.

Also grouping processes together and isolating them is not really new but a
proven technology (FreeBSD jails, virtualization). It's also pretty hard to
argue against that the knowledge about security of unix systems didn't
increase.

The irony about the fallacies is that just throwing them around even without
writing a sentence goes against the very nature they were conceived in. The
corresponding counter-question would be: "Why is modernity here something
good?", but that question is already answered in the post to begin with.

~~~
julie1
You are right.

I am actually in a phase of archeology where I read a lot of rob pikes, ken
thompson, ted nelson, linus torvalds, esr ...
([http://harmful.cat-v.org/](http://harmful.cat-v.org/)) and I begin to
question myself a lot of things. Even the statu quo.

At work I deal with a lot of dependency hell (system and distributed software
requirements, confinments (VM and chroot or jails)) and I begin to doubt some
of "the wisdom and progress" I have been adopting.

I search for answers now because I think some old "conceptual bugs" are
bitting us very hard (like the way http url are built, threading, shared
libraries, the abuse of concurrency) and I don't know anymore what progess is.

I just kind of feel status quo is a very old hard rock band that should be
forgotten :)

------
falconfunction
What about openrc?

[https://wiki.gentoo.org/wiki/Comparison_of_init_systems](https://wiki.gentoo.org/wiki/Comparison_of_init_systems)

What's up with the words words words

~~~
exDM69
According to one of the links in the original article, OpenRC and sticking
with SysVinit were also evaluated as options early in the discussions.

~~~
falconfunction
I'm sorry could you post a link?

I just really don't like how this stuff is couched in words from either an
apt/yum dudes blog that focuses on boot time.

~~~
exDM69
No, I can't post a link. That phornoix article only links to other phoronix
articles and I can't find a way to an actual discussion thread or meeting
minutes from people that were actually involved and I don't have time to
search for one.

~~~
falconfunction
It's cool, everyone digs monolithic stuff anyway.

------
rdn
Hopefully what happened with pulseaudio does not happen with init

~~~
stephen_g
It can't really - the problem with PulseAudio was that it was adopted by a
major Linux distribution before it was ready for primetime. It worked well
after a while.

Systemd is has been the main init system of several distributions (like
Fedora) for some time now, so I wouldn't worry.

------
sparkie
This article lacks any real substance, and perhaps that embodies my dislike of
systemd in general. The demonstrate what I mean, I've modified the parent
article, replacing "systemd" with "Windows", "sysv" with "Unix", and "init
system" with "operating system", plus a bunch of other title changes to make
it coherent, without really modifying the impression of the post:
[http://pastebin.com/sLsDVBG8](http://pastebin.com/sLsDVBG8) (Don't take it
too serious.)

Obviously this is just a bit of humor, but it sounds like something that
could've been written in 1990, and the popular choice at the time has made at
least a generation of developers and sysadmins suffer, and which some are
still suffering from. I think the lesson we can learn is that "ideas" are not
unimportant, and should be properly looked at before jumping to binding
decisions, because what "solves your problem" now, may cause significantly
more in the future.

------
luuse
The biggest fear i have after reading all of the latest articles popping up is
that it's too monolithic, just as a lot of other people. However from reading
on their faq it seems they've split out into several different processes and
if the processes themselves are well scoped i can't really see the problem?

I tried googling for something but i can't find any good documentation about
what different processes systemd uses and how they interact and their roles in
systemd? Anyone have any tips?

------
awalton
Wow. This is the sanest commentary about systemd and the state of things I've
read to-date.

------
evilDagmar
There are _numerous_ problems with the argumentation being used here. Starting
from the top, the first one is actually kind of silly.

"none of these alternate init systems did the hard work to actually become a
replacement init system for anything much."

This conveniently overlooks whether or not there was any reason to do so. The
scope of "classic" init is very simple. Its scope is well defined. It amounts
to "start and stop the services when they're supposed to be started and
stopped" and that is _all_. Those other init systems mentioned all expanded
the scope of the problem of starting and stopping service a bit further, but
only a tiny bit along the lines of deciding whether a county border should be
on one side of a twisty creek or the other--in practice, very few people even
care. Systemd expands its scope by _miles_ and strides boldly forth as a proud
example of _scope creep_.

The bulk of the rest of the argument amounts to "Well, systemd did all this
hard work!". This isn't KINDERGARDEN. Its insane to argue that people should
be giving systemd a free pass simply because the developers _worked really
hard on it_. All those edge and corner and simply misbehaving daemon cases
aren't things systemd should be more than peripherally concerned with--they're
things to push back on the original developers to fix from the start, and in
the meantime those workarounds should be held in their proper regard... as
_workarounds_, not major features, because again... _scope creep_.

Lastly, while they're busy giving systemd points for trying real hard and
solving a bunch of problems that it shouldn't be bothering with, they ignore
the fact that systemd was busily creating _new_ problems... but I'm sure
they'll also credit systemd for solving those as well. Specifically Poettering
himself recently posted about a "bug" with apparent filesystem corruption
caused by systemd failing to properly unmount a filesystem when it's
upgraded... during which at some point they appear to have decided that PID 1
is some mystical holy number (which it is _not_) and that going back to the
initrd the system booted with is a completely fine and reasonable thing to do,
and that it is not, in fact, a sign that one has seriously painted themselves
into a corner. They're essentially arguing that they didn't paint themselves
into a corner because they're standing in the middle of a long hallway...
surrounded by paint... and that the real problem is the lack of roof access.

It's a _huge_ workaround for what is simply _not_ a problem for a small,
simple initd that _only_ handles a small, well-defined problem and handles it
correctly.

...but you pro-systemd people enjoy having to explain why half the core system
functionality has to stop whenever you have to upgrade _any_ of it. The rest
of us will continue to use systems that do what they're supposed even while
being upgraded.

------
dschiptsov
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 the very same way you write stupid
web-pages (without any deep knowledge) - great meme. With Docker no sysadmins
are required, and an underlying operating system is just viewed an abstract
"container" for an app (they you _will_ pay to "experts" who would spend weeks
analyzing why your crap is _so slow_ and unpredictable in production). With
systemd you don't have to understand the subtleties, and it is run with
Docker. Yay!

The list could be too long.

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

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

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

It's not Windows 98 any more.

~~~
dschiptsov
Do you apply updates? If so, have you ever seen how it breaks functionality of
legacy code? Never seen problems with third party tools like Delphi or Java?
Never seen Trojan or a virus?

~~~
d0
Yes we apply updates after _testing them_. MS11-100 was the only breaking
change we've had in 10 years and we picked that up in test no problems at all
and knew about it as we read about it before applying the patch in the KB
article that accompanied it. Did you know Ubuntu LTS releases shipped buggy
and broken MySQL versions multiple times? We caught them in testing. Canonical
haven't fixed MySQL in 10.04LTS yet.

No problems with Java, ever in 10 years. We don't use Delphi. Did you know
that Debian broke the entire SSH key generation infrastructure for a bit
leading to insecure key generation. We regenerate our own keys up front
anyway.

Never seen a Trojan or virus because we have proper mitigation at the edge of
our network and on critical machines and everything is locked down properly.
Did you know about SSH worms -- you know the things that hammer the crap out
of every node with SSH on it for the last 5-6 years? We mitigate at the edge
(authenticating firewall).

If your opinion of windows is based on such things, you're approaching the
problems wrong.

~~~
dschiptsov
I never seen any statistics about bootnets hosted on rooted Debians. I also
remember that in Metasploit framework the number of exploits targeting windows
is incomparable larger than Linux related. The last time I made a firewall it
was OpenBSD/spark64 based, and I think it is still in production. I never used
Debian or Ubuntu as a server. There are Centos or RHEL for that, and I am
capable to recompile and repackage any tool I needed.

Sorry, I cannot understand most of mentioned difficulties.

~~~
d0
Likewise I don't understand your POV -- in fact I think you're spouting
rubbish much as most advocates seem to. I've been dealing with Windows, Linux
and BSD systems for 20 years and there's really not much in it between them.

The bad rep Windows gets is from idiot users clicking Ok. If we had user
friendly OpenBSD desktops with idiots pushing the buttons we'd have the same
statistic with a different OS.

The brand doesn't matter - the fundamental problems are the same.

~~~
dschiptsov
Let's say that I am very sceptical about _any_ proprietary bloatware pushed by
big money and developed by outsourcers on a payroll. I also do not believe in
the myth that these corporations employ more talent that is behind some
selected open source projects and startups. In Russia where traditionally IT
is heavily dominated by Windows and now Java and SAP, I have seen enough, and
it is what biased my POV.)

~~~
d0
Oh I agree entirely with you there.

Forget the words bloatware, outsourcers and money for a minute...

Surprisingly it's rarely the core products of the companies that are
problematic. It's usually the army of consultants and cash backhanders (the
enterprise lot) who come wading in to pillage everyone. That's where the bad
rep comes from. They build half-arsed products on top of these platforms which
everyone comes to hate.

Regarding open-source talent; much as it is anywhere else, it's hard to come
by. In fact a lot of the open source software out there is considerably worse
than the closed source stuff that I've seen over the years. There are a few
gems here and there for example the FreeBSD operating system, LLVM, valgrind,
postfix, postgresql etc but the vast majority is total half-baked shit. I
include a big chunk of GNU in that as well which is shameful.

The vast majority of commercial software is total shit too.

Regardless of that, the core of Windows and even Java (but not SAP - I've had
my fair share of integration there) are good products. Just don't go and grab
piles of enterprise integration junk on top and it's fine.

That, IMHO, is where all the pain comes from and why people have such hatred.

Hatred is infectious as well. It takes experience to distinguish justified
hatred and rumors.

------
Fasebook
"init wars" what a joke. the fact that systemd has "declared war" on other
init implementations is all the information I need.

~~~
krakensden
See, you're missing all the fun drama:
[http://lwn.net/Articles/583182/](http://lwn.net/Articles/583182/)

~~~
Fasebook
No thanks.

------
blueskin_
Because nobody wants Canonical to control a critical part of their distro.

~~~
pekk
Better to have Red Hat in control of Debian, then?

~~~
blueskin_
In preference to Canonical, yes.

systemd is more open, has a greater count of contributors, and is already more
widely adopted with more distros planning their move to it. I'm not saying
it's without problems, but anything (including keeping sysvinit) is better
than Upstart.

GNOME is practically a Red Hat project these days, but people aren't
advocating its removal (although yes, GNOME is awful since 3.x)

As it is, Red Hat already maintain or otherwise have a hand in a _lot_ of
things that are in Debian - seeing them as somehow adversarial isn't true,
while Canonical have a long tradition of keeping their own work close to their
chest and not sending improvements upstream.

