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

Where is Debian going?



Hi All.

I am not subscribed to this mailing list, nor do I routinely follow
discussions in this list. I hope not to upset anybody in case this message
is misplaced, and I apologise for not being a native English speaker.

I'm a long-time Debian user, and I really appreciate the work that stands
behind this Linux/GNU distribution.  But I wonder why many non-casual
Linux users around me are definitely frightened by Debian, and I would
try to explain my personal feelings about it, and why I would like to
see Debian change.

Perhaps the biggest problem is the distribution scheme of Debian, that by
`experimental observation' allow one to choose between

1. a `stable' distr., that is continuously patched for security issues,
   but is made of software whose version has been frozen 1--3 years ago.

2. an `unstable' distr., that is made up of software in fast evolution,
   and possibly seriously messed up. (not for the faint of heart)

3. a `testing' distr., which seems to be something in between, in that
   software versions have been frozen several months ago, and there is
   plenty of pending bugs.

Now suppose I want to install Linux/GNU on my "brand new" PC, as a base
for my daily work. What I essentially need is

- a stable and bug free basic system (kernel, libc, and so on), possibly
  relatively old, yet supporting my presumably new hardware. To name one,
  XFree should be reasonably up to date.

- an up to date user-land software for daily work (editor, web browser,
  mail client, developing environment and so on), possibly not very
  stable, but fully functional.

After a moment of thought, one soon realizes that none of the above
mentioned distributions in Debian fulfil these requirements:

Potato has a very stable and secure basic system, yet it sticks to
XFree 3.3.6, that has a very limited support for new hardware. Moreover,
it has plenty of "obsolete" packages, e.g. Mozilla M18.

Woody made a step ahead, but still has XFree v. 4.1.0 and Mozilla 0.99,
instead of the most recent (and upstream-stable releases). Moreover,
it contains roughly twice as many packages than Potato, and is likely
to have many undiscovered security problems.

Please note that Mozilla is a kind of paradox: a "stable" distribution
contains a pre-beta version of a package that is included in a "testing"
distribution in a more stable and reliable version.

As a result, many Debian users are led to compromise solutions like
installing the base system, then downloading interesting software from the
upstream distributors and installing it in /usr/local (and periodically
checking all distributors for updates). But this effectively breaks one
of the distinctive points of Debian, that can be kept up to date with
a single command line ("apt-get update; apt-get -u upgrade").

Others refuse Debian as soon as they realize that most software in the
stable installation is several years old, and turn to Red Hat.  (BTW:
no user new to Debian will try 'Testing' or 'Unstable' before 'Stable'.)

And worse, some developers feel that they are working in maintaining
obsolete packages, or in preparing and debugging packages that (although
perfectly clean and usable) will not be used by people around the world
for a long time. (cfr. Adrian Bunk retirement from Debian)

Now I turn to the  main question: is Debian distribution scheme the most
efficient way to handle software evolution? By looking at other software
distributions, I should say not.

The problem might consist in one single issue, that the current Debian
scheme {stable, testing, unstable} / {main, contrib, non-free} fails
to address: different pieces of software installed on a system should
evolve at different paces. So the list of package versions that make
up a working system should not be static;  and there should be a way to
distinguish between the operating system itself and add-on software.

Other OS distributions, like FreeBSD and Solaris (TM), have addressed this
issue, and separate clearly the operating system from additional software.
They offer base distributions that are rather complete (but customisable)
and light. User land software pieces are kept to the minimum, and enter
"the base system" only if very useful and stable enough. (Think of bash
and apache in Solaris.) There's no surprise FreeBSD is contained in 1
CD, Solaris 8 comes in 2 CDs (actually, one and a little), and Debian
(Official) takes 3 CDs.

The main advantage of such schemes is that the people that maintain the
OS proper must not keep in sync with the large number of people that
maintain other software, and they can release stable versions of the
operating system more frequently, ending up in a stable, secure, and
not-too-obsolete OS.  Maybe one could manage to have several base-system
versions, tagged by kernel- or libc-revision or whatever release managers
think suitable, but still flexible enough to avoid sticking to a several
year old 2.2.x kernel in the "stable" software installation.

On the other end, additional software has a life-cycle that Debian fails
to recognise. Let's take Mozilla for example.  Debian Stable has Mozilla
M18, that is hardly usable. (a snapshot alpha version).  Debian Woody has
Mozilla 0.99, that's a pre-release.  The team that develops Mozilla has
recently released Mozilla 1.0, but I doubt that it will ever make its way
in Stable or Testing, because Potato sticks to M18 and Woody to 0.99,
and by the time the Unstable distribution will converge to something
reliable, other versions of Mozilla will be included.

I think it would be much more convenient to have several package lists,
e.g. named `beta', `current', `previous' and `obsolete', and allowing
packages to move between these lists as the mainstream version evolves.
According to this scheme (probably not the best possible) Mozilla 1.0
should  have followed a route similar to the following:

0. 0.99 is in Current

1. 1.0RC enters Beta

2. 1.0 enters current, 0.99 moves to previous, 1.0RC dies.  Updates to 1.0
   (i.e. 1.0.x) will still belong to Current

3. six months later, when Mozilla 1.2 is out and stable, 1.2 enters
   current, 1.0.x moves to Previous, 0.99 moves to obsolete.

Maybe deciding whether a package belongs to the OS or add-on software,
when it is upstream-mature enough to be included in 'current', and so
on, is not a trivial task, but probably it's only a matter of common
sense.  Currently there is a strong focus on legal terms and decisions
concerning the eligibility of packages for inclusion in main, contrib
or non-free, and I hope that someone can devote some time to help take
easier decisions.

This scheme is an over-simplification, and of course it does not take
dependencies into account.  But if you put together the staticity of
Debian stable distributions and the fact that every new release takes
much longer than the previous (mostly because the number of packages
to synchronise dramatically raises everyday), you should recognise that
the current scheme does not work.

Best regards
Giuseppe


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: