Re: /bin/sh (was Re: jessie release goals)
On 05/12/2013 07:40 PM, Helmut Grohne wrote:
With all due respect, this might be utter bullshit, but is at least
[citation needed]. I have yet to see a failing pid 1 (be that sysv,
upstart or systemd). Acquiring data on failure modes of any of those
systems appears like a difficult task and d-devel might not be the best
place to discuss that.
It's not PID 1 itself that is failing, but the daemons and scripts run
by the init daemon. The init daemon therefore needs to be more
intelligent and provide mechanisms to deal with crashed daemons.
Yes, System V Init has been working for the last three decades. However,
we weren't running the very same kernel and plumber land on everything
from a smart phone up to a large compute cluster.
systemd provides many useful features that help making systems on any
scale more reliable and easier to maintain.
Of course, you don't care if daemon XYZ crashes on your desktop and
you're notified immediately, you just reboot in the worst case. However,
you *do* care if that happens to the NFS daemon on your home directory
server or your httpd on your web server.
You also want to make sure that a single user won't be able to bring
down a large login server (systemd's support for cgroups can do that)
and you also want remote filesystems always to be mounted reliably when
you reboot your system and not being a game of Russian roulette. I have
observed both things happen several times on the network of my old
university.
I also think it's important to have a proper system of resolving
dependencies between daemons in a clean and well-defined, intrinsic way
and not through hacky bash scripts where scripts like insserv already
fail when my last FAI update created a .prefai_copy file of a script in
/etc/init.d.
Socket-based activation is, in my humble opinion, the only proper way to
have a proper means of determining dependencies and starting dependency
chains of daemons in a reliable, reproducible and atomic way, e.g.
either the whole chain runs or not. I don't think you can implement it
with the same reliability and elegance using System V Init scripts.
Both Solaris, MacOS X and iOS have dropped the classical System V Init
in favor of socket-based activation long time ago and I haven't heard
anyone complaining that users got deprived of their choices. The design
has proven itself and powers over 100 million iDevices.
The problem is not that people disagree on that a good init system is
needed, but about what good comprises. Some people believe that a good
init system should run on all supported architectures including
kfreebsd-*.
Ok, so could you please go ahead and make sure I can use things like
launchd, ZFS and jails without any limitations on Linux?
Honestly, you simply can't expect every single package in Debian to run
on any of the supported kernels. If systemd profits from the use of
Linux-specific kernel features, which is a good thing in my humble
opinion because Linux has many very advanced and useful features, it
should use them.
I don't understand why these people who are so worried about systemd
making the kfreebsd-* ports look bad don't go ahead and port launchd to
it. launchd exists and is mature, is largely on feature par with systemd
and has been released under a free license. systemd for the Linux ports,
launchd for the kfreebsd-* kernels.
By this particular metric sysv init still outperforms
systemd. In fact for every combination of init systems you will find a
metric where one outperforms the other.
No, sysvinit has always been slower for me than systemd. The first thing
I do after installing a new Debian box is replacing sysvinit with
systemd. It's like using Internet Explorer to download Firefox on Windows.
Let me therefore direct a question to those in favour of a switchable
/bin/sh:
What are the benefits of using shells other than dash for /bin/sh? (as
opposed to other viable mechanisms to select a shell such as the shebang
of your scripts)
The difference between a shell and an init system is that the former is
directly exposed to the user while the latter will only be visible to
developers and admins most of the time. It makes sense to be able to
customize your user interface, but I don't think it makes sense to be
able to customize a core component like the init daemon.
I already think that it's a bit crazy (and geeky) that we have the
capability in Debian to choose between different kernels, so I guess
it's natural that we have discussions about being able to make choices
for init as well :).
Cheers,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Reply to: