I think the reality is that adopting systemd as default init for Debian is
nothing short of a death sentence for the non-Linux ports. The move to a
different init will have a snowball effect in the distribution, as packages
stop being tested with sysvinit and popular support grows for dropping
compatibility with sysvinit altogether. This is not a problem if the ports
are in a position to come along on this transition with a moderate
investment in porting init. But the porting required for systemd as a whole
is far from moderate, and I believe that faced with such a requirement the
non-Linux ports would wither and die. I know there are Debian developers
(including many in the GNOME/systemd "camp") who think this is a desirable
outcome. I have no personal attachment to the non-Linux ports, but I do
think that as an existing part of our Debian community, the TC should at
least give these ports a fighting chance, because this kind of competition
is healthy.
> My understanding was that Dimitri had got upstart running on BSD.
The latest that I have seen on this porting effort is here:
http://blog.surgut.co.uk/2013/11/libnih-upstart-dependency-ported-to.html
I asked previously on this bug if someone had later news. Do you have
more information than that?
The above is definitely not "upstart running on BSD." That's upstart's
underlying support library mostly working on BSD after disabling two
features (that are required for upstart). I haven't not heard whether the
porting of upstart proper has started. That will certainly be much easier
once libnih is ported, but there are, for example, direct uses of epoll in
upstart proper. (I don't know if kFreeBSD already has a portability layer
for epoll in terms of kqueue.)
AIUI, upstart itself built out of the box once libnih was available, because
all the portability issues are encapsulated in libnih. (The single use of
epoll in the upstart source is in the upstart-socket-bridge, which is an
optional component from upstart's perspective and certainly not needed for
booting a Debian base system - so presumably Dimitri just built with this
bridge disabled.)
With libinotify-kqueue (that Dimitri maintains), kfreebsd 10 (in
experimental), eglibc 2.18 (also in experimental), and Dimitri's branch of
libnih, it seems that all the portability requirements for upstart are met,
except for abstract socket support. There are evidently still some porting
problems that aren't detected at build time, because upstart doesn't yet
boot on kfreebsd. But all things considered, the port is rather far along.
upstart is a great project, of which its maintainers are deservedly proud.
However, I don't agree that it's better than systemd. My own research
convinced me of the opposite. But putting that aside, my point in that
section is that, given feature parity (and I mean "feature" expansively,
including adaptibility to Debian's needs), we should choose systemd
because it has more project momentum and better existing integration,
which means that we will have to spend less energy on it and will have
more energy to spend on other things.
It's absolutely worth doing our own, better things. What I don't want to
do is our own *worse* things. Or, for that matter, our own equivalent
things, when we could instead use work that already exists. It's a waste
of energy.
I think this downplays the significance of the integration work that has
already been done in Ubuntu on top of upstart, that Debian will be able to
adopt as-is (or with whatever bugfixes the maintainers find along the way).
My look at Fedora 20 confirmed my belief that the integration necessary to
have a robust systemd boot across all the configurations that Debian
supports has not actually been done yet. systemd upstream advocates
shipping systemd units upstream where they can be consumed unmodified by
distributions, but in practice Debian is going to be on the hook for
debugging the very long tail of integration problems. It's hard to gauge
whether the energy saved by not bringing upstart up to feature parity
outweighs the energy spent on bringing systemd integration up to snuff, but
I definitely don't think there's a clear point here in systemd's favor.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org