lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: The big IDE fight in a different light
In <397877F4.30F7C81B@swiftview.com> Scott Long (scott@swiftview.com) wrote:
> 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.

Yeah. Good attempt. Replace one flamewar subject with different even
more flame-provocating one. Bright move :-/

> 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.

Thanx god, it's not true (yet). That's why kernel developers are STILL
not dropped linux BTW.

> At least, if you want to continue on this path of world domination.

"World domination" is just a joke. We are playing different game. Really
different.

> 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?

It's possible with 2.0, it's possible with 2.2, it's possible with 2.4,
it's possible with Windows 9X, it's possible with WindowsNT and Windows2000,
it's possible with FreeBSD and Solaris. There are NO way to fix HARDWARE
flaw with ANY software. Including ANY OS. If you are root (Administarator,
etc), you CAN FRY your disk, not matter "what and if". In Linux it's too
simple (and yes, I think it should be made more hard and Andrea suggested)
but there are no silver bullet.

> 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.

ALL OSes out there are susceptible. You can convert such code from linux
program to Windows .VxD or .SYS easily.

> We cannot afford data destruction, but even more importantly we CERTAINLY
> cannot afford having our disks physically destroyed.

Blame hardware manufacturers then. It's NOT Linux fault that current hardware
does not protected against software errors. Yes, it's stupid: instead of
few jumpers which can fix ALL such problem FOREVER companies are trying
binary-only programs for firmware upgrading and all such stupidity. Yes,
world it going to HUGE disaster really quickly but it's not Linux fault :-(

> 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.

"Hacker kids" can download needed program from web. It's as simple as it is.

> 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.

No. What IS matter is what's right and what's not.

> 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.

If they stupid enough to make such switch then I do not care.

> 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.

Go back to Microsoft NOW and stop whining. If (when?) linux kernel changes
will be made on "how to make it look better for dumb users out there" basis
linux DEVELOPERS will dump it. At least bright ones who do care about
clear design and not about marketing.

> 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.

Blackmail, heh ? You ALREADY have OS where a lot of stuff to make it more
appealing fo "mere users" was added (Windows). It sucks. Let's not try to
repeat this error.

> And I think other users feel the same. Keep that in mind.

No, thnx. If kernel developent will become marketing-driven we can drop linux
as well and start to hack *BSD, HURD or even something like EROS OS. Keep
THAT in mind.




-
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:57    [W:0.132 / U:0.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site