This is, of course, way off-topic, and I rather like Shad's reply, but a couple
of
interesting points are made here which I think merit response...
Christopher Wolf wrote:
> At 08:21 AM 2/20/2001 -0500, Adam C Powell IV wrote:
>
> >We spend MONTHS in testing cyclles trying every possible configuration to
> >ensure a
> >perfect upgrade for all users, and NOTHING is released unless ALL of the
> >RC bugs
> >in ALL critical packages are eliminated on ALL platforms. If a less
> >important
> >package has an RC bug, it gets booted. Period.
>
> You're talking about single releases, which Debian does very well. But I'm
> talking generally about the lifetime of a free product, not necessarily
> Linux, in responding to a statement that free software is better. Debian
> does not write (all of) Linux. Linux is bloating, modules just move that
> bloat from memory to disk. You're going to be spending more and more time
> in validation. What happens when the time to validate exceeds the time
> between releases, especially considering the variety and history that you
> mention maintaining (below)? There's always more and more hardware being
> created which needs more and more custom patches to support it. And while
> the individual Debian releases are easy to upgrade, the individual pieces
> of the product itself are getting harder to install and configure, not
> easier, because of the variety of minor differences.
And even so, Debian with a brand-new kernel still runs on eight-year-old Amiga
2000s with 6 MB RAM and 30 MB hard drives, and similarly-equipped 386s. How
does
that fit into your theory?
The thing about good free software design, which holds for GNU and the kernel
and
Debian and is intended for GNOME as well, is that the development scales well.
For example, the reason Richard Stallman chose Unix as the basis for GNU is that
it is built on hundreds of little applications and scripts, each of which has
simple and predictable behavior, such that if each contributor chooses to work
on
one or two, then a lot of people doing a little bit of work each can make a
functioning system.
IMHO, this is the reason Linux is thriving and Hurd is not; RMS himself seems to
have made similar noises in the last month or so (I can dig out the URL if you
like). OTOH, as everyone seems to agree, Linux (kernel) needs some kind of
BTS/patch management system to continue to move forward... but that's another
topic.
But Debian has these things (BTS etc.), and they work very well. So as Debian
grows, the community of developers grows, so we're all set, right? Well, not
quite, things don't always scale linearly, as non-straightforward networks of
dependencies make things difficult. But we're pretty darn close to linear
scaling, testing cycles for woody look to be similar to what they have been in
the
past, and if not, it's because of the completely rewritten install system (for
the
first time since... 1.3?). But the new "testing" distro is helping a lot with
upgrade testing- as you say, we can now start testing the new release as soon as
the old one is out the door.
Check out the debian-history package for an (outdated) history, which should
show
something about the package-developer ratio and frequency of releases.
The point being that Debian is vast and enormous, and getting more vast and
enormous, but by design we are probably the best-equipped to deal with it.
> Yes. Debian is one of the better companies. Obviously, or I wouldn't be
> running Debian releases. But when we wave a purchase contract in Sun's
> face, they're at our door today, fixing the problem, because if they're not
> we'll go to someone else. There is no-one at Debian or "Linux" who will do
> that.
As someone else pointed out, get it pre-installed from VA and they'll do the
same
thing- and more, because they know that the competition doesn't end once they
ship
the hardware, anyone can support any Linux box. Sun can't do that for you- once
you have a Sun box, their only motivation for servicing it well is to get you to
buy another one, but nobody else can service the hardware that box.
And when Sun stops supporting it, the drivers are closed-source, the project is
abandoned, the box is dead. Like SunOS, like Ultrix, like NT on MIPS or Alpha
(or
all the other processor families it was supposed to support), like MacOS on m68k
or even pre-G3 Macs, like Digital Unix/Tru64 on pre-21264 Alphas, like
FrameMaker
on Linux- all closed-source, abandoned, dead. Oh well!
Furthermore, try getting Sun to suuport MatLab- you don't stand a chance! But
because the vast majority of Debian is free as in speech, VA- or SuSE or RedHat
or
Joe Debian Developer- can do that for you. I'm not much of a programmer, but
have
fixed some pretty ugly bugs myself (with help from the mailing lists), in
packages
from quik (PPC boot loader) to GNOME Calendar to GNUCash to Kerberos4KTH to
libglade to the kernel's Cirrus Logic framebuffer driver. In each case the
source
was transparent enough to zero in on the problem and fix it. Again, try doing
that with Sun.
> >... or get hardware with Debian
> >pre-installed- which solves the driver problem too!
>
> ...solve the driver problem only until you need a new piece of hardware. I
> may have missed it, but I don't believe you're implying that hardware never
> changes in a system.
So you're saying VA and Penguin and others have no new hardware?
Sure, you can find new hardware that isn't supported. But that doesn't mean
that
you can't find new hardware that is supported. And eventually, Linux supports
just about everything, and the rest just about nothing.
Thanks for the more thoughtful reply,
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best software in the world today cafe!
