Re: On init in Debian
Samuel Thibault <firstname.lastname@example.org> writes:
> So you believe that systemd already implements all the important details
> that readahead+inetd+udev+autofs+fsck+quota+swapon+kbd+getty+etc. have
> polished over time?
I suspect there are corner cases that are not yet polished properly, which
is why people run it and report bugs. That's already being done in
Fedora, of course, similar to how upstart has been tested, debugged, and
polished by use by thousands of Ubuntu users and corner cases were
discovered and fixed in the process.
I also think that it and upstart have an inherently better design than
some of the components that they are replacing, and don't have to deal
with as much historical cruft that, within the context of that design, is
no longer necessary. That makes the code much less complex, which in turn
makes it less buggy and makes ongoing maintenance better. Yes,
well-tested historical code is rock-solid in the areas in which it's been
well-tested; that doesn't mean that adding a new feature to a crufty old
code base is much fun, nor does it mean that code is resistant against
bugs introduced by necessary new modifications (and there are always some
Sure, I'm sympathetic to the idea that one shouldn't replace subsystems
but just evolve the ones one already has. That's often the right
approach. But it isn't *always* the right approach, particularly when
other people have already done quite a lot of the work of developing a
replacement subsystem and there are architectural reasons for doing
something differently that are new from when the old subsystem was
You can add GSS-API authentication, encryption, and a wide variety of
other things to ftp. Yet, as it turns out, we're mostly all using sftp
instead these days, which was a completely new implementation that didn't
do a lot of the things ftp did (and, indeed, still doesn't; I don't think
sftp has a TENEX mode) and didn't have all the bugs ironed out at first.
But, in the long run, it's now what everyone uses.
This happens in computing. It's part of the natural process.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>