Ok. I don't work on the kernel, and I never post on this list. I do read
it however, and I've been a little unnerved by the enormous argument
between Andre and others over the past two days.
I've found that the best way to break up a fight isn't to try to
convince one side that the other side is correct. Instead, I try to
distract the combatants with a different issue. And this is my attempt
to do that.
I think the kernel people need to remember one very important thing: you
are no longer working for yourselves, as a hobby. Your ideals about what
Linux "should" be are no longer as relevant as they once were. You are
working for MILLIONS of users who put their faith in you and trust in
you. And it is their opinions that matter ultimately, not yours. At
least, if you want to continue on this path of world domination.
The discussion (or rather shit-flinging contest) seems to be centered
around the ability to physically fry an IDE disk. First of all, if this
is possible in 2.2, is it possible in 2.0? I will back up to a 2.0
kernel if not. If it is only possible in 2.4, then I WILL NOT UPGRADE TO
2.4. And no one in this office will, either. If all versions of Linux
are susceptible, maybe we'll look for a different OS where it is more
difficult to accomplish this damage. We cannot afford data destruction,
but even more importantly we CERTAINLY cannot afford having our disks
physically destroyed.
I understand the argument that if you are root, you can do anything you
want. But remember also that most hacker kids do not understand the full
potential of their root access. Most hacker kids cannot write ioctl()'s
that will do the damage you describe, MUCH LESS do the necessary
bit-banging. I believe it was an unfortunate decision on Andre's part to
publish these destructive sequences. I realize that it was his way to
try to coax the kernel people into accepting his argument, by giving the
hackers what they need to do this damage.
You may think my arguments make little logical sense. THAT DOESN'T
MATTER. It matters what I believe, not what you believe. I am the one
using the kernel in the real world, along with the millions of other
users who have about the same level of technical knowledge (perhaps less
-- I am, at least, a programmer and understand your discussion). If they
believe their OS could damage their disks, then they will switch to a
different OS REGARDLESS of stupid technical issues and technical points
made by people who are among the 0.01% of people who understand it. It
is unfortunate but as Linux becomes accepted into the mainstream, user
opinion will be dominated not by fact but by common schema. The
"correctness" of these schema is irrelevant. You, the kernel developers,
will have to go with the flow or risk being dumped. Users will sleep
better at night knowing that this sort of disk damage has been made more
difficult to accomplish. And that will be a selling point (not in a
literal sense obviously) for Linux.
So don't try to convince me that *I* am wrong by giving me technical
spew. It won't work. And it won't work for the many other users out
there. Make your decisions based on what the USERS will say, not on
technicalities. It's your ass on the line. We can always go back to
Microsoft if we want.
And so in conclusion, I, a "mere user," want this safeguard in the
kernel. If it's not there, I won't use the system. Period. BeOS is nice
too. A simple API, good threading, good SMP. Just what I need.
And I think other users feel the same. Keep that in mind.
Regards,
Scott
-
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/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:16 EST