
Linus: “I no longer feel like I can trust ‘init’ to do the sane thing” - cnst
https://lkml.org/lkml/2017/7/6/577
======
floatingatoll
Is there any useful comment anywhere on this post that talks about the
technical meat of Linus' post here? He explicitly goes out of his way not to
go into a long-form argument about systemd, and then HN dumps something like
150 points of comment karma into systemd.

EDIT: Here are links to comments discussing the actual content of his email,
in case anyone else came here for that and left wanting.

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

[https://news.ycombinator.com/item?id=14733973](https://news.ycombinator.com/item?id=14733973)
->
[https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J](https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J)

EDIT: I read all the comments on this post, and I am disgusted to report that
(as of this EDIT, nitpickers) the 2 above-linked comments are the sum total of
actual replies to the content Linus was trying to discuss. I hope LKML had
more self-control than HN.

EDIT: 14733558, it was really excellent of you to try and defuse things, too.

~~~
smhenderson
Yes, he specifically goes out of his way to refer to init as generically as
possible. But then drops this line at the end of the post:

 _And yes, a large part of this may be that I no longer feel like I can trust
"init" to do the sane thing. You all presumably know why._

It's not hard to understand what he meant and for some of us it's articles
like this on HN which give an opportunity to talk about systemd without being
off topic.

IMO the take away from the article is that systemd has become enough of a
moving part that it would be unwise to rely on it for default anything. Maybe
I read it wrong but there's my take on the technical argument against using
init to set default limits on processes. There are already defaults in the
kernel so use them and allow an override for admins that need one.

~~~
floatingatoll
It's impossible to misinterpret that he's referencing systemd, but _that 's
not the point of his post_. He's saying, "Kernel over here, Init over there,
One way transaction". You're talking about whether Systemd is qualified to
_be_ init. He's talking about whether the Kernel-side or Init-side is
responsible for defining a given value. He declares his bias clearly (trusts
Kernel, doesn't trust Init, especially doesn't trust Init via Systemd) and
then makes his point. I'm just deeply saddened that literally two comments out
of a hundred bothered to discuss _his point_ , that divide, at all.

~~~
dpark
So talk about that divide. Clearly a lot of people care a lot about Sysemd and
want to talk about it. It's even the title of the post.

Complaining that people aren't having the conversation you want to have is
just weird. Start the conversation you want instead of complaining that others
are failing to have it. No one is obliged to hold the conversation you want.

~~~
floatingatoll
I came here to learn about a technical issue that HN felt worthy of the front
page, because I'm not certain how I feel about systemd yet. I ended up
learning what a bunch of people feel about systemd, but nothing about whether
this is a reasonable divide strategy, or whether anyone has any arguments to
counter his, or .. anything whatsoever. I'm glad the thread benefited the
wellness of the community by providing an outlet for unresolved rage, but
y'all missed a key opportunity here to consider a _new_ semantic about the
Kernel-Init(Systemd) interaction before it's fixed into stone by commits or
whatever.

~~~
dpark
Was the title different when you clicked on this story? If you clicked a story
about how Linus no longer trusts init and expected some deep discussion of
init/kernel separation, I kind of feel like you were destined to be
disappointed. The topic was clearly Linus's distrust of init, not
architectural purity.

------
dredmorbius
Ted Ts'o, the Linux ext2/3/4 filesystem developer, posted this two days ago at
G+ as well. Interesting discussion, particularly about 1) systemd's bad
programming taste and complexity, and 2) Lennart Poettering's inability to
admit when he is wrong.

"For me a lot of "good taste" is about adding complexity when it's needed, and
avoiding it when it's not needed. And if you do have complexity, making sure
you have the tools so you can debug things when they break. And for me one of
the things that I don't like about systemd is that it has added a lot of
complexity, and when it breaks, trying to debug it can be almost impossible."

Also:

"Heck, I don't even I want to file bug reports, just so I can get abusive
messages from Lennart. At least when Linus flames me, it's because I did
something wrong which hurts users and which I d*mned well should have known
better, given my years of experience in the community. Lennart just flames you
because you're wrong, and he's right. By definition."

And:

"The high bit, in my opinion, is "not being able to admit you are wrong". If
someone (such as Lennart) is always right, then it's impossible to have a
technical discussion in a post-mortem to avoid similar problems in the future.
In a company, if there are personnel issues like that, you can escalate to the
person's manager, or use other mechanisms. In the open source world, all you
can do is route around the damage. Whether you call the inability for someone
to admit that he or she has contributed to the problem a "lie" or just that
they were "mistaken" is really beside the point as far as I'm concerned."

[https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J](https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J)

~~~
digi_owl
Ts'o strikes me as damn close to Torvalds in attitudes. The guy have been with
the kernel for almost as long as Torvalds himself, happily developing EXT
version after EXT version for it.

The problem is with more recent people, that seem to be more "american" their
approach. Always looking to climb the ranks and find new domains of
development to undertake rather than stick with one area and become deeply
proficient.

------
throw2016
Making too many assumptions about the user environment is not smart. Then you
start putting constraints and becoming defensive when these assumptions are
questioned. This is becoming a pattern for systemd as is blaming everyone
else. [1]

Those who need the complexity or some features should adopt the technical
debt, there is zero rationale to enable it by default and impose it on
everyone.

For instance if you have too many network interfaces and naming is a problem
then switch on predictable network names which btw is anything but predictable
for human beings and let the 97% who don't carry on.

12 digit random names are simply not predictable or better for human beings
than eth0, wlan0? If there is a problem predictable network names is not the
solution.

Similarly if you need binary logging and an audit trail then turn on binary
logging but don't impose it on everyone else.

Its time to move beyond silly accusations of 'hate' etc every time there is a
discussion about systemd because at the moment it just serves to deflect
criticism and avoid accountability for questionable decisions.

[1]
[https://github.com/systemd/systemd/issues/2407](https://github.com/systemd/systemd/issues/2407)

~~~
danieldk
_Those who need the complexity or some features should adopt the technical
debt, there is zero rationale to enable it by default and impose it on
everyone._

Indeed. Even if I have multiple ethernet interfaces, I'd prefer to map a MAC
address to eth[0-9] myself. But most machines only have one ethernet interface
and one WiFi interface anyway.

These things pop up all over the place. E.g.: why would I want to have
NetworkManager on a server, which never switch networks and need to set up a
VPN connection? Why do I need firewalld on a server? I rarely need a zone-
based firewall on my laptop (probably like most users, I just block all
incoming traffic), let alone a server.

Layer upon layer is piled to solve hypothetical situations that do not arise
for > 90% of the population.

(I do like systemd as a service manager, but systemd and the surrounding
ecosystem has made it terribly difficult to understand and debug UNIX
systems.)

~~~
marcosdumay
Most of my machines have more than 1 wired interface, and guess what? Those
predictable names have caused me way more problems than they ever fixed. And
those problems have always been harder to fix. Just stable names, like udev
used to do were enough for nearly everything.

> why would I want to have NetworkManager on a server, which never switch
> networks and need to set up a VPN connection?

It's funnier because NetworkManager must wait for the filesystems to be
mounted, but then, networked filesystems (that are, those ones, important
there) need a functioning network that NetworkManager postpones to after it's
up.

------
zdw
systemd is a mess. A while ago I tried writing a script for CD ripping that
ran when udev detected a music CD in the optical drive, ripped the CD, then
ejected the disk.

This kept failing. It turned out to be systemd having a hardcoded timeout of
something like 30 seconds on any process launched by udev, that couldn't be
changed without recompiling it from source, or having it fork off some other
process group that lacked this limitation.

From what I can tell, systemd has some of the worst sort of developer myopia,
where whole swaths of legitimate use cases are actively destroyed.

~~~
rlpb
It sounds like you're blocking udev while your script executes, and instead
you should start a service from your udev script and then exit. For example,
see systemd-run(1).

> ...where whole swaths of legitimate use cases are actively destroyed.

Your use case is fine. Your implementation doesn't fit with udev's design;
that's all.

~~~
zdw
I was having udev starting a separate ripping script as a background process,
and it worked on pre-systemd udev systems.

systemd kills the entire udev process tree (all children) including the
ripping script after 30 seconds.

~~~
inopinatus
To fix this, perhaps it'll need to fork and detach the session, as per the
standard daemonisation sequence. c.f.
[http://www.itp.uzh.ch/~dpotter/howto/daemonize](http://www.itp.uzh.ch/~dpotter/howto/daemonize)

~~~
mst
systemd's session killing stuff will happily kill anything that's been
daemonised by the standard approach :(

------
theonemind
Linus has the proverbial moral authority to bootstrap an init system and the
technical skill to pull it off. Amusingly, this strikes me something like the
chairman of the Federal reserve hinting that he thinks interest rates are too
high. Hopefully, the systemd developers will take notice and clean up some of
their act. (Not to _insinuate_ anything. They have widely known problems in
playing nice with other projects, taking feedback, etc.)

~~~
SolarNet
_waits patiently for Linus to get fed up with ___ enough to write it himself_

 _dies_

~~~
theonemind
I don't really think he would, will, or wants to. But that he _could_ , and
actually _might_ if he begins to feel that systemd hurts Linux, might create
some positive pressure on the systemd developers. That's exactly the thing,
like the fed. They have enough power that an implied threat can fix things
(sometimes to some extent) without them actually taking any action.

------
owaislone
They [systemd] shouldn't piss him off too much. He will sit down for a week,
come out with his own init system which will take over the world. /s but not
entirely :)

------
ausjke
Like what happened to git in the past, will Linus write a new init himself
this time?

~~~
JdeBP
Considering the broad range of such softwares that _already exist_ , written
by people such as Felix von Leitner, Gerrit Pape, Laurent Bercot, and so on,
why do you think that Linus Torvalds is the person to write one? Or _needs_ to
write one?

* [http://blog.darknedgy.net/technology/2015/09/05/0/](http://blog.darknedgy.net/technology/2015/09/05/0/)

* [http://skarnet.org/software/s6-linux-init/](http://skarnet.org/software/s6-linux-init/)

* [http://smarden.org/runit/runit-init.8.html](http://smarden.org/runit/runit-init.8.html)

* [http://www.fefe.de/minit/](http://www.fefe.de/minit/)

* [https://jdebp.eu/Softwares/nosh/guide/system-manager.html](https://jdebp.eu/Softwares/nosh/guide/system-manager.html)

~~~
noisy_boy
There were many version controls systems before Git came along. He doesn't
need to write it. But if he wants, he has the technical chops to do a damn
good job of it.

~~~
digi_owl
Few did what Git does, take multiple forks and merge them.

Most that came before were good at forking, but not so good at merging.

------
gjvc
The quote here in the title is missing the vital context -- the full quote is

""And yes, a large part of this may be that I no longer feel like I can trust
"init" to do the sane thing. You all presumably know why.""

------
dsfyu404ed
This reminds me of a relevant joke.

Systemd walks into a bar. It shoots the bar owner and proclaims itself to be
the new owner. It then turns the bar into a farm, brewery and distillery,
opens a casino, a freight rail line and an investment bank. Oh, and there's an
init system thrown in there somewhere too.

------
testcross
The internals of systemd are maybe not the best. But the UI is definitely
easier to grasp than what existed previously.

~~~
JdeBP
I suspect that you are not aware of what actually _did_ exist previously.
Mewburn rc had short pretty much declarative service definition files. Upstart
had declarative configuration too, as did InitNG. Launchd, Upstart, and
Solaris SMF had the launchctl/initctl/svcadm concept.
daemontools/runit/perp/s6 had universal logging of standard output/error. And
so forth.

* [http://blog.darknedgy.net/technology/2015/09/05/0/](http://blog.darknedgy.net/technology/2015/09/05/0/)

* [http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-s...](http://jdebp.eu./FGA/run-scripts-and-service-units-side-by-side.html)

~~~
dijit
SMF without XML is gods init system.

It's so cleanly engineered, just like ZFS.. makes me sad that solaris died a
death.

(Their package management was crap though tbh)

~~~
JdeBP
Well illumos exists and people can always pick up SystemXVI and work on it.

* [https://github.com/ServiceManager/ServiceManager/](https://github.com/ServiceManager/ServiceManager/) ([https://news.ycombinator.com/item?id=10212770](https://news.ycombinator.com/item?id=10212770))

~~~
dijit
I'm a sysadmin, I'm at the mercy of OS developers as to what I run on prod,
and Solaris/IllumOS does not have the mindshare linux does.

I am certain that right now the choice of POSIX OS's at large companies such
as mine is Debian or RHEL/CentOS. Smaller companies get away with ubuntu.

But nobody is making new infrastructure with IllumOS/Solaris. The most people
will deviate is probably Free/OpenBSD.

------
qb45
Just wanted to say that the issue is about automatically copying rlimits from
the init processes to all processes executing setuid binaries - apparently
Linus thinks that init could possibly apply some rlimits to itself for its own
purposes which wouldn't necessarily be suitable for copying to any other
random process.

IMO this idea with copying is in itself even less sane than init using rlimits
on PID 1.

------
eleitl
Gee, such a surprise. Why didn't you speak out about it earlier, then?

~~~
digi_owl
Because he do not want to get involved with userspace bikesheding (beyond
posting rants about insane defaults in his distro of choice).

He sees his domain beginning and ending with the kernel, and that's it.

Sadly certain people below him, that he trust deeply, are not so content (some
even support Poettering and crew). And i fear the day he hand off the keys to
the kernel to them.

~~~
reactor4
Linus giving his opinion on userland is a far cry from bikeshedding though...

------
jwilk
For those who can't stand lklm.org UI, here's the mail on spincs.net:

[https://www.spinics.net/lists/kernel/msg2550717.html](https://www.spinics.net/lists/kernel/msg2550717.html)

------
codesurfer
When so many think that something is wrong, maybe there is some truth about
it...

If even the creator have concerns, man, that's not a joke!

------
yuhong
I wonder why Poettering chose Kay Sievers to work on systemd in the first
place.

------
Rjevski
I would assume this is about systemd. Personally my experience with it has
been great - the occasional screw-ups (they did happen - something related to
dbus made all systemctl commands fail until a reboot) were nothing compared to
the time I gained not having to worry about prehistoric initscripts.

So while it isn't perfect, it's IMO a step in the right direction, if only by
lowering the barrier to entry to actually using and managing the thing.

If you are worried about stability then you shouldn't rely on a single machine
anyway. Personally I manage systemd screw-ups (though I haven't had one in
production yet - all of them were on my personal machines while monkeying
around with Archlinux) just like any other hardware failure - by making sure
my app/service stays available even if I yank the power cord from the machine.

~~~
SwellJoe
It seems obvious he is referring to systemd. I _like_ systemd, but Linus hates
it when people break userspace, and systemd has broken userspace a _lot_.

Poettering seems to take the advice of "release early and often" to heart and
pushes things into widespread usage long before they're quite fully baked.
PulseAudio was awful for _years_ , and then it was good and we all stopped
complaining about it. systemd was kinda crap for months after it became
widespread...a ton of breakage, including in ways that were occasionally
dangerous. We're lucky, I guess, that systemd didn't take as long as
PulseAudio to stop sucking all the time (systemd still sucks some of the time,
but what it replaced sucked a lot, too).

So, yeah, you can't break userspace if you want Linus on your team, and
systemd has broken userspace now and then.

~~~
asveikau
You seem to exist in a fictional universe where pulseaudio "got good" and
doesn't suck. All these years later I have never seen that be the case. I
think a much more likely explanation is that desktop Linux is less common
since the rise of OS X in the "Unix-like developer machine" market so there
are now fewer people noticing it sucks.

~~~
SwellJoe
I believe the universe I exist in is real, but how would I know for sure?

Anyway, I haven't had to google about a pulseaudio problem in at least a few
years. I've been using Linux as my primary desktop OS since 1995. I've hated
Linux audio for most of that time, and I've broken it in every possible way.
But, today, my Fedora system has sound that Just Works. I don't know how it
Just Works (though I know it's pulseaudio), because I haven't had to
learn...because it Just Works. It works for Steam games, it works for browser
audio, it works for system notifications, it works for movies, it even works
for audio and music software. It's pretty weird.

Anyway, from what I can tell, the bugs, misfeatures, poorly thought out
implementation, etc. all got worked out somewhere along the way. It took a
long time. But, it did get fixed.

Have you actually used it in the past couple of years?

~~~
fiddlerwoaroof
I did try to use it and discovered that it's impossible to configure mpd to
run as a system service and be able to play sound while also allowing desktop
applications to play sound. I forget all the details, but the way I figured
out how to get sound to do what I wanted was to enable alsa dmix and to pipe
everything possible through dmix, using pulseaudio only for the one or two
essential apps that insist on it.

~~~
perakojotgenije
Funny, I just did that yesterday. I was reconfiguring my mpd server and I saw
it was configured to use alsa (which, incidentally broke my sound
occasionally). I set it up to use Pulseaudio and now I can listen to mpd
server while listening to deezer.com that runs through browser while making a
skype call on the same machine (not that I'd want to do it, anyway).

~~~
fiddlerwoaroof
Also, alsa+dmix does everything pulseaudio does (for all my use cases) without
having to run an extra daemon / abstraction layer.

~~~
majewsky
> for all my use cases

Exactly. Does it support redirecting audio streams to another machine on the
same network? That's a vital feature in our hackspace, where everyone can send
audio to the room speakers via PA, and it's also used extensively in my living
room (where the speakers are connected to the home server).

~~~
fiddlerwoaroof
I don't know, but sending audio over a network sounds like the sort of use
case that requires a sound server. Playing sound locally doesn't. Although, as
I said elsewhere, I have mpd stream to icecast for playing my audio remotely
so, in my case, I don't need pulseaudio for this: I imagine you could
configure a similar setup where anyone on the local network can register with
icecast as a "radio station" znd stream sound that way.

~~~
majewsky
A workflow that enables network transparency by using a tool for radio
stations might work for music, but not for anything with latency requirements.
Imagine playing any video game with even a 100ms audio delay.

------
TheAceOfHearts
Here's something I don't understand... Why do so many people hate systemd but
not macOS's launchd [0]? Don't they serve similar purposes? I've been digging
into macOS for a few months now, and I'm pretty happy with their defaults.

EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm
not a linux expert, so I'd love to hear your criticisms.

[0] [http://www.launchd.info](http://www.launchd.info)

~~~
AceJohnny2
I've worked with launchd, and I hate it more than systemd. Most of it is
because of launchd's atrocious doc. Note that launchd was rewritten a few
versions ago for Reasons [1]. I couldn't find any release notes that
highlighted this, and you wouldn't know it from launchd's version number...

Thing is, launchd's developers made a good effort at preserving backwards
compatibility, but it's far from perfect. And most online docs (such as
launchd.info that you're linking to) is subtly out-of-date. For example, I see
no mention of "service-targets": new launchd learned about "bootstrap domains"
(huh?), which are namespaces implemented at the Mach (macOS kernel) level.
It's not a Unixy thing. Trick question: how do you define a _user_ job that
runs in the background even when the user's not logged in? How do you define a
user job that runs if the user logged in via SSH (ie not GUI)?

It's late and I'm tired, I can try being more coherent tomorrow. There are
some good sources of information hidden out there, but the first few Google
responses are woefully obsolete. And fuck Apple's own docs.

[1] I'm not sure what the reasons are, but I suspect for a) merging iOS and
macOS functionality and b) tightly integrating it with the kernel's XPC
interprocess comms infrastructure (again, for iOS?)

~~~
eridius
> _do you define a user job that runs in the background even when the user 's
> not logged in?_

Well, you can't. Only administrators get to define things that run when the
user isn't logged in. That's an intentional decision.

> _How do you define a user job that runs if the user logged in via SSH_

Offhand, I don't think you can do that either, though I haven't researched
this particular angle. And it would be surprising to me that SSH'ing into a
machine would trigger daemons anyway.

~~~
JdeBP
> _And it would be surprising to me that SSH 'ing into a machine would trigger
> daemons anyway._

You might want to find out about systemd, then, which does exactly this. (-:

A PAM hook indirectly causes a per-user systemd instance to be created at
login and terminated at logout, which triggers all of the per-user daemons
that the account has.

If one has a user that is used for lots of little SSH sessions, hundreds of
thousands of times a day, the overhead of starting up and tearing down the
per-user systemd for each one, not least in terms of the log noise, becomes a
serious consideration, and one has to learn the systemd mechanisms for making
the user a "lingering" one.

~~~
eridius
For an OS that is frequently used headless, starting up per-user daemons on
SSH makes some amount of sense. macOS is designed to be primarily GUI-driven,
rather than primarily used headless, so it makes more sense for macOS to avoid
the issue that you describe by not supporting launching per-user daemons on
SSH.

------
stephenr
I fucking hope not.

Linus is clearly very smart, but user-facing tools is not what he's good at.
Git is a perfect example of this.

Mercurial and Git were created ridiculously close to each other, and their
main features/use model are quite similar, and yet mercurial is literally
years ahead in terms of usability. The results to a given command are 99% of
the time, what you would intuitively expect.

Now here's what I _would_ love to see: Linus initiate a fork/rewrite/whatever
of the init part of systemd, that _keeps_ the concept of non-executing service
definition files. They don't have to be compatible with systemd but that
wouldn't necessarily be a bad thing either.

Edit: actually, aiming for compatibility probably means having to reimplement
systemd weirdness, so probably _is_ a bad thing as I think about it.

~~~
beefsack
It's quite frustrating seeing people complain about Git usability like it's
some broadly accepted and objectively bad thing. As frivolous as anecdotes
are, I took to Git very smoothly and I found it to operate in a very obvious
and explicit fashion, particularly once I'd shifted my mental model from what
I was using at the time (primarily SVN.)

Git is a very powerful, flexible, reliable and efficient tool. I'd be over the
moon if someone wrote an init system holding similar values.

~~~
stephenr
That's the thing: it _is_ broadly accepted as having poor usability compared
to other version control tools.

If you haven't had those issues, you're one of the lucky ones.

Edit:

> Git is a very powerful, flexible, reliable and efficient tool.

I didn't say it isn't any of those things. I said it's harder to use than
competitors such as mercurial.

~~~
ShinTakuya
Do you have a source for this widespread acceptance? I mean I get that version
control in general can be hard for new developers to wrap their heads around
but I never really had trouble picking up git personally, and the interns at
my workplace haven't had any significant trouble either besides needing some
coaching in how rebase works.

~~~
stephenr
This comment (from a Hg developer on Lobste.rs [1]) is a good start:

> Furthermore, the proliferation of git wrappers says something. Mercurial has
> a lot of users too (Facebook), and guess what, they don’t write wrappers for
> it. They do write aliases and extensions, using hg’s established
> customisation mechanisms, but they don’t feel like the entire UI is so
> terrible that it has to be completely replaced by a different UI

Then let's consider this snippet, from the people that _literally_ wrote the
book on Git, in the Chapter "Git Internals" [2]:

> You may have skipped to this chapter from a previous chapter, or you may
> have gotten here after reading the rest of the book — in either case, this
> is where you’ll go over the inner workings and implementation of Git. I
> found that learning this information was fundamentally important to
> understanding how useful and powerful Git is, but others have argued to me
> that it can be confusing and unnecessarily complex for beginners.

If you don't know the internals, you don't really know git. I use git for
client work on at least a weekly basis - not necessarily daily. I know enough
to use it, and enough to know when I need to check the manual or search for
something. I don't know the internals, and it's wrong that we 'need' need to.

[1]:
[https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experien...](https://lobste.rs/s/klqjwc/two_commits_wrecked_user_experience_git#c_hukpc8)

[2]: [https://git-scm.com/book/en/v1/Git-Internals](https://git-
scm.com/book/en/v1/Git-Internals)

~~~
awinder
Careful with equating "Facebook is a wildly market-successful product" with
"Every engineering practice at Facebook is industry-applicable and should be
emulated".

~~~
stephenr
I didn't, the Hg dev simply used Facebook as a very large, well known software
shop that uses Mercurial. We could swap out "Facebook" for "Mozilla" or "Nginx
Inc." or a number of open source (either community or corporate backed)
projects.

~~~
awinder
We could do the same thing with Git though, so clearly source control scheme
is not strongly correlated with actual success of the project -- which makes
sense.

~~~
stephenr
That wasn't the point of the comment.

The point was that there are a _lot_ of git "wrappers" created to solve the
problem of Git's usability. The same doesn't happen with Mercurial, and it
_isn 't_ just because of a lack of use, as demonstrated by X, Y, Z
prominent/large software companies/projects using it.

------
Tharkun
Systemd is a steaming turd. However, it's one we have to live with, and there
doesn't seem to be anything better on the horizon.

A good book on the subject might make things slightly better. However, it
doesn't seem like anyone is interested in writing one :-(

------
teddyh
This is taking a quote out of context and trying to start the old usual
systemd flamewar. Flagged.

~~~
dpark
This isn't out of context. It's a direct quote and links to the full content
of the email.

Also " _If you flag something, please don 't also comment that you did._"

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

------
cperciva
I'd say that I no longer feel like I can trust 'git' to do the same thing
either... but who am I kidding? I never trusted it to do the sane thing.

~~~
dijit
You can say some negative things about git, but sanity is not one of them.

