lkml.org 
[lkml]   [1999]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Slashdot shitheads
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:1.212 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site