lkml.org 
[lkml]   [2005]   [May]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: OT] Joerg Schilling flames Linux on his Blog
Kyle Moffett wrote:
> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
>
>> "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>"
>> <7eggert@gmx.de> 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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-26 21:23    [W:0.365 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site