[Eug-lug] Free O'Reilly book

[T. Joseph CARTER]

On Sat, Jan 29, 2005 at 02:49:49AM -0800, Alan wrote:
> >Question for you: I just built a machine for $300.  Can YOU install Debian
> >stable on it?  (The answer is no.)
> 
> _I_ could, yes. Could I do it with the standard installation CD? No.
> Could I do with a custom built installation CD? Sure could.
> (Assuming of course, you haven't built a ringer with hardware 
> unsupported by Linux. heh)

I run Ubuntu on it now.


>   You can't run Debian stable on any machine with an
> >ATA100 or ATA133 chipset.
> 
> Huh, that'd be news to my two machines with ATA100 on them.
> Is it an "official Debian.org" kernel? Nope.
> Is it still Debian stable? As far as I'm concerned, yes.

Ahh, but you have to have a Debian box or reasonable facsimilie to be able
to build a new boot CD.  So you have to install Debian to be able to
install Debian.  Brilliant, why didn't I think of that?


> Now, you could make the argument that any kernel that's not apt-gettable 
> doesn't qualify as "Debian Stable", but you make that argument for any 
> distribution that needed to be patched to support the latest hardware.
> 
> Damnit..here I am getting myself involved in another silly debate.
> 
> Let's just say that yes, in stock form, stable is a bit aged, but there 
> is nothing stopping anyone competent from getting as bleeding edge as 
> they want with it.

The problem isn't that stable itself has aged so much as that it has been
unmaintained in any usable respect.  Old versions of apache are fine, as
long as they're secure.  Old kernels are fine as long as they support the
common types of hardware needed to boot them.  Supporting the Audigy 2
sound card may not be critical in Debian, but supporting ATA100, ATA133,
and SATA is pretty important.  If you need to patch the Linus kernel you
shipped with your distribution three years ago in the next revision, do
it.


It's the same reason I didn't install Red Hat 4.2 before I ended up trying
Debian back in 1997: Red Hat 4.2 required(!) that you get XFree3 working
as part of its install procedure.  If you didn't do it, you couldn't
finish the installation.  As I couldn't (weird video card and no clue what
a modeline was), I simply couldn't do it.  Not with the level of skill I
had at the time.

Sure, everyone said Red Hat was great (who used it, anyway), but what did
it matter if it was great if you couldn't actually get the thing
installed?


> >On top of all of that, at the time, the Debian people said they were
> >rewriting their installer and it would be about a year before it was ready
> >for its first real test.  In that time, people with new machines could not
> >install Debian at all, and after it only if they went after the
> >experimental new sarge installer for another 6-8 months.  Them's the
> >breaks, say Debian.
> 
> Them is the breaks. Debian isn't for everyone. It's conservative, and 
> probably overly concerned with "the right thing"(which of course, no one 
>  can agree on). But to some people these are strengths, and denigrating 
> it just because you don't happen to agree with it, well, that's just bad 
> form.

No, it is not at all conservative to leave people with standard and
supported hardware year-old hardware out in the cold with no way to
actually bootstrap the system.

This problem was created by the apathy and laziness of one developer who
complained that managing a bunch of patches to the kernel was too tedious
(and therefore he would always use the Linus kernel, straight up) and the
eagerness of the installer team to do something new and revolutionary
because the system they had was combersome and widely criticised.


> Myself, I've never understood the installer hatred that some folk have, 
> it's always worked fine for me.

Worked for me too, until I bought a new HD that didn't like my older
motherboard and I tried to use the ATA100 controller in the box with the
drive on it.

Given that packages were moving into frozen for inclusion into woody, I
asked for the patch I needed.  I was told that if Linus wanted the patch
in the kernel, it'd be in the kernel.  Of course, it already was, in
2.4.19pre1.  Two weeks later, 2.4.19 was released with the patch.  Two
weeks after that, woody released without support for my hardware.  A week
later, I discovered this, reported it, and was flamed for not reporting it
when I had the chance.  Except I had, and demonstrated so.

They got quiet, and have yet to fix the problem.  THREE YEARS LATER.


> >Okay, Debian stable has a policy that no new software goes in.  Period.
> >If there is a need for a backport of a security patch, it is backported.
> >There are times (required boot drivers!) when this doesn't make sense, but
> >the powers that be insist that the policy must be followed to the letter.
> >Consider that.
> 
> And it's a policy I agree with.
> If you want to play with the bleeding-edge, there's unstable for ya.
> You want the middle ground, testing is your best bet.

I know the policy.  (I'd better--I wrote it!)

It goes something like this:

Stable
	no updates that aren't essential (eg, security patches)
	
Testing
	always installable, dependencies always consistent, kept
	reasonably bug free as possible, but we can't always promise that
	things might not slip through

Unstable
	updates to testing.  Large pool of packages, the bleeding edge.
	End users should steer clear unless they have a death wish for
	their system.

Various other pools
	updates to testing, internally consistent subsets of unstable.
	This was a centralized answer to "staging areas" people were
	beginning to try to create, and now frequently do create since
	there is apt.

It happens that sarge will be the first distribution based on this method,
or rather the derivative of this method James Troup was willing to have
done.  He said that it sounded good, but like a lot of work, more than
anyone should expect unless they were willing to step up and do it.  A few
people did, but James considered the system too important to let just
anyone get near it.

Larry pointed out at some point that I seem really not to like the guy.
It has something to do with him being a self-appointed central figure of
every major aspect of Debian's infrastructure (he has final authority to
approve or reject new maintainers, controls Debian's cryptographic
keyring, is one of Debian's sysadmins, and one of its ftp masters.  He can
(and does) keep people he doesn't like out of the project, holds their new
uploads because he doesn't want to release them, acts as judge, jury, and
executioner of people he feels have mismanaged their cryptographic
responsibility, has a bad temper, and has had two seperate project
leaderships actually admit to trying to placate or otherwise undermine his
assumed authority.  When I last left Debian, they had been arguing about
new policies for new maintainer which would force him not to approve one
maintainer before he's made a decision about any others who've been on the
list longer.


> Stable is supposed to be just that. Stable.
> Stable does not mean "Hey, let's install the latest IDE patch and find 
> out 3 months later it has a data loss condition under high load".

We're not talking three months.  We're talking about the IDE subsystem in
use for more than half a dozen 2.4 kernels released since, the entire 2.5
and 2.6 trees, and the creation of all of one more set of boot floppies
sometime within the past three years to provide a kernel that can actually
install the so-called "universal" operating system.


> I usually run a mixed system because I do find, like you, that sometimes 
> stable is a little too conservative, but for the most part, it does what 
> I need it to do.

I have no problem with conservative upgrades.  I have a problem with
shipping a product that is broken and then refusing to fix it because the
right combination of stubbornness, policy, and politics make the only
people authorized to be unwilling to do it.

What would have been wrong with a bf2.4-newide?  I'd have even been
willing to do the work.  But I hadn't got the authority to do that.  And
the last time a developer took it upon himself (at his employer's request)
to produce an update to Debian stable to work with new hardware, that
developer got flamed for working on slink rather than putting effort into
finishing potato which would be ready in a couple of weeks anyway.  His
finished product was ignored by Debian and is now lost to obscurity.
(BTW, potato was released about six months after he finished it.)


This is but one incident of many.  Debian is all about consensus, unless
one of a small group of people disagrees.  The group varies from issue to
issue, but there are a few key players who are part of nearly all issues.
There are things that go on in that project at times which would make most
people on this list stay far away from Debian if they knew.  Some of them
are more inflamitory than I am willing to discuss on this list.

The really sad thing is that the core values--technical and otherwise--of
Debian were good ones--a consistent policy that all packages of a given
type must follow to ensure interoperability, a place to discuss revision
of this policy in public view, the DFSG and social contract, the
(formerly) open development model, and the development of common
infrastructures that let you decide how your system is going to work
instead of the distribution maker.  So many years later, I'm still
wondering how it went so totally wrong.