Re: This is really Ridiculous

Brian Grunkemeyer (bg2k@cmu.edu)
Mon, 29 Jul 1996 20:19:59 -0400 (EDT)


> David Miller wrote:
> 20 minutes compared to days or even weeks. Thankfully, free software
> lets you try our way of doing things very cheaply. Also, free
> software allows you to actually do something yourself about a
> development methodology you have deemed as broken, you can go in and
> dork with the controls if you get the incentive.
> [...]
> There is something to be said about free support from the developers
> themselves on the net (good luck talking directly to a kernel engineer
> at a major unix vendor when you report a bug to them, that is unless
> you are one of those $4 million customers who keeps their lights on).
> Them doing it out of the kindness of their hearts and not because it
> means the roof over their heads, and then watching somebody
> complaining about it.

I never meant to spread the idea that I don't like free software or hate linux
or anything. I thought I was making a reasonable suggestion on how to save
those of us who do keep up with the latest Linux patches from wasting too much
time through a weak test run before distribution instead of afterwards. My
motivation was to save myself and others time, and to help Linus realize when
the code he's releasing is uncompilable in some configurations because of a
simple typo. I believe a compilable kernel is and should be a realizable goal
with each patch.

I've been using Linux for a year and a half now and I've shifted to using it as
my primary OS instead of OS/2. Overall, I'm happy with it and the style & pace
of development. I respect the work done by everyone who's contributed,
especially Linus. I'd just like to see Linus catch a few typos before he
releases them in hopes of making more perfect code. No one needs to advocate
free software nor Linux to me, nor do I think this is the proper list for such
ranting. Apparently critical reading of English is not a skill everyone here
posesses.

Now back to my actual suggestion:
I've gotten 3 responses directly about my suggestion (among the ~10 about my
slothy motivations and obvious contempt for free software). The most
compelling one was from Michael Elizabeth Chastain, who said he opposed my
suggestion on the grounds that typos indicate untested code, which could be
unreliable and not something he wants to run. As I understand what he wrote,
catching typos wouldn't help him at all because instead of flagging areas that
are still under very major development, they hide the rough edges and leave
real bugs in the code, which appears a bit more stable than it really might be.

This makes sense from a software development standpoint. I understand and
agree completely. For this reason alone, my suggestion is just about worth
throwing out.

The other critical material response was from Craig Schlenter, who said the
number of possible configurations is too large to test well (and then proceeded
to question my motivations). I'd like to think that a well-chosen subset would
be good enough, using some decent heuristics which could be developed by
looking at what broke in the past and for whom, in addition to some common
sense. We couldn't catch every error, but we could get a majority of typos.

Since this has been a widely unpopular idea in addition to the fact that it may
be more harmful than helpful in some cases, just forget I made the suggestion.