
Systemd redux: The end of Linux - bcantrill
http://blog.lusis.org/blog/2014/11/20/systemd-redux/
======
AaronFriel
Perhaps this is a controversial idea, but is this not just someone finally
taking the tried and true Open Source "advice" to heart?

That is, every time I've reported something is broken, wonky, doesn't work
reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or
worse, "Implement it yourself."

Someone finally got fed up with the haphazard state of affairs in Linux-land.
Fed up with the fragmented and sometimes many places you have to look for
error logs. Fed up with the many files you have to edit to configure the
network correctly (different on every major distribution). Fed up with the
half dozen ways to configure X, where X is a common function to every modern
operating system.

It seems Lennart has taken the advice and followed through, and distribution
maintainers liked it. They liked the idea that someone was taking all this
complicated work - this dirty, boring to write and maintain code - and making
their lives easier. Why else would nearly every distribution be on board?

Systemd is offering a more compelling solution than anyone else, and if you
don't like it, well, you should submit a patch, write some code, or implement
it yourself.

~~~
badgersandjam
I had no opinion on systemd until yesterday. In fact I had a glace or two at
the code and it's pretty clean and I liked the rough objectives laid out.

I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on
and was poked in the face with timedatectl and dbus problems for an entire
hour, some of which were intermittent. Debugging these issues is a horrific
pain. I lost 4 hours on it. I've never lost that much time on a system
function before. This is not what I expected and there is no way I could
possibly introduce that to our production environment.

I think that might why people are slightly sensitive to it.

Yes you're exactly right, but replacing something with something less stable,
more complicated and more difficult to debug isn't a rational or good
engineering. I'm sure many people will be fed up with systemd much quicker
than what was already there.

Not impressed with a community which pushes this as stable, quality software.
Voting with my feet: FreeBSD is being trialled instead. WhatsApp throwing a
million dollars at it draws a lot of valuable attention and puts it in the
business's mindset.

Choice is as much of a valuable aspect of open source too...

~~~
seivadmas
You know this is funny, I remember reading comments EXACTLY like this about
3-4 years ago but with pulseaudio in place of systemd.

Pulseaudio was Lennart's previous project. It broke everything in linux sound
for a while, everybody moaned and hated it and said it was the worst thing
since the crucifixion of Christ.

Yet, name one problem you had with sound on linux in the past year? There are
very few. Pulseaudio now just works(tm) and is a unseed, unheard of part of
the plumbing.

If you remember what is was like messing with ALSA and (shudders) OSS before
pulseaudio came along you will agree that the current state of affairs is a
million miles better. It used to be really difficult to get more than one
application to be able to play sound at a time. I remember compiling sound
drivers from source just to get them working. Configuring ALSA config files to
get surround sound working was practically a black art. Creating manual
scripts that unmute the sound card on every boot because the driver didn't
initialize it properly.

With pulseaudio, I never have to worry about any of that and configuring
surround sound takes me two clicks of the mouse.

Lennart did a fantastic job with pulseaudio, he took on a dirty problem that
nobody else dared to touch and went through years of criticism to produce a
really high quality solution that solved the linux audio problem so well that
you don't hear complaints about it anymore.

In light of that, I trust him to do a good job with systemd. It'll be a couple
of years of everyone moaning and bitching and whining about it, then one day
it will have become a seamless part of the plumbing, everyone will take it for
granted and wonder how they ever managed fighting with shell scripts and
fragmented init systems before systemd came along.

It's ironic that Lennart Poettering is probably the most abused developer in
the entire OSS ecosystem, yet he is one of the people contributing most to it.
For our sake, I'm glad he has such a thick skin. If I was him I'd have quit
this game long ago.

~~~
byuu
> Yet, name one problem you had with sound on linux in the past year?

That's just it. Linux sound worked fine for me before Pulseaudio, and FreeBSD
sound has always worked perfectly fine for me. In fact, FreeBSD solved sound
mixing sooner via /dev/pcm virtualization (while Linux chose to create the
Linux-only ALSA instead), and has always had lower observed latency.

Pulseaudio screwed up my audio so badly that for a year I was running the
closed source OSSv4 binaries and manually recompiling all the audio libraries
to use OSS instead of ALSA/Pulse.

It is not fantastic to push horribly broken code onto the entire Linux
userbase while others frantically jump in to help patch and fix the
trainwreck.

And we're doing the same thing again with systemd. Instead of having a few
years where users can choose between systemd, sysvinit, openrc or upstart,
while all of the major bugs are worked out, we're being forced immediately
from sysvinit (Wheezy) to systemd (Jessie). I was on Lennart's treadmill with
Pulse, I'm not getting on it again with systemd.

~~~
baldfat
WAIT you NEVER had an audio problem in Linux before PulseAudio? I would have
said the weakest link in Linux on desktop WAS audio.

Now PulseAudio was released into the wild too soon by too many distros BUT it
has fundamentally fixed what was HORRIBLE in Linux. (Previously a Sound
Engineer and Record Studio owner)

BUT I would say that Systemd is extremely stable and not broken. What people
are complaining about is the philosophy aspect.

~~~
byuu
> WAIT you NEVER had an audio problem in Linux before PulseAudio?

To be fair, I didn't say I _never_ had Linux audio issues prior to Pulseaudio
(whereas I did say that about FreeBSD.)

Back in '98, my SB16 ISA card would only output sound at 8-bit monaural under
mikmod, and I could only play CD-audio with that passthrough cable between the
CD-ROM drive and the sound card. Once I was able to get sound working well
enough, the only way I was able to play MIDIs was through Timidity and
Soundfont emulation. And until ALSA, there was obviously pain whenever two
things would want to play sound at the same time. This of course was due to
the OSSv3 author changing the license before introducing his own audio mixing,
and all of those awful sound server daemons (esd et al) never really worked,
since there were multiple daemons and each application wanted different
daemons or just wanted to stab right at the OSSv3 ioctl's.

But once ALSA was established and working, yes. Audio under Linux at that
point worked just fine for me. Pulseaudio was a solution looking for a
problem.

> (Previously a Sound Engineer and Record Studio owner)

I won't claim to be either of these. I like to listen to music while I write
code, I'll occasionally watch some movies or play some games, and I want
Pidgin to make a chime when someone sends me a message.

In particular, I'm very sensitive to latency in gaming (emulation), but that's
about the extent of what I need speaker sound output for.

> What people are complaining about is the philosophy aspect.

To me, the worst part is the backroom politics, the complete disregard for
portability, and the lock-in effects of consuming other daemons and services,
and making software dependent upon it.

However, I do also object to the design itself, as well as to the developers
responsible for working on the project, and the attitude of disdain they
present to the community at large.

~~~
baldfat
The thing is that we HAD TO HAVE JACK to over come latency in Linux and MAN
that was HARD and once it worked DON'T mess with it or else 3 hours later you
had a broken keyboard, mouse and monitor.

The issue was ALSA was HUGE latency to use for anything in recording was just
not doable! I had to buy a closed source solution under Windows. Today I could
easily do it in Linux.

------
matthewmacleod
Really bored of this nonsense at this point. Take this for example:

 _If you absolutely MUST run Linux, my recommendation is to minimize the
interaction with the base distro as much as possible. CoreOS (when it’s
finally baked and production ready) can bring you an LXC based ecosystem_

Systemd is absolutely key to how CoreOS works. It's the basis for the
distributed init system it provides — a major selling point.

Taking any of this blog's advice would be harmful. I'd suggest a better
approach would be to accept that the majority of distributions have settled on
systemd and that generally this decision has not been made by idiots. So it
would be worth either understanding what their pain points are and how they
can be solved with an alternative to Systemd, or to help solve the issues that
are apparently in Systemd yourself.

~~~
badgersandjam
Many large decisions have been made by idiots, badly. Blindly accepting
consensus as a rational choice without a counterpoint had caused many years of
suffering for the human race from wars to bad science to bad medicine.

Whilst I agree that the blog is probably hocum, there's nothing wrong with
critical thinking.

~~~
matthewmacleod
I completely agree – but critical thinking involves something along the lines
of "here are the things that I think are wrong, this is why I think they're
wrong, this is how I think they could be solved."

The answer "let's throw everything out" isn't that useful; likewise,
dismissing the considered opinion of lots of people who have been doing this
sort of thing for a while needs to be done with some rationality. An empty,
bandwagon-jumping appeal like this adds little value and just helps spread
more misinformation.

~~~
badgersandjam
Actually the answer is to be slightly more conservative with the approach. No
one has to pick up systemd now for example. Leave it a year and see where it
is. The technical merits will be obvious and the technical problems will also
be.

Moving all the chess pieces at once, which is what is happening is not
productive, professional or a sign of experience.

~~~
matthewmacleod
That's not the case though – systemd has been enabled by default by Fedora for
three and a half years or so, and has been steadily adopted since then by most
other major distros. Not everybody is moving at once, so why would waiting a
year make any difference?

~~~
badgersandjam
This bugzilla query against RHEL 7.0 systemd says otherwise:

[https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s...](https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&classification=Red%20Hat&component=systemd&product=Red%20Hat%20Enterprise%20Linux%207&query_format=advanced)

A lot of the bug descriptions are quite scarily bad when you consider them in
context such as "various loginctl commands not working" etc.

~~~
matthewmacleod
So what you mean is "Systemd still has serious bugs," which is nothing to do
with whether or not everybody is moving at once.

That's the point – if systemd has important bugs _they should be fixed_.
Clearly, the groups responsible for the decision have concluded that the
tradeoff is worth it, and have accepted that a large, fundamental change will
have issues. That's fine – there are a bunch of other distress you can use
that have not adopted systemd, which you can use in the meantime if you
disagree.

~~~
badgersandjam
The two are related.

People are shipping production operating systems with systemd that is chock
full of bugs.

An all consuming tentacle monster like systemd is fine if you want to dogfood
it but to throw at paying customers and/or supporters of your distribution is
a little off key.

------
api
One thing I've realized about the Linux community through all this systemd
flame warring is how unbelievably conservative a large subsection of it is.
There's this huge so-called "neckbeard" continent that views anything
architecturally beyond the 1980s as a huge affront to Unix.

IMHO I kind of shrug at this, since Unix was never really all that great to
begin with. Unix won because the only _commercially viable and well supported_
alternative was Windows, an OS that was (and in many ways still is)
significantly worse especially for server and embedded applications. Everyone
rallied around Unix and especially free/open Unix as an alternative, and so
here we are.

It's also tough to compete with free, and Unix OSes got a huge boost from both
Linux and the various free flavors of BSD. Yet that boost came at the expense
of things like BeOS, Plan9, original NeXT, and the OS I still feel is hiding
behind the JVM ... which for their day represented fresh ideas that might have
gone somewhere.

Ultimately I think the existing Unix paradigm is going to be killed by Docker
and mobile OSes that containerize in similar ways, and I'm not sure this is a
step forward. It escapes much of the ugliness and the poor permission model of
Unix, but it does so by handing virtually everything to the app. Docker
containers (and mobile apps) can be thought of as something almost akin to
giant statically linked binaries. We're getting more monolithic and coarse-
grained.

~~~
thasmin
People who aren't extremely familiar with how the Linux init system works and
whose job doesn't include keeping the servers stable don't see why the
neckbeards are up in arms about systemd, but there's good reason. Many
peoples' jobs depends on making sure the servers are working, and knowing how
the servers work is a big part of their job (and sanity). In its current
incarnation, systemd changes the fundamentals of how servers work without much
increase in features - large risk and little reward.

~~~
toolz
Server admins have so much new technology to learn and play with to stay
relevant. If they feel like learning systemd is a chore, they might be in the
wrong business.

~~~
dredmorbius
All the more reason to be judicious in what new technologies are introduced.

One of the huge benefits of the Unix/Linux, CLI, and Free Software traditions
is that they tend to be _very strongly preserving of established knowledge_.
Changes are incremental, usually additive, a reliance on scripting means that
interfaces are unlikely to change, and new tools are very frequently drop-in
replacements for old.

As specific examples:

I first learned editing under BSD vi in the mid 1980s. In the time since I've
learned and used on various PCs (and a few other systems): WordPerfect,
WordStar, MacWrite, AmiPro, several iterations of MS Word, the EDT and EVE
editors under VAX, the TSO-ISPF editor, and a few others under Unix: emacs,
ae, nano, nedit, Abiword, Lyx, and various iterations of what's now
LibreOffice. _Most of that skill-acquisition is now dead to me -- the tools
simply aren 't available or aren't useful._

I'm no longer using vi, but vim (adopted in the mid 1990s as I switched to
Linux), but the basic muscle-memory is the same. And its an editor I can
utilize across a huge number of systems (though I do admit to finding
traditional vi / nvi painful).

Similarly, the bash shell is an iteration on the basic Bourne and Korn shells.

ssh is a drop-in replacement for rsh, to the extent that /usr/bin/rsh is
typically a symlink to ssh. While the dynamic is _slightly_ different from
telnet, it's still pretty similar with a few exceptions.

The rare occasions in which a utility changes its commandline options you'll
virtually _always_ hear about it. The fact that it's so painful (and tends to
break decades-old scripts) means its generally avoided. Authors who make a
point of doing this tend to find that people avoid their tools.

A bigger point is that _forgetting_ stuff is often much harder (and more
important) than _learning_ stuff. And when you're invalidating long-
established patterns, that's really painful.

There's also the fact that we manage technology by managing complexity, and
most of us in the field work at the limits of our ability to manage the
complexity we're faced with: the basic OS, shells and interpreters, hardware,
vendors, hosting providers, management tools, employers, clients, customers,
co-workers, engineering and development teams, services, abuse and security
concerns. It's a really complex and dynamic field.

Linux has done quite well (with a few notable exceptions) of maintaining a
balance between capabilities provided and complexity imposed. One problem is
that as systems become more complex, the additional benefits of yet more
complexity are lower, and the costs are higher (this is a very general rule,
not just specific to Linux, operating systems, or computers).

The question of _how to introduce radical change_ is a key one. I've seen a
number of failed attempts to drastically revise existing systems in place --
this almost always fails. Linux itself wasn't introduced in this way -- it
emerged _as an alternative_ to both "traditional" proprietary Unices, to Big
Iron (mainframes, VAX), and Microsoft's then-new WinNT. Linux ended up
dominating virtually all of these categories, but it did so by incrementally
beating out the competitors through replacement.

An interesting space where a lot of this comes to a head specifically is in
the graphical user interface field. I've noted several times that Apple,
notable for a great deal of success in this area, has been _exceptionally_
conservative in its GUI development. It's effectively had two GUIs, the
initial Mac System interface, and Aqua. Each has had a roughly 15 year
lifespan, and yes, there was incremental improvement over the span of both,
but the essential base remained the same.

Since the early 1990s, I've watched Unix/Linux go from twm to fvwm, Motif/mwm,
VUE/CUE (a "corporate" standard based on Motif plus a desktop), Enlightenment,
GNOME, and KDE, and now alternatives such as xfce4 and ... oh, that funky
graphics thing Suse's got, as the "primary" desktops. GNOME and KDE themselves
have gone through about three major revisions. And there are a number of other
"lesser" more minimal desktops as well -- I use one of these, WindowMaker,
which is actually based in a late 1980s ancestor of the Aqua interface now
used by Apple.

Microsoft's experienced some similar recent tribulations. As has pretty much
every online site ever that's done a site redesign.

As jwz has observed: changes to GUIs _just don 't offer that much win_.
They're highly disruptive, they're possible because the interfaces generally
_aren 't_ scripted (other than via automated QA testing systems, but that's
another story), but more importantly: the productivity benefits granted users
really aren't that significant, especially regards the cost.

Worse: changing an _existing_ interface leaves users in a no-recourse
situation, _especially_ in the case of SAAS. For Linux and systemd, the
options are slightly more open in that (for now) it's possible to disable or
block systemd from installing in at least some cases. But over the long run,
it may be that the only options are voice and exit, as opposed to loyalty (a
reference to the book and concept of _Voice, Exit, and Loyalty_ , which I
recommend looking up).

So yes: those of us with numerous decades of experience in the field often
_do_ have an extremely jaundiced view toward radical change. And with very
good reason.

But your comment is really unwarranted.

~~~
wazoox
Exactly that. You know what's insanely great? When you watch this presentation
video of 1978 at AT&T where Ken Thomson explains Unix and type some commands
on his VT-52 and you think: all of this is still current knowledge, and all of
his explanations still hold true. Just like celestial mechanics or Pythagorean
theorems. We are heirs of this ancient wisdom and this is _friggin good_ ,
this is _culture_.

~~~
XorNot
And systemd is changing precisely none of that.

Nothing about systemd removes the basic unix command line. Because he's most
definitely not explaining the init system, which wouldn't have been the same
from year to year then, or even similar decade to decade.

~~~
dredmorbius
Systemd _does_ touch numerous parts of Unix as it existed in 1978: logging,
authentication, and devices come to mind. But much of what it's interacting
with came along afterward: networking, far more services than existed at the
time, a much more complex security scope, and more.

But that's _still_ a good 25-30 years of work, experience, practices, and
smoothing out the rough edges that will be shot down the drains.

Systemd _also_ fundamentally changes the control locus of key features within
Linux and how applications, the kernel, and OS as a whole are constructed and
constrained. Putting all of that under the control of a small group with
highly evident disdain for any "outside" concerns (in quotes as these are of
the larger Linux community, and the concerns are most decidedly inside that
group), contempt, and plays-poorly-with-others attitudes.

I'm not impressed.

Nor with your comment, FWIW.

~~~
XorNot
Authentication is done with PAM and Kerberos these days - Kerberos is late
1980s, PAM came along in the 90s. Unix evolves and had continued to do so
since its inception. udev certainly changed how we do devices.

The rest of your comment is fear mongering which could be applied to any group
of core devs on any OSS project in existence. After all who controls Debian
and security defaults? Do YOU trust them?

~~~
dredmorbius
You're missing the point: there _was no networking_ (outside of UUCP and dial-
up connnections) in 1978 Unix, so there were large classes of functionality
since added which _simply didn 't exist_.

What 1978 Unix _did_ have was security and authentication. The OS was multi-
user from the very beginning -- hence the pun in the name: uniplexing
operating system (Dennis and Ken created a two-user OS to play Space
Traveller).

As Bruce Perens recently discussed in a set of comments at LWN, the first
thing he did as DPL of Debian was decentralize the management of Debian
packaging. He recommends a very similar process for Systemd. The Systemd
proponents in that discussion aren't particularly taken with the idea.

[http://lwn.net/Articles/621022/](http://lwn.net/Articles/621022/)

It's not a matter of fear mongering when the stated goals and practices of
Systemd are to intentionally break compatibility with other Unixen, to reject
compatibility patches, and to provide "choice" in the form of allowing users
the option of any Linux distro on which they can run systemd:

[http://imgur.com/r/linux/Is9vjRJ](http://imgur.com/r/linux/Is9vjRJ)

As Jon Corbet noted at LWN in his Grumpy Editor post on the topic, it would
greatly behoove systemd leadership and proponents to demonstrate a modicum of
gracious victory.

As for Debian's governance, _that_ process has been more than slightly
troubled of late, with at least four key departures (Joey Hess, Ian Jackson,
Russ Allbery, and Tollef Fog Heen), only in the past couple of weeks. The
cabal question was raised by former DPL Bruce Perens in the LWN post linked
above. And, frankly, no, I haven't been happy with the recent directions of
Debian's Technical Committee of late. Joey Hess's resignation (as well as
those of Ian and Russ) calls into question more than just the specific
decisions, but the _process_ as a whole.

Your attempts to smear my own comments which are based on actual events,
facts, and highly considered views of those with deep and broad experience in
the field is, I'm _really_ sorry to say, far too typical of what I see from
systemd proponents (the attacks on Perens in the LWN thread strike a pretty
similar tenor).

Something is sick in this process. That more than anything is what's bothering
me about it, though I've also grave doubts over the technical direction.

------
sandGorgon
>single parent hierarchy for namespaces

Predictably, all the blame is laid at systemd's feet.

The current churn is happening, because all of Linux's core developers (kernel
and user space) are wanting that change...to push the envelope.

For example, the current change in CGroup's namespaces are because kernel is
mandating that the current cgroup access mechanism be deprecated. They want a
single writer to Cgroups. Systemd is in the unfortunate position of complying
with that request. Guess what? Soon enough, so will Upstart.

Again with kdbus, the person who made the push is not "evil" Lennart, but Kay
Sievers - a long time maintainer of udev.

Systemd is nice. Don't be afraid.

Http://www.lambdacurry.com/systemd-nice-dont-afraid/

~~~
nisa
You mean this Kay Sievers?
[http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dus...](http://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/)
\- It's basically the buddy of Lennart at Red Hat - at least that is my
impression from far away..

systemd may be nice but it's coming from Redhat and cgroups are changed due to
because systemd folks wanted it that way as far as I followed that debate...

~~~
sandGorgon
Yes, we are veering dangerously close to Godwin's Law : not only is Lennart
and systemd evil, but everyone who agreed or contributed to it.

~~~
simoncion
Sievers appears to be an unreasonable dick. Gunderson announces to the world
that systemd's DHCP client is pretty damn cool. In the same post, he puts out
a call for interested volunteers.

Ted Lemon (the author and maintainer of ISC DHCP from its inception to 2003
[0]) asks for the location of the project's source repo. Sievers replies with
a LMGTFY link that doesn't even answer Lemon's question. Lemon politely
criticizes Sievers for his rude and unhelpful answer. Sievers fails to even
apologize.[1]

Both Sievers and Poettering have pretty serious attitude issues. It's one
thing to lambast a peer who frequently fails to meet the potential that
they've demonstrated in the past. It's entirely another thing to try to score
social points with your callous indifference and blinkered bullheadedness.

[0] [https://www.isc.org/downloads/dhcp/](https://www.isc.org/downloads/dhcp/)

[1] Check the first few comments of:
[https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8](https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8)

~~~
Karunamon
What you've just mentioned here is what scares me most about systemd. Not its
tight coupling, not its bugs, not its philosophy - all of these things are
arguable and in most cases fixable.

The project being run by people who hold unreasonable and downright odious
views who act like, frankly, _utter asshats_ , is a much more serious problem.

The Kay/Linus debacle is something you can expect to see more of from these
fine folks going forward. Mark my words. Ask yourself if you want software
developed this way running your OS.

~~~
Torgo
I am not sure if you're referring to this, but I have seen so many instances
where an individual joins a community and then systematically tears it apart
by calmly and coolly promoting ideas that ~51% kind of like and ~49%
absolutely hate, through a combination of personality cult and back-room
coalition building. I have seen this happen in forums, IRC channels, RPG
groups, businesses. It is a particularly insidious type of toxic personality
because you can't fix the problem by excising them without alienating and
losing a large chunk of your community.

~~~
Karunamon
Been there and done that.. what's a community to do in such a case?

------
davexunit
I'm quite happy to be a part of the development team for GNU Guix, a distro
that is _not_ using systemd. I'm not a systemd hater, but it's definitely not
for me and I'm not thrilled with the direction that development is going. It's
a shame that sysvinit and friends are so bad that using systemd is the best
option we have right now. Maybe GNU dmd will be able to stand up to it
someday.

~~~
TheLoneWolfling
Thank you for doing this.

That being said, it's a little too esoteric for my tastes (among other things:
"if you are looking for a stable production system that respects your freedom
as a computer user, a good solution at this point is to consider one of more
established GNU/Linux distributions.").

Do you know of any Linux distros that a) don't use systemd, b) are vaguely
active / supported, and c) run on UEFI? (My current laptop, unfortunately, has
UEFI. It's a royal pain, but oh well.)

~~~
davexunit
>it's a little too esoteric for my tastes

Yes, we're still in alpha. Not ready for prime time yet.

>Do you know of any Linux distros that a) don't use systemd, b) are vaguely
active / supported, and c) run on UEFI?

Gentoo? I use Debian most of the time, which of course uses systemd now.

~~~
TheLoneWolfling
> Gentoo doesn't officially support UEFI

~~~
davexunit
Ah, didn't know that. Thanks!

------
lazyjones
I have mixed feelings about systemd: like many others, I've spent a lot of
time with traditional Unix systems (25 years) and like the simplicity and
stability commonly associated with them and familiar tools/conventions. On the
other hand, OS X showed what a modern system built on Unix should feel and
look like, while Linux never got anywhere near (not only on the GUI layer). If
it takes unreasonable people to make progress (like in the famous G.B. Shaw
quote), then let's sit back and see what happens. Perhaps Linux will shed more
cruft and become simpler to develop for rather than harder.

Of course, I'm in the favourable position of not having to maintain/administer
a bunch of Linux boxes for a living. I can fully understand the frustration of
people who built and shipped custom solutions on top of SysV init.

The end of Linux? No, it's the end of Linux as a traditional Unix with lots of
arbitrary optional features on top perhaps. We'll get used to it, or switch to
something better.

~~~
e40
_On the other hand, OS X showed what a modern system built on Unix should feel
and look like, while Linux never got anywhere near (not only on the GUI
layer)._

This feels like a non-sequitur. The nice GUI of Mac OS X has nothing to do
with launchd (which is the systemd-like portion of Mac OS X).

~~~
scott_karana
Are you kidding me? Launchd helps coordinate a massive selection of on-demand
GUI-related services and their prerequisites. (254 services on my Mavericks
install as of writing)

SysV init is ill-suited to that sort of complex event-oriented management,
which (for example) is exactly why Canonical developed Upstart in the first
place.

------
SwellJoe
The ignorance in this post runs _deep_.

For example:

 _Speaking of zones and Solaris, if that’s an option for you it’s probably the
best of breed stack right now._

Does the author have no idea what's going on with Solaris? Hint: Nothing.
Nothing is going on with Solaris, because Oracle doesn't care about Solaris.
They closed the source, and now push out the occasional minor update from on
high for their enterprise customers. Anyone who is suggesting Solaris as an
alternative to Linux at this point in history is simply not credible.

~~~
bcantrill
He's actually suggesting SmartOS[1][2] and OmniOS[3], which are both illumos
distros that are very much alive, having forked from OpenSolaris over four
years ago.[4]

[1] [https://smartos.org/](https://smartos.org/)

[2]
[https://news.ycombinator.com/item?id=8571961](https://news.ycombinator.com/item?id=8571961)

[3] [http://omnios.omniti.com/](http://omnios.omniti.com/)

[4]
[https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

~~~
SwellJoe
That's probably a wrong choice, too, for most Linux users (though there _are_
some reasons a reasonable, and technically competent, person might choose an
Illumos system, if you're doing it because a random crank on the Internet
tells you to, you probably don't know enough to understand those reasons and
the quite large tradeoffs you'd be making).

Regardless, it's one example of many where the author exhibits a very poor
grasp of...well, everything he talks about. Dunning-Kruger effect is funny
that way.

~~~
bcantrill
You realize that you're just talking in _ad hominem_ circles? You acknowledge
that there are reasons that a "reasonable and technically competent person
might choose an illumos system"; is it as least possible that someone
advocating that choice might not be merely "a random crank on the Internet"?
And given that this is potentially a reasonable choice, how does advocating it
represent "a very poor grasp of [...] everything"? If there are specific
technical arguments to make here, please make them; the repeated personal
attack is unwarranted -- and unpersuasive.

~~~
SwellJoe
Yes, I find the whole article so full of wrong that I didn't think it needed
more than simply calling it "wrong". Though seeing how many upvotes it now
has, I guess _I_ was wrong.

But, if you insist, let's break it down a bit:

 _"...FreeBSD...also ships with ZFS as part of the kernel and has a jails
which is a much more baked technology and implementation than LXC."_

Which is an assertion that would require significant citation and
specification about the ways in which the author believes jails to be superior
in order to be a useful claim. I believe it is an assertion based on ignorance
of either Jails or LXC, or the ways those technologies have been used
historically and are being used today. For most of the uses I see talked about
on HN, LXC is the "more baked" implementation. While Jails has existed for a
_long_ time, it was not intended for the purposes we're using LXC for today in
Docker and similar deployments. The tools exist, the resource management
exists, for LXC and they don't, or are quite rudimentary for jails. To suggest
someone choose jails where they are currently using Docker and LXC is to
suggest they live with a large variety of limitations and pain points, and in
a lot of cases to simply not do what they are currently doing, or to do it in
wildly different ways. All to avoid the minor pain that is represented by
SystemD for most users.

In short: Jails are not (currently) a reasonable alternative to LXC in that
context, and it exhibits some kind of ignorance to suggest them.

Continuing on, despite your suggestion that he is talking about SmartOS or
OmniOS, he quite clearly is not. He specifically mentions Solaris while
mentioning the others as other options:

 _" Speaking of zones and Solaris, if that’s an option for you it’s probably
the best of breed stack right now. Rich mature OS-level virtualization.
SmartOS brings along KVM support for when you HAVE to run Linux but backed by
Solaris tech under the hood. There’s also OmniOS as a variant as well."_

That paragraph clearly _is_ recommending Solaris, specifically. If you'd like
to argue that Solaris is a reasonable alternative for most Linux users, it's a
conversation I'm going to opt out of. I'm pretty sure we'd be speaking
completely different languages.

 _" If you absolutely MUST run Linux, my recommendation is to minimize the
interaction with the base distro as much as possible. CoreOS (when it’s
finally baked and production ready) can bring you an LXC based ecosystem."_

So, CoreOS is the Linux option he recommends? The same CoreOS that uses
SystemD? Indeed, was among the first distros to embrace SystemD with gusto.
CoreOS, that is _remarkably_ different than all other Linux distros. All
because "Linux is becoming something different than it was"? So, in response
to Linux becoming something different, he recommends people switch to
something that is utterly different, like an entirely different operating
system (FreeBSD, Solaris(!), etc.) or a Linux distribution that rethinks
everything, not just the init system (CoreOS).

All to avoid something being different. It absolutely boggles my mind, and I
have hard time responding with anything other than derision; for that, I
apologize.

You're right that I haven't been particularly persuasive, and have been quite
abrasive. This article just really rubbed me the wrong way.

~~~
mbainter
"That paragraph clearly is recommending Solaris, specifically."

He says, as he quotes a paragraph that specifically calls out SmartOS and
OmniOS -- both of which are under the IllumOS branch of OpenSolaris.

"So, CoreOS is the Linux option he recommends? The same CoreOS that uses
SystemD?"

The problem he's raising isn't that linux is going to be different, and if you
think it is you need to re-read. Try doing it with your --with-reading-
comprehension switch. It being different is just a statement of fact, the
problem statement was separate.

CoreOS is not a distribution in the classic sense. It is a platform for
deploying containers, and in the use-case they've setup the author clearly
believes it will allow you to still be successful _in spite of_ systemd.

------
morganvachon
I think the article got one thing wrong: That sooner or later every GNU/Linux
distro will switch to systemd. I can think of three that most likely will not:
Slackware, Crux, and Gentoo. Granted, the more that systemd binds itself to
formerly modular userspace utilities and apps, the more pressure on those
distros to make the switch, or else either fork every systemd userspace app at
the risk of being left behind. But I have a feeling there will be a schism in
Debian, resulting in a fork or (less likely) dropping systemd altogether,
before too much longer. That might just be the catalyst to move away from it
in other major distros.

Then again, I could be completely wrong, and systemd will end up in every
single surviving distro by default, turning GNU/Linux into systemd/Linux.
That's when we'll see a true exodus of those opposed to it to other OSes.

~~~
wtallis
I'm also interested to see how things play out with OpenWRT. High-end home
routers are starting to get a lot more powerful with the transition to ARM
SoCs and NAND flash, but they won't be able to run any software that depends
on the systemd ecosystem while OpenWRT is still supporting the massive install
base of hardware that systemd can't fit on.

~~~
morganvachon
Ditto for small ARM devices like the Raspberry Pi. When the RPi version of
Arch Linux went to systemd, the system actually got slower in my experience.
On such an already limited device, it was a quantifiable difference; before
systemd, Arch was the fastest GNU/Linux distro for the Pi by leaps and bounds.
After systemd, even Raspbian feels faster than Arch, and now Slackware is the
reigning king of speed for it (again, among Linux distros).

Unfortunately Slackware is still a bugaboo when it comes to installing it on
the Pi, but once you've got it on there you can image your SD card and have a
ready-to-roll distro that's lean and mean.

------
keyle
Can someone put in Layman's terms what the change entails and why it would be
the end of Linux?

~~~
fidotron
It's not the end of Linux. It's the final death of the idea that Linux should
just idly continue to act like a clone of some vague Unix of old because it
was better when men were men and their computers had obscure RISC processors
with billions of registers.

Linux hasn't really been that way for an incredibly long time, but a large
proportion of the userbase still cling to this notion, some for ideological
reasons, and some out of sentimentality.

~~~
nitrogen
Systemd is most problematic because of its own-everything monolithic nature,
and the changing of kernel interfaces to match. The vast majority of Linux
systems are not desktops, and probably not servers either. The kernel and the
core utilities around it (like init) should be designed with multiple
implementations and all machine types in mind. This means phones, set top
boxes, TVs, routers, automation hardware, supercomputers, and more.

If the core utilities around the kernel and the interfaces they use are well-
documented, designed, and modular, then different machine types can pick and
choose the components they need, and easily write their own by opening a well-
defined API on something in /dev. If systemd continues to take over and
alternatives smothered, very quickly the kernel will become useless to any
system where systemd makes no sense, especially non-desktop embedded systems.

~~~
general_failure
Your comment is the very definition of FUD. You have nonfacts just baseless
fear.

~~~
nitrogen
I developed and marketed my own embedded Linux products. It would have been
difficult to do some of the customizations I did if the kernel, DHCP server,
logging system, HAL/udev, etc. were all adapted to the one systemd way of
doing things with dbus.

------
zobzu
we've already upgraded to RHEL7 here. ppl didnt know systemd too well but it
works (im the only guy who knew systemd. heck ppl didnt even know of
journald).

Now im not saying that i like systemd in general - for the reasons the author
explains I don't really like it. Systemd could have been way better if it
wasnt for the political shit and attempts to take control over distros,
kernel, etc.

That said it has some features I do like. Likewise for kdbus. This is like
Chrome vs Firefox. People would like to support Firefox better. But Chrome and
Google apps do enough of what they want _right now_ to go with the solution
they don't really approve of - I'll say it again: it works.

------
noobermin
It has been said before, but it deserves mention, there are alternatives to
Systemd out there, like OpenRC which has been around for a while, and other,
newer projects like Uselessd.

Of course, whether those other options will be as well supported and developed
as systemd remains to be seen.

~~~
gnufied
I am no expert on this but apparently when Gentoo developers tried integrating
OpenRC they ran into too many bugs.

[http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-
loginds...](http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-
logindsystemd-thoughts/)

~~~
simoncion
> ...apparently when Gentoo developers tried integrating OpenRC they ran into
> too many bugs.

You are certainly no expert on this.

I've been using Gentoo since 1.4... back in 2003, maybe 2004. I vaguely
remember when _Stable Gentoo_ was switched to OpenRC, which happened in mid
_2011_. Unstable Gentoo (which I ran -and still run- on my laptop) switched to
OpenRC much earlier [but that date I cannot remember].

What the first topic in the blog post that you linked to is _really_ saying
is:

"We Gnome developers _still_ claim that recent Gnomes don't require systemd.
We stand by this assertion. Recent Gnomes only require init and system
management daemons that behave exactly like systemd in pretty much every
aspect; they don't actually require you to have systemd installed.

It's a pity that developers don't want to spend time re-working their init and
system management software to be systemd clones. If they did, then the world
would _finally_ understand why we Gnome developers continue to assert that
Gnome doesn't require systemd."

~~~
jude-
That's the fundamental problem with DBus-exposed interfaces: they're APIs that
get marketed as abstractions. APIs don't leave much room for different
interpretations, meaning you'll end up rewriting the component you're trying
to avoid using in the first place.

~~~
simoncion
I'm not sure what you're saying here. If you want to avoid using a particular
piece of software, but need to adhere to its API, you're _going_ to either
reimplement parts of it, or use someone else's reimplementation. There's
really no way around that. It's a fundamental problem shared by all software.

~~~
jude-
Exactly. I'm (obliquely) affirming your argument that the commonly thrown-
around excuse of "you don't need systemd, you just need something that
implements its DBus interfaces" is a distinction without a difference.

~~~
icebraining
Is a system running Linux + Wine no different than Windows, just because it
implements the same Win32 API? Is FreeBSD the same as Linux, since they both
implement POSIX?

There are many ways to implement the same APIs.

~~~
lmm
Wine is not reliable enough for mission-critical software. Nor is running a
nominally POSIX-compliant program that hasn't been tested on FreeBSD. If a
project claims not to hard-depend on systemd, I would not trust that unless
it's actually, y'know, tested on something that isn't systemd.

------
renovaatio
Two distros that don't use systemd:

[http://www.voidlinux.eu/](http://www.voidlinux.eu/)

[http://crux.nu/](http://crux.nu/)

Void linux is a rolling release, has binary packages, uses a very good package
manager (even better than pacman) and the community is small but very
friendly.

Crux is very minimal, and you have to compile your packages.

I use Void Linux, and am very happy with it.

~~~
papaf
Thanks for that information.

I am using Arch at the moment but I spent the last 45 minutes trying to fix a
network problem which involved fighting with journalctl to see what was
actually happening.

Void linux looks like a great alternative.

~~~
renovaatio
I assure you void is a great aternative to Arch. I was with arch until
systemd, and it feels like home, only smaller, with Arch.

------
pdkl95
Wow. The UNIX-haters are out in force. Apparently proven, real-world tested
code is no longer a relevant feature to a lot of people. Well, "Those who do
not understand Unix are condemned to reinvent it, poorly."

But enough about the technical distractions. Why is systemd so important? It's
certainly not technical quality or design (even if some of the ideas are
useful, the implementation is junk). There is a far more important reason,
that some of you have noticed parts of, at least tangentially.

From this very thread: "systemd makes a lot of sense for embedded systems".
Yes, it does, andor, and it's all because of this: "kdbus: efficient IPC". The
thing is, kdbus/dbus isn't really that great for a lot of things - you have to
bounce through the kernel at a minimum, and there is and encode/decode steps
that add some overhead. It might be useful for some types of _IPC_ , but it is
replacing what should be a fast and simple _library call_ in many places.

Now, here's where a lot of you are going to start calling me crazy or
"obviously wrong", both without actually addressing the key claim, which was
is probably better explained by stevel over in the Gentoo forums[1]. I
encourage reading that post.

The goal with all of this is not technology related at all: the systemd
takeover is an attempt to separate Linux and many userspace tools from the
GPL, so that software can be used under the LGPL terms instead.

What is the big difference between GPL and LGPL? Linkage. Linking to a GPL
library requires you to follow certain requirements if you link against it,
while the LGPL specifically allows taht usage. (k)dbus provides the
workaround, by replacing what would be a normal function call into a library
with a "IPC". It's slower, but so what, computers are way faster than needed.
In the end, while you can still choose to release your code as GPL, if you
have to use an IPC mechanism to do anything useful the license requirements
that will actually apply ends up being being more like the LGPL.

Well, if I wanted to release under the LGPL, I would. What I'm not going to do
is undermine my choice of license just because a bunch of embedded developers
(and others) want to use what were traditionally GPL projects without having
to be bound by the coopyleft requirements. If this was proprietary software,
you would call that kind of behavior "stealing".

(seriously, the linked comment below does a much better job of explaining
this)

[1]
[http://forums.gentoo.org/viewtopic-p-7645524.html#7645524](http://forums.gentoo.org/viewtopic-p-7645524.html#7645524)

~~~
icantthinkofone
Where do you get UNIX-haters? I read systemd haters which begets Linux haters
but UNIX? No.

Besides, Linux is no longer a UNIX-like system. Linux is now only Linux unto
itself with UNIX-similarities.

~~~
pdkl95
Just look at this very thread - there are numerous posts trashing the "old
ways" of UNIX.

It has been a common thread throughout the systemd mess. Lennart himself is
_very_ strongly outspoken against any use of shell scripting (not just in
init).

~~~
antientropic
Sigh. Obligatory reference to [http://0pointer.de/blog/projects/the-biggest-
myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html):

"Myth: systemd is incompatible with shell scripts. This is entirely bogus. We
just don't use them for the boot process, because we believe they aren't the
best tool for that specific purpose, but that doesn't mean systemd was
incompatible with them. You can easily run shell scripts as systemd services,
heck, you can run scripts written in any language as systemd services, systemd
doesn't care the slightest bit what's inside your executable. Moreover, we
heavily use shell scripts for our own purposes, for installing, building,
testing systemd. And you can stick your scripts in the early boot process, use
them for normal services, you can run them at latest shutdown, there are
practically no limits."

~~~
vezzy-fnord
Note that your quote doesn't contradict pdkl95's statement. Nowhere did they
say that systemd _prevents_ you from starting shell scripts, but that the
developers have a (strong?) revulsion towards them.

------
exabrial
The real reason people are pissed about systemd is it's intentionally designed
to take over the entire system. Conveniently is also maintained by RedHat. So
yes, it is a hostile takeover of Linux.

------
derengel
Are there any reliable VPS providers that offer FreeBSD?

~~~
stock_toaster
There are quite a few. Some decent ones I have heard good things about:

* rootbsd.net * arp networks * vultr

There are quite a few cheap-ish dedicated server vendors out there that can
either be ordered with FreeBSD or provide some means to install it yourself.

~~~
PurplePanda
I have had good luck with arpnetworks. So far only noticed one outage in three
years of use. Have had good network and CPU performance. They don't do tech
support for things inside your operating system, but they are always helpful
when I ask them to do things on their end.

------
phkahler
The description of systemd - monolithic, taking on function of other things -
sounds like the X server. Look what's happening now with Wayland, and look at
how hard it's been to get there (hint Wayland is only possible as a result of
all the driver architecture changes over the last 5-8 years). It's hard to
undo this kind of thing once it's entrenched, but it can be done.

~~~
e7620
Look how many platforms X supports, how many paradigm shifts has survived.
systemd already has a less flexible architecture _by design_ that an ancient
system, so in the future it'll be difficult to untangle.

------
willhamina
Does systemd increase the security of the OS or reduce it? For example, does
it allow currently-separated processes to dip into each others' memory space?
I would appreciate a birds-eye view from someone familiar with the security
ramifications of systemd.

Would not the incorporation of many loosely-coupled but individually secure
mechanisms into a single monolithic mechanism be useful to an entity whose
purpose was to monitor communications, view/modify systems unbeknownst to
sysadmins and users, etc.? Yes, I'm talking about the NSA et al. I reference
the following which also brings up Red Hat's control of Linux:

"Julian Assange: Debian Is Owned By The NSA"

[http://igurublog.wordpress.com/2014/04/08/julian-assange-
deb...](http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-
owned-by-the-nsa/)

------
SEJeff
He rants about systemd, then talks about liking CoreOS, which uses systemd for
everything. He is contradicting himself, but I'm genuinely not sure of why.

~~~
angersock
Read it again:

Author is saying that CoreOS is a good solution _because you use it with
heavily isolated containers_. Thus, any use of systemd is unable to screw up
hosted applications. For that use case, it makes sense, whereas in more
general use, systemd wants to get all up in everything.

~~~
timf
He responds to that here as well:
[http://blog.lusis.org/blog/2014/11/21/a-few-
things/](http://blog.lusis.org/blog/2014/11/21/a-few-things/)

------
orionblastar
I think that SystemD is an attempt to put Linux on par with Mac OSX and
Windows 8.X, and attempts to do that haven't worked in the past.

Like Canonical changing Ubuntu to use Unity and Mir, so that it was easier to
use on tablets and modern PCs. It just doesn't seem to work and it drove me to
Lubuntu and use LDXE with an XP like Start Menu UI.

Ubuntu doesn't use SystemD yet, but I got a feeling it will.

I am downloading Fedora 20 because it has SystemD in it, so I get some idea
what it is like.

But I think every Linux company wants to become another Apple for some reason.
They saw how *BSD Unix went into making Mac OSX, and they want to try and copy
that with their Linux distro and right now this SystemD seems like a path to
that.

It is like a change from free and open source to commercial Linux. We all saw
how Lindows/Linspire tried that and failed.

I might go to ReactOS, HaikuOS, AROS when one of them gets finished to the
right level that it is ready for prime time. All they need to do is port
Apache2, PHP, MySQL and other stuff to those operating systems to be used in
VPS hosts so they can be used as alternative to Linux with SystemD if it ever
breaks things.

~~~
pekk
Which Ubuntu release did you find to be using Mir as a default?

~~~
orionblastar
I think it was on a tablet, not on the desktop by default yet.

It is kind of confusing.

------
saurabhnanda
New to this entire brouhaha, but I'm concerned because my entire production
stack runs on Linux. At some point devops is not going to be able to do things
the old way.

Is there a link where one can read about the rationale of why systemd was
needed? Perhaps by the person who started off the initial project?

~~~
scourge
is this a joke? \- "my entire production..." you're a devops engineer? \-
"link where one can read about the rational.." with good grammar? \- "why
systemd was needed... " ok you lost me there \- "the person who started off
the initial project?" and you've been hidden under a rock for the past 10
years??

[http://0pointer.net/blog/](http://0pointer.net/blog/) \- is his blog

are you seriously trying to tell me that someone is going to have to explain
what a "container" is by comparing with chroots? :D how have you been running
your production stack all these years if you didn't have an internet
connection under your rock :)

------
return0
As a rule of thumb, it's good to distrust products when you know that the
politics behind have been loud enough to be heard widely. But the sharp razor
which will decide if systemd is better is simplicity. Those who have switched,
is systemd _simpler_ than sysvInit?

~~~
sethrin
Simplicity is not necessarily a good measure of suitability. See this:
[http://mjg59.dreamwidth.org/2414.html](http://mjg59.dreamwidth.org/2414.html)

There are some aspects of systemd that are simpler than sysvinit. The mess of
double-forking and PID files goes away, and process management is much more
reliable. Setting up containers for services is much simpler. Unit files are
generally much simpler than a given init script.

I think more useful adages ("boned wisdom for weak teeth" \- AB) would be,
"Everything should be as simple as possible, but no simpler," and "Simple
things should be simple, complex things should be possible." There is an
enormous amount of complexity inherent in the problem of initializing and
monitoring a modern OS. If your solution to this is actually simple, it is
probably wrong or incomplete. How you manage that complexity and what your
abstraction layers are are the vital questions.

------
sciurus
[https://news.ycombinator.com/item?id=8641839](https://news.ycombinator.com/item?id=8641839)
is a much needed response to this discussion.

------
lwh
It seems like most systemd problems boil down to: shit this will take more
than half an hour to understand, I'm a lazy admin and don't feel like learning
something new.

------
timf
The author responds to a number of the comments here:
[http://blog.lusis.org/blog/2014/11/21/a-few-
things/](http://blog.lusis.org/blog/2014/11/21/a-few-things/)

------
sztanpet
You know the blog is just a clickbait when it capitalizes the name of the
project wrong.

(on the wiki, the big Spelling header could not be more explicit)

------
Andys
> Freebsd has jails which is a much more baked technology and implementation
> than LXC

Disagree!

1\. FreeBSD has nothing like cgroups or namespaces. You can't apply cpu or
memory limits to a whole jail, only individual processes in that jail.

2\. it is early days for virtual network cards and ethernet bridging and
jails: you have to recompile kernel to add VIMAGE.

~~~
Sanddancer
You've been able to apply cpu and memory limits to entire jails since 10.0 was
released through the rctl mechanism.

~~~
Andys
Thanks. I don't think it changes my point - various attempts were made to
implement this feature since Freebsd 6 - almost 9 years ago, for some reason
these were incomplete or ignored.

FreeBSD 10 was released only this year. For reference, Heroku began in 2007,
using resource limits with LXC... a whopping 7 years ago.

------
dschiptsov
Going against the "divide et impera" principle, "do just one thing, and do it
well", "everything is a text file" (configurations and logs) and "pipes" which
are very natural idiom, _in a UNIX-like system which has been built upon these
principles_ , is just bad engineering, shallow understanding and, perhaps, too
high ambitions of knowing better how to fix what isn't broken.

The question _why_ do we have this project and why there is such a buzz is
more interesting.

But the answers doesn't belong to realms of system design or engineering, they
are in more obscure notions of "business strategies" and "sales techniques".

It is a text-book example how to sell - "show them that they have a problem
they didn't realize before, and give them the one and only fix". Fine. Except
that the problem doesn't exist outside discussions of "why this product is
good - it solves this and that".

Another thing is that it is an excellent strategy to "create a niche for
oneself". Look, we are the ones who give you a solution (to a problem which
doesn't exist). We are "world leader" \- look, we have lots of experts, web-
presence, lines of code.

There are so many examples in "parallel worlds", beginning with _eco_ products
or "fair-trade" coffee, you name it.

But you see, lots of people don't need an _eco_ or _environmental-friendly_
daemon which does everything "the right way". No, thank you.

Another thing, back to system design. If Windows has "registry" and there are
millions copies of Windows everywhere, or Mac has that settings daemon (from
which GNOME Gsettings has been copied) it doesn't mean that these design
decisions are superior to plain old text configs. You could compile them and
have an "intermediate storage" to gain a 5% more efficiency for application
startup times, but this is, again, not a fundamental problem. Being able to
use regular expressions on configuration and logs without any restriction are
much more fundamental. And memorizig all the details of all these xxxxctl
insted of saying something like

    
    
       $ grep -R ^sysctl /etc  
    

or whatever I need, is just an additional unnecessary burden.

Most of the problems systemd is trying to "solve" does not exist. At least not
BSD, AIX, Solaris, you name it. And, of course, there never been any problem
with syslog, init or cron. They were *good-enough".

~~~
the_why_of_y
If the problems with sysvinit are all imaginary then why has every other UNIX
replaced it?

Mac OS X has launchd for 10 years now.

Solaris 10 replaced sysvinit with SMF.

Don't have any experience with AIX but the documentation says it has a "System
Resource Controller" with a "srcmstr" daemon to manage services; though it
looks like it runs on top of something sysvinit-like:

[http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com...](http://www-01.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.osdevice/sysrescon.htm?lang=en)

BSDs have generally never used sysvinit, although they do have shell-based
service management.

So actually none of the particular examples you cite use purely sysvinit to
manage services.

And it's also quite obvious that there are use-cases where reliable and fast
service management are very important on servers.

One is containers, where you may run 10000 of them on a single host, and you
have to reboot the host some time too, so you don't want to delay the start up
of all those containers by loads of slow and racy shell scripts. Or even
better, you want to have socket activated containers that don't actually start
until they are needed.

[https://www.getpantheon.com/blog/pantheon-running-
over-50000...](https://www.getpantheon.com/blog/pantheon-running-
over-500000-systemd-units)

Another is hyperscale servers: There are now really small ARM and x86 based
servers and you can put 4-500 of those in a single rack. That means a lot more
individual servers to admin, and failure modes that are relatively rare in
current server rooms will become an order of magnitude less rare, so more
robust OS level service management is helpful.

~~~
julie1
Problem 0: Yes sysinit has problems but systemd brings even more problems
(journalctl, PID 1, dependancy Hell ++, undeterministic bootup process)

Systemd is a broken silver bullet for handling the decrease in quality of
packaging.

There are problems with sysinit: the first one is the missing link between
devs and syadmins in companies: people known as packagers.

For a sysinit to work well shell scripts, permissions, where resources are
located, the dependency management has to be done with art and expertise. It
is a human job with human which are:

1) a very skilled rare resource, 2) not identified has needed by companies, 3)
company's software QA is shitty (it has barely the level it works for me (tm)
of quality

Talking about debian, which is considered the distribution with the most
talented packagers debian has 2 flows in this domain:

* too rigid: projects goes for logical units of packaging that are consistent and organization of assets in packages that can ease maintaining. Debian has its guideline that makes them «fix» poorly packaged softwares like lateX, python, ruby: cutting language distro in at least runtime, dev, extra. Debian packagers are often debian experts, not upstream software package experts and they first break some stuffs (latex is so poorly packaged on debian it can be considered broken), AND it adds more works

* too much features typical linux distro compared to BSD are pacakging fucking more packages in their core resulting in more work; less attentions to the details and conflicts of functionality/overlaps. This result in more resource drained from the packagers. Like we have 4 shells considered OK for writing shell related stuff, when they have only one: «sh».

The problem of linux vs BSD is symbolized by the systemd vs sysinit: linux is
an OS of devops that are super devops, poor coders and sysadmins, BSD is an OS
of sysadmins and devs that are good sysadmins and devs, but no devops.

And we still lack in 2014 of maintainer, sysadmins and coders of quality.

Linux/Gnome ... FSF projects are not sustainable in these conditions. They
think of free software has an infinite resource of benevolence. And they
exponentially overblow the works required for maintaining, deploying ... thus
they are mathematically doomed to die under their own weight.

I see BSD as a calvinist boring protestant community turned towards humility
doing what is right and linuces as catholic exhuberant rockstars over spending
the good will of developers without thinking of the future.

Being lutherian, I still dream of THE right OS that would less terse than BSD.

------
andyl
Everything I read about SystemD is negative. Negative on the technology,
negative on the people who created it. Nothing positive.

How is it that SystemD is about to dominate the market? Who is driving SystemD
adoption, and why?

~~~
Mikeb85
It's so terrible (literally the devil incarnate, sacrifice your offspring now)
that it's already been adopted by:

\- Arch Linux

\- Fedora/RHEL

\- openSUSE/SLES

\- Mageia

\- NixOS

\- CoreOS

\- Sabayon

\- Debian and Ubuntu in the near future

> Everything I read about SystemD is negative. Negative on the technology,
> negative on the people who created it. Nothing positive.

There's a vocal group that seem to think it's some Red Hat conspiracy to
destroy Linux and take over the world. You don't hear the positives because
people either don't care about init systems (as long as their distro continues
to work) and happy programmers are generally silent on the issue.

The fact that the article says that Solaris is the 'best of breed stack right
now' and also suggests CoreOS (apparently not knowing they use Systemd) should
speak volumes...

~~~
pnathan
Well, in fairness, I did have a RH chap tell me to my face several weeks ago
that Linux needs to replicate the Windows registry model and stop using the
/etc text file approach. So I have a certain sympathy for the idea of Red Hat
conspiracy (what is a company anyway but a conspiracy to produce work &
products for hire?).

~~~
tracker1
ROFLMAO... more and more applications in Windows are moving _AWAY_ from the
registry.. other than install/uninstall notations created by the installer,
very few recent apps use the registry. Most use the global ProgramData or
user's AppData paths for configuration. It simply works.

I don't hate the registry... I'm just not in a hurry to see Linux adopt it.
What's so bad about /etc/app/config or ~/.config/app/config? It works in
pretty much every platform (though the paths may be slightly different).
Windows does have both roaming and local data directories, which can be pretty
nice (if you don't bloat them).

------
icantthinkofone
I've been saying some of these things since systemd came out and typically get
downvoted into oblivion so here this article makes HN's front page.

His implication about switching to FreeBSD is a good one and I notice a decent
influx of Linux admins switching to FreeBSD showing up on every forum I visit.

------
frozenport
I used Gentoo for 10 years, and I can't figure out how to get a Systemd
configuration working with XFCE. Indeed, most of the existing documentation
has greatly slowed me down.

~~~
general_failure
Fwiw, my friend runs Ubuntu for 10 years and he cannot understand gentoo for
the life of him. He thinks it is absurd people want to keep recompiling stuff.

~~~
nyir
People don't want to recompile stuff, they want to configure the software to
their liking. Basically it's very enjoyable if you're a developer.

And FWIW with Gentoo/Portage you can create and install binary packages.

------
dgdsgdsg
for me it seems that most people complaining/crying out loud come from a
system admin perspective.

For example the author of this blog article does not seem to have contribute a
lot of code to any project and is more "just" an admin and not a dev.

for me it looks like they don't like new stuff love the linux world how they
knew it and don't want things to get easier or even change.

~~~
linuxydave
>for me it seems that most people complaining/crying out loud come from a
system admin perspective.

Sysadmins complaining about it is pretty important, as at the end of the day
_they_ are the ones who are maintaining the systems.

Personally, I have a strong dislike for Systemd. I don't believe it's the
right replacement for sysvinit however it's not going away so we'll have to
try and work around its warts. Also, currently it's buggy as hell so I will
use Centos 6/Ubuntu 14.04 for a few more years to see if the many problems are
sorted by then.

~~~
general_failure
That's exactly as intended. People who want to help out systemd will use
latestbsoftware, report bugs and fix it because you know thats how free
software works.

People who don't want to help out use the most recent stable and have nothing
to worry about.

~~~
linuxydave
TBH with the current direction systemd is going in I'll probably end up using
one of the BSDs. However, I doubt I'd be able to use a *BSD in a production
environment as I am a contractor and all of my clients only want Linux.

