Re: Init system deba{te|cle}
On Mon, 04 Nov 2013 10:37:51 -0600
Conrad Nelson <yaro@marupa.net> wrote:
> 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.
Good ol' chkconfig - that's easy. And its' replacement in systemd is
called?
Startup speed is irrelevant for me. I don't reboot servers that often
(and when I do, 90% of the time it is the hardware initialize itself),
and on desktops I use hibernate.
> 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.)
And what about removing this journal thing? I mean, if it inferior to
rsyslog, why bother keeping it (or installing it in the first place)?
> > 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.
Um. RHEL6, OEL6, CentOS6, Scientific Linux 6.
> 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.
That's simply terrible.
> 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?).
So, they're reverting to good ol' inetd days. Hardly an innovation, but
may be useful to someone.
> > 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.
Basically these guys came with the idea of parallel dependency-based
boot (Debian started to use the same approach couple of years later),
and managed not to break sysvinit THAT much by implementing that idea.
> > 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.
I still fail to understand why sysvinit shell-scripts are bad, yet,
when used by systemd they suddenly became good.
> 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.
And working drop-in replacement for X is …? And unless it cannot run
that Motif app written 15 years ago it doesn't count. And if it has
problems with Java's Swing it doesn't count too.
> 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.
Wait. Upstream developer writes a daemon, yet somehow it never occurs
to him (or her, irrelevant) that such daemon needs to be actually
started. The very existence of systemd somehow tells this guy 'hey,
you'll need to write systemd unit'. Does not compute.
Either developer writes something that allows daemon to be started (be
it script, upstart job or systemd unit), or not.
> 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.).
I disagree. Poettering wrote at least one working thing, ifplugd.
All the problems with avahi usually boil down to inability to read
and understand RFC 6762.
Now, the fact that Poettering doesn't like to support stuff he wrote -
now that's really disturbing.
> 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.).
Neat. Let me guess: and the tool to read this journal comes with
systemd, there's no backward compatibility with older journal versions,
and you cannot read this journal unless you manage to start couple of
obscure services via dbus.
> 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.
Hardly. Un-portability is a byproduct of vendor lock-in. RedHat one in
this case.
> 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.
Simple. Use Linux-only syscalls. Depend on a specific files in /proc
and /sys which only Linux provides. There're many ways to write
non-portable software.
> But this does mean most anythign that wants to use systemd to its
> fullest might end up being Linux-exclusive when kept vanilla.
There's other scenario. Either you use RHEL, or some systemd feature
misbehave.
> 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.
Building software on a different processor architecture or with
different kernel helps to find bugs in such software. Helps with quick
support of new architectures too. The fact Debian provides non-Linux
kernels is a strength, not a weakness.
> 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.)
It's the userland that is killing BSDs, not a kernel.
Reco
Reply to: