Re: OT] Joerg Schilling flames Linux on his Blog

[Bill Davidsen]

Kyle Moffett wrote:
> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
>
> > "Bodo Eggert <harvested.in.lkml@xxxxxxxxxxxxxxxxxxxxxxxxxx>"  
> > <7eggert@xxxxxx> wrote:
> >
> > > I just burned a CD on my IDE-burner using mmc_cdr with cdrtools-2.01
> > > (the one without the hack) on a vanilla 2.6.11.10. I can even scan
> > > both my SCSI and IDE devices using -dev=ATAPI, but not without -dev.
> >
> >
> > The unability to give this kind of convenience to cdrecord users is  a 
> > result
> > of the refusal of the Linux kernel crew to include the kernel internal
> > device instance numbers in the ioctl structures I need to read.
>
>
> There is a specific reason that the numbers are _kernel_internal_!!!   I 
> set up
> my udev so that my green CD burner is /dev/green_burner, and my blue  CD 
> burner
> is /dev/blue_burner.  Please tell me again why exactly I can't just  
> give the
> option -dev=/dev/green_burner and have it use my green CD burner? 

You do realize that you can?

> That's a lot
> easier than messing with random groups of 3 numbers and trying to  
> remember in
> which order I plugged in my burners, and which kernel I'm running, so  I 
> can
> remember the enumeration order, etc.
>
> > Note that the fields are there but the information is intentionally  
> > obscured
> > for come of the calls just to make the life of cdrecord useers  harder 
> > :-(
>
>
> The information is obscured because userspace shouldn't know or care

So having you see the information to set up your udev is a good use and 
having Joerg use them is bad? If you want to have names mapped into 
"humanspace" why is program use bad? I agree numbers are ugly and 
confusing, but if I wanted someone to make those choices for me I'd run 
another o/s.

The "support is accidental" message pisses me off, because it isn't 
true. Code was added, I'm betting by design.
> > > (I'm running as user, and cdrecord has no need for suid bits.)

Which is fine if you have a system to dedicate to burning CDs. But on a 
loaded system Joerg is right, you get a better burn if you don't have 
the burnfree used. Like any other minor defect it may or may not bite 
you, a lot of them will measurably reduce your CD capacity, which 
actually will bite you if you are trying to use every last byte.
> > I am frequently reading false claims like this. Usually from people  who
> > do not have the needed SCSI background knowledge to understand that
> > SCSI is a protocol where commands frequently fail by intention in  
> > order to
> > propagate a state or a implementation level to the application.
>
>
> What exactly is false about the claim?
>
> > If you don't call cdrecord as root, you will not be able to lock in  
> > memory
> > and to raise priority in order to prevent buffer underuns.
>
>
> I burn CDs fine all the time as a user, and I _don't_ need to lock  
> memory or
> raise priority, because I have a good scheduler, plenty of RAM, and  
> dual CPUs.
> It would be nice if you could let me leave on the _hardware_ BurnProof
> technology designed to prevent that sort of thing, but it doesn't  
> appear to
> fit with your ideals of 100% perfect CDs, does it?  Besides, by the  
> time we
> hit the point where BurnProof would turn on, the disk is either  completely
> dead and useless (no burnproof), or slightly scarred and still  useable 
> (with
> burnproof).  Personally, I'd rather have the latter.

See above. It hasn't bitten you, therefore it doesn't bite... it's 
generally safe on a fast unloaded system.
> > In addition (with Linux-2.6.8.1 or newer) you will not be able to  
> > send some
> > of the important SCSI commands mainly related to newer CD or DVD  
> > drives. As
> > a result, cdrecord cannot write DVDs
>
>
> I was not under the impression that the free cdrecord could write DVDs.
>
> > or ultra speed CD-RWs or cannot do other things....
>
>
> Did you try submitting a list of important SCSI commands and their  
> functions?
> I suspect that if you provide a clear, concise list of harmless  commands,
> they would be included in the available command set.

Possibly true, didn't work for me.
> > Not true: if only R/W fd would be allowed, no non root program  could 
> > do that.
>
>
> Uhh, but I don't run cdrecord as root.  My /dev/green_burner device  is 
> owned
> by root, has group "media", and perms rw-rw-r--.  Since this is a  
> somewhat public
> machine with lots of users in the "media" group, I don't want anybody  
> to be able
> to turn my drives into bricks.

No argument with that.
> > See above, this false claim is a result of the fact that you miss  the 
> > background
> > knowledge on CD/DVD writing. Turning burnproof on degrades the  
> > quality of the
> > media and writing without burnproof but with the apropriate  
> > privilleges just
> > works fine.
>
>
> Why can't you just provide an option to leave it on?  My Mac and Windows
> computers seem to do just fine with it.  In fact, all modern CD-ROM  drives
> were designed to be able to read such "degraded" media, even "degraded"
> media that also has scratches and dents and dings and scars and all  sorts
> of other glitches in the CD surface.
There is an option if you would read the manpage. There are legitimate 
complaints, this doesn't seem to be one of them.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/