
What's wrong with systemd - uggedal
http://www.landley.net/notes.html#23-04-2014
======
hdevalence
> The systemd developers are responding to upstart and launchd and android
> init as things they must _defeat_, an establish a new standard by crushing
> all the competing implementations.

This actually... isn't true. If you feel like wasting valuable time of your
life, try reading the Debian systemd flamewar: the people with the most rabid
'holy war' attitudes are the systemd opponents.

People who favour systemd generally use it to get shit done [1], not write
blog posts about 'freedom of choice' [2].

Fedora/RHEL, SuSE, Arch, and now Debian didn't decide switch to systemd
because they were all strong-armed by Lennart's evil cabal or something, they
did it because each of them decided that it was a superior system.

Because it is [3], and no other system, save Upstart, actually put in the work
required to be a potential replacement.

[1]: [https://lists.debian.org/debian-
ctte/2014/01/msg00287.html](https://lists.debian.org/debian-
ctte/2014/01/msg00287.html)

[2]: [http://www.redhat.com/archives/fedora-devel-
list/2008-Januar...](http://www.redhat.com/archives/fedora-devel-
list/2008-January/msg00861.html)

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

~~~
mackal
In most cases the opponents are mainly opposed because of Lennart, not
technical reasons, not freedom of choice, but because of Lennart. Most of them
will explain their reason with refences to technical or freedom of choice but
once you get down to it, its just Lennart.

You know what your average user wants? A faster booting system. In most cases
that will be systemd.

~~~
felixgallo
You couldn't be any more wrong. The average user has no idea that she is using
Linux. The number of people using a Linux system that reboots frequently
enough to be noticed is zero.

~~~
bitwize
Are you talking about servers? Because it's not 2000 anymore; the idea of
servers running single instances of Linux for months or years at a time and
rebooting is so infrequent that an extra second or two is no big deal, is
obsolete. The cloud is king, and in the cloud you want to have instances which
can be started up and shut down quickly and safely. That means that systemd
makes just as much sense on servers as it does on desktop and mobile systems,
if not more.

~~~
felixgallo
My cloud instances already boot up quickly and safely, thank you. I don't need
a mountain of technical debt and poorly designed architecture in order to
increase the speed by two seconds.

------
asb
I fail to understand the swipe at Canonical for having /bin/sh point to dash.
Having /bin/sh point to a lightweight POSIX compliant shell seems a wholly
sensible choice. Indeed, the ability to swap out one implementation for
another (made possible by the POSIX standardisation of the unix shell) seems
to be exactly what he's arguing for elsewhere in the article.

~~~
byroot
I'm pretty sure this change was initiated by Debian. I recall it was already
the case on Debian stable circa 2008.

~~~
masklinn
According to each distribution's documentation, Debian switched to dash in
2011 with Squeeze[0] whereas Ubuntu switched in 2006[1]

[0] [https://wiki.debian.org/Shell](https://wiki.debian.org/Shell)

[1] [https://wiki.ubuntu.com/DashAsBinSh](https://wiki.ubuntu.com/DashAsBinSh)

~~~
teddyh
That is misleading. Debian seems to have changed earlier, but not done an
official release for some time after the change; Ubuntu took, as they always
do, this unreleased version of Debian and released it as the new version of
Ubuntu.

~~~
masklinn
> That is misleading.

No. Even if you don't agree that a stable release is the correct check point,
that means the change was done during Squeeze's testing cycle and thus Lenny's
lifetime, which started in 2009. Fact remains that Ubuntu switched years
before Debian, as a number of sources confirm such as this LWN post from July
29, 2009[0] noting that, at that time, dash remained _a topic of discussion_
on Debian mailing lists (and an unrealised goal for Lenny) whereas Ubuntu had
switched 3 years prior.

> Ubuntu took, as they always do, this unreleased version of Debian and
> released it as the new version of Ubuntu.

That's not just "misleading", that's outright bullshit. Ubuntu switched to
dash as /bin/sh independently from Debian and regardless of what Debian did.

[0] [http://lwn.net/Articles/343924/](http://lwn.net/Articles/343924/)

~~~
teddyh
I stand corrected. I did try to do some research, and what little I could find
seemed to support my recollection, but apparently I was confused and failed in
my research.

I concede the point.

------
matthewmacleod
I'm kind of indifferent to system's adoption, but I've heard quite a lot of
complaints about it that have subsequently turned out to be false. It can
sometimes be hard to filter out the noise.

However, it looks like most major Linux distributions are going to be using
systemd. Fedora, Arch, Debian, Ubuntu (eventually), Redhat, SUSE, even CoreOS.
What I don't get is why there would be comprehensive adoption across
distributions if systemd was obviously the wrong decision.

------
vezzy-fnord
The main source of ideological disagreement between pro-systemd and anti-
systemd users is just how much an init should handle. Anti-systemd side
insists on init being just an init and not exceeding its duties, whereas pro-
systemd are willing to make the init handle various other functions, due to
the alleged benefits.

I think at this point it's erroneous to call systemd an "init system," it's
far more than that and Lennart himself freely admits it in (ironically) the
article meant to dispel systemd myths ([http://0pointer.de/blog/projects/the-
biggest-myths.html](http://0pointer.de/blog/projects/the-biggest-myths.html)):

 _Well, systemd certainly covers more ground that it used to. It 's not just
an init system anymore, but the basic userspace building block to build an OS
from, but we carefully make sure to keep most of the features optional. You
can turn a lot off at compile time, and even more at runtime. Thus you can
choose freely how much feature creeping you want._

I'm not entirely sure about how optional the whole package really is. I know
for a fact LXC tools like systemd-nspawn, Python bindings, etc. can be removed
from the build using ./configure, but I don't know the full extent to judge
the veracity of his claims.

Olav Vitters of GNOME and Debian (I believe?) later echoes the same sentiment
in a somewhat self-contradictory manner:
[http://lwn.net/Articles/575790/](http://lwn.net/Articles/575790/)

 _Systemd is meant to do one thing and do it well: be the basic building block
for Linux._

Of course, one must first define what a "basic building block for Linux" is,
although that isn't really elaborated.

Personally, I don't have any strong opinions in favor of or against systemd,
but I do feel it was introduced in a rather rushed manner. I think it would
have payed off better for the community if people researched certain alternate
init schemes that were already present before systemd (not talking about
launchd/Upstart), such as Richard Lightman's depinit:
[https://web.archive.org/web/20050206182736/http://www.nezumi...](https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html)

However, it's probably a bit late by now, since systemd's place has been set
in stone, for better or for worse.

------
thegeomaster
I developed an (unjust) animosity for systemd when a `pacman -Syu` installed
it and broke my Arch system (which relied on a small password-prompt
initscript written by me that I had completely forgotten about) but when I
took a fresh look it didn't look bad. I have only a year of so of real
GNU/Linux experience so take this with a grain of salt, but I think that even
if systemd's got problems, they're not related to it being too monolithic. And
although I haven't really measured, my ancient Atom-based MSI netbook seems to
boot way faster than with initscripts.

------
SEJeff
TL;DNR version: systemd breaks the one thing that makes Linux great, it's
modularity and ability to swap out individual components with separate
discrete implementations.

~~~
dsr_
No, I think you got that wrong.

TL;DR: systemd's supporters treat anyone who doesn't like it as an enemy to be
defeated rather than a fellow traveller who is taking a different path.

If I look at launchd or upstart or openrc or runit, I see a project which
wants a competitive landscape where they can demonstrate their merits for
various uses.

When I look at systemd I see Microsoft.

~~~
PeterisP
Systemd's supporters might as well be devil-worshipping baby eaters, but
that's not any argument for or against systemd as such, that's simply
irrelevant.

~~~
felixgallo
Not entirely irrelevant. Sociopath risk is real.

~~~
ithkuil
Not sure I understand. Are you implying that we should resist systemd because
Poettering is a sociopath?

------
pmoriarty
Does anyone have any insight in to why something like runit[1] was never a
serious candidate for a sysvinit replacement in any mainstream Linux distro?

[1] - [http://smarden.org/runit/](http://smarden.org/runit/)

~~~
zdw
A few reasons:

\- There's a general opposition to the djb's designs and tools, which has some
basis in their licensing, and is why djbdns and qmail aren't in the default
distro of most systems. Note that this is being reversed right now with the
embrace of NaCL crypto (Salsa20/ChaCha/Poly1305, etc.) as alternatives to the
mainstream.

\- runit is pretty much an reimplementation of djb's daemontools for service
supervision.

\- runit/daemontools definitely do things their own way. Service directories
make sense, but they tend to be shell scripts all the way down. Logging is
quite different and non-centralized. Services need to be set not to fork and
do their own daemon management. And the list tends to go on - this unusual-
ness is generally not what people want from a core OS part.

So, in short, there's no reason why people haven't used runit, other than
"nobody else is doing it" and "it's different and has quirks".

~~~
pjscott
Note that both djbdns and qmail have been in the public domain for years now.
The general opposition to their license seems to have long outlived their
license.

~~~
zdw
I think that's more related to the non-unified, pre-DVCS patch centric model
of development, and the fact that djb has better things to do/is no longer
interested in developing them.

If djb would have found an interested party to accept patches to the codebase,
set it up on a code hosting site, then declared "this is the main repo for
continuation of djbdns/qmail development", it would have gone a lot further
than just "it's in the public domain" and no other guidance.

This has lead to things like "dbndns", which are a good attempt, but
definitely not a general, cross unix version solution:
[http://packages.qa.debian.org/d/djbdns.html](http://packages.qa.debian.org/d/djbdns.html)

------
intslack
The vast majority of distros seem to agree that standardization is a good
thing in the switch to systemd. If you don't want to be standardized maintain
it yourself, see: GoboLinux.

But modularity of Linux doesn't seem to be going anywhere. Contrary to what
the author says, systemd is not monolithic but rather consists of protocols
and multiple daemons outside of PID1.

There doesn't seem to be any plans to stop one from using anything other than
systemd on say Debian either. As far as I know the only hard requirement for
systemd (really logind) is with Gnome on Wayland for user seats, because
Consolekit is dead. Gnome seems to be willing to work with the *BSDs et al who
have no plans to switch to systemd.

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

~~~
Sanddancer
The problem is that while systemd is superficially a bunch of different
commands, they are a clinking, clanking mess of poorly documented programs
that do their job worse than the programs they replace.

For a moment, let's look at one of these components, systemd-backlight, and
it's terribly written manual page,
[http://www.freedesktop.org/software/systemd/man/systemd-
back...](http://www.freedesktop.org/software/systemd/man/systemd-
backlight.html) . Okay, so what return values can you expect? Where on the
filesystem does it store the saved values so you can debug if things do go
cactus? Why does it always overwrite the value at shutdown? These are all
things that a reasonable program either should not do, or should document why
and where they put things. Systemd just is not a responsible, well-engineered
project.

Furtnermore, the only real reason consolekit is dead is because Lennart again
shows a complete lack of responsibility as a developer with that project. He'd
rather shove everyone towards his new baby of systemd than to do a responsible
hand-off. This is furthered in his inability to document the interfaces used
so that people can write compatible software, so that people can debug
software, and so that people can maintain things if he ever gets hit by the
number eight bus going downtown. It's just not a good way to run things,
period.

~~~
JoshTriplett
> Where on the filesystem does it store the saved values so you can debug if
> things do go cactus?

Quoting the page you linked to: "On disk, the backlight brightness is stored
in /var/lib/systemd/backlight/."

~~~
Sanddancer
I missed it. I guess I've gotten spoiled by BSD manual pages that have file
locations in a subsection labelled Files instead of stuck in the description.
At the same time, it gives a directory location, instead of an actual
filename, which lends one to believe that the actual name and location will be
subject to change without notice, as well as the contents of the file, format,
etc.

------
Aloha
I still sorta look at systemd as a solution looking for a problem.

System V style init is just 'good enough' for most applications - and if there
is anything I've found in my time, the only people more adverse to change then
telecom folks are Unix system administrators.

------
revscat
Could someone with more knowledge about the subject explain why launchd was
never taken up outside of OS X? I'm not an admin by any stretch of the
imagination, but it seems to fit the bill _fairly_ well, and I've always
wondered why it has not been ported elsewhere.

~~~
vvhn
launchd makes heavy use of Mach IPC (
[http://en.wikipedia.org/wiki/Mach_(kernel)](http://en.wikipedia.org/wiki/Mach_\(kernel\))
) which makes a port to any other non Mach derived OS a non trivial effort.
There was apparently an effort to port it to FreeBSD -
[https://wiki.freebsd.org/launchd](https://wiki.freebsd.org/launchd) and more
recently
[https://github.com/rtyler/openlaunchd/blob/master/README.md](https://github.com/rtyler/openlaunchd/blob/master/README.md)
.

------
JoshTriplett
Replying to the article:

> The first issue is that Linux has always been a commodity white box OS built
> from interchangeable parts available from multiple sources, just like the
> PC. Systemd goes out of its way to break that, and in doing so represents an
> enormous loss of flexibility.

systemd goes out of its way to _fix_ the massive integration failures we've
had for decades (and seen as almost unfixable) because Linux is so focused on
modularity to a fault. And because of systemd, we're finally starting to get a
level of integration that previously only appeared in proprietary operating
systems. [http://islinuxaboutchoice.com/](http://islinuxaboutchoice.com/)

Linux is good at evolutionary changes, but not nearly as good at escaping
local maxima via large-scale cross-project changes. Not least of which because
anyone attempting to make such changes has to be prepared for the anti-change
"but the UNIX way!" flames.

Every time I see someone railing about the UNIX way, I think of how people
flame each other about / versus /usr, and how the original motivation for /usr
was "we ran out of space on /, put some of the less critical stuff on the user
disk". Appeal to tradition is not an argument unless you have a concrete
reason why the tradition is _better_ , and I rarely see such reasoning in
arguments leveled against systemd.

I've also found that well-articulated and well-founded arguments about
problems in systemd don't tend to last long, because systemd will _fix_ them.
I'd encourage people who see a legitimate _technical_ problem with systemd to
go discuss it on the systemd mailing list; you might be surprised how quickly
it gets fixed, if it has substance.

> Linux systems are modular, with multiple implementations of anything
> important.

Feel free to make something better than systemd, document it as extensively as
systemd, spend years writing guides to its most compelling features that get
people eager to switch, and do as much work as the systemd developers did to
help the entire Linux ecosystem adopt it with shockingly few _technical_
problems. There's nothing stopping you; you can even leverage the entire
systemd codebase in the process. Fork it and change what you don't like, if
you think you can keep up. Good luck; you'll need it.

> But systemd isn't like that. It's a single all or nothing blob

Refuted so many times that anyone still saying this is either intentionally
misleading or utterly uninformed about what they're railing against. systemd
runs incredibly little in PID 1; it has numerous separate single-purpose
processes (typically named /usr/bin/systemd-foo or /lib/systemd/systemd-foo),
as well as several libraries abstracting out key bits of common functionality
for other code to use.

> Ubuntu did upstart, but ubuntu also did unity, and mir, and pointed /bin/sh
> to dash, and their launchpad is based on the obsolete "bazaar" source
> control system... People not following Ubuntu's technical lead is pretty
> deeply justified at this point.

Now this one is actually a very well-made point, and it's something few people
have stated outright. There's a reason that few other distributions switched
to upstart; while it adds a few key features over sysvinit (such as service
supervision), it has some serious deficiencies as well. It's not at all clear
that switching from sysvinit to upstart would have been an improvement. And
the biggest key feature of upstart, service supervision, is actually something
_sysvinit already has but nobody uses_ : you can run a process directly from
inittab, and sysvinit will restart it when it exits. But rather than using
that, every Linux distribution just uses sysvinit to launch a shell script
that launches a hundred other shell scripts.

That said, I applaud Ubuntu for actually _trying_ to make major changes to
Linux. Unity isn't what everyone wants, but it's certainly an attempt at a
non-incremental improvement over other desktop environments, and it has some
nice properties. Similarly, Bazaar was an attempt to do better than CVS and
SVN, and it's not wildly awful; it just lost to an even better system for a
variety of reasons ([http://www.stationary-traveller.eu/pages/bzr-a-
retrospective...](http://www.stationary-traveller.eu/pages/bzr-a-
retrospective.html)). /bin/sh -> dash is, while not necessarily inherently
better, an attempt to enforce an absence of bashisms in #!/bin/sh scripts, and
an attempt to improve the performance of such scripts; in that, it has worked
reasonably well.

There's no excuse for Mir, though. :)

> Android also has a no GPL in userspace policy

Not exactly, though Android certainly pushes back on GPLed code. They're
willing to adopt it when there's no viable alternative. But systemd is LGPL
these days, not GPL. And even if systemd were GPL, it would still be quite
possible to use systemd as an init system to launch proprietary software.

Regardless of Android's allergy to copyleft, permissive-versus-copyleft is an
ancient holy war that long predates Android. The only reason the argument
comes up so strongly in this case is that systemd is the right combination of
rapidly developed and _too useful to ignore_ to make it a serious threat to
people who don't want to use it. If systemd were less useful, or otherwise
easier to clone, its copyleft license would be less of a concern to the
opponents of copyleft. _That 's a feature_, and it's exactly the kind of thing
the authors of the GPL and LGPL had in mind: the existence of high-quality
software under copyleft licenses that make life difficult for the proprietary
software world.

Personally, I was rather disappointed when systemd switched to the LGPL; I
would have rather seen it remain GPL.

> Those of us waiting to see how it shakes out feel we're having systemd
> shoved down our throats by a development team actively threatened by the
> idea of people _not_ using their stuff.

It couldn't possibly be that the software is sufficiently compelling that
those without religious objections to it are switching to it to take advantage
of its useful features. No, it must be a conspiracy.

> But even if it wanted to, android can't easily clone systemd, becuase it's
> (intentionally) a moving target with no standard and no documentation.

"no documentation" is insultingly misinformed; systemd is one of the best
documented software products I've ever seen.

And in any case, why should the systemd developers go out of their way to make
life easier for _people who don 't want to use systemd_, when they could
instead spend their time making life better for _people who want to use
systemd_?

> We can't opt out and see how it goes, we must fight to stay where we are.

Sure you can opt out: just sit there doing nothing, and the world will pass
you by. Or you can participate, and do as much work as the systemd developers
are doing, in favor of your preferred system. What you _can 't_ do is try to
stop other people from doing work you don't like without putting at least as
much work into a better alternative. Keep up or get out of the way, don't
shout "wait up" or "no fair".

~~~
asb
Systemd detractors seem to view the pre-systemd landscape through rose-tinted
glasses or at least completely ignore what has been going on with the desktop.
I hardly think ConsoleKit embodied the UNIX philosophy, and if the various
desktop environments end up replacing their own subtly different session
managers with systemd user session management that seems like a step forwards
to me, both for the Linux developer community and for the end user.

~~~
felixgallo
I can't speak for any other 'systemd detractor', but I can definitely confess
that I've completely ignored what's going on on the desktop. Because it's been
utter crap for the last 20 years and is clearly getting no better.

The fact that the desktop is now spawning lovecraftian horrors from the deep
in the service of 'booting to the desktop faster' and 'supporting hot-plug
devices better' and that those awkward, stupid requirements now threaten to
invade the standard installation on my servers, that definitely has my
attention now, though.

------
whoopdedo
I've been a stick-in-the-mud about changing to systemd until I bumped into an
ugly wart of sysvinit. While upgrading a service I moved the old daemon aside
in case I wanted to downgrade again, then remembered that I hadn't killed it.
So typed `/etc/init.d/myservice stop` and saw it did nothing. Huh? Oh, that's
right. The simplistic script won't do anything if the daemon file doesn't
exist. I had to manually kill the PID. So would I be correct in assuming that
systemd would know the service names of all running daemons and be able to
stop them without having to check to original file?

~~~
vezzy-fnord
Well yes, systemd is far more sophisticated than sysvinit. No one here is
advocating for sysvinit, as it _does_ need a proper successor. "sysvinit or
systemd" is a false dichotomy, however.

------
skylan_q
The theme of Monolithic vs. Modular reminds me of Linux vs. Minix.

 _The Tanenbaum–Torvalds debate was a debate between Andrew S. Tanenbaum and
Linus Torvalds, regarding Linux and kernel architecture in general. Tanenbaum
began the debate in 1992 on the Usenet discussion group comp.os.minix, arguing
that microkernels are superior to monolithic kernels and therefore Linux was,
even in 1992, obsolete. Other notable hackers such as David S. Miller and
Theodore Ts 'o joined the debate._

[http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_deba...](http://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate)

A link to the newsgroup discussion:
[https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16...](https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI\[1-25-false\])

~~~
jude-
More like a tightly-coupled (monolithic) vs loosely-coupled (non-monolithic)
debate. Systemd is modular, but its components are tightly-coupled. The key
difference between systemd vs the existing userspace, and Linux vs Minix, is
that there's ~50 years precedent of loosely-coupled being the winning design
paradigm in the long run. This is because a system made of loosely-coupled
components allows the user to add, remove, and swap out parts independently of
one another without having to drop the whole OS, thereby gaining the ability
to adapt the OS to a changing set of requirements with minimal cost. Tightly-
coupled systems do not have this advantage, and it makes them brittle in the
face of change.

------
Workaphobia
There was a lot of repetition about X, Y, and Z being anathema to the systemd
people. I would've appreciated some links backing up these claims of their
hostility. I've heard so much against systemd, and so little that wasn't
hearsay. (This is not a comment on the merits of the objections against
systemd, just on the exposure to the arguments I've gotten from casually
browsing hackernews.)

------
jqm
I have no problem with systemd but neither do I have a reason to use it
(although I admit, Poettering's general attitude does bother me a bit).

As long as Slackware doesn't incorporate systemd and alternatives remain I'm
fine. If alternative disappear, I guess I'll cross that bridge when it
happens.

------
erikb
Aren't the init wars just over? I saw photos from the still running German
Linux Tag were people are wearing T-shirts with "I survived the init war" (or
something like that) on it. I think we better leave it at that.

~~~
vezzy-fnord
The init war was never properly "fought" to begin with. It was presented as a
false trichotomy between systemd, Upstart and OpenRC, when there were other
options lying in plain sight that could have been researched, such as depinit:
[https://web.archive.org/web/20050206182736/http://www.nezumi...](https://web.archive.org/web/20050206182736/http://www.nezumi.plus.com/depinit/index.html)

systemd was simply far more visible and offered more than Upstart, which
wasn't all that well engineered, admittedly. OpenRC was largely skimmed over,
for some reason. systemd also had that aura of being "innovative," even though
most of its concepts are old and were done well by systems such as Solaris SMF
(although it isn't without flaws, either).

systemd came in at the right place, right time, was given a boost by a company
as renowned in the developer community as Red Hat, and as such was adopted as
a solution by people looking for a convenient fix, rather than actually trying
to tackle the issue from the core.

~~~
erikb
I agree that the two developers are really good community people and therefore
are able to win over votes that might not be as objective as they should have
been. But I think it's also a skill to tackle a community together and focus
them on one goal. This also improves FOSS as a whole, even if the software
might not be the best.

------
rossjudson
Seems like sour grapes from the author of another initialization subsystem
(mdev). His argument would seem to apply to _any_ effort to standardize
initialization on Linux.

~~~
akerl_
The point he's making is that having One True System is the death of one of
the biggest strengths of the Linux ecosystem: diversity. What he's ignoring is
that the various distros that are making this change have done so because they
think it's the best decision for their users.

No higher power decreed "systemd or death" and forced it on the distros.
They've adopted it on its merits, and most have retained the ability to run
other init systems if the user wishes.

This is a pinnacle of the Linux ecosystem, not a blemish on its record: the
larger community is working towards better interoperability between distros.

~~~
makomk
What the systemd supporters are ignoring is that if the existing init system
was as all-encompassing and heavily intertwined with the rest of the system as
systemd is, it would be impossible to replace it with systemd no matter how
much of an improvement it is.

~~~
sparkie
_This time_ we have the right design! It will never need replacing, honest.

~~~
sunfish
One of my favorite phrases from the Refactoring world is "speculative
generality". Adding customization points in the present can make adapting in
the future easier if the future aligns with your expectations, and harder if
it doesn't.

------
pjmlp
Interesting how the evolution of GNU/Linux distributions and their
interactions with other UNIX systems just look like the second coming of UNIX
wars.

------
blux
So, why not fork systemd and modularize it...?

~~~
jude-
I think OpenBSD is working on that this summer.

[http://www.openbsdfoundation.org/gsoc2014.html#systemd](http://www.openbsdfoundation.org/gsoc2014.html#systemd)

------
drdaeman
> So the systemd developers are saying a billion android devices aren't
> interesting [...]

Isn't being anti-GPL (and pro-vendor/anti-consumer) primarily Android's and
not systemd's issue?

Even considering that Android is a big thing, it's still _possibly_ unwise to
get rid of copyleft just to please Google and be accepted into phone vendors'
proprietary blobs.

------
lasermike026
I agree with this article. In addition, systemd, upstart, and launchd are just
not up to it. Time to go back to the drawing board.

~~~
duskwuff
The fact that you're mentioning launchd in the same breath as systemd and
upstart suggests that you don't actually know a lot about the situation.
launchd is a Mac OS X init equivalent. It has never, to the best of my
knowledge, been ported to Linux at all.

~~~
lasermike026
You didn't read the article. Launchd is being ported to BSD. If you knew
anything about about any of these inits you would see their similarities.

~~~
duskwuff
The article's not particularly accurate on that note. There is a project to
port launchd to FreeBSD, but it's basically stalled: no commits or mailing
list posts in over a month, and it's not clear that it's even been
successfully compiled on FreeBSD yet.

[https://github.com/rtyler/openlaunchd](https://github.com/rtyler/openlaunchd)

