Messages in this thread | | | Date | Mon, 29 Jul 1996 20:19:59 -0400 (EDT) | From | Brian Grunkemeyer <> | Subject | Re: This is really Ridiculous |
| |
> 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.
| |