[lkml]   [2005]   [May]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OT] Joerg Schilling flames Linux on his Blog
    On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
    > "Bodo Eggert <>"
    > <> 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 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?
    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

    >> (I'm running as user, and cdrecord has no need for suid bits.)
    > 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
    dead and useless (no burnproof), or slightly scarred and still
    useable (with
    burnproof). Personally, I'd rather have the latter.

    > In addition (with Linux- 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
    I suspect that if you provide a clear, concise list of harmless
    they would be included in the available command set.

    > 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.

    > 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
    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
    of other glitches in the CD surface.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-05-26 01:35    [W:0.025 / U:32.392 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site