apologies and summary. was: Where is Debian going?
First of all, let me say I am deeply sorry for having wasted your time.
So those that groan when reading deja-vu are kindly advised to stop
reading here, and turn to more interesting things. Since so many serious
developers out there believe that "Debian is perfect just the way it
is", I must be wrong, and what I perceive like paradoxes to a closer
look must reveal as brilliant features.
\begin{serious}
Second, let me just point out that I am a Debian user since Bo (1.3.1?),
which I installed on my notebook through a home-made Plip cable many
years ago; since then I have gone through hamm, slink and potato, and
will switch to Woody one of these days. And I use Debian for my daily
work. So I don't think to be a newbie, nor do I care about linux newbies
or Windows addicts choosing other distributions instead of Debian. It's
not a matter of marketing.
What scares me is the fact that experienced users around me (academic
developers as well as sysadmins managing hosts providing services to
millions of people) after careful thinking and a comparison period discard
Debian and choose RedHat. I don't think they are all short-sighted or
lazy. Moreover, despite someone's belief that Debian stable is an ideal
"server distribution", there are many more RedHat linux servers than
Debian out there. Perhaps, only perhaps, there is a reason.
I landed on Debian after trying SlackWare and RedHat, and I chose it
for three main reasons, namely the focus on security and the readiness
in critical updates; dpkg, and later on apt; the lack of a setup tool
a` la RedHat. Choosing Debian meant accepting to be "a step behind"
other distributions, in order to have a strong control on the system.
Now the step has become a large gap, because the release interval is
growing longer and longer. There is nothing evil in this growth, and it
is not accidental, since the number of packages involved and presumably
maintainers to coordinate increases rapidly. It can't be helped.
What is evil is the fact that very long release intervals automatically
result in Stable distributions that are already obsolete the day before
they are released.
I think there is nothing wrong with Branden not including XFree 4.2.x in
Woody, if he (or the whole Debian universe) thinks it is not upstream-
or package-mature enough to be of general use. What is wrong is that by
the time Branden thinks XFree 4.2.x is ready and stable he will still
have to wait for the next release cycle before he can include it in a
"stable" release. This could take literally years.
Some people think it's only a matter of nomenclature, and
it suffices to alias stable='dist-for-immutable-servers' and
testing='current-dist-that-works-pretty-well-and-is-up-to-date' to
make the world happier. But this is not quite true, since a testing
distribution is as far as I know something that is meant to eventually
freeze and become a stable distribution. Most comments regarding the
presence of Mozilla 1.0 (admittedly the wrong example) in woody are
misleading, if one thinks that Woody was scheduled to be released two
months ago.
One possible escape is splitting the core system from the more or
less useful corollary software. This could shorten the time between
releases, but maybe it would be too difficult to decide where to put the
boundary. (I guess that every single maintainer thinks his packages
are absolutely essential ;-) Not an easy job for release managers...
Another solution could be to break the equivalence stable=static, unique
to Debian. Currently "stable" is a list of packages whose upstream
(major) version has been fixed once and for all, and will not be changed
until next stable release, even when the upstream newer versions are
much more reliable and sometimes the versions in "stable" have been
obsoleted upstream. Sometimes it would be easier to solve a security
issue by turning to a more recent (and tested) upstream version for a
particular package instead of patching the stable obsolete version. But
the "stable" list does not change. (With the notable recent exception
of ssh, but again this is a wrong example.)
Now, what if "stable" were simply a list of packages blessed as reasonably
stable and reliable and bug-free, in other words the continuously
evolving list of "current packages", being defined current a package
that has traversed "unstable" and "testing" and is ready to be used by
all Debian users? Why wait for the next release cycle?
Maybe a sysadm prefers to have to update some package on his servers
now and then, rather than having a sudden catastrophe at every switch
between stable distributions. (let me remind you that currently a stable
distribution becomes obsolete shortly after it is replaced, and is not
subject to security updates anymore: a sysadm is compelled to switch.)
Obviously there is no need to remove the old versions, they could simply
be moved to another list, while still being available (through the pool)
and maintained, until they become obsolete and nobody wants to maintain
them anymore.
Despite the "lack of faith" of some developers, I think dpkg and apt
are now powerful enough and the ELF system is flexible enough to allow
for multiple versions of libraries and applications to live in the same
list and perhaps if not on the same running system.
\end{serious}
Now, since I'm not a maintainer and I'm not subscribed to debian-devel
and my ideas are not original, I am not entitled to comment on Debian
and I wasted your time (despite the advice at the very beginning...)
So please pretend that I have talked about the weather, and have a
pleasant week-end.
giuseppe
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: