
Busybox removes support for systemd - sethvargo
http://git.busybox.net/busybox/commit/?id=accd9eeb719916da974584b33b1aeced5f3bb346
======
vezzy-fnord
The technical aspect here is completely insignificant. All they did was remove
a basic listener function that was already optional, used to communicate with
systemd's socket activator without linking to libsystemd itself. And it seems
only one Busybox daemon ever made use of it.

The political significance is quite high, and I have to say I feel that this
move, though perhaps a bit childish, is a valid signal to express grievances
with the absolutist attitudes of the systemd developers. Plus let's be honest
here, they aren't the pinnacles of mature behavior either. I think this is the
first time a major project has done a statement like this against systemd. I
would expect more to follow their example.

I of course summarized my issues in "Structural and semantic deficiencies in
the systemd architecture for real-world service management" [1] and hope to
see systemd go the way of devfsd and HAL.

[1]
[http://blog.darknedgy.net/technology/2015/10/11/0/](http://blog.darknedgy.net/technology/2015/10/11/0/)

~~~
JdeBP
> _The technical aspect here is completely insignificant._

I disagree. My initial reaction was to lament the fact that BusyBox syslogd
has lost the ability to be passed its socket as an open file descriptor. One
may debate whether systemd's mechanism or UCSPI-UNIX (extended to datagram
sockets) is the better way to pass such descriptors along. But it now has _no_
mechanism. BusyBox syslogd is now less than it was.

~~~
skarnet
Honestly, the people who use Busybox are probably aware of the problems -
political as well as technical - with systemd, and most likely not using
systemd in the first place because it's not exactly a good choice for embedded
systems.

Also, for busybox syslogd, it does not matter at all whether you can hold its
socket. syslog isn't a reliable mechanism anyway, and busybox is light enough
that the non-ready period is really short.

So, on the technical side, the impact is quite minimal. On the political side,
however, it looks like Denys made a splash, and I'm not going to complain
about it. :)

~~~
davidstrauss
> it's not exactly a good choice for embedded systems.

I don't develop embedded systems, but systemd is actually popular in that
space because of its watchdog capabilities and its inclusion in projects like
GenIVI and Tizen.

More detail is in this post from an embedded systems developer here:
[http://www.phoronix.com/forums/forum/phoronix/latest-
phoroni...](http://www.phoronix.com/forums/forum/phoronix/latest-phoronix-
articles/832368-busybox-drops-systemd-support?p=832615#post832615)

~~~
skarnet
I see nothing there that can't be achieved by a simple supervision suite. s6,
nosh, even runit provide those features; the extra complexity of systemd isn't
needed at all. If even embedded developers are getting pulled in by the sirens
of systemd because OH MY GOSH IT HAS WATCHDOG CAPABILITIES, then we definitely
need to work more on raising awareness about supervision.

------
woofiefa
I really like systemd because all the controversy made me look towards
FreeBSD, and this has really been a great experience. No offense, but I can't
stop thinking about the Linux community as a screaming child with short
attention span. The BSD community seems more like an old grey beard, sitting
calmly in the corner solving problems in the best way possible. This may take
some time but the result is often superior.

~~~
bsder
As a FreeBSD guy, I'd like to claim smug, grey beard superiority, but there
are more than enough counterexamples to poke holes in that attitude.

GEOM, cvsup, how many versions of port managers?, perl and gcc
extraction/clang migration in base system, and the big ones NetBSD and OpenBSD
--all represented wrenching progress--*BSD has its own set of people throwing
temper tantrums at various points, as well.

------
erpellan
PID 1 should be boring. Tiny, simple and boring. Any software project that
raises this much controversy should be looked at with a raised eyebrow.

A software project this large, complex, controversial and coupled that wants
to be PID 1? Absolutely no way.

~~~
bossrat
you are exactly on point.

the unix way is simplicity and transparency. systemd is complex and opaque.

it's ok to have systemd's goals, but an additional goal should be "not a huge
monolith"

~~~
otterley
What is the criteria by which you classify something as "opaque"? The
documentation for systemd and its utilities is second to none.

~~~
vezzy-fnord
_The documentation for systemd and its utilities is second to none._

God help the software industry if that is indeed the case (of course, it is
not).

~~~
witty_username
How so? I was able to easily use systemd and the man pages seem decent. Maybe
not the best documentation, but it seems reasonable.

~~~
simoncion
In order to see the quality difference, you have to compare the docs to
_another_ project that you make extensive use of.

I know that Postgresql's and Erlang's documentation is really rather good. So,
go use Postgresql or Erlang for a slightly non-trivial project, then -now that
you know about the topic that the docs cover- compare the quality of the
systemd documentation to the documentation of either other project.

Pay _special_ attention to the documentation provided to folks who want to
understand the _internals_ of systemd, Postgres, or Erlang. AIUI, [0]
systemd's internals documentation is _woefully_ lacking.

[0] And as has been repeated by everyone I've ever seen try to use said
documentation.

~~~
witty_username
True, systemd's documentation isn't very bad though, it's reasonable (lack of
internal documentation is pretty common in many open source projects).

~~~
simoncion
Remember that this thread was sparked by otterly's comment: [0]

> The documentation for systemd and its utilities is second to none.

What little I've seen of systemd's _user_ / _sysadmin_ documentation leads me
to believe that it _is_ okay. I _also_ understand that documentation is often
the least interesting part of _any_ project, and _often_ sorely neglected.

However. _Everyone_ I've heard of that tests out the Systemd Cabal's claim
that

"Systemd is _not_ monolithic! Systemd is fully documented and modular, so
_any_ sufficiently skilled programmer can replace any and all parts of it with
their own implementation."

by attempting to make a compatible reimplementation has failed at their task
[1] and reported that the internals documentation is woefully insufficient.

When you're writing software for general consumption, good user documentation
is a _requirement_. After all, if noone can figure out how to use your system,
"noone" will use it.

When you _also_ claim that you go out of your way to provide enough
documentation to allow others to understand the relevant parts of your
internals, _and_ be able to write compatible, independent implementations of
your software, the quality of the documentation about your internals is now in
scope for evaluation and criticism.

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

[1] I am _very_ aware that this task is made harder by the fact that it is
large and thankless. :)

------
throw23000
I have to make this comment with a throwaway as its related to my previous
job. Leaving aside the technical issues the launch of systemd 'looks' very
much like a playbook PR campaign designed to push through something unpopular.

The discrediting debates, labeling near abuse and mockery of opponents,
appeals to authority and exaggerated consensus do not look accidental. This
has all the markings of a sophisticated campaign.

For many this can be off putting but its also a wake up call on some naive
ideas about how the world works. Money drives decisions, the cathedral and
bazaar as a metaphor has no meaning when the bazaar has spawned a billon
dollar cathedral in its midst, and like the failure of communism in practice
this too could be anticipated. Money has its own agenda and always corrupts
everything. And we all know this because its part of our historical record and
common sense. And there is nothing we can do about that because in the real
work words are meaningless. Individuals have zero power, groups have some
power but its groups with money that hold the cards.

The Debian management tells users,not out of exasperation, or frustration but
of arrogance that they essentially don't matter, and the only way they can
have a voice is with code. This disrespect for users lies in contrast to a
project that has none and thus the self awareness to realise it is meaningless
without them. This new found arrogance sits uneasily with the ideals of the
open source movement but anyone who draws the dots will realise its not an
open source movement but a full fledged corporate movement with the thinnest
veneer of ideology that is not up for 'management'.

For the next generation you cannot protect ideals if you enable and allow
cathedrals to grow in your midst. For the current things do not automatically
fix themselves, the awareness of the power of money to influence outcomes and
how to firewall them, how to ensure co-existence, sustenance and growth, how
to reward projects and developers and how to ensure you are not getting
hijacked and sidelines by interested parties should be the 'community', and
there is no such current organization in the ecosystem that's not tainted by
corporatism and opportunism.

~~~
ymse
How is this related to anything, let alone your job?

As I'm sure you know, systemd grew out of Red Hat, and Debian as most other
Linux distributions have adopted it in lack of a better alternative. There is
no grand scheme to it other than getting rid of SysV.

In a few years time uselessd, nosh, dmd and the many other systemd-lookalikes
in development have matured and there will once again be diversity in init
land.

~~~
JdeBP
The self-styled "uselessd guy" is present on this page, and xe has gone on
record some months ago that uselessd is a "dead project". Replace uselessd in
your list there with s6-rc and System XVI, therefore.

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

* [https://github.com/ServiceManager/ServiceManager/](https://github.com/ServiceManager/ServiceManager/)

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

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

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

And replace "systemd-lookalikes" with service and system management systems,
while you are at it. Neither of those is aimed at looking like systemd, and it
would do them a disservice to miscategorize them as such.

nosh 1.22 is about to be announced.

------
tym0
> systemd people are not willing to play nice with the rest of the world.

Can we get a bit a of context on that?

~~~
semi-extrinsic
After they repurposed the "debug" kernel flag and made it literally unusable
with systemd, Linus banned one of their core devs (Kay Sievers) from
contributing to the Linux kernel, and I quote:

"I'm not willing to merge something where the maintainer is known to not care
about bugs and regressions and then forces people in other projects to fix
their project."

[https://lkml.org/lkml/2014/4/2/420](https://lkml.org/lkml/2014/4/2/420)

~~~
magila
It's worth noting that this is a case of Linus flying off the handle based on
incomplete information. It was latter revealed that the bug which caused this
whole spat on LKML had already been fixed in systemd, Kay Sievers just failed
to communicate that in the bug opened by Borislav Petkov.

~~~
felixgallo
that is not at all what happened. Here's Kay Sievers, defiantly posting after
in his own words after the incident:
[https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB](https://plus.google.com/+KaySievers/posts/3cWXzYqB6MB)

~~~
magila
There were two different issues at play:

1\. A system hang due an assertion in journald spamming kmsg.

2\. The question of whether systemd should be logging to kmsg or doing
anything based on the "debug" kernel command line argument.

Linus got pissed because, based on Steven Rostedt's post to LKML and the
referenced bug report, it looked like Kay was refusing to fix issue #1, but
that bug had already been addressed and a fix committed to systemd. In the
aftermath there was also a flamewar over issue #2, which is what Lennart is
responding to in that G+ post.

~~~
digi_owl
Note that going by the Torvalds email, this is far from the first time him and
Sievers has been at odds.

------
jkot
It sort of makes sense. Systemd has many utilities which can replace stuff
from Busybox. And Busybox contains its own init system.

~~~
raverbashing
Correct

Also, most of systems using busybox shouldn't be running Systemd (or any other
'new' init system to be honest)

~~~
bbanyc
What about initrd? Most of those use busybox and it's now "recommended" to
start systemd there. (Granted, I don't see why anyone would run busybox's
syslog - the only component affected by this change - in an initrd.)

~~~
thwarted
If you want an extremely small system, you can put everything you need into
the initrd. It's not _strictly_ an initrd then, since it's not really used for
bootstrapping a larger system image.

~~~
rawdisk
This is the only way I use Linux.

I will use the Linux kernel (although it is not my favorite kernel).

But I am interested very little in GNU userlands and all the idiosyncracies,
complexity and politics that comes with them.

------
Sevrene
There's a lot of hate for systemd and there's also a lot of people ignoring
valid criticisms and going so far as labeling those making the criticisms as
haters. This does not bode well for reasonable discussion. It has become very
political.

Whether systemd is a good thing or a bad thing depends ultimately on what
you're trying to do and what sort of operating system you're using. For some
people systemd is really helpful, for others it gets in the way and creates
unnecessary complexity where it otherwise wouldn't exist.

I've been using systemd along with fleet on coreos, and it's fantastic for me
but I personally wouldn't want systemd on my desktop. The problem is that it
has been forced onto people left right and centre when it doesn't suit their
needs. That essential reasonable debate never occurred and those that are
forced to either swap distro or 'convert' to systemd get upset. If there was a
reasonable debate people would still hate on systemd, but at least the reasons
for using it would be more known and the criticisms atleast acknowledged.

~~~
digi_owl
> There's a lot of hate for systemd and there's also a lot of people ignoring
> valid criticisms and going so far as labeling those making the criticisms as
> haters. This does not bode well for reasonable discussion. It has become
> very political.

I can't shake the suspicion that ever since gamergate, or perhaps even "for
the lulz" anonymous, there have been people going around the net, latching
onto anything vaguely controversial, and trying their best to stir up trouble
by making threats and statements that are barely relevant to the topic.

~~~
Sevrene
I think there has pretty much always been trolls on the internet. Back in the
90s it felt like no one took the happenings on the internet all that
seriously, it was a bit of a lark. Now that it's much more mainstream, it's
embedded in our everyday lives and companies make a lot of money from it. So
it would make sense that everyone takes it a lot more seriously and it's
easier to troll people if they take you seriously.

Although not all haters are trolls of course, but it's really
hard(impossible?) to tell over the internet (Poe's law), especially when you
have haters, fanatics and trolls all playing each other and the only person
who wins is the troll in that scenario.

------
sandGorgon
has anyone used Fedora 23 with Gnome, Wayland and Systemd ? I see a lot of
religious handwaving around systemd, but F23 shows you the future of Linux
desktop.. and it is brilliant.

Right from network interfaces that dont change names when you swap hardware
(powered by systemd) to making it damn easy to file crash bugs (using
coredumpctl) to checking what services have failed "systemctl --failed" to a
more secure graphical desktop (rootless gnome with systemd) - it makes for a
better linux.

Deploying web-services on systemd is so much better - think supervisord, but
much more stable and robust. Even docker machines using systemd is great (in
fact it is a great way to explore systemd).

~~~
Sanddancer
I think the key word there is desktop. The systemd folks are desktop folks
first and foremost, server operations be damned. coredumpctl requires root
access, which means one has to be much more diligent in scripting automatic
actions to handle core dumps. Failed services again are something that any
supervisor service can handle and report -- launchd can get all that
information from launchctl. Rootless X is something OpenBSD has had for years,
through better access control than linux devs seem to be able to be bothered
with.

The biggest problem with systemd is its mediocrity. The journal is an
interesting idea, but it's inflexible. Its insistence on json and internal
formats mean that it doesn't work with the rest of the extant logging
infrastructure tools that exist, so if you want to have a dedicated log
server, you have to run essentially two syslogds. Its core dump misfeatures
make it harder to use extant access control features to manage files. Its unit
files don't allow for any sort of extensibility, so adding things like a
configtest command for a unit are impossible. In short, its oversimplified
itself to the point where it adds a huge management load just to keep servers
where they were.

~~~
digi_owl
> server operations be damned.

I think it depends somewhat on how one define server.

The traditional hardware on shelf doing their designated task (i have seen it
be referred to as "pet" servers) not so much, no.

But they do seem to heavily support container and virtual machine based
servers ("cattle", to go with the pet reference earlier).

------
AdmiralACK
Good. Systemd can die. Debian should never have started using them, too.

~~~
cosarara97
There is plenty of people happy with debian's adoption of systemd, myself
included.

~~~
AdmiralACK
I'm going to step out on a ledge here, but those that are happy with it really
don't understand linux or much of how it works beyond editing a few confs.
None of which ever touch systemd

~~~
XorNot
What understanding do you think they would need to have to find your
unhappiness?

Because while I'm sure in a competition of esoteric kernel knowledge I would
lose to a great many people, I also simply _don 't care_. systemd makes
establishing my service start up dependencies amazingly simple. It makes
daemon deployment simple. It simplifies a whole host of problems which are not
cleanly solvable by other means. It handles process restarts, limits and a
whole host of other things for me.

No one is bringing a superior solution to the table. Everyone is telling me
daemon-tools and init scripts are "fine" (they're not).

------
pepijndevos
Wait, people are using Systemd on embedded Linux? You go out of your way to
replace the Linux userland with a single small binary, and possibly go through
the trouble of using a small libc implementation, and then you install this
mammoth called systemd.

~~~
Matthias247
Embedded is not embedded:

Theres the really deeply embedded systems running on tiny processors which
probably only run a single binary and are never updated.

And then there are big systems (think cellphones, automotive infotainment,
etc.) running on quad core procoessors where you have dozens of processes,
which might even be independently installed or updated. For those kind of
systems you really want a sophisticated init system, and the cost of systemd
is probably minimal compared to the instances of chromium/webkit/blink that
you might already have on your system.

------
Stratoscope
Interesting to see that the commit linked here has been yanked from the repo.

For the curious, here is the original commit comment:

> remove systemd support

> systemd people are not willing to play nice with the rest of the world.

> Therefore there is no reason for the rest of the world to cooperate with
> them.

> Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>

[http://webcache.googleusercontent.com/search?q=cache%3Ahttp%...](http://webcache.googleusercontent.com/search?q=cache%3Ahttp%3A%2F%2Fgit.busybox.net%2Fbusybox%2Fcommit%2F%3Fid%3Daccd9eeb719916da974584b33b1aeced5f3bb346&oq=cache%3Ahttp%3A%2F%2Fgit.busybox.net%2Fbusybox%2Fcommit%2F%3Fid%3Daccd9eeb719916da974584b33b1aeced5f3bb346)

~~~
ymse
Hm? It's still there.

[http://git.busybox.net/busybox/log/?ofs=49](http://git.busybox.net/busybox/log/?ofs=49)

~~~
Stratoscope
Ah, very good. The page the submission links to did have some kind of error at
the time I posted my comment - instead of the commit message and diffs it had
a vaguely-404ish error message in red. But it sounds like it was probably just
a temporary error - perhaps the HN effect!

------
sandGorgon
Interestingly, Busybox developers seem to have a lot of hate for sysv init.
[http://busybox.net/~vda/init_vs_runsv.html](http://busybox.net/~vda/init_vs_runsv.html)
"SysV init must die."

------
teddyh
This comment thread seems to be the 2-minutes-hate for systemd, with mostly
predictable results. But the _actual_ news seems to be that Busybox removed
the use of the systemd notify system which lets systemd know that the service
has indeed started and it’s OK to start other processes which depend on it.
This is no great thing – the _normal_ and _traditional_ Unix way of daemons is
for a program to fork, where the fork continues to be the actual daemon, and
the original process exits. Systemd can detect this exiting of the started
process, and will take _that_ as the signal that the daemon is ready, so there
is no need for the notifying function in this case.

~~~
JdeBP
That is wrong in three ways.

* That's not what the removed code was doing at all.

* That's a 1980s idea of "normal". Forking is something that has been gradually disappearing as standard practice for daemons for the past 16 years, as can be seen from the large number of daemons that _now_ have "don't fork" modes, as compared to the number in the middle 1990s. The idea that daemons fork as some sort of standard practice was the mainstream thinking then, but it is not now.

* Most programs in the wild do not correctly speak the forking readiness protocol, in part because those programs are not forking as a readiness protocol in the first place. Many people, in particular those involved in the Debian Technical Committee hoo-hah a while back, considered the _opposite_ of what you claim to be actually true. There is no need for the flawed, bodged, and in practice broken forking readiness protocol when one has a proper readiness notification protocol. [http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/un...](http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/unix-daemon-readiness-protocol-problems.html#NooneSpeaksForking)

~~~
teddyh
> * _That 's not what the removed code was doing at all._

All right, what _was_ the removed code doing?

> * _That 's a 1980s idea of "normal"._

That’s why I called it “ _normal and traditional_ ”.

> * _Most programs in the wild do not correctly speak the forking readiness
> protocol_

True enough. But for practical purposes, it’s _mostly_ good enough. And I’d
think that it doesn’t matter that much for people running BusyBox with
sysvinit.

------
fidget
Seems a bit childish

------
hachre
Why?

~~~
whoopdedo
Politics.

"But politics shouldn't be a factor in software design. We should cooperate to
work with the technologically most useful solution and not let personal or
ideological differences get in the way."

Bless your heart.

~~~
SFjulie1
That's one of the critics of open source (BSD) world versus free software
world.

 __GNU __/ Linux projects have been designed for figthing on socio-ethico-
political grounds against proprietary software. The first one being Unix.
(GNU's Not Unix)

On the other hand, BSD prefers to see itself like a community of pragmatism,
and creating values in business by sharing externalities (plus a bunch of
fanatics that loves nice code like others ferarris).

The constant criticism of BSD vs linux is building tools for ideological
reasons rarely favours the best solutions because you give yourself an
obligation to beat the time to market of "proprietary companies" and to add
support for stuff that do not worth being shared.(Word/WYSIWIG editors are a
terrible idea in the first place, why spend resources to give them more
traction by helping to broaden the user base?)

It favours kludges and hacks instead of a consistent simple design. It burns
benevolent time, and attention.

And BSD have been denouncing GNU/linux projects (Gcc, gnome, systemd, binary
blobs in linux kernels) like long term disasters by locking people in
technical debts of poor designs.

Actually, I am a linux guy with BSD boxes and hadn't I problem with hardware
support I would be fully on BSD.

I would say they have a point. And just for the record, GNU fundation is not
Linus Torvald's best friends.

The first time I heard Moglen's talk he was litterally saying that linux was a
bad example of a free software project.

Yes, freedom of choice is political. But it is not a question of organisation,
but individuality.

Still some communities aims to gather more zealots than master in their
domains. That is the distinction between Free Software and Open Source.

~~~
vezzy-fnord
My interpretation is a tad more charitable.

The reason the Linux community is so dysfunctional is because, for most people
born during a certain time period, it's the first ever OS they use that isn't
Windows, and the first ever Unix. Naturally this creates a lot of sudden
revelations, and a lot of blowhards who think they're hot because they can
rice their Arch Linux box. In the process a lot of false sense of technical
prowess is generated.

Moreover, the network effects become so strong that at some point (which has
already been crossed) Linux becomes _the_ alternative OS, and from then on
people feel like they can just ignore everyone else with impunity. They start
to perceive themselves as the leaders, and everyone else must be biting their
dust. Notice how Linux users often tend to be ignorant (and not only that, but
_resentful_ ) of what BSD, Solaris, MINIX, Hurd and other folks are doing. Not
the case with users of those other OSes, who as underdogs have more of a
reason to cooperate and usually also have to study what the other is doing,
especially so that Linux the big dog doesn't poorly reinvent some interface
that ends up mutating across FOSS and leaving their access to portable
software in the dust.

If through some historical accident 386BSD ended up making it unfettered from
the trademark lawsuit fallout, it likely would have followed the same course.
So would have the Hurd.

~~~
SFjulie1
The AT&T lawsuits for the Unix (c) infringement has been largely used as a FUD
from both MS and GNU against open source.

It was fixed fast, but the PR standed long. (calomniez, calomniez, il en
restera toujours quelque chose)

The BSD community having been beaten early by the IP problems have been more
cautious since this time whereas the linux (as an OS) community becoming an
official UNIX (c)(tm) in 1997 as they became POSIX compliant and have been
artificially protected from IP problems has been careless in disentangling
itself from all the proprietary shit that IBM and other big company that
wanted to kill the cost of maintaining their own OS have been putting in the
OS. (the legal construct for protecting linux from patent/IP problems involves
a lot of big companies and complex clauses).

POSIX may have follow IP protocol in the direction of bloatware
specifications.

Linux without this compliance and the support of the big companies seeing it
as a way to reduce their costs (RH/IBM/maya/Oracle) would not have been able
to substitute itself to other proprietary UNIX in the realm of "professional
IT". Especially because big vendors made a pax romana around linux concerning
the claims of patents when contributing to the OS.

But by mimicking and being driven by normalization/fundations where the main
stake holders are proprietary vendors (HW/SW...) linux has became something of
a proprietary software itself.

(Just look at who are the main ISO/IETF/IEEE/POSIX contributors nowadays, and
the member of OSI/linuxfundation.)

Those who controls the API controls the OS.

------
mback00
Does anyone here know the real reason for this move (beyond speculation)?

------
mback00
Does anyone in this forum know the reason behind the change (beyond
speculation)?

------
slapresta
This is going beyond ridiculous.

