Messages in this thread | | | From | (Zygo Blaxell) | Subject | Re: Slashdot shitheads | Date | 15 May 1999 15:03:48 -0400 |
| |
In article <199905150035.UAA15919@furryterror.org>, Henning <hhv@hhv.de> wrote: >Zygo Blaxell wrote: >> Maybe some combination of those will suffice, or maybe put them all >> in along with a few others surrounded by a box of stars... > >Do it and be sure I'll write a script to automate commenting it out.
Well, then I don't see a problem.
Well, maybe there's a problem with the "all of them with a box of stars" suggestion. 80 characters of warning message is probably plenty.
>> It's really just a matter of appropriate labelling: the 2.3.x series is >> intended for kernel hackers, not non-hackers > >I'm not a kernel hacker, that is I'm a non-hacker. I'm not even >a C programmer. Neverthheless I've been using development kernels >ever since (that is, for years). Never encountered serious problems. >Also, I would never __complain__ if something goes wrong. It's my >risk and I'm not having any problems with that.
Again, I don't see a problem. On the other hand we have kernel revisions in the 2.1.xx series with warnings in the FTP archives that say "don't run this kernel or it will trash all your filesystems." It makes sense (to me at least) that from a consumer protection point of view, kernels at the most risk of this kind of problem should be labeled as such prior to release.
You of course remain free to alter or remove the warning as you see fit (as all users are). No armed men in dark suits will visit your home to force you to compile the warning into every binary.
>I'm constantly compiling every new release, every pre-release, And I'm >applying and testing lots of the patches on l-k. > >Sometimes things don't compile or a kernel compiles but boots segfaulting. >No problem. If I can't fix it myself and there are no fixes on l-k, >I simply wait for the next. No Prob. Some times I can fix it myself >(like 2.1.3-pre5 and 2.3.1) > >I'm always keeping thhe 16 last kernels. Be sure I know what I'm >doing. And, be sure, lots of other non-hackers too.
You seem to be establishing your qualifications as a kernel tester. I do not intend to drive away people such as yourself. I do intend to drive away people who would run an unstable kernel release without a backup, get all their precious data blown away, and then whine about "how awful Linux is" and "why doesn't it say that it's unstable then? I just downloaded the latest version and expected it to work" to SlashDot.
>Well I don't see any reason, why I shouldn't do what I do. And why >you should undertake the useless attempt to annoy people who are wil- >ling to test new stuff?
I think you are being too easily annoyed, possibly by the terminology in the text of the warning message rather than the idea of the warning message itself. As I said the first time, if you know better, you can just ignore the warning. I don't know what the precise text of the message should be. I was sort of hoping someone else would. ;-)
My experience with various MIS departments is that they like software to be labeled. They want Y2K statements and assurances that it works with this or that hardware. I don't see any reason why, if they knew that there was a difference at all, they would not want Linux kernels to be labeled stable vs. unstable. The 'odd minor revision number' rule isn't sufficient, because very few people outside of this mailing list actually know that the rule exists, and the rule isn't generally followed outside of the Linux kernel tree.
However, there are two problems with asserting that the kernel is a production kernel:
1. It's a lot harder to assert that software is useful for something and does not have bugs, than it is to assert that it might not be useful for anything and probably has bugs. It's possible to get into serious legal issues if one says something that can be disproved, or that would impose an express or implied obligation.
2. The absence of an assertion that something is untested and possibly dangerous unfortunately for many unsophisticated users implies that it _is_ tested and _not_ dangerous.
So for _unsophisticated_ users, I would prefer that an instability warning be attached to the unstable code instead of a stability assertion attached to stable code. Let commercial Linux vendors do the latter if they are prepared for the consequences.
-- Zygo Blaxell, Linux Engineer, Corel Corporation. zygob@corel.ca (work) or zblaxell@furryterror.org (play). Opinions above are my own, not Corel's. Linux mokona 2.2.2 #1 Mar 1 03:05 EST 1999 i586 up 14:24 Linux hysterical 2.0.35 #1 Aug 9 17:26 EDT 1998 i486 up 34 days, 21:39
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |