Re: [OT] Joerg Schilling flames Linux on his Blog

[Giuseppe Bilotta <bilotta78@hotpop.com>]

On Thu, 26 May 2005 09:45:01 +0600, Alexander E. Patrakov wrote:

> That list would be device-dependent. See two examples below.
> 
> 1) cdrecord uses some Sony proprietary commands instead of standard MMC ones 
> if the drive seems to be made by Sony. What is the effect of those Sony 
> commands on non-Sony drives?
> 
> 2) I have the following DVD-ROM + CD-RW combo drive:
> 
> 'PHILIPS ' 'CDD5301         ' 'P1.2'
> 
> Originally, I bought it with the 'B1.1' firmware revision. This drive with old 
> firmware is a security hole by itself: if one calls cdrecord dev=/dev/hdd 
> -dao some-image.iso, the drive will enter some strange mode at the end. In 
> particular, it will flash its light randomly, will never give the CD back 
> (waited 15 minutes), and will prevent communication with /dev/hdc until I 
> power off the computer (pressing Reset is not enough). Burning CDs with -raw 
> switch instead of -dao works. With newer firmware, -dao doesn't lock up the 
> drive, but still results in damaged CDs.
> 
> Also this drive always silently produces CDs with a lot of wrong bits (but a 
> useless and broken image can still be read with dd or readcd) when BurnFree 
> is off.
> 
> So this filter, if it is in the kernel, should forbid commands specific to SAO 
> burning for this drive _and_ also return a modified list of capabilities for 
> this drive (i.e. say that this drive _cannot_ burn in SAO mode).
> 
> Isn't this too much knowledge for the kernel?

Isn't this exactly the knowledge the kernel, not the apps, should
have? What if I wanted to use a different CD burning program? Why
should we have duplicate knowledge about the hardware?

Do you picture every PCI-accessing userland program to have its own
copy of pciids & relative knowledge?

-- 
Giuseppe "Oblomov" Bilotta

"I weep for our generation" -- Charlie Brown