Re: Init system deba{te|cle}
On 11/03/2013 10:41 AM, Reco wrote:
On Sun, 3 Nov 2013 14:21:40 +0000
Jonathan Dowland <jmtd@debian.org> wrote:
On Sun, Nov 03, 2013 at 02:06:06AM +0400, Reco wrote:
Linux is way ahead of AIX, FreeBSD and HP-UX in this regard even if
using good ol' sysvinit. So, Lennart fixed what wasn't broken in the
first place.
If that were so, why are people adopting it?
I don't know why people adopting it. I only have an option about why
distributions adapting systemd. IMO:
Well, there are some nice features in systemd. It's easier to work with
unit files over shell scripts. It's nice to write out how you want the
system to manage services in a declarative style over an imperative one.
Also, teh dependency/concurrency-based startup makes a properly set up
systemd boot up a Linux system very fast.
What's maybe not so nice is the journal. It's great to be able to search
it, but I rather like not having my logs stored in a binary format for a
feature that, while nice, might not see much use on my system. :/ I'd
still rather be able to just open logs in a text editor and parse
through myself. Fortunately systemd has no qualms about passing system
events to stuff like syslog (And adds a few useful things to the logs to
boot.)
Fedora - because RedHat needs something enterprisey for their RHEL, and
apparently upstart in RHEL6 doesn't cut it (being pet Canonical project
and all that).
Upstart has the right idea but the wrong implementation. You'd be hard
set to see anyone care to use it outside of Ubuntuland and it's not just
purely for the fact it's got ties to Canonical. I think the most
classical example used is its dependency approach. Rather than bring up
a service if another service calls for it, it brings up a service, then
brings up EVERY LAST SERVICE IMAGINABLE THAT USES IT. Imagine what it's
like to launch your network service and see sshd, httpd, telnetd, and a
Minecraft server all launch because their configuration states they use
the network service (Unless you disabled it.). That's how Upstart
approaches dependency launching. Systemd is about trying to keep the
number of services minimal to save memory and CPU for the user(s), not
to mention minimizing boot times. Systemd works much the same way as
launchd on OS X (That's what OS X's init is called, isn't it?).
OpenSUSE - because Novell (assuming, of course, there's anybody left to
make decisions after their sellover) needs something enterprisey for
SLES, and their homegrown sysvinit doesn't cut it for some reason.
I can't comment on their init. I used SLED for a time and found it
unnecessarily cumbersome.
ArchLinux - because they like to ship upstream projects unmodified and
like to change things frequently. They ship GNOME - GNOME says 'use
systemd' - they ship systemd.
Nah. That's not why they did it. They actually went over the reasons on
their forums and GNOME didn't really come up all that much. Primarily it
was because sysvinit is not really all that nice. Its entire
functionality relied on well-written shell scripts, and lots of them.
Even the upstream maintainer, from what I understand, is not crazy about
sysvinit anymore. Thing is, sysvinit, while it works and it is simple
and tried and true, is a real dinosaur and, like X11, was designed for a
different day with different needs. Being able to use an init system
that's a lot more "smart" is a real plus. One goal that I definitely can
appreciate is that systemd is meant to allow upstream developers of
services to create units for it so that distribution maintainers don't
have to do much extra work packaging them or someone building a service
from source won't have to write scripts for it.
This is not to say systemd doesn't have its issues. Unless you have a
distribution that fully supports it, it's not going to be fun to use as
you'll end up spending most your post-install time writing your own
units for it as the distro might not have any (Or much.). Systemd is
also large and complex. And some people also view the fact that Lennart
Poettering is the guy behind it as a real negative (Not fans of
Pulseaudio and Avahi, usually.). As I mentioned before, the journal is
not readable outside of its tools which I don't like (The admin in me
would rather things like configuration and logs be in plain text, which
is one reason why I hate Windows.) Lots and lots of people were less
than thrilled also with the udev merge (Gentoo developers seemed
downright angry about it and are, last I checked (Though a while ago.)
they were making their own udev fork.).
Maybe one major downside is systemd uses very Linux kernel-specific
features, which is what this thread was about, I think. systemd isn't
really portable which to a lot of Linux fans is almost sacrilege. I
personally don't have a problem with it since there are so few projects
I know of that actually make specific use of Linux-exclusive
functionality. Maybe they do so indirectly through libc, I don't know.
But this does mean most anythign that wants to use systemd to its
fullest might end up being Linux-exclusive when kept vanilla.
Did I miss some more-or-less important distribution that already moved
to systemd?
PS Not that I have anything against systemd. By the time I'll get my
hands on it (be it next Debian stable, or RHEL7) they'll sure stabilize
it somehow, write distribution-specific documentation and all that.
I dunno if Debian will ever adopt it as its official init. At least as
long as there's the Hurd and kfreebsd projects. Though that's another
debate (I think Debian's resources are wasted on those two projects:
Hurd will never amount to anything worthwhile (It took them well over a
decade just to get SATA and USB support.) and BSD is slowly, painfully,
dying (I personally think the only thing sustaining it is Apple. I know
I'll catch flak for this opinion, but I can't look at usage statistics
for BSD and really think it's doing anything but losing users and
developers.). In my opinion neither are really worthy of much attention.)
All that aside... if Debian adopts systemd as its official init they'd
pretty much have to abandon those two ports, and I don't see much
willingness there.
Reco
Conrad
Reply to: