[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: A few observations about systemd



> That is very good and has way more chances of changing the status quo
> in Debian than any pro- or against-systemd thread on -devel.

Just to clarify -- this is not a pro- or against- thread, which, as I've
tried to make clear in my initial mail, would be premature.  My goal is
to get people thinking about the current work being done on next-gene-
ration init systems, and it appears that I have succeeded.

Let me be more explicit.  Over the last few years, we've seen a mul-
titude of new init systems appear.  The other distributions have been
switching like crazy -- as far as I'm aware (I may be wrong) Gentoo went
for initng, then switched back to SV init, Fedora switched to upstart
and then, within two releases, to systemd, openSuSE switched to upstart,
then started switching to systemd, then apparently stalled.

This sort of disruption is not good for the users; neither is it good
for the developers' morale (a vitally important consideration for
a distribution that relies on volunteer labour).  Again, this is just my
private opinion (and as you know I'm not even a DD, just an enthusiastic
user), but I'd like to see Debian wait until the dust settles.  I'm
acutely aware, however, that waiting only makes sense if Debian developers
are aware of the ongoing community-wide debate, and participate in it.
Which is why the work of people like Tollef and Scott is so crucially
important.

So folks -- please relax.  Please play with runit, play with initng,
play with upstart, play with systemd.  Oh, and read djb's thoughts on
the subject[1].  When enough Debian developers are competent to have an
opinion on the new init systems, the Debian community will naturally
converge on the technically correct solution; at that point, fitting the
non-Linux kernels into the picture will be a simple matter of hacking.

As a final note, Bastien and Ian have outlined a different architecture
for a new init system, one that does not rely on running 700 kB of text
under pid 1.  I happen to agree with their vision.

-- Juliusz

[1] http://cr.yp.to/daemontools/faq/create.html  Please note that I am
    not suggesting daemontools as a solution, just recommending that
    people be aware of the rationale behind it.


Reply to: