If you have the time, please take a moment to read over the text, and
follow a few links. I am quoting the first few paragraphs as a summary:
We are Veteran Unix Admins and we are concerned about what is
happening to Debian GNU/Linux to the point of considering a
fork of the project.
Some of us are upstream developers, some professional
sysadmins: we are all concerned peers interacting with Debian
and derivatives on a daily basis.
We don't want to be forced to use systemd in substitution to
the traditional UNIX sysvinit init, because systemd betrays
the UNIX philosophy.
We contemplate adopting more recent alternatives to sysvinit,
but not those undermining the basic design principles of "do
one thing and do it well" with a complex collection of dozens
of tightly coupled binaries and opaque logs.
I understand discussion on this matter has been quite polarized in some
circles. As stated, it's not my intention to start an argument on
whether A is better than B, nor do I believe that to be the site's
purpose. Rather, I would like to divulge and hopefully incite some
productive discussion.
It started as a replacement init system. I suspected it had jumped
the shark when it sprouted an entirely new DHCP and NTP service. And this
was confirmed when I saw this:
"Leading up to this has been cursor rendering support, keyboard mapping
support, screen renderer, DRM back-end, input interface, and dozens of other
commits."
When your init system is worrying about cursor rendering, you have truly
fallen victim to severe feature bloat. I guess Jamie Zawinski was right:
"Every program attempts to expand until it can read mail."
I was actually not aware of this. I've been told that systemd also
includes fsck's functionality (or is planning to?). That just seems
absurd to me.
I didn't really have a strong opinion on either side of this yet. Seeing
the replies from other people here, though, and reading some more about
it, this seems to be a very bad idea.
The binary logs for example worry me, especially corruption issues:
Perhaps they could make a "desktop" version with systemd if the devs want
it that bad, but it'd be a shame if they ruined it for everyone that uses
Debian as a server as well. Haven't installed x on Debian since Etch... o.O
I've done a fair amount of hand-to-hand combat with systemd.
When it's good it's good, tho not always apparent why it's good. But
for example some of my servers boot in seconds.
When it's bad it can be painful and incredibly opaque and a huge time
sink.
Googling for suggestions I've found several threads where the
co-author (Poettering) jumps in usually to be annoyingly arrogant (I'm
sure he's very bright and good to children and pets and overworked)
responding with comments like why don't you just read your logs and
not bother this list or similar (that was paraphrased.) The logs are,
in my experience, almost always useless or nearly so, "mumble failed
to start" basically.
It also resists tools like strace because it tends to do things by
IPC. In one extreme case I just reworked an /etc/init.d script to
avoid systemd (not use the various /etc/rc.foo files), mostly just hit
it with a sledgehammer and put fixing that on my TODO
list. Unfortunately I am mortal and have limited time on this earth.
My experience as I said is mixed, hard cases are very hard where they
really seem like they shouldn't be (just tell me roughly what you're
trying to do rather than just fail, eg, via some debug enable), most
are just your usual oops it wants this or that situations.
I don't think I'd want to revert to sysvinit, systemd seems
architecturally superior.
But it needs a lot more transparency and some attempt to gather common
problems -- like why is it hanging asking for a password on the
console when I can't see why it thinks it needs one? -- and FAQ them
with real answers or add some code/configuration to fix that (never
ask for a password in this script OK? And no --no-ask-password isn't
fixing this so stop repeating that answer!)
Or the next user activity collection point. Systemd really is a
black hole to 99.9% of the people who will use/deploy it... seems
perfect for lots of things.
1. Move fsck functionality into systemd
2. Have it generate opaque binary logs
3. If your filesystem is corrupted in a way that systems can’t repair, you can’t even read the logs of what systemd saw or did?
Yeah, that sounds like a very definite “bad thing”.
One is reminded of a mail, included in the Preface to _The UNIX-HATERS
Handbook_, available at http://www.art.net/~hopkins/Don/unix-haters/preface.html. Apparently,
things really are going to get a lot worse before they get worse.
I have been working with developing systems that boot with Linux for a
number of years on a multitude of distributions and I never saw a problem
with the tools or the process. Purely the lack of standards.
It seems stubborn at the least to propose an opaque software solution when
a simple standards organization for how to structure the init system is all
that is required.
Why not write high level code to manage standardized scripts rather than
replace them with binary darkness. The only reason we have desktop Linux is
due to the flexibility of the Unix architecture, seems silly to abandon
that now.
The pure fact of it is that developers hate messing with text because its
unpredictable and prone to bugs. However with standards and possibly a
decent meta format (I look towards YML, XML, JSON) that can be consumed and
produced with scripts there should be no issues.
The final fact is that bash itself is a dirty language that developers hate
and system administrators love. Its a gross blend of programming
functionality mixed with command line awareness and its unpredictable,
especially at the code generation level. Its also too sensitive to text
formatting and line endings.
In conclusion, we will continue to deploy our scripts to a number of Linux
distributions and have came to the conclusion that it is simply cheaper to
have a human deal with the actual deployment of the system rather than
write host of deployment code to cover every system. End users know how to
use their system and we rely on that. Finally, why not focus on creating
and maintaining collaborative unbiased standards rather than parading egos
and hurting communities.
it's really not clear to me that 'reboots in seconds' is a thing to optimize...
I suppose the win is:
"Is the startup/shutdown process clear, conscise and understandable
at 3am local time?"
followed by:
"Can I adjust my startup processes to meet my needs easily and
without finding a phd in unix?"
If systemd is simply a change in how I think about /etc/init.d/* and
/etc/rc?.d/* cool, if it's more complexity and less EASY flexibility
then it's a fail.