Deleting an alpha iso for the safety of users hardware

Vincenzo Ciancia ciancia at di.unipi.it
Thu Oct 2 23:59:55 UTC 2008


This discussion started after a complain of an user on the following bug
report:

[intrepid] 2.6.27 e1000e driver places Intel ICH8 and ICH9 gigE chipsets
at risk
https://bugs.launchpad.net/bugs/263555

I continue it here because it makes no sense for the bug report by
itself, but makes a lot of sense for future decisions in similar cases.

The user in question had seen his hardware damaged by the infamous e1000
bug. Later he was told he should not use alpha for serious work, but the
stock reply certainly does not apply in this case: he might as well have
been a good tester, but damaging his hardware permanently is not a nice
thing.

Now we know that the damage is reversible, and this is thanks to intel
who cares for linux users instead of just ignoring them.

In the bug report I said

"Indeed the alpha release should have been replaced in a hurry by a new
release with the module blacklisted. What I see from "outside" is that
the burocratic need to release images only at established dates is
preventing a well known practice - release a fixed iso in a hurry - to
happen."

What is said above is what any person observing ubuntu development may
say (e.g. newspapers, online feeds, blogs etc.) and it is no better than
the typical "patch over patch over service pack" news that feed
anti-microsoft activists all over the world. In other words - if
microsoft damaged people's hardware with an alpha release most of us
would have used this as an anti-microsoft campaign - and probably
someone might have concluded that a person so crazy to work for free for
microsoft indeed deserved the consequences of their acts. Now what makes
the big difference is that we love ubuntu but I doubt this can be used
as an excuse :)

It has been argued - and I agree - that putting a warning in the
download page is not enough, because isos circulate, get downloaded at
night automatically etc.

then on 2008-10-02 at 22:18 Steve Langasek said that indeed it is not
fair to say that users of the alpha should know that their hardware
might be damaged, and also explained:

> 
> This is not "bureaucratic".  A working milestone image can't be
> produced at
> random, it takes approximately a week to prepare and validate a set of
> images and we can only muster one of these once every two weeks (at
> best).
> Doing a new alpha release right would have meant deferring the beta;
> doing
> it wrong is no better than just deleting the images, since there's no
> guarantee they'll work.

I didn't know this and would like a better explanation to the benefit of
everybody who is wondering why.

So: suppose I take the alpha iso and mount it, I am 80% confident that I
can blacklist e1000 easily by hacking some of the contained files. This
would take a couple of hours, and leave the alpha exactly as is, without
changing any package except for blacklisting e1000 - and I suppose
md5sums and eventual signatures of the iso. This is a quick and dirty
fix, and I am sure you may think of many better methods, so why whould
this take a week? What's wrong with the above?

The urgency of the problem (reversibility of the damage was not known at
the times, and notice there is not a program yet to do that) suggests to
me and probably many other people that the isos should have been made
unavailable immediately after discovering the problem. I think I have
seen such things as making downloads temporarily unavailable, and
uploading a quick-patched release (with such fixes as disabling a driver
as you did in the archvies) in many other releases of software.

Vincenzo






More information about the Ubuntu-devel-discuss mailing list