On Tuesday 18 November 2003 06:56 am, Anarky wrote: > >So even though you intellectually know that it is not Mandrake'a fault, > > you are still blaming them? It's not a nice thing for hardware > > manufacturers to make things that break when standards compliant software > > tries to access them. > > > > okay ... this finally sounds like a good explanation ... one that I > imagined might be the truth: so mandrake coded acording to some aprooved > standard and LG didn't suport it? Was it something not-often used, or > how come it worked in windows?
Who says it didn't. Now that the problem was finally nailed down because of the Mandrake release, there are reports of this happening with SuSE, Gentoo and Windows too. A valid explanation is now had for what people thought at the time were just random hardware failures. >From what I understand, the problem arises when a software program tries to read the capabilities of the device. If the Windows software tested this in a different way than the Linux patch did, this does not change the fact that the drive firmware has a bug that should not be there. Besides, the statement "it works in windows" has no bearing on the quality of a piece of equipment. In fact, I think something that works in Windows but not in Linux is exactly the opposite of high quality. The manufacturer is simply hiding behind a windows device driver. In the present case, the kernel patch at issue used commands that are published in the ATAPI standards. LG decided that FLUCHE_CACHE should mean UPLOAD_FIRMWARE on their drives, so when the kernel patch issued the FLUSH_CACHE command, the drive firmware was overwritten. When the ATAPI standards define what those commands do, and the software author uses them as intended, how can you blame them when the hardware fails? -- /g "Outside of a dog, a man's best friend is a book, inside a dog it's too dark to read" -Groucho Marx
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
