On Wednesday 29 October 2003 02:36 pm, robin wrote:

> Since when is a stable release "bleeding edge"?  Bleeding edge is
> Cooker. Bleeding edge is running alpha apps.  Bleeding edge is using a
> development kernel.

Mandrake Linux is considered much more cutting edge and state of the art than 
many other distributions including Debian or Red Hat.  If one valued 
stability over getting the latest technology, there are distributions that 
provide that.  I don't remember any Mandrake release that wasn't followed by 
several rounds of patches to fix problems.  If you were running on the 
assumption that a new release was stable, then perhaps my cynicism has just 
been protecting me.

I think that any new release, especially one that was tested with a fairly 
limited audience and on probably limited platforms should be considered 
bleeding edge.  This is especially true where the test platform is probably 
not the lowest level of computer equipment.  Most people running cooker or 
even installing the release candidates are not your average test bed so 
common sense should indicate some caution before installing and using a brand 
new release of software.  Given the fact that it is still not available to 
persons not members of Mandrake Club, I would argue that the release pool is 
still too small to be considered to be fully vetted by anyone.

> > It is not outrage, it is simply annoyance that there are so many more
> > people prepared to bitch and look a gift horse in the mouth than there
> > are people prepared to contribute and offer support, or accept personal
> > responsibility for knowing about their own computer equipment.  Criticism
> > of something that should not have been done is one thing, blaming a linux
> > developer because he wasn't smart enough to protect an idiot designer at
> > LG from his own stupidity is something else entirely.
>
> You are making an assumption that the people who complain (or "bitch",
> as you so charitably put it) are a separate group from the people who
> contribute and offer support, or for that matter pay for their software.

I am making no assumptions.  You said that the kernel developers should have 
tested the patch with LG CDROMS and unless you want to admit to chiming in 
with "hindsight is 20/20" advice, I would argue that suggesting such testing 
would also involve several varieties of motherboards, hard drive controllers, 
network cards, modems, CD Burners, DVD Burners and the list goes on.  In each 
case, it is possible that some change introduced into the kernel will have 
some negative effect on legacy hardware.  The only way to be sure is to test 
exhaustively.  That means loading them up, configuring the software and then 
testing each one in turn.  That takes time and resources, all from people who 
have regular jobs, in some cases that don't involve Linux.

MS, which has a much bigger QA group and loads more resources than does 
probably any Linux developer does NOT do this type of testing.  They require 
hardware manufacturers to do it themselves.  Still think that it is trivial 
for Linux developers to do it?  Would you pay the extra cost to have it done?  
And wait the extra time for the release?  If I were willing to wait the extra 
time, I would still be running Debian, that is a very stable and well tested 
distribution.

Testing will add on to the release schedule and extend the period when 
releases are made and probably reduce revenue for a company that is already 
not on the best financial ground.  And this for software changes that 
Mandrake itself may not be making or even familiar with.  

The point that I am making is that short of that hindsight advice, you are 
suggesting that they create and maintain a test lab of machines and hardware 
for testing purposes but not suggesting how cash-strapped developers are 
supposed to pay for such a lab.  Thus my characterization about people 
complaining but not offering solutions.  I think it is apt.

> > At the point that MS starts to deploy closed box console computers to the
> > general public, I am sure that they are going to point to this particular
> > incident to explain why it is preferable for people to not install their
> > own OS or software, and not to buy separate computer components.
>
> That was exactly my point.

And mine that followed.  The only way to be sure is to operate with  a closed 
box.  No developer or company will take responsibility for something that 
they have not personally vetted or built.  If it is impossible for Linux 
developers to exhaustively test each piece of hardware, then that 
responsibility falls to those of us who install the software at our own risk.

If anyone doesn't like taking that responsibility themselves, there are plenty 
of others who will take it for you, you simply have to pay for that.  Or wait 
for others to do so.

> > Unlike some others in the community, I am not at war with MS, I do not
> > seek the destruction of MS, I am not on a holy crusade, nor am I an
> > evangelical pushing a philosophy.  I am simply someone who enjoys the
> > fruits of labor that have been given to me and tries to contribute back
> > when I am able to do so.
>
> With the implication that those who criticise don't do this, perhaps.

Nothing at all implied and you missed my point.  I am not encouraging Linux 
because I want to defeat MS and I don't care and think that the Linux 
community should not care one whit if someone wants to install MS software 
because the Linux community failed to live up to their expectations and 
demands about providing the type of product that they wanted.  I don't care 
if we lose some fair-weather friends to Windows because their crappy drive 
blew up due to a hardware design screw-up.  

My point was, I don't care about MS's monopoly, or anyone else's for that 
matter because I still have choices and the only cost to me has been time and 
effort to learn how to do for what I need for myself or pay or find someone 
else to what I can't.  So if this little glitch drives some other people to 
Windows, I say, don't let the door hit you on your ass on your way out.

> > If the price of getting someone to use Linux is that I have to dummy it
> > down to the point where I replicate the same mistakes, bad design and
> > idiotic marketing bullshit that MS has propagated, then I say that price
> > is too high.
>
> I don't see what any of this has to do with dummying down Linux.
> Besides, would you rather go back to the days when installing Linux
> meant editing  configuration files in emacs?

No, but I don't think that the answer is to implement the same design mistakes 
trying to dummy proof software for someone that doesn't want to accept 
personal responsibility for learning and figuring out some things for 
themselves.  That includes buying cheap-ass, defective hardware and then 
complaining because the Linux OS, performing a completely standard activity 
caused said defective hardware to blow up.

> > I wouldn't consider trying to perform electrical design in my home or car
> > because I am not qualified to do so.  Buying a particular OS does not
> > make someone qualified to configure or maintain a computer.  If someone
> > wants something that is just like Windows, I say, let them use Windows.
>
> And if someone doesn't want a user-friendly Linux, I say, let them use
> Debian. But as I said, this isn't the issue here.

No, it is not about user-friendly.  It is about compatibility, logos, 
certification and expectations.  It is about either checking the hardware out 
with the manufacturer for support or checking with others who have looked at 
it first.  Either that or you take your chances, throw the dice, and don't 
whine when it comes up craps.

> > No, but asking developers to keep fully stocked hardware labs for testing
> > purposes is hardly a simple criticism.  You do not provide any mechanism
> > for them to easily implement your suggestion and leave the onus of doing
> > so entirely on them.  Not to mention the extra time and resources
> > required to conduct such testing.  I do have some knowledge of what is
> > involved and it is NOT trivial.
>
> If LG were some really obscure hardware manufacuter, I would agree.  The
> fact is that these are some of the most common CDROMs on the market. And
> as someone pointed out, they cost around $12.

Again, hindsight is 20/20.  Now, if you had made this observation about 
testing against LG drives before the release, I might have a tad more respect 
for the warning.  Since you are suggesting this after the problem has been 
found, I am giving it what I think it warrants.  Anyone can chime in after 
the fact and talk about what someone else should have done.  It does not 
sound helpful and, IMO, pisses off people who volunteer a lot of time to 
benefit others because it sounds and awful lot like the blame game.  Try 
making suggestions before the problem crops up and people will probably be 
much more receptive.

If I sound a little emotional here, it is because I do testing for a living 
and I constantly listen to people who stroll in after the fact and say very 
matter of factly, "well why didn't you test this part where the bug was?" and 
then look around as if we are all supposed to be awed by their brilliance.  
Gee, why didn't I think of simply testing where the bugs are?  Well, I guess 
it has to do with not keeping my subscription to the Psychic Friends Network 
current so I don't know where the bugs are.  I have found through practice 
that figuring out where to look for problems before they are found is a tad 
more difficult than pointing them out afterward.

At this point, LG probably won't have much business in the immediate future 
because even if the Linux glitch didn't burn them enough, the subsequent 
exploits probably will.  So, more than likely, this particular problem won't 
crop up again because any hardware manufacturer who is left is going to be 
wary of finding themselves in a similar position.

Since the problem with LG drives is least likely to be repeated and you are so 
anxious to tell the developers how important it is to test for possible 
glitches, perhaps you want to make a prediction as to the next bug or problem 
that will come up so that they can be sure to test for it.

If I sound a little offensive here, I am sorry but again, I think that the 
point that I am making is very appropriate.  People who don't understand the 
complexity of QA often completely underestimate how hard and resource 
intensive it can be.  And doing it halfway is almost worse than not doing it 
at all, at least if you just don't do it, you are not fooling yourself 
thinking that you have found the worse stuff and giving your customers false 
expectations about what to expect.  

Doing it right takes a lot of time, people and money.  Short of suggesting 
where to find those resources, suggesting to developers that they should have 
tested a particular thing where a bug just happened to crop up serves 
absolutely no point at all.  It does however, yank my chain.

> > For those that wanted to gain the benefits, the only thing that they
> > needed to do was actually WAIT before installing until others had had a
> > chance to do the same type of testing that you propose.
>
> As I said, it was a stable release.  That should mean testing was
> complete.  Not testing on every obscure bit of hardware on the planet,
> just the most common stuff.

Fine.  Define common and give me a list because that is certainly something 
that I could use in my current line of work since I test for a living.  Oh, 
and points off if your list doesn't match the fifty others that are submitted 
all by people who have different ideas as to what is the most common hardware 
set built completely according to what they themselves own.

-- 
Bryan Phinney
Software Test Engineer


Want to buy your Pack or Services from MandrakeSoft? 
Go to http://www.mandrakestore.com

Reply via email to