Allen Kistler wrote:
Michael A. Peters wrote:
On 11/15/2004 08:45:54 AM, Kim Lux wrote:
Ouch: "Basically, what I'm saying is I fail to see where FC stands out
above other distributions that would make me want to use it. Granted,
after the general buginess I experienced with FC2, I may be biased,
but
the whole point is the fact that I wasn't having similar issues with
the
other distributions, so why should I have to put up with them with
FC?"
People who post stuff like that rarely can identify what their issue
was. Last *serious* redhat/fedora problem I can recall was the gcc 2.96
thing. Oh - and RH8 shipped with a gnome that would go crazy if you
made your panel go vertical or added a vertical drawer.
9 time out 10 when I have come across a seriously messed up system, I
find that the user has replaced half of the vendor supplied stuff with
3rd party (less or no QA) replacements, forced installed stuff opposed
to resolving dependencies, etc.
And of course - there are always the slashdot trolls - who post just to
get reactions.
See bug 123281 about flakey behavior with genuine SCSI drives with mixed
audio/data CDs.
In addition to the problem listed there, I've had highly variable
success with writing CDRs from kernel to kernel. I've got FC3 installed
on 2 different machines with completely different hardware (that *ouch*
works fine with that other OS and Roxio) -- Plextor CD & Plextor CDR,
Toshiba DVD & Teac CDR.
I suspect what happened is that IDE has overtaken SCSI so much that not
as much genuine SCSI testing occurs among kernel hackers.
Bad assumption. Lots of problems with this statement with regards to
Linux support of IDE and SCSI.
Perhaps some history around IDE would suffice?
http://64.233.167.104/search?q=cache:oCdiyzdLNfAJ:linas.org/linux/peeves.html+IDE+subsystem+sucks+in+Linux&hl=en
Despite what people would have you believe, SCSI isn't going away. I
read about SERIAL ATA blah blah better blah blah faster...
But that assumes the SCSI spec is standing still, which it is not.
SCSI is designed to be a complete I/O sub system unto itself, and it can
operate quite nicely without the CPU.
Serial ATA and IDE cannot do that, and are designed for cost/performance
curves akin to the desktop needs.
If you want to do big RELIABLE stuff, you are going to use SCSI in one
form or another to manage I/O.
Possibly even iSCSI if you want to have a PETABYTE storage
system...which is replacing Fibre Channel.
You also realize the physical MECHANISM of say a 250GB SCSI drive vs a
250GB IDE drive from the same manufacturer is NOT the same.
IBM makes lots of DESKSTAR IDE drives of the same capacity as thiner
SCSI models. When large amounts of Deskstars where failing, the SCSI
models didn't have such problems of equivalent storage capacity. The
reason is SCSI drives are designed and engineered for a vastly different
job than desktop drives.
http://www.tech-report.com/news_reply.x/3035/1/
For a desktop casual user it probably makes sense to go with a Serial
ATA or IDE drive.
But I think you are mixing in some assumptions about SCSI and IDE here
that are not correct in that IDE has overtaken SCSI, and what uses are
for either devices do not really correlate to bugs each driver system
contains nor does it suggest kernel developers are favoring one over the
other.
2.6 is still baking out the bugs and I don't think it is a correct view
to take that because this is so, IDE is overtaken SCSI. IDE has always
overtaken SCSI in sheer numbers, but to suggest less work or work is
dropping on the SCSI subsystem support for storage is a bit much.
I know modern
IDE is supposed to be SCSI in disguise (i.e., same command set), but
apparently there are some real world differences. kernel 2.6 introduced
"simplification" of the SCSI/IDE code, but perhaps a little too much got
simplified away.
Mmm, well I am not sure what you mean by Modern IDE.
Perhaps you mean:
http://www.acc.umu.se/~sagge/scsi_ide/
From a command set perspective, SCSI and IDE command set
implementations share pretty much nothing in common:
http://www.t10.org/scsi-3.htm
http://www.t13.org/#Links
Perhaps what you are referring to is the unification/IO API in the
kernel to treat for example all devices as SCSI devices.
Here is a overview of 2.6 for you to read along that lines among other
things about 2.6:
http://www-106.ibm.com/developerworks/library/l-inside.html?ca=dnt-438
Ever notice when you mount your USB drive it becomes posted as a SCSI
device?
If IDE is really truly gaining ground as you say, why are all storage
devices treated as SCSI devices...(I.E. USB, Firewire)
I wonder why they just didn't become another ATAPI device? (i.e. HDX
instead of SDXX)?
???
:-)
The current Nahant beta appears to be based on the work that went into
FC3. I'm not a RHEL tester, but I'm hoping RHEL testing exposes a wider
range of SCSI devices to the new kernel and shows up errors better than
FC2/3 (and kernel 2.5) testing did.
As for slashdot posting whether FC3 is worthwhile or not...why...
OF COURSE IT IS.....
:-)
-gc