Re: Where is Debian going?
Sounds great. Let me know when you have that all finished...
On Wed, 2002-07-10 at 09:45, giuseppe bonacci wrote:
> 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-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
Lorens Kulla
lorens1@attbi.com
--
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: