
Why pro-systemd and anti-systemd people will never get along - uselessdguy
http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
======
fidotron
It will be very interesting to see how this all plays out in the long run,
though the short term is utterly depressing. My hunch is Lennart will be
vindicated, on the basis that systemd as it exists right now is not right, but
it can be evolved into something much better, and while that may not have
occurred to other projects here the stakes are enormous. There is a definite
strand to the resistance that any change to something so fundamental must be
resisted.

The bigger side argument about the Unix philosophy is also intriguing. Rob
Pike claimed it was dead and Perl delivered the eulogy, which I can half agree
with. The problem is shell scripting is archaic nonsense, but our script
languages can't do what you can do in shell scripts well enough. The idea of a
Unix where you get rid of bash/csh/whatever and just run a lua/python/ruby
prompt and have your apps implemented largely in that same language (with
shell commands being replaced by functions) may make some people squirm, but
would make a lot of sense for reducing the overall learning curve.

~~~
uselessdguy
Shell scripting isn't "archaic nonsense" at all, it's just that the warts from
how most shells implement their command language (ksh/bash/POSIX sh) are
holding us back. If you go look at Plan 9 rc shell scripts, you'll see how
much cleaner they are. In addition, the s6 people have done some interesting
things with execline (which looks kind of like Tcl), which works as a chain
loader instead of holding the shell resident, has a simple parser and is
performant:
[http://skarnet.org/software/execline/](http://skarnet.org/software/execline/)

The more I realize all the untapped potential lying around, the more I realize
how so many Linux users are living in their monoculture. Unfortunately there
is no one there to amplify all the good efforts and hidden gems scattered all
over the place, so you have people just reading Phoronix and LWN articles and
standing in their bubble. Meanwhile, all the non-Linux Unices and the "toy
project" builders are doing great things, but everyone thinks they're
irrelevant and dying.

~~~
zokier
> The more I realize all the untapped potential lying around, the more I
> realize how so many Linux users are living in their monoculture.
> Unfortunately there is no one there to amplify all the good efforts and
> hidden gems scattered all over the place, so you have people just reading
> Phoronix and LWN articles and standing in their bubble. Meanwhile, all the
> non-Linux Unices and the "toy project" builders are doing great things, but
> everyone thinks they're irrelevant and dying.

This is one of the main reasons I approve of systemd. It is something
completely new fighting against the old entrenched cruft. End result might be
good, might be bad, but at least it is activity instead of sedateness.

For all bad things that could be said about Poettering, at least he has ideas
and the confidence to execute on them.

~~~
jimktrains2
> This is one of the main reasons I approve of systemd. It is something
> completely new fighting against the old entrenched cruft.

Most people aren't anti-systemd because it's new, but because it doesn't
conform to their philosophy of how their computer should run. There could be
newer init systems that conform to their ideals, but systemd is not one of
them.

~~~
chc
_Could_ there be, or _are_ there? Because it is entirely possible that their
philosophy is too rigid to permit a system that is substantially different
from what exists now, in which case "They're against it because it's new"
seems like a fair assessment.

~~~
pessimizer
Are you arguing that it may me that all objectors to systemd would be
dissatisfied with all possible init systems different than what exists now?

~~~
chc
I'm arguing that "It doesn't agree with their philosophy" is not incompatible
with "They don't like it because it's new." It's not uncommon for people to
build personal philosophies that work out to "change is bad."

------
pessimizer
I have none of these objections to systemd. My objection is that it's both
pervasive and unauditable. I can accept one or the other.

I don't have to rely on 'many eyes' to tell me what's going on with init
scripts, I can just look. systemd is sprawling, has no particular philosophy
that I can notice, and all of its internal systems are heavily interconnected;
this leads me to expect that very few people will be auditing the code that
don't work for redhat, because very few will understand it. I expect it to
increase the vulnerability of the entire system to accidental or intentionally
inserted bugs by an order of magnitude. Therefore, I'd like to see it in the
wild for 5 or so years before personally using it - but it looks as if to
continue using many linux applications I have to switch to it _while it is
being written_.

I don't get the point (other than cgroups and boot times), I don't get the
hurry, and I don't get the animosity to alternate and legacy init systems, and
to alternate Unices.

~~~
bkor
Red Hat has audited the code in the past. The boot time bit is an item from
the linked article. The thing is that systemd provides more than just an init
system. Stuff that's pretty useful.

~~~
pessimizer
>very few people will be auditing the code that don't work for redhat,

~~~
bkor
You also said: > My objection is that it's both pervasive and unauditable.

You said it was unauditable, it has already been audited. Adding arbitrary
limitations to this doesn't change that.

~~~
e7620
I didn't downvote you, but I want to audit it myself, thanks.

~~~
bkor
I also help out at Mageia, the systemd packager (Colin Guthrie) is fairly busy
but does find the time to add patches to systemd package (e.g. backporting
fixes). Before systemd was integrated, he also fixed a fairly important
journald bug. He doesn't work for Red Hat. Every time before systemd package
is upgraded, he performs a lot of testing, often pushing things upstream
again. It's not without bugs by far. Reason it is stable is continued
coordinated effort across distributions. If you check the release notes of
some versions there are fairly big changes every so often. It requires a bit
of expertise to sort that out. Though a lazy distribution could just wait a
little and backport the "stable" marked patches.

~~~
e7620
The problem is that systemd is taking a lot of work better spent in other
parts of the project. Instead of testing systemd, it's better to user simpler
components, systemd is evolving, introducing more bugs, and people like that
packager have to make a Herculean effort instead of using other init system,
even sysv! and improving other applications.

------
FreakyT
Interesting discussion! I would have liked it if the author had provided some
background information (for the uninitiated) about some of the other related
issues mentioned. For example, what was meant by "the horrors of PulseAudio",
"the udev debacle", and why was HAL bad?

I realize that I could probably find out "bad things about HAL" via internet
searching, but it would be more interesting to see the author's take on the
issues in the context of the article.

~~~
uselessdguy
I kind of stitched this essay together haphazardly, and it certainly does
require some background knowledge to fully understand.

Nonetheless, "the udev debacle" refers to systemd merging udev into its
codebase, along with tying it to systemd's shared files, the recent "debug"
parameter fiasco and the rather blunt statement by Lennart concerning
migrating the transport to kdbus:
[http://lists.freedesktop.org/archives/systemd-
devel/2014-May...](http://lists.freedesktop.org/archives/systemd-
devel/2014-May/019657.html)

PulseAudio (originally PolypAudio) is a networked sound server most often used
in Linux systems coming with a variety of centralized features (see here:
[http://www.freedesktop.org/wiki/Software/PulseAudio/About/](http://www.freedesktop.org/wiki/Software/PulseAudio/About/)),
which proved to be highly controversial initially and less so to this day.
People realized it was buggy and unstable, and different factors were blamed:
poor integration, sloppy ALSA drivers, or PulseAudio itself. The most common
narrative these days is "PulseAudio was bad because Ubuntu rushed it", but I
haven't studied things in enough detail to pinpoint exact reasons.

As for HALd, it did solve problems at the time, but I'll quote the Ubuntu
wiki: [https://wiki.ubuntu.com/Halsectomy](https://wiki.ubuntu.com/Halsectomy)

~~~
adwf
Pulseaudio is still crap for me. I can't get consistent volume across
applications and it's 50/50 as to whether it'll recognize my headphones on any
given day. I still rate it as crap compared to my nice stable ALSA setup.

So that really worried me when I found out Arch linux was switching to
systemd! Thankfully it's all been ok as far as I can tell. Had to learn a few
new commands and that's about it. Maybe it's different for the people actually
configuring daemons, but as far as the end user goes, I haven't noticed any
problems.

------
nanoscopic
That was a very long and detailed explanation of the sides of the argument.

It misses one huge thing: Consistency.

The elephant in the room is that most people who dislike systemd simply
dislike it because they learned and used init.d scripts, runlevels, and
chkconfig, and that is the extent of their understanding.

The main hatred for systemd is coming from people simply being resistant to
change. If it ain't broke, don't fix it.

I like systemd for it's technical merits. I personally would prefer to use a
distribution like CentOS in a mode where there is no systemd, simply because I
like simplicity and systemd is more confusing to me.

What I foresee happening: people who don't like systemd are going to go try
other distributions that don't use it, and may abandon the ones that do
because it is too much trouble to run them without it.

The statement that it will lead to divide between graphical linux users and
minimalists is likely very true. Runlevels may be simplistic and outdated, but
they are easy to remember.

~~~
uselessdguy
No, I specifically addressed this:

\--------------------------------

"The rather huge scope and opinionated nature of systemd leads to people
yearning for the days of sysvinit. A lot of this is ignorance about good
design principles, but a good part may also be motivated from an inability to
properly convey desires of simple and transparent systems. In this way,
proponents and opponents get caught in feedback loops of incessantly going
nowhere with flame wars over one initd implementation (that happened to be
dominant), completely ignoring all the previous research on improving init, as
it all gets left to bite the dust. Even further, most people fail to
differentiate init from rc scripts, and sort of hold sysvinit to be equivalent
to the shoddy initscripts that distros have written, and all the hacks they
bolted on top like LSB headers and startpar(2). This is a huge
misunderstanding that leads to a lot of wasted energy."

\-------------------------------

This isn't about people "hating change". It _looks_ like it, because a lot of
people who defend sysvinit aren't really doing that as much as they are
defending minimal and transparent systems. In fact, there's _way_ too many
people who don't understand "init". Init is the first userspace process that
is started. That's it. Init doesn't mean "manages services", "manages
processes" or anything like that. Those are separate concepts. The sooner we
realize this, the sooner we can have some more innovative architectures for
managing services, as we're still trapped in this mental cage.

Moreover, it's not just systemd haters who are resistant to change. A lot of
systemd lovers are, as well. In fact, the reason we didn't fix the problem
earlier and stuck with SysV for so long was precisely _because_ people didn't
care about init, and didn't want to change their flawed ways. Well, at least
in the Linux communities. Many of the people who resisted change when
presented with non-SysV approaches back in the day are the same who now
support systemd and lament on how much "systemd haters don't like change".

systemd, of course, went significantly beyond service management, and thus had
a much bigger impact than previous designs which were rather focused on one
problem domain. Thus, systemd simply became far more prominent (and
controversial) than anything else because of its huge ambitions.

~~~
nanoscopic
Most people don't know much about any of the details. They have simply done
things one way for a long time and now it is changing. You haven't addressed
that besides accusing those people of being "ignorant about good design
principles" and "having huge misunderstandings that leads to a lot of wasted
energy."

From the perspective of the average linux user ( one that knows little to
nothing about linux internals ) the entire discussion is the real waste of
energy.

The people who know a ton are a different category altogether; you have
addressed those.

The category of people you are ignoring is those who did it one way now they
are suddenly "forced" to change.

I feel the same way about firewalld as I do about systemd. Iptables was
confusing, but I used it till I was able to do what I needed. Now all of that
knowledge is useless because I have to use a different system to stay with the
rest of the group.

Is systemd better? Sure. Is firewalld better? Dunno; I think so. Am I ignorant
and clueless and misunderstanding everything? No... I just have a different
perspective than all of the people fighting about this. All I want is to
continue my simple life. Learning new stuff is a drag if it worked fine
before. ( I'm aware of how sucky 'fine' is... )

This is not an argument; it's just a statement of how I and a lot of people
feel. We used to have a normal car; now the steering wheel is gone and
replaced by a grid of 20 buttons that control an automated robot who steers
for us. We were used to the wheel. We ask for the wheel back and we are told
we are clueless and ignorant and should use the buttons.

~~~
e7620
> From the perspective of the average linux user ( one that knows little to
> nothing about linux internals ) the entire discussion is the real waste of
> energy.

If all distros adopt "systemd/linux", a future plan for systemd according to
lead developers, what happens if systemd collapses? It would take GNU/Linux
with it. Remember how pulseaudio adoption by ubuntu drove users away. I want
others to have access to UNIX, the best OS in the world, just like I had the
opportunity.

~~~
stock_toaster
> I want others to have access to UNIX, the best OS in the world, just like I
> had the opportunity.

Thankfully, there are several alternative free unix-like operating systems
these days. Are they are popular as Linux? Do they have as much big
business/corp backing as Linux? No and No. However, if Linux implodes there
are great alternatives these days. I personally use and quite enjoy FreeBSD.
ymmv.

* Linux (topic of discussion) * BSD derivatives: * FreeBSD / NetBSD / OpenBSD / DragonFlyBSD * Illumos (opensolaris) derivatives * SmartOS / OmniOS / OpenIndiana * Minix * more[1]

[1]: [1]:
[https://en.wikipedia.org/wiki/List_of_operating_systems#Unix...](https://en.wikipedia.org/wiki/List_of_operating_systems#Unix-
like)

~~~
e7620
I agree completely, those operating systems are great, as good or better than
GNU/Linux. But with that phrase I was thinking people without prior
experience, like Windows users, FreeBSD install is fairly involved for them,
there's PC-BSD, but it seems to me, distros like Mint are easier for beginners
and useful as a stepping stone to those OSs.

~~~
stock_toaster
I think Linux has an edge in driver support, and corp vendors -- especially
for gaming with things like Steam.

I really like some of the things the pc-bsd folks are doing though. Lumina
seems to be coming along nicely.

~~~
e7620
> I think Linux has an edge in driver support, and corp vendors -- especially
> for gaming with things like Steam.

Still, remember when using linux meant compiling the kernel ten times, editing
some .c file, changing some obscure flag. And then you needed to open that
.doc, .ppt or use msn messenger. You tried dual booting, but windows kept
rewriting the bootloader...

Now, with VMs and tech like PCI pass-through this is just SO easy, that issue
is less relevant and will result in more popularity for other OSs and a
reversing of the consolidation trend.

------
Aardwolf
I think most of it is ok, such as the init system, except the logging. Why did
they have to touch logging, and change everything about it, and put it in a
non-text format...

------
hello_there
What I really dislike about these debates about systemd is that usually nobody
mentions the alternatives. From reading the debate I get the impression that
both sysvinit and systemd have major problems, but I'm never presented with a
solution. So if I'm going to be against sysvinit as well as systemd, then what
should i be supporting?

~~~
exelius
The main alternatives seem to be OpenRC and Upstart. One of the biggest
criticisms of systemd by its detractors is that it's unproven and not stable;
and neither of these address that concern.

Upstart was developed by Ubuntu, which has stopped supporting it and is
adopting systemd because they recognized the need to standardize on a single
system. After the Debian committee voted to go with systemd, Ubuntu (being a
Debian derivative) followed suit.[1]

OpenRC isn't really a replacement for sysvinit; rather it bolts on some
functionality on top of sysvinit. My understanding is that OpenRC is not an
incredibly mature codebase and would have needed a lot of work to come up to
feature/stability parity with systemd. Because it doesn't fully replace
sysvinit, it also doesn't solve all of the same problems as systemd.

[1]
[http://www.markshuttleworth.com/archives/1316](http://www.markshuttleworth.com/archives/1316)

~~~
vertex-four
> The main alternatives seem to be OpenRC and Upstart.

There's also outliers like nosh[0], which implements at least some of the good
bits of systemd (socket activation is in there), and the ideas and general
architecture are solid enough that it could be extended to implement more
(device/path dependencies through udev and inotify are two that I hear people
wanting). Then separate pieces of software can implement the remainder of what
systemd implements (its many dbus APIs).

[0]
[http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...](http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html)

~~~
exelius
This debate has been raging for the better part of two years and many of these
alternatives didn't exist when it started. Really though, systemd has the
momentum and I don't see anything else remaining a mainstream alternative
unless it just emulates systemd's functionality.

~~~
vertex-four
systemd's functionality isn't the issue - it's its architecture that is. An
alternative bundle of software which is less strongly coupled would likely be
accepted with open arms. I'd like to be able to pick what init system I want
to use separately from what manages /dev and what handles my logging and what
handles sessions/seats/logins.

nosh's architecture allows for that, whereas with systemd, while it amounts to
60-whatever binaries, you end up being required to run a significant amount of
them in order to use any given bit of the system, and have to run systemd as
PID 1 to run a fair amount of them. Why setting up kdbus, for example, can't
be a separate process that doesn't depend on anything but libc and the kernel?
No idea.

~~~
exelius
Yeah; I get the objections. More pragmatically, systemd was developed the way
that it was, and for a large portion of its life there have been no credible
alternatives that were objectively _better_.

But once systemd's behavior has become standardized, it becomes hard to change
implementation details because its dependencies rely on not just what it does,
but how it does the things that it does. You have to standardize on something,
and it will inevitably be flawed because no system is perfect. Sysvinit is not
adequate anymore (and I don't think you would disagree with that). Systemd was
a solution that someone came up with, and was able to get a number of
influential groups to agree to standardize on that solution.

~~~
vertex-four
> Sysvinit is not adequate anymore (and I don't think you would disagree with
> that). Systemd was a solution that someone came up with, and was able to get
> a number of influential groups to agree to standardize on that solution.

Absolutely. I'm just sad that the people behind the solution are making it
harder and harder to replace that solution for people who'd like to, and
anybody who sees the issue with that is labelled a "troll" or a "hater".

On the other hand, at least you can parse systemd unit files to convert them
into whatever (nosh has a utility to do that). I think that's going to be a
standard well after the Linux community diversifies from systemd. It's a
fairly solid format.

------
floatboth
The referenced article that criticizes both SysV and BSD inits is from 2002.
BSD systems have had separate scripts in a folder (rc.d) since, like, forever.
And "[package installation] needs to edit one of the existing boot scripts" is
the only criticism there.

There might be more current issues, but I believe it's good enough. For
example, BSD init doesn't have super web scale auto restarting and monitoring
and log routing. Well... it doesn't need to. Just use it to launch supervisord
or something. Also, it's not super fast because it uses the shell. Again, it
doesn't need to be. It's fast enough for general purpose servers and desktops.
For special cases like containers and whatnot you need special tools.

~~~
JdeBP
That's an odd definition of "forever", there. NetBSD gained its rc.d system at
the end of 2000, with the release of NetBSD 1.5. FreeBSD started porting work
in 2001, and that carried on through 2002. FreeBSD 5.0 with rc.d was released
in 2003. OpenBSD didn't get the rc.d system until version 4.9, released in
2011. Is just 3 years ago "forever" in World Wide Web time, now? If so, does
that make the 11-year gap between NetBSD and OpenBSD "almost quadruple
forever"? (-:

------
jude-
Thank you for taking the time to write this up! (the link is also appreciated
:)

I think a lot of the rage and loathing regarding systemd is due to its
coupling to the rest of the OS. I think a lot of !systemd users were quiet on
this initially (and today even) since it's not hard to avoid systemd _if_
you're not running a full-fledged desktop environment. I think it's the fear
that this will change in the near-future that has prompted the backlash we're
seeing now.

I hope that Debian's new init system coupling GR will address this, both for
itself and for its derivative distros. If the rest of the OS does not care
about whether or not it's systemd managing the daemons or something else, then
everyone wins.

------
hk__2
Could someone ELI5 this pro-systemd/anti-systemd thing?

~~~
deelowe
Linux/unix has a bit of an issue with it's init aging systems. One simple
example is that they are serial, meaning that services start one by one with
little to no concurrency. This causes several issues. Also, the most popular
variant, system V is difficult to maintain having multiple directories for
various run levels and other cumbersome features. I won't go into details
here, just know that the popular init systems needed a refresh.

There are other options, but systemd seems to have caught on as the popular
option for a replacement. The issue that most people take with systemd is that
it does much more than replace init. It replaces cron, has a login management
hooks, has it's own network daemon, replaces the system logging facilities and
more. It's a serious complex system.

The issue some take with systemd has a few facets:

1) Some feel that systemd's approach to managing everything goes against
Unix's core principles where services and applications are supposed to be
small, self contained entities that work in unison to form a cohesive system.

2) It can be daunting task to switch over to systemd as you have to relearn
many traditional unix tools that most take for granted (remote logging for
example).

3) Security minded people are concerned that a single service is touching so
many parts of the core system all at once. There have been many complaints
levied that such a large change introduces too much risk into the ecosystem
all at once.

4) Some have accused the dev team of having a "not invented here" problem.
I've seen it asked many times why they really needed to replace cron or
logging.

The pro-systemd stance is that they are simply cleaning up many of the
antiquated systems. Cron, logging, and init definitely all needed an overhaul.
Linux never had a good network daemon and there are good reasons for the other
things they are doing. The systemd team sees systemd as not just an init
system but basically the system manager. So, by that view, this all makes
sense.

Ultimately, it's a fundamental difference of opinion about what services in
general should or should not look like on a unix/linux system.

~~~
rthomas6
Could someone just fork systemd and make a version that relaces the init
system and nothing else?

~~~
bkor
That's uselessd. Software however relies on the other bits, e.g. logind dbus
interfaces. For that there is a systemd-shim, but was not there initially and
used to lag behind systemd for a 6+ months. Apparently it was also quite
buggy. Seems ok now though.

~~~
washadjeffmad
To clarify, uselessd
([http://uselessd.darknedgy.net/](http://uselessd.darknedgy.net/)) is "a
project to reduce systemd to a base initd, process supervisor and
transactional dependency system, while minimizing intrusiveness and
isolationism", not just the parent making a joke in the phrasing.

------
erhardm
I see the whole pro/anti systemd as a philosophical debate. Basically each
part is arguing where the complexity should be in the system and how dense it
should be distributed. I think we need _two_ competing init systems to really
know maybe in 5-10 years what the best trade-offs are. A _modern_ sys V init
and systemd.

~~~
exelius
I think the point is that you _can 't_ have two competing init systems: the
market will eventually need to standardize on one of them or risk forking the
entire Linux ecosystem. What you call "modern sysv" would look a lot like
systemd depending on your definition of modern. I think that definition of
what modern should look like is what's being debated here.

The big features sysvinit are missing require user space applications to be
able to interact with [generic launch system]. Those applications must use
some sort of standard taxonomy and flow control. As applications are ported to
[generic launch system], they cease working on sysvinit systems because sysv
either doesn't support those features or supports them in a different manner.

Sysvinit doesn't really do all that much, to be honest. So it's really easy
for [generic init system] to emulate most of its functionality. [generic init
system] does a lot more, so it's harder to copy. Even more, if you were to
"clone" [generic init system], applications make big assumptions as to how
[generic init system] functions, so your [generic init system] replacement
would need to function nearly identically to [generic init system].

Basically, someone made a call and said "this is how a modern init system
should function". There is a vocal group of people who disagree with that
definition. But no matter what the definition is, people would disagree
because different people have different ideas about what Linux is/should be.
You would see the same problem if a sysvinit derivative was the leading
candidate instead of systemd.

~~~
erhardm
They're good points, but from the philosophical point _The Unix Way_ , systemd
leaves some things to desire. Is there a _modern_ Unix way? I don't see a lot
of exploring in this area/side, but I see a lot of _this is the way it 's
gonna be from now on_ on the other side.

I'm not on either side, but I appreciate the way some complexity is dealt with
simple little things. So elegantly solving problems:
[https://www.youtube.com/watch?v=S0mviKhVmBI#t=450](https://www.youtube.com/watch?v=S0mviKhVmBI#t=450)

~~~
exelius
I'm not on either side myself, either. But "this is the way we've always done
things" is a terrible reason to keep doing them that way. Systems change,
requirements change, and so implementations and methods must change as well.
I'm not saying this is warranted or not in the case of systemd (I don't know
enough of the details to opine either way) but it has been a cultural problem
in the Linux community for a number of years. Modern _use cases_ require a
more coordination between multiple parts of the system, which is I think where
a lot of the friction comes from.

The entire systemd debate is as bad as it is because this is a can that has
been kicked down the road for two decades because nobody wanted to have the
same argument again. Everyone has known for a long time that at some level,
Linux needed better coordination between user applications, hardware, and
system services. systemd seems to deliver on most of the functional
requirements of such a system, though the implementation method has upset some
people on a philosophical level because they believe it's counter to the Unix
way, whatever that means.

I would argue that software development in general has drifted away from "the
Unix way". Modern software development is a mess of dependencies, abstraction
layers, control points and dominant standards controlled by
individuals/companies with a vested interest. Linux is a good counterbalance
to that, but at the same time it can't stray too far away from the way that
people use systems or it becomes too outdated to matter. Is systemd the
answer? Who knows. But in the absence of something that performs its function,
companies will step up with proprietary solutions for their use cases (launchd
on OS X/iOS, whatever Android uses) that lead to more walled gardens, not
less.

~~~
agrover
I think the fallacy is looking at the composability of tools on the command
line and thinking you want/need the same composability in how the system runs.
You don't. The Unix Way is actually TWO things: one is shellscripting and the
composability of the command line, and the other is C and libraries.
"Whipupitude vs manipulexity", to quote Larry Wall. Systemd is the result of
determining that running system services _is_ complex and needs to be handled
by a real program instead of scripts. This is easier in C, but the flipside is
the unavoidable loss of whipupitude. For most people this is fine. When Unix
was young, whipping up something simple was fine. Now it isn't, and really
hasn't been for quite a long time.

~~~
anko
Thank you, this is the most insightful comment I've read.

People like the whipupitude, because they know it. But nearly every init.d
script I've read has bugs. There isn't a testing framework to ensure
correctness and even if there were it would be needlessly complex because
you'd spend a bunch of time mocking out the filesystem / the process table /
whatever else init scripts do.

We know what initialising a process should look like and we should be
stabilising this API so that we limit mistakes/bugs.

------
wmf
If systemd is bad for servers, why did RHEL[1] and CoreOS adopt it? Are we to
believe that these companies work against themselves?

[1] AFAIK 90% of Red Hat's revenue is from servers, not desktops.

~~~
makomk
It's a good weapon against Red Hat's proprietary Unix competitors like Solaris
- by tying as many things as possible to systemd they ensure it can't run on
non-Linux systems. Same reason the proprietary Unices had their own oddball
service management frameworks, APIs, etc. Also, RHEL was still using the old,
grotty sysvinit-based system where you had to manually specify the order in
which services were started and stopped; almost anything's an improvement on
that. (All the other major distros had migrated away from it ages ago.)

------
burtonator
emacs is the one true editor...

same thing all over again :-P

------
ck2
I don't want anything bad to happen to Lennart, I just want him to take his
football and go home.

Then suddenly init.d will look very open and friendly again.

Maybe the same thing can happen to grub2 and I wouldn't mind going back to
good old grub.conf

~~~
vidarh
> Then suddenly init.d will look very open and friendly again.

Having used systemd on a few machines by now, I won't ever go back. It's
utterly naive to think that systemd would go away if Lennart were to.

~~~
mercurial
Not to mention that quite a few people contribute to systemd [1], even if
Lennart is still leading the pack.

1:
[https://github.com/systemd/systemd/graphs/contributors?from=...](https://github.com/systemd/systemd/graphs/contributors?from=2014-01-08&to=2014-10-21&type=c)

