On Wed, Jul 20, 2011 at 09:37:07AM +0200, Raphael Hertzog wrote: > I am among the people who are proud to see that we managed to achieve > Debian kfreebsd.
Same here, I've always mentioned GNU/kFreeBSD as one of the things I'm
most proud of in the Squeeze release. I'd be no less proud of seeing
Debian grow other non-Linux ports (e.g. Hurd) in future releases. No
matter how unimportant those ports might seem to people using only
GNU/Linux, the make Debian today one of the most important porting
platforms for our upstreams and users. They can both benefit from Debian
seeing how portable their software really is. This is an important role
that Debian is playing in the whole ecosystem of Free Software.
> We should be shaping the future and not be simple followers. I agree
> with Joey Hess that we should have init systems that make use of all
> the powers of Linux on Linux and make use of all the powers of FreeBSD
> on FreeBSD.
I agree with this as well. Even if it might seem at stake with the
former argument, I believe it is not. We cannot hold back advancements
just because one part of our huge archive does not support them; doing
so would mean taking a rather extreme (and wrong, imo) side in the
trade-off among "universality" (in the technical sense of "runs
everywhere") and "advanced" (when compared to other distros).
If we lag behind in features that are good for GNU/Linux users (who are
the vast majority of our users) just because users of some ports can't
have them, we might force users to choose other distros, renouncing to
some of the unique features that Debian has to offer (freedom, quality,
open development, etc.). This of course goes both way: we should not
hold back non-Linux features on non-Linux kernels because the Linux
kernel lack them. Adopting that as a general principle would mean
offering, overall, the intersection of features available in all our
ports, something which is doomed to reduce with the growth of the number
of ports.
But what I find surprising in this discussion (with notable exception,
luckily) is the feeling that portability is boolean: it is not. It is
rather a trade-off among the work that needs to be done / code that
needs to be maintained and the distro-wide technical choices that we
make. In that respect, the fact that systemd upstream might decide not
to integrate upstream our chances is sad, but it's not the end of the
world: it won't be the first nor the last upstream not willing to
integrate some of our changes.
> This is why interfaces are much more important than the individual
> implementations. This is what has been suggested in this thread
And speaking about interface, another surprising absence in this thread
is the mention of Debian's most important "interface", namely the Debian
Policy. No matter how much we discuss whether systemd (or upstart, fwiw)
is good or not in this thread, the discussion won't make adopting it any
easier. init.d scripts are explicitly supported by the Debian Policy and
required for packages shipping services. That means that the first
mandatory step to have support for a non SysV init system in Debian is
to add support for it into policy.
That has started after the "upstart in Debian" BoF at DebConf10 and is
being tracked in #591791. I've pointed the systemd maintainer to it a
long time ago and he has chimed in there (thanks Tollef!). I'm not
following the bug log closely, but it seems to me that they are also
discussing there how to generalize the policy change to other init
systems, such as 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.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, | . |. I've fans everywhere
ti resta John Fante -- V. Capossela .......| ..: |.......... -- C. Adams
signature.asc
Description: Digital signature
