RE: OT] Joerg Schilling flames Linux on his Blog

RE: OT] Joerg Schilling flames Linux on his Blog

[Lincoln Dale (ltd)]

> But what you claim is simply impossible.

wrong. again.

look up the man page for udev(8), pay particular attention to the part
that can tie devname into device serial number.
take note of the example shown under 'serial'.

> So let me sum up: Never rely on things that cannot be made 
> 100% unique in case you like to run security relevent 
> software like cdrecord.

LOL.

Re: OT] Joerg Schilling flames Linux on his Blog

[Toon van der Pas]

On Mon, May 30, 2005 at 05:19:43PM +0800, Lincoln Dale (ltd) wrote:
> > But what you claim is simply impossible.
> 
> wrong. again.
> 
> look up the man page for udev(8), pay particular attention to the part
> that can tie devname into device serial number.
> take note of the example shown under 'serial'.

These were my thoughts too.
But I just checked the entries in my sysfs tree for my CDRW drive,
and there is no serial number available...

Regards,
Toon.
-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Toon van der Pas <toon@hout.vanvergehaald.nl> wrote:

> > look up the man page for udev(8), pay particular attention to the part
> > that can tie devname into device serial number.
> > take note of the example shown under 'serial'.
>
> These were my thoughts too.
> But I just checked the entries in my sysfs tree for my CDRW drive,
> and there is no serial number available...

BTW: an implementation that uses something like Solaris does with
/etc/path_to_inst and puts USB serial numbers into the path_to_inst 
kernel instance database could come very close to the desired result 
and would give stable SCSI addresses too.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Kyle Moffett]

On May 30, 2005, at 08:26:43, Joerg Schilling wrote:
> Toon van der Pas <toon@hout.vanvergehaald.nl> wrote:
>
>
>>> look up the man page for udev(8), pay particular attention to the  
>>> part
>>> that can tie devname into device serial number.
>>> take note of the example shown under 'serial'.
>>>
>>
>> These were my thoughts too.
>> But I just checked the entries in my sysfs tree for my CDRW drive,
>> and there is no serial number available...
>>
>
> BTW: an implementation that uses something like Solaris does with
> /etc/path_to_inst and puts USB serial numbers into the path_to_inst
> kernel instance database could come very close to the desired result
> and would give stable SCSI addresses too.

But why fix what isn't broken?  I can tell all my other programs, from
dd to mount, that I want to use the udev-created /dev/green_burner, so
why do you indicate such usage is _deprecated_ in cdrecord?  For such
device nodes, a _filesystem_ is the preferred name=>number index, so
why add an extra strange file "just because Solaris does".

And why again do you need stable SCSI addresses for my _USB_ drive?



Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> > BTW: an implementation that uses something like Solaris does with
> > /etc/path_to_inst and puts USB serial numbers into the path_to_inst
> > kernel instance database could come very close to the desired result
> > and would give stable SCSI addresses too.
>
> But why fix what isn't broken?  I can tell all my other programs, from
> dd to mount, that I want to use the udev-created /dev/green_burner, so
> why do you indicate such usage is _deprecated_ in cdrecord?  For such
> device nodes, a _filesystem_ is the preferred name=>number index, so
> why add an extra strange file "just because Solaris does".

If you use /dev/ entries to directly address SCSI targets, then you 
are relying on on assumptions that cannot be granted everywhere.

Cdrecord is portable and this needs to implement a way that is portable 
and does not rely on nonportable assumptions like yours.


> And why again do you need stable SCSI addresses for my _USB_ drive?

Well if the udev program was polite to users, it would also support
to edit /etc/default/cdrecord...... 

... if it _really_ does wat you like with /dev/ links, then it has all 
the information that is needed to also maintain /etc/default/cdrecord



Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Terry Vernon]

#!/bin/bash
######################################################
##                              CampFire Song v0.1                     
               ##
##                                 by Terry Vernon                     
                  ##
##   This is dedicated to those who like to keeping pouring fuel    ##
##           on that stack of burning tires which is this thread...    
     ##
######################################################

#######decalre variable#######
drool='This stupid thread lives!'

####loop it forever and ever####
while [ "$drool" == 'This stupid thread lives!' ]; do
        echo "This is the thread that never ends!"
        echo "It goes on and on my friends!"
        echo "One day people starting reading it not knowing what it was!"
        echo "They kept on replying to it just because..."
        echo ""
    if [ "$drool" != 'This stupid thread lives!' ]; then
        echo "Finally people have stfu about redundant crap!"
    fi
#just for anticipation...
    sleep 1
done
    echo "It just faded off..."






Joerg Schilling wrote:

>Kyle Moffett <mrmacman_g4@mac.com> wrote:
>
>  
>
>>>BTW: an implementation that uses something like Solaris does with
>>>/etc/path_to_inst and puts USB serial numbers into the path_to_inst
>>>kernel instance database could come very close to the desired result
>>>and would give stable SCSI addresses too.
>>>      
>>>
>>But why fix what isn't broken?  I can tell all my other programs, from
>>dd to mount, that I want to use the udev-created /dev/green_burner, so
>>why do you indicate such usage is _deprecated_ in cdrecord?  For such
>>device nodes, a _filesystem_ is the preferred name=>number index, so
>>why add an extra strange file "just because Solaris does".
>>    
>>
>
>If you use /dev/ entries to directly address SCSI targets, then you 
>are relying on on assumptions that cannot be granted everywhere.
>
>Cdrecord is portable and this needs to implement a way that is portable 
>and does not rely on nonportable assumptions like yours.
>
>
>  
>
>>And why again do you need stable SCSI addresses for my _USB_ drive?
>>    
>>
>
>Well if the udev program was polite to users, it would also support
>to edit /etc/default/cdrecord...... 
>
>... if it _really_ does wat you like with /dev/ links, then it has all 
>the information that is needed to also maintain /etc/default/cdrecord
>
>
>
>Jörg
>
>  
>

Re: OT] Joerg Schilling flames Linux on his Blog

[Richard B. Johnson]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3378 bytes --]

On Tue, 31 May 2005, Joerg Schilling wrote:

> Kyle Moffett <mrmacman_g4@mac.com> wrote:
>
>>> BTW: an implementation that uses something like Solaris does with
>>> /etc/path_to_inst and puts USB serial numbers into the path_to_inst
>>> kernel instance database could come very close to the desired result
>>> and would give stable SCSI addresses too.
>>
>> But why fix what isn't broken?  I can tell all my other programs, from
>> dd to mount, that I want to use the udev-created /dev/green_burner, so
>> why do you indicate such usage is _deprecated_ in cdrecord?  For such
>> device nodes, a _filesystem_ is the preferred name=>number index, so
>> why add an extra strange file "just because Solaris does".
>
> If you use /dev/ entries to directly address SCSI targets, then you
> are relying on on assumptions that cannot be granted everywhere.
>
> Cdrecord is portable and this needs to implement a way that is portable
> and does not rely on nonportable assumptions like yours.
>

Portability is relative. It's normally handled with a wrapper.
If your software is to work on a Unix or Unix-like machine, a
claim to "portability" must mean that its interface on a Unix-
like machine is either through a virtual file in '/dev' or
through a socket. This is because these are the 'standards'
that we all have to live with whether we like then or not.

Your `cdrecord -scanbus` hack to find I,J,K numbers that the
rest of your code was written to use, probably took more
time to write than a Unix wrapper which would provide the
correct (for a Unix environment) interface semantics.

Administrators need to set up symbolic links for /dev/burner
or /dev/cdreader, etc., to help cut down nuisance complaints
from users who fail to write CDs on their CD readers. This
is the de-facto Unix way. We need 'devices' in /dev.

BYW I have used your software from its inception and it
always worked well in my SCSI environment. The best working
software in the universe will not receive due credit if
it doesn't meet user (and customer) expectations. If you
are still interested in improving your generous gift to
the Linux community, you should seriously consider writing
wrappers  to address portability issues.

>
>> And why again do you need stable SCSI addresses for my _USB_ drive?
>
> Well if the udev program was polite to users, it would also support
> to edit /etc/default/cdrecord......
>
> ... if it _really_ does wat you like with /dev/ links, then it has all
> the information that is needed to also maintain /etc/default/cdrecord
>
>
>
> Jörg
>
> -- 
> EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
>       js@cs.tu-berlin.de		(uni)
>       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
> URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
> -
> 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/
>

Cheers,
Dick Johnson
Penguin : Linux version 2.6.11.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by Dictator Bush.
                  98.36% of all statistics are fiction.

Re: OT] Joerg Schilling flames Linux on his Blog

[Gerd Knorr]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> If you use /dev/ entries to directly address SCSI targets, then you 
> are relying on on assumptions that cannot be granted everywhere.
>
> Cdrecord is portable and this needs to implement a way that is portable 
> and does not rely on nonportable assumptions like yours.

Not really.  Yes, it runs on different operating systems.  But to send
the SCSI commands to the device you have OS-specific code in there,
simply because it's handled in different ways on Solaris / Linux /
whatever OS.  You could make the device addressing OS-specific as well
instead of expecting everyone in the world follow the Solaris model,
that would make life a bit easier for everyone involved.

Addressing IDE devices (try to get a real SCSI burner these days)
using scsi host+target+lun is sort-of silly IMHO ...

  Gerd

Re: OT] Joerg Schilling flames Linux on his Blog

[Lennart Sorensen]

On Tue, May 31, 2005 at 06:59:01PM +0200, Gerd Knorr wrote:
> Not really.  Yes, it runs on different operating systems.  But to send
> the SCSI commands to the device you have OS-specific code in there,
> simply because it's handled in different ways on Solaris / Linux /
> whatever OS.  You could make the device addressing OS-specific as well
> instead of expecting everyone in the world follow the Solaris model,
> that would make life a bit easier for everyone involved.
> 
> Addressing IDE devices (try to get a real SCSI burner these days)
> using scsi host+target+lun is sort-of silly IMHO ...

Well I remember the first time I saw devfs running, I thought "Wow
finally I have a way to find the disc that is scsi id 3 on controller 0
even if I add a device at id 2 after setting up the system", something
most unix systems have always had, but linux made hard (you had to
somehow figure out which id mapped to which /dev/sd* entry, which from a
users perspective wasn't trivial, and of course keeping your fstab in
sync with the mapping was a pain).

I think sysfs can do it too, although I haven't looked to much at sysfs
yet.

For IDE devices the /dev entry always mapped to a specific device
(modulo your ide drivers loading in a consistant order, but scsi host
controller load order has the same issue).  Scsi just assigned /dev
entries in the order devices were discovered.  In some ways it is handy
to know your first scsi drive is sda if you are doing raid1 or something
and a drive dies, but on the other hand it is annoying that drives move
around if you add drives with a lower id than your existing drives.
Having both would be preferable.

I don't know if the ide or scsi method is currently more sane, but it
sure would be nice to have a consistent behaviour between the two.

Len Sorensen

Re: OT] Joerg Schilling flames Linux on his Blog

[Gerd Knorr]

  Hi,

> Well I remember the first time I saw devfs running, I thought "Wow
> finally I have a way to find the disc that is scsi id 3 on controller 0
> even if I add a device at id 2 after setting up the system", something

> I think sysfs can do it too, although I haven't looked to much at sysfs
> yet.

Yep, it can.

> I don't know if the ide or scsi method is currently more sane, but it
> sure would be nice to have a consistent behaviour between the two.

On my suse 9.3, out-of-the-box, I find this (implemented via
udev rules):

   # find /dev/cd /dev/disk -type l -print | sort
   /dev/cd/by-id/HL-DT-ST_DVDRAM_GSA-4040B_K213BDG5213
   /dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e
   /dev/cd/by-path/pci-0000:00:04.1-ide-1:0
   /dev/cd/by-path/pci-0000:00:04.1-ide-1:1
   /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751
   /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751p1
   [ ... ]
   /dev/disk/by-id/SIBM_DCAS-34330_B3GX3681
   /dev/disk/by-id/SIBM_DCAS-34330_B3GX3681p1
   /dev/disk/by-id/SIBM_DCAS-34330_B3GX3681p2
   /dev/disk/by-label/WIN98
   /dev/disk/by-label/unknown
   /dev/disk/by-path/pci-0000:00:04.1-ide-0:0
   /dev/disk/by-path/pci-0000:00:04.1-ide-0:0p1
   [ ... ]
   /dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0
   /dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0-generic
   /dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0p1
   /dev/disk/by-path/pci-0000:00:0e.0-scsi-0:0:0:0p2
   /dev/disk/by-uuid/3140-1206
   /dev/disk/by-uuid/5fbce796-2a1a-4ea3-bd5f-be35b28b2fb1
   /dev/disk/by-uuid/b6a45df7-63bb-4890-b5d2-7bdcbe6c70a5
   /dev/disk/by-uuid/cb367983-ac59-42cd-839d-b5cf0735fae5
   /dev/disk/by-uuid/unknown
 
You'll have stable names both by connection path (great for the
raid case) and by device name (useful for the usb burner which
you plug into a different port each time).  Guess you'll find
there what you are looking for ;)

  Gerd

-- 
export CDR_DEVICE=/dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Gerd Knorr <kraxel@suse.de> wrote:

> > I don't know if the ide or scsi method is currently more sane, but it
> > sure would be nice to have a consistent behaviour between the two.
>
> On my suse 9.3, out-of-the-box, I find this (implemented via
> udev rules):
>
>    # find /dev/cd /dev/disk -type l -print | sort
>    /dev/cd/by-id/HL-DT-ST_DVDRAM_GSA-4040B_K213BDG5213
>    /dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e
>    /dev/cd/by-path/pci-0000:00:04.1-ide-1:0
>    /dev/cd/by-path/pci-0000:00:04.1-ide-1:1
>    /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751
>    /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751p1

Nice, but will be the Linux /dev/ fashion next year?

>From my experiences it makes no sense to implement support
for things like this before waiting long enough to know 
whether this is something that will become ordinary.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Dagfinn Ilmari Mannsåker]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:

> Gerd Knorr <kraxel@suse.de> wrote:
>
>> > I don't know if the ide or scsi method is currently more sane, but it
>> > sure would be nice to have a consistent behaviour between the two.
>>
>> On my suse 9.3, out-of-the-box, I find this (implemented via
>> udev rules):
>>
>>    # find /dev/cd /dev/disk -type l -print | sort
>>    /dev/cd/by-id/HL-DT-ST_DVDRAM_GSA-4040B_K213BDG5213
>>    /dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e
>>    /dev/cd/by-path/pci-0000:00:04.1-ide-1:0
>>    /dev/cd/by-path/pci-0000:00:04.1-ide-1:1
>>    /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751
>>    /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751p1
>
> Nice, but will be the Linux /dev/ fashion next year?
>
> From my experiences it makes no sense to implement support
> for things like this before waiting long enough to know 
> whether this is something that will become ordinary.

You don't need to implement any special support for this. Just stop
whining about open by device node and let the user specify whichever
path to the same device she prefers.

-- 
ilmari

Re: OT] Joerg Schilling flames Linux on his Blog

[Gerd Knorr]

On Wed, Jun 01, 2005 at 05:56:20PM +0200, Joerg Schilling wrote:
> Gerd Knorr <kraxel@suse.de> wrote:
> 
> >    # find /dev/cd /dev/disk -type l -print | sort
> >    /dev/cd/by-id/HL-DT-ST_DVDRAM_GSA-4040B_K213BDG5213
> >    /dev/cd/by-id/LG_CD-RW_CED-8080B_2000_07_27e
> >    /dev/cd/by-path/pci-0000:00:04.1-ide-1:0
> >    /dev/cd/by-path/pci-0000:00:04.1-ide-1:1
> >    /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751
> >    /dev/disk/by-id/IBM-DTLA-305040_YJEYJM36751p1
> 
> Nice, but will be the Linux /dev/ fashion next year?

You simply shoudn't care.  Just open the /dev/whatever device
node passed by the user and be happy ;)

> >From my experiences it makes no sense to implement support
> for things like this before waiting long enough to know 
> whether this is something that will become ordinary.

I don't see what kind of special support you want implement in
cdrecord.  The user says "this device", cdrecord takes it and
opens it, tries a ioctl or two to figure what kind of device
handle that is (scsi generic or 2.6-style /dev/hdx), then uses
it to send scsi commands to the device.

You don't have to solve the problem of providing stable device
names within cdrecord.  That is the job of the operating system.
A udev-based linux distro can do that as you can see above.
cdrecord should just accept these device nodes, nothing more.

  Gerd

-- 
-mm seems unusually stable at present.
	-- akpm about 2.6.12-rc3-mm3

Re: OT] Joerg Schilling flames Linux on his Blog

[Horst von Brand]

Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:

[...]

> Well I remember the first time I saw devfs running, I thought "Wow
> finally I have a way to find the disc that is scsi id 3 on controller 0
> even if I add a device at id 2 after setting up the system", something
> most unix systems have always had, but linux made hard (you had to
> somehow figure out which id mapped to which /dev/sd* entry, which from a
> users perspective wasn't trivial, and of course keeping your fstab in
> sync with the mapping was a pain).

Why? Just use LABELs, ou UUIDs.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: OT] Joerg Schilling flames Linux on his Blog

[Lennart Sorensen]

On Tue, May 31, 2005 at 10:23:42PM -0400, Horst von Brand wrote:
> Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
> > Well I remember the first time I saw devfs running, I thought "Wow
> > finally I have a way to find the disc that is scsi id 3 on controller 0
> > even if I add a device at id 2 after setting up the system", something
> > most unix systems have always had, but linux made hard (you had to
> > somehow figure out which id mapped to which /dev/sd* entry, which from a
> > users perspective wasn't trivial, and of course keeping your fstab in
> > sync with the mapping was a pain).
> 
> Why? Just use LABELs, ou UUIDs.

Great if those worked on ALL filesystems, which to my knowledge they do
not.  Last time I tried to use labels to mount filesystems, I gave up on
it when I discovered swap didn't support it.  I haven't bothered with
them since.

Len Sorensen

Re: OT] Joerg Schilling flames Linux on his Blog

[Theodore Ts'o]

On Wed, Jun 01, 2005 at 11:56:29AM -0400, Lennart Sorensen wrote:
> > Why? Just use LABELs, ou UUIDs.
> 
> Great if those worked on ALL filesystems, which to my knowledge they do
> not.  Last time I tried to use labels to mount filesystems, I gave up on
> it when I discovered swap didn't support it.  I haven't bothered with
> them since.

While filesystems do you need?  Most filesystems actually do have
LABELs or UUID's, including FAT, VFAT, iso9660, ext2/3, reiserfs, xfs,
etc.  OK, xiafs doesn't have labels or uuid's, but it was removed from
the Linux tree before 2.4 shipped!

						- Ted

Re: OT] Joerg Schilling flames Linux on his Blog

[Oliver Neukum]

Am Mittwoch, 1. Juni 2005 04:23 schrieb Horst von Brand:
> Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote:
> 
> [...]
> 
> > Well I remember the first time I saw devfs running, I thought "Wow
> > finally I have a way to find the disc that is scsi id 3 on controller 0
> > even if I add a device at id 2 after setting up the system", something
> > most unix systems have always had, but linux made hard (you had to
> > somehow figure out which id mapped to which /dev/sd* entry, which from a
> > users perspective wasn't trivial, and of course keeping your fstab in
> > sync with the mapping was a pain).
> 
> Why? Just use LABELs, ou UUIDs.

For burning a CD? A label is hardly practical and UUIDs are rare. Sometimes
addressing the medium won't do and you need the device.

	Regards
		Oliver

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

lsorense@csclub.uwaterloo.ca (Lennart Sorensen) wrote:

> > Addressing IDE devices (try to get a real SCSI burner these days)
> > using scsi host+target+lun is sort-of silly IMHO ...
>
> Well I remember the first time I saw devfs running, I thought "Wow
> finally I have a way to find the disc that is scsi id 3 on controller 0
> even if I add a device at id 2 after setting up the system", something
> most unix systems have always had, but linux made hard (you had to
> somehow figure out which id mapped to which /dev/sd* entry, which from a
> users perspective wasn't trivial, and of course keeping your fstab in
> sync with the mapping was a pain).

What you explain is exactly the reason, why libscg maps the /dev/ names
to something stable.

Then some people claimed that there was a new way in Linux but I could
not find a machine running this stuff.....

When I checked again, this still had not become "standard" on Linux
but I got the impression that somebody was developing a new system.
So I gave up.

If someone will develop a useful system that eventually appears as
a standard on all Linux systems it may make sende to add support into
libscg.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Gerd Knorr <kraxel@suse.de> wrote:

> Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
>
> > If you use /dev/ entries to directly address SCSI targets, then you 
> > are relying on on assumptions that cannot be granted everywhere.
> >
> > Cdrecord is portable and this needs to implement a way that is portable 
> > and does not rely on nonportable assumptions like yours.
>
> Not really.  Yes, it runs on different operating systems.  But to send
> the SCSI commands to the device you have OS-specific code in there,
> simply because it's handled in different ways on Solaris / Linux /
> whatever OS.  You could make the device addressing OS-specific as well
> instead of expecting everyone in the world follow the Solaris model,
> that would make life a bit easier for everyone involved.

This is not the Solaris model....

I did define this model 19 years ago when I did write the first 
Generic SCSI driver at all. Adaptec indepentently did develop ASPI
2 years later and did chose the same address model. Nearly all
OS use this kind (or a very similar model) internaly inside the kernel
or the basic SCSI address routines.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Jim Crilly]

On 06/01/05 05:11:50PM +0200, Joerg Schilling wrote:
> > Not really.  Yes, it runs on different operating systems.  But to send
> > the SCSI commands to the device you have OS-specific code in there,
> > simply because it's handled in different ways on Solaris / Linux /
> > whatever OS.  You could make the device addressing OS-specific as well
> > instead of expecting everyone in the world follow the Solaris model,
> > that would make life a bit easier for everyone involved.
> 
> This is not the Solaris model....
> 
> I did define this model 19 years ago when I did write the first 
> Generic SCSI driver at all. Adaptec indepentently did develop ASPI
> 2 years later and did chose the same address model. Nearly all
> OS use this kind (or a very similar model) internaly inside the kernel
> or the basic SCSI address routines.

Just because it's old, that doesn't mean it's good. The kernel using the
numbers internally makes sense, but requiring them for userspace seems
stupid. All you should do is open the appropriate device node and let the
kernel figure out which SCSI ID to send the commands to. Every other tool
I've ever seen uses device nodes, why should cdrecord be different? All it
does is make cdrecord more difficult to use.

> 
> Jörg
> 

Jim.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> > I did define this model 19 years ago when I did write the first 
> > Generic SCSI driver at all. Adaptec indepentently did develop ASPI
> > 2 years later and did chose the same address model. Nearly all
> > OS use this kind (or a very similar model) internaly inside the kernel
> > or the basic SCSI address routines.
>
> Just because it's old, that doesn't mean it's good. The kernel using the

Just because it is old, it does not mean that it is bad....

It is the only interface that did not need to be modified since then.
The current driver interface is still 100% binary compatible to the
one I made in August 1986.

> numbers internally makes sense, but requiring them for userspace seems
> stupid. All you should do is open the appropriate device node and let the
> kernel figure out which SCSI ID to send the commands to. Every other tool
> I've ever seen uses device nodes, why should cdrecord be different? All it
> does is make cdrecord more difficult to use.

Note that Linux did not have a usable /dev/whatever based interface 10 years ago.
Also note that cdda2wav distinguishes between "OS native Audio ioctl calls" and
generic SCSI from checking the dev= parameter. For this reason using 
/dev/whateter is just wrong. Take it this way or you are a victim of you own 
decision to ignore the documentation of a program.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Jim Crilly]

On 06/01/05 06:55:16PM +0200, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> >
> > Just because it's old, that doesn't mean it's good. The kernel using the
> 
> Just because it is old, it does not mean that it is bad....

Agreed and AFAIK most unix users prefer to use filenames to access their
devices. Why bother populating /dev at all if half if your apps require
random ID numbers to use them?

> > numbers internally makes sense, but requiring them for userspace seems
> > stupid. All you should do is open the appropriate device node and let the
> > kernel figure out which SCSI ID to send the commands to. Every other tool
> > I've ever seen uses device nodes, why should cdrecord be different? All it
> > does is make cdrecord more difficult to use.
> 
> Note that Linux did not have a usable /dev/whatever based interface 10 years ago.
> Also note that cdda2wav distinguishes between "OS native Audio ioctl calls" and
> generic SCSI from checking the dev= parameter. For this reason using 
> /dev/whateter is just wrong. Take it this way or you are a victim of you own 
> decision to ignore the documentation of a program.

I don't use cdda2wav so I can't comment, but every other ripping tool that
I've used on Linux has had no problem using the /dev/whatever interface, so
once again it appears that your tool is the blacksheep for no good reason.

> 
> Jörg
>

Jim.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> I don't use cdda2wav so I can't comment, but every other ripping tool that
> I've used on Linux has had no problem using the /dev/whatever interface, so
> once again it appears that your tool is the blacksheep for no good reason.

You should use it as it is even used by people on Win32 because it is the
best DAE program for even badly readable sources.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Jim Crilly]

On 06/01/05 07:50:57PM +0200, Joerg Schilling wrote:
> "Jim Crilly" <jim@why.dont.jablowme.net> wrote:
> 
> > I don't use cdda2wav so I can't comment, but every other ripping tool that
> > I've used on Linux has had no problem using the /dev/whatever interface, so
> > once again it appears that your tool is the blacksheep for no good reason.
> 
> You should use it as it is even used by people on Win32 because it is the
> best DAE program for even badly readable sources.

I'm not an audiophile, I can't tell the difference between a mp3 encoded at
128k and one encoded at 160k so I really doubt I could tell the difference
between what cdda2wav and what most other DAE programs would produce. So
given that the quality of the rips will be effectively equal to my ears,
I'll use whatever's most convenient.

> 
> Jörg
> 

Jim.

Re: OT] Joerg Schilling flames Linux on his Blog

[Bill Davidsen]

Jim Crilly wrote:
> On 06/01/05 07:50:57PM +0200, Joerg Schilling wrote:
> 
>>"Jim Crilly" <jim@why.dont.jablowme.net> wrote:
>>
>>
>>>I don't use cdda2wav so I can't comment, but every other ripping tool that
>>>I've used on Linux has had no problem using the /dev/whatever interface, so
>>>once again it appears that your tool is the blacksheep for no good reason.
>>
>>You should use it as it is even used by people on Win32 because it is the
>>best DAE program for even badly readable sources.
> 
> 
> I'm not an audiophile, I can't tell the difference between a mp3 encoded at
> 128k and one encoded at 160k so I really doubt I could tell the difference
> between what cdda2wav and what most other DAE programs would produce. So
> given that the quality of the rips will be effectively equal to my ears,
> I'll use whatever's most convenient.

The "quality" or fidelity isn't the issue here, but rather the rip being 
deterministic and producing the same (as as often as possible, correct) 
data. Joerg used the "paranoia" library to do the ripping validation, 
and I'm unconvinced that there is anything better in that regard.

The device names are totally another issue, which I'm not ready to drag 
around the block yet again.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: OT] Joerg Schilling flames Linux on his Blog

[Måns Rullgård]

Bill Davidsen <davidsen@tmr.com> writes:

> Jim Crilly wrote:
>> On 06/01/05 07:50:57PM +0200, Joerg Schilling wrote:
>>
>>>"Jim Crilly" <jim@why.dont.jablowme.net> wrote:
>>>
>>>
>>>>I don't use cdda2wav so I can't comment, but every other ripping tool that
>>>>I've used on Linux has had no problem using the /dev/whatever interface, so
>>>>once again it appears that your tool is the blacksheep for no good reason.
>>>
>>>You should use it as it is even used by people on Win32 because it is the
>>>best DAE program for even badly readable sources.
>> I'm not an audiophile, I can't tell the difference between a mp3
>> encoded at
>> 128k and one encoded at 160k so I really doubt I could tell the difference
>> between what cdda2wav and what most other DAE programs would produce. So
>> given that the quality of the rips will be effectively equal to my ears,
>> I'll use whatever's most convenient.
>
> The "quality" or fidelity isn't the issue here, but rather the rip
> being deterministic and producing the same (as as often as possible,
> correct) data. Joerg used the "paranoia" library to do the ripping
> validation, and I'm unconvinced that there is anything better in that
> regard.

So any program that uses that library would produce equally good
results, no?  The paranoia library was written by monty@xiph.org, whos
real name I can't find, but which I have reason to believe is not an
alias for Mr. Schilling.

-- 
Måns Rullgård
mru@inprovide.com

Re: OT] Joerg Schilling flames Linux on his Blog

[Bill Davidsen]

Jim Crilly wrote:

> I'm not an audiophile, I can't tell the difference between a mp3 encoded at
> 128k and one encoded at 160k so I really doubt I could tell the difference
> between what cdda2wav and what most other DAE programs would produce. So
> given that the quality of the rips will be effectively equal to my ears,
> I'll use whatever's most convenient.

Apologies for continuing in a separate post, I seem to have had and did 
a send before I was ready.

The reason I use cdrecord is just what you say, convenience. I have 
written tons of scripts over the years to use it, and perl programs to 
prepare it's input and commands, and I have no reason to change because 
it whines at me when I say /dev/hde instead of 2,0,1 or whatever. It's 
in a config file, I only need to see it once, so I don't care.

Joerg gave us a working program when cdwrite died, he keeps it up to 
date, and I'm happy with it still. I wish he would learn to "play well 
with others," but he doesn't CARE if users like the interface, and he 
possibly keeps the ProDVD closed source just to piss people off. He's 
smart enough to know that contributions work better than closed source, 
he just doesn't care to change his policy. His choice.

-- 
bill davidsen <davidsen@tmr.com>
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979

Re: OT] Joerg Schilling flames Linux on his Blog

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

On Wednesday 01 June 2005 01:50 pm, Joerg Schilling wrote:
> You should use it as it is even used by people on Win32 because it is the
> best DAE program for even badly readable sources.

KISS theology tends to break down after the declaration of Gene Simmons being 
God.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OT] Joerg Schilling flames Linux on his Blog

[Matthias Andree]

Joerg Schilling schrieb am 2005-06-01:

> Note that Linux did not have a usable /dev/whatever based interface 10 years ago.
> Also note that cdda2wav distinguishes between "OS native Audio ioctl calls" and
> generic SCSI from checking the dev= parameter. For this reason using 
> /dev/whateter is just wrong.

Now this is an implementation detail of your application, and the OS
abstraction inside your application might well use a smarter way of
figuring out if it's a SCSI interface or not.

-- 
Matthias Andree

Re: OT] Joerg Schilling flames Linux on his Blog

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Wednesday 01 June 2005 11:11 am, Joerg Schilling wrote:
> I did define this model 19 years ago when I did write the first
> Generic SCSI driver at all. Adaptec indepentently did develop ASPI
> 2 years later and did chose the same address model. Nearly all
> OS use this kind (or a very similar model) internaly inside the kernel
> or the basic SCSI address routines.

That doesn't mean its the right model. Infact, for being 20 years old /and/ 
the first, it stands to be the absolutely worst model. Linus and crew have 
every right to do something new.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OT] Joerg Schilling flames Linux on his Blog

[Jim Crilly]

On 05/31/05 01:03:31PM +0200, Joerg Schilling wrote:
> 
> > And why again do you need stable SCSI addresses for my _USB_ drive?
> 
> Well if the udev program was polite to users, it would also support
> to edit /etc/default/cdrecord...... 
> 
> ... if it _really_ does wat you like with /dev/ links, then it has all 
> the information that is needed to also maintain /etc/default/cdrecord

The rules and scripts that udev uses to name things can do anything since
it runs in userland, so udev could easily edit /etc/default/cdrecord if
someone took the time to write the script.

Jim.

Re: OT] Joerg Schilling flames Linux on his Blog

[Dmitry Torokhov]

On 5/31/05, Jim Crilly <jim@why.dont.jablowme.net> wrote:
> On 05/31/05 01:03:31PM +0200, Joerg Schilling wrote:
> >
> > > And why again do you need stable SCSI addresses for my _USB_ drive?
> >
> > Well if the udev program was polite to users, it would also support
> > to edit /etc/default/cdrecord......
> >
> > ... if it _really_ does wat you like with /dev/ links, then it has all
> > the information that is needed to also maintain /etc/default/cdrecord
> 
> The rules and scripts that udev uses to name things can do anything since
> it runs in userland, so udev could easily edit /etc/default/cdrecord if
> someone took the time to write the script.
> 

Yes it could but why should it? The purpose of udev is to maintain
dynamic /dev. Do you want to have thoustands quirks in udev to cope
with bazillion configuration files for utilities whose authors refuse
to adopt standard naming convention [for the operating system in
question].

I do not understand why Joerg is so fixed on presenting SCSI interface
to userspace. Why when I mount just burned CD I can use /dev/scd0 but
for writing it I should say dev=5,4,0?? I do not really care that
internally X,Y,Z might or might not used, they should not be exposed
to userspace, especially since days when they could be used for static
device identification are long gone.

-- 
Dmitry

Re: OT] Joerg Schilling flames Linux on his Blog

[Jim Crilly]

On 05/31/05 02:28:16PM -0500, Dmitry Torokhov wrote:
> Yes it could but why should it? The purpose of udev is to maintain
> dynamic /dev. Do you want to have thoustands quirks in udev to cope
> with bazillion configuration files for utilities whose authors refuse
> to adopt standard naming convention [for the operating system in
> question].

I didn't say it was a good idea, just that it was possible to do what he
wants.

> 
> I do not understand why Joerg is so fixed on presenting SCSI interface
> to userspace. Why when I mount just burned CD I can use /dev/scd0 but
> for writing it I should say dev=5,4,0?? I do not really care that
> internally X,Y,Z might or might not used, they should not be exposed
> to userspace, especially since days when they could be used for static
> device identification are long gone.

I totally agree, whenever I use cdrecord I use dev=/dev/whatever and will
continue to do so until it no longer works. But if that ever happens I
would hope another tool would take it's place. And contrary to what he
believes I also burned as a non-root user so it wasn't able to set itself
to rt or mlock itself into memory and I've never burned a coaster that I
could blame on either case even on my slowest machines.

> -- 
> Dmitry

Jim.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> Yes it could but why should it? The purpose of udev is to maintain
> dynamic /dev. Do you want to have thoustands quirks in udev to cope
> with bazillion configuration files for utilities whose authors refuse
> to adopt standard naming convention [for the operating system in
> question].

You show exactly the habbit that makes me unwiling to believe it makes
sense to put effort into anything in Linux that is not at least 5 years old.

10 Years ago, Linux was completely unsuable with Linux /dev/sg* naming 
and mapping conventions. After I did develop an abstraction layer that
made Linux usable people could use stable dev= parameters across
reboots of Linux.

Then somebody started to implement a way to make linux more sane with /dev/
but this method has been replaced before it did become ordinary.

Think again what you like to tell me here.... You like to tell me
cdrecord is one of thousands of bad programs but it is the first
program that introduced stability at command line level if talking about
generic SCSI usage. 

If somebody later develops something like udev (did not see it yet)
I would asume that this person would look at earlyer stable software and
provide some way of integration.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Dmitry Torokhov]

On 6/1/05, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > Yes it could but why should it? The purpose of udev is to maintain
> > dynamic /dev. Do you want to have thoustands quirks in udev to cope
> > with bazillion configuration files for utilities whose authors refuse
> > to adopt standard naming convention [for the operating system in
> > question].
> 
> You show exactly the habbit that makes me unwiling to believe it makes
> sense to put effort into anything in Linux that is not at least 5 years old.
> 
> 10 Years ago, Linux was completely unsuable with Linux /dev/sg* naming
^^^^^^^^^^^^^^^^^^
> and mapping conventions. After I did develop an abstraction layer that
> made Linux usable people could use stable dev= parameters across
> reboots of Linux.

Joerg, that is the problem. It was 10 years ago. USB was not existant,
Firewire wasn't there, FC, etc. You could rely on your naming then.
But it was last millenium, now dev= parameters are anything but
stable. It just does not cut anymore, while using device node to
specify device you want to work with is natural. And I am willing to
bet if you give this oprion to users of other Unix-like OSes they
would not complain either.

-- 
Dmitry

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > 10 Years ago, Linux was completely unsuable with Linux /dev/sg* naming
> ^^^^^^^^^^^^^^^^^^
> > and mapping conventions. After I did develop an abstraction layer that
> > made Linux usable people could use stable dev= parameters across
> > reboots of Linux.
>
> Joerg, that is the problem. It was 10 years ago. USB was not existant,
> Firewire wasn't there, FC, etc. You could rely on your naming then.
> But it was last millenium, now dev= parameters are anything but
> stable. It just does not cut anymore, while using device node to
> specify device you want to work with is natural. And I am willing to
> bet if you give this oprion to users of other Unix-like OSes they
> would not complain either.

There is still no new and definitely stable interface that allows me to
asume that it makes sense to put effort in implementing support for it.

The natural way to access SCSI is the method I use, ASPI uses and FreeBSD
uses..... If Linux likes to implement things differntly, they are free
to do so but the Linux authors need to learn that I don't like to spend my
time on somethign that might be useless next week. Also note that the fact that
the Linux kernel by intention hides information I like to see from interfaces that 
the Linux kernel authors like me to use makes it obvious that there is
no mind on a useful cooperation with me.

For me it makes sense to wait until I see that this attitide did change.

I am still interested in cooperation, but this needs to be done in a way that
does not start with calling me a novice programmer....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Chris Friesen]

Joerg Schilling wrote:

> There is still no new and definitely stable interface that allows me to
> asume that it makes sense to put effort in implementing support for it.

Why not just accept *any* device node that the user passes in?

I fail to see why it matters what the device name is as long as it 
accepts the required ioctl() commands.

Chris

Re: OT] Joerg Schilling flames Linux on his Blog

[Måns Rullgård]

Chris Friesen <cfriesen@nortel.com> writes:

> Joerg Schilling wrote:
>
>> There is still no new and definitely stable interface that allows me to
>> asume that it makes sense to put effort in implementing support for it.
>
> Why not just accept *any* device node that the user passes in?

That's the question I think we're all asking.  The answer is that
cdrecord *already* does this.

In my understanding there are three basic parts involved here: 1) SCSI
commands, and the devices that use them, 2) low-level
addressing/transport used by the OS to deliver SCSI commands to the
devices, and 3) high-level addressing used by userland when talking to
the OS.  2 can be more or less anything: traditional b/t/l SCSI,
ATAPI, parport, USB, etc, each with it's own unique addressing style.
3 is what applications should be using, and varies across OSes, Unix
systems using device nodes, others using other methods I do not know.
Through a thorough misunderstanding of the word "portable",
Mr. Schilling appears to be attempting to forcibly extend one
particular incarnation of 2 to also cover 3.

FWIW, I run cdrecord using dev=/dev/cdrw as a regular user, without
any suid bits, and close my eyes while the warnings scroll by.  Using
a small window and the -v flag, they're out of sight before you know
it.  I have yet to burn a coaster not resulting from bad media or
hardware, even on loaded systems, over NFS, or whatnot.

-- 
Måns Rullgård
mru@inprovide.com

Re: OT] Joerg Schilling flames Linux on his Blog

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 861 bytes --]

On Wednesday 01 June 2005 01:03 pm, Joerg Schilling wrote:
> If Linux likes to implement things differntly, they are free
> to do so but the Linux authors need to learn that I don't like to spend my
> time on somethign that might be useless next week.

Holy what the fuck, Batman?! I could very well argue 
that /dev/sd/crackrock/ahoy/ or whatever Solaris traditionally uses is 
equally as bad. At least with Linux's current method, a) people (other than 
you) are happy, b) people are finding it useful, c) it works well with udev.

LKML: 1, Joerg: 0.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OT] Joerg Schilling flames Linux on his Blog

[Lukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

Joerg Schilling napisał(a):

> The natural way to access SCSI is the method I use, ASPI uses and FreeBSD
> uses..... If Linux likes to implement things differntly, they are free
> to do so but the Linux authors need to learn that I don't like to spend my
> time on somethign that might be useless next week.

This will be my next 2 cents.

The *natural* way to access any device is its device file in the /dev/
directory.

I've "straced" cdrecrod few times when it coundn't do scnabus properly.
What I have discovered is that cdrecord *just* tries to open several
devices that *might* be recorders. There is no need to use USB for this
to fail. For example if I had /dev/hda HDD and /dev/hdc CDR (no one
attaches both on one channel) cdrecord stopped as it faild to open hdb
while ther was no such file. Do I have to create device file if I ve got
no device?

The only thing we all ask is to make it possible to choose manually the
device node cdrecord is trying to detect. That is a 'mechanism not
polisy' thing. Let the other software insure the stabilit of naming.

Best regards.
-- 
Było mi bardzo miło.                    Trzecia pospolita klęska, [...]
>Łukasz<                      Już nie katolicka lecz złodziejska.  (c)PP


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: OT] Joerg Schilling flames Linux on his Blog

[Matthias Andree]

Joerg Schilling wrote:

> Think again what you like to tell me here.... You like to tell me
> cdrecord is one of thousands of bad programs but it is the first
> program that introduced stability at command line level if talking about
> generic SCSI usage. 
> 
> If somebody later develops something like udev (did not see it yet)
> I would asume that this person would look at earlyer stable software and
> provide some way of integration.

Heck. The whole issue is that cdrecord is unjustly complaining when it
is given a device node that is perfect. For my 2.6.11 system, /dev/hdd
(ATAPI hardware, ide-cd device) is as stable as it will get, yet
cdrecord complains and attempts to coerce some numbering scheme that
Linux isn't offering through /dev/*. Same story with FreeBSD, I need to
figure out some intransparent ATAPI transport identifier rather than
just using /dev/acd0.

So your first step to pull the rug from underneath most of this
discussion is just to disable this unnecessary warning for the ATA:
interface, whether it is

	Warning: Open by 'devname' is unintentional and not supported.

or

	Warning: Using badly designed ATAPI via /dev/hd* interface.

This is your personal vendetta against Linux device naming or numbering,
 hence policy, and not a technical reason to complain. Particularly, if
cdrecord can use the device node, it MUST not print a warning, if you
think it's intentional or not.

Please remove these two warnings and you'll see a considerable part of
the discussion end.

ATAPI: is a different story, if the device doesn't support DMA (ide-scsi
bugs), that's a serious reason to avoid it, and the warning is justified.

-- 
Matthias Andree

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Matthias Andree <matthias.andree@gmx.de> wrote:

> Heck. The whole issue is that cdrecord is unjustly complaining when it
> is given a device node that is perfect. For my 2.6.11 system, /dev/hdd
> (ATAPI hardware, ide-cd device) is as stable as it will get, yet
> cdrecord complains and attempts to coerce some numbering scheme that
> Linux isn't offering through /dev/*. Same story with FreeBSD, I need to
> figure out some intransparent ATAPI transport identifier rather than
> just using /dev/acd0.

Looks like you need to take a closer look at FreeBSD. Cdrecord 
implements a completely _native_ interface to the FreeBSD SCSI drivers.
Cdrecord uses _exaclty_ the official way of addressing which is
(you may wonder) identical to what my SCSI libraries did since
August 1986 and what many other OS use too.

Also note that this interface is SCSI standard compliant (check the CAM
standard). Also note that the libscg interface to FreeBSD has been implemented
in close collaboration between me and the author of the FreBSD SCSI
subsystem. There was never even a slight wish for having a different
interface than the one that is used by libscg on FreeBSD.

And yes, in former times the implementor of ATAPI on FreeBSD made similar
mistakes as have been made on Linux. He did even write a kernel based 
CD writing driver but people did like to do things that have not been
implemented by his driver but by cdrecord (like writing CDs in RAW
mode or writing DVDs). It even turned eventually out that he did 
secretly sell a modified version of cdrecord to his customers that
did use a secret SCSI pass though interface in his driver, but the
patch he made to cdrecord was ugly (like smashing the window to get
into the house although the door nearby was wide open...).

Then someone from France take some time and implemented an 
ATPAI-CAM module that now is the standard on FreeBSD.



> So your first step to pull the rug from underneath most of this
> discussion is just to disable this unnecessary warning for the ATA:
> interface, whether it is
>
> 	Warning: Open by 'devname' is unintentional and not supported.
>
> or
>
> 	Warning: Using badly designed ATAPI via /dev/hd* interface.

First a note: using /dev/* _is_ wrong because using /dev/* is a way to
tell cdda2wav to switch to the Audio ioctl based interface wich gives
bad DAE quality compeared to the method that uses SCSI pass though.

-	dev=/dev/* uses an interface with driver abstraction

-	dev=b,t,l uses the Generic SCSI interfcace

Take this as a fact that has been true for a long long time and definitely
predates recent Linux interface changes.


> This is your personal vendetta against Linux device naming or numbering,
>  hence policy, and not a technical reason to complain. Particularly, if
> cdrecord can use the device node, it MUST not print a warning, if you
> think it's intentional or not.

Wrong, this is a result of the fact that the Linux kernel by intention
and unneccesarily hides useful information that is of course available in
different interfaces like e.g. /proc. So what Linux does is a bump against
me and what you see is just a "passive" reaction.


> Please remove these two warnings and you'll see a considerable part of
> the discussion end.

What you see is a "passive" reaction on thrusts agianst me. At the first time,
I see a minimal kind of willinglness to cooperate, things could go completely
different...

Well, this is the first useful and non-personal thread on LKML I did ever see,
so I am in hope something may change.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Jim Crilly" <jim@why.dont.jablowme.net> wrote:

> On 05/31/05 01:03:31PM +0200, Joerg Schilling wrote:
> > 
> > > And why again do you need stable SCSI addresses for my _USB_ drive?
> > 
> > Well if the udev program was polite to users, it would also support
> > to edit /etc/default/cdrecord...... 
> > 
> > ... if it _really_ does wat you like with /dev/ links, then it has all 
> > the information that is needed to also maintain /etc/default/cdrecord
>
> The rules and scripts that udev uses to name things can do anything since
> it runs in userland, so udev could easily edit /etc/default/cdrecord if
> someone took the time to write the script.

If it has the knowledge and if it is able to run parameterized sed from 
internal rules, it should be possible to configure udev to 
modify /etc/default/cdrecord, but as I don't have such a system, it would
be nice if this was done by someone else.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Jim Crilly]

On 06/01/05 05:28:50PM +0200, Joerg Schilling wrote:
> > The rules and scripts that udev uses to name things can do anything since
> > it runs in userland, so udev could easily edit /etc/default/cdrecord if
> > someone took the time to write the script.
> 
> If it has the knowledge and if it is able to run parameterized sed from 
> internal rules, it should be possible to configure udev to 
> modify /etc/default/cdrecord, but as I don't have such a system, it would
> be nice if this was done by someone else.

I doubt anyone would want to do that, as soon as a script for cdrecord
gets submitted people will start submitting scripts for other tools and I
really doubt the udev maintainer has the resources or desire to maintain
dozens of scripts for tools that he doesn't use. If such scripts were to be
written they would most likely have to be maintained either by the upstream 
author or by a package maintainer for a particular distribution that wants 
to hack around the lack of Linux integration in a particular tool.

> 
> Jörg
> 

Jim.

Re: OT] Joerg Schilling flames Linux on his Blog

[Tomasz Torcz]

On Mon, May 30, 2005 at 11:34:20AM +0200, Toon van der Pas wrote:
> On Mon, May 30, 2005 at 05:19:43PM +0800, Lincoln Dale (ltd) wrote:
> > > But what you claim is simply impossible.
> > 
> > wrong. again.
> > 
> > look up the man page for udev(8), pay particular attention to the part
> > that can tie devname into device serial number.
> > take note of the example shown under 'serial'.
> 
> These were my thoughts too.
> But I just checked the entries in my sysfs tree for my CDRW drive,
> and there is no serial number available...

 Wild thouht - you can attach a camera pointing to device and use udev
callout script, which will grab a picture by v4l and check color.
 It *is* possible in Linux.

-- 
Tomasz Torcz               RIP is irrevelant. Spoofing is futile.
zdzichu@irc.-nie.spam-.pl     Your routes will be aggreggated. -- Alex Yuriev

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Lincoln Dale \(ltd\)" <ltd@cisco.com> wrote:

> > But what you claim is simply impossible.
>
> wrong. again.
>
> look up the man page for udev(8), pay particular attention to the part
> that can tie devname into device serial number.
> take note of the example shown under 'serial'.

Let me give up here :-(

If you don't understand that the availability of the device serial number is 
not a basic SCSI feature, it makes no sense to continue this discussion.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

RE: OT] Joerg Schilling flames Linux on his Blog

[Lincoln Dale (ltd)]

> "Lincoln Dale \(ltd\)" <ltd@cisco.com> wrote:
> 
> > > But what you claim is simply impossible.
> >
> > wrong. again.
> >
> > look up the man page for udev(8), pay particular attention 
> to the part 
> > that can tie devname into device serial number.
> > take note of the example shown under 'serial'.
> 
> Let me give up here :-(
> 
> If you don't understand that the availability of the device 
> serial number is not a basic SCSI feature, it makes no sense 
> to continue this discussion.

bzzt.

oh but it IS a standard SCSI feature.  unit serial number is part of the
VPD page 80h.
Multipathing software for FC HBAs have made use of this for quite a
while now.

(ok, we're quibbling here - its OPTIONAL for a device to support this -
but i can go back ~7 years of SCSI/FC devices i have here and all
devices i've found do return this...).



cheers,

lincoln.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

> > Let me give up here :-(
> > 
> > If you don't understand that the availability of the device 
> > serial number is not a basic SCSI feature, it makes no sense 
> > to continue this discussion.
>
> bzzt.
>
> oh but it IS a standard SCSI feature.  unit serial number is part of the
> VPD page 80h.
> Multipathing software for FC HBAs have made use of this for quite a
> while now.
>
> (ok, we're quibbling here - its OPTIONAL for a device to support this -
> but i can go back ~7 years of SCSI/FC devices i have here and all
> devices i've found do return this...).

OK, if you understand the meaning of the word optional, then you should
know that any example drive that does support is is absolutely no
evidence for general availability.

If you did test enough different drives, you would know that the chance
is less than 50% for beeing able to retrieve the serial number via SCSI.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Bodo Eggert]

Bill Davidsen <davidsen@tmr.com> wrote:
> Kyle Moffett wrote:
>> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:
>>> "Bodo Eggert <harvested.in.lkml@posting.7eggert.dyndns.org>"

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

It's just strange if you're able to see my SCSI devices only through
ATAPI.

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

It's "unintentional and not supported". Users are supposed to convert the
device name into scsi numbers (e.g. using lsscsi) in order to to enable
cdrecord to peek around until it finds that number instead of directly
opening the correct device.

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

Udev is supposed to handle physical to logical mappings. No other program
should need to care, except for lsscsi and similar programs.

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

If I need RT privileges, I'll need to suid untill the non-root RT support
is ready and I'll be glad that it's supported.

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

AFAI read, burnfree isn't supposed to do anything unless a buffer underrun
occures. If that's true, I'd prefer a warning message to really destroying
my CD.

> There is an option if you would read the manpage. There are legitimate
> complaints, this doesn't seem to be one of them.

I had to write a wrapper, and wrappers tend to indicate bad programs.
-- 
Ich danke GMX dafür, die Verwendung meiner Adressen mittels per SPF
verbreiteten Lügen zu sabotieren.

Re: OT] Joerg Schilling flames Linux on his Blog

[Lee Revell]

On Thu, 2005-05-26 at 23:53 +0200, Bodo Eggert wrote:
> If I need RT privileges, I'll need to suid untill the non-root RT support
> is ready and I'll be glad that it's supported.

It is in 2.6.12-rc5.  You need to patch PAM (and bash, if you want to
use ulimit) to use it.

Lee

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"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. 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 :-(


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

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. 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 or ultra speed CD-RWs or cannot do other things....


> > If Linux plans to implement incompatible changes, I would expect that
> > "important users" are informed in advance so that it is possible to discuss
> > the problems an to have a planned smooth migration.
>
> While, in the meantime, users can destroy the hardware.

Not true: if only R/W fd would be allowed, no non root program could do that.

>
> <OT>
>
> BTW while talking about destroying hardware: Turning off burnproof so the
> drives that have this feature _for a reason_ will destroy my CD-Rs like
> a outdated CD-recorder would is doubleplusungood, even if it creates
> consistent behaviour across drives. It's like waring no seat belt in
> your car just because curricles didn't have them. ¢¢
>
> </OT>

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.


> There are other uses for write access to devices. Disabeling SCSI commands
> for r/o fds would only be a quickfix. (IMHO it could have been introduced
> as a config option and gone away in 2.6.13.)

The good/bad SCSI commands table that is currently used is a really bad and
ugly (incorrect) hack and much worse than my proposal.


> > P.S.: About 10 days ago, I made an attempt to include a workaround for the
> > interface changes in Linux, check cdrtools-2.01.01a03
>
> The fix is wrong: You're asuming root is capable of everything. This
> doesn't need to be true (missing CAP_SYS_RAWIO) and you'll run into a
> loop in that case.

If you are really true, then there is a design problem in Linux.

BTW: If Linux starts introducing fine grained rights manamement like on Solaris, why 
does it miss the apropriate management tools at user level?
On Solaris, I could run cdrecord rootless if I use pfksh as my shell and if
the roles database would include cdrecord with its needed privilleges and me
as a member of the cdwriters role.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Kyle Moffett]

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?   
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  
completely
dead and useless (no burnproof), or slightly scarred and still  
useable (with
burnproof).  Personally, I'd rather have the latter.

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

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

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

Re: OT] Joerg Schilling flames Linux on his Blog

[Kyle Moffett]

On May 26, 2005, at 15:20:32, Bill Davidsen wrote:
>> 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?

Well, yes, and I do all the time, but the dammed deprecation warning  
is just plain
stupid.  That's not the deprecated method, that's the reasonable method.

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

I don't use the three-number made-up SCSI-over-USB IDs that Joerg was  
complaining
about being unavailable.  I have mine set up based on the UUID of the  
burner.  I'm
sorry for being unclear, but my objection is to his desire to expose  
the SCSI IDs
to userspace as the primary naming scheme, when said SCSI IDs are  
frequently just
made up by the kernel for USB devices, etc.

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

Agreed.  My personal gripe is that it screams at me even when I'm  
just doing a
quickie burn of a 60MB debian netinst CD for a one-use-only thing.

> There is an option if you would read the manpage. There are  
> legitimate complaints, this doesn't seem to be one of them.

Ah, crap.  I just realized that some accidental disk corruption took  
a chunk out of
the middle of my copy of the manpage.  A reinstall of the package  
seems to have
fixed the problem.  Sorry about the noise.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

Re: OT] Joerg Schilling flames Linux on his Blog

[Matthias Andree]

On Thu, 26 May 2005, Kyle Moffett wrote:

> I don't use the three-number made-up SCSI-over-USB IDs that Joerg was
> complaining about being unavailable.  I have mine set up based on the
> UUID of the  burner.  I'm sorry for being unclear, but my objection is
> to his desire to expose  the SCSI IDs to userspace as the primary
> naming scheme, when said SCSI IDs are  frequently just made up by the
> kernel for USB devices, etc.

Given that I know the SCSI IDs of every single device I install, am not
using SCAM, I don't object to using SCSI IDs, unfortunately, SCSI CD or
DVD writers are rare and costly - I'd prefer them over ATAPI every day
since I take one PCI device to connect like half a dozen narrow SCSI
devices. ATAPI is so wasteful. And I have bought SCSI for as long as
somewhat up-to-date devices were available.

Things get interesting though with ATAPI, ATAPICAM, ide-scsi, ide-cd and
all sorts of interfaces since probing various busses is something that
requires user intervention or trial & error to list _all_ devices in
different buses, and drives have unlogical bus numbers (seen these on
FreeBSD), or more generally, when cdrecord tries to coerce a device
numbering scheme on devices that are not enumerated, or devices that are
hotplug with device numbers changing with every plug-in action, or
whatever.

-- 
Matthias Andree

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On May 25, 2005, at 18:46:55, Joerg Schilling wrote:

> > 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_!!!   

So if you really believe this, you should immediately remove all
stuff under /proc.

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

Try to start with reading the cdrecord manual page. Your question
is answered in there.....but if you issue a command that is only
halfway correct you will never be able to get the full set of features from 
cdrtools. Using UNIX device names for SCSI devices is highly nonportable 
and for this reason not supported by a portable program like cdrecord.

Cdrecord includes the needed features to do what you like, but do not
asume that you will be able to force me to make nonportable and Linux
specific interfaces a gauge for the design of a portable program.
If you read the cdrecord man page, you know that you could
happily call cdrecord dev=green_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.

Aha, so you would prefer /dev/ftp.kernel.org also?

Before trying to make inadequate comparisons and before you request
inadequate similarities, it often helps a lot if you first try to look
around and check whether your claims are really a tautology.

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

If you read the LKML archives, it would be easy for you to prove that this
is not true :-(

The numbers are obscured _only_ in order to prevent me to implement a workaround
for the fact that Linux does not implement _one_ unique interface for sending
generic SCSI commands to all devices that talk SCSI.

I aked for a non obscured interface in 2002 (note that the fields _are_ present
inside the ioctl parameter structure) in order to hide this drawback from Linux
users, but I have been told that the Linux developers don't like nice
and _unique_ interfaces for their users. 

	-	The fields are in the ioctl structures for user land 
		communication.

	-	The kernel knows the numbers that would allow libscg
		to detect duplikate drive appearances when trying to
		implement a global umbrella for all different SCSI
		interfaces in the Linux kernel

	-	The kernel hides the fact only to make it impossible for
		cdrecord to implement  a better user interface.



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

Do you really believe this? It would help a lot if you did a reality check.


> 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  

Again, try do do some reallity check.... Cdrecord by default uses the
setup that grant best media quality. I asume you are able to read, so 
just read the man page and set up your defaults the way you like them.


> burnproof).  Personally, I'd rather have the latter.

So why do you refuse to read the manual and to setup the parameters
you like?


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

Having such a list in inherently wrong. It never could be made correct.

There are a lot of different drives with a lot of overlapping commands
in the vendor unique part of the name space. Cdrecord needs the
vendor unique commands for old writers in order to be able to write at
all, and cdrecord needs the vendor unique commands in order to implement
the nice features people like for their convenience.

Nut even in the non vendor unique part the list in Linux is incomplete.

****
And please note: Cdrecord uses some of the commands that are used for 
firmware upgrade in order to do DMA speed metering........ This is
definitely _not_ a security issue with cdrecord.
In special on Linux, users frequelty did complain about insufficient
DMA speed before I did add this feature. Not cdrecord refuses to write
faster than possible after metering the transfer speed from/to the drive.
****

In case you don't understand this correectly, let me explain:

A security problem may only be correctly dealt with by having a 
coherent and consistent security strategy. The SCSI op code table
is not part of a security strategy but just a bad hack.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Wakko Warner]

Joerg Schilling wrote:
> Try to start with reading the cdrecord manual page. Your question
> is answered in there.....but if you issue a command that is only
> halfway correct you will never be able to get the full set of features from 
> cdrtools. Using UNIX device names for SCSI devices is highly nonportable 
> and for this reason not supported by a portable program like cdrecord.
> 
> Cdrecord includes the needed features to do what you like, but do not
> asume that you will be able to force me to make nonportable and Linux
> specific interfaces a gauge for the design of a portable program.
> If you read the cdrecord man page, you know that you could
> happily call cdrecord dev=green_burner.....

Portable programs have specifics to each OS that it can be compiled on.  Why
do you think some portatble programs use automake?  Not ever OS defines
variables the same way or uses them the same way as others.

You are going to have to realize that accessing devices directly under
different OSes will require different code.  I've read all the stuff you've
posted and it is apparent that you want all OSes to use the scsi scheme.

I don't use cdrecord much anymore since 1) I have a DVDRW and 2) I burn
DVDs mostly.  It happily uses /dev/<whatever> instead of compilaining that
it's unintentional.

As far as I can see, you can use scsi ioctls on regular devices so why do
you really need to use the 3 numbers?  To find the right /dev/sg and use it? 
Doesn't make sense.  I looked at the eject program one day.  The IOCTL used
to eject a cdrom is different than solaris.  Gee, I guess eject is not
portable.  You should probably write a library that deals specifically with
each OS.  I don't ever see something like this being portable.  Especially
between a Unix environment and a Windows environment.

P.S. This is the first and will be the last time I post on this thread.  I'm
not trying to flame anyone, this is mostly an enduser observation.  The
native OS device usage should be used instead of something supposedly
portable.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: OT] Joerg Schilling flames Linux on his Blog

[Dmitry Torokhov]

On 5/27/05, Joerg Schilling <schilling@fokus.fraunhofer.de> wrote:
> Kyle Moffett <mrmacman_g4@mac.com> wrote:
> > 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?
> 
> Try to start with reading the cdrecord manual page. Your question
> is answered in there.....but if you issue a command that is only
> halfway correct you will never be able to get the full set of features from
> cdrtools. Using UNIX device names for SCSI devices is highly nonportable
> and for this reason not supported by a portable program like cdrecord.
> 
> Cdrecord includes the needed features to do what you like, but do not
> asume that you will be able to force me to make nonportable and Linux
> specific interfaces a gauge for the design of a portable program.
> If you read the cdrecord man page, you know that you could
> happily call cdrecord dev=green_burner.....
> 

No, that static mapping is not good. I have an external enclosure that
does firewire and USB. I want to be able to use "sony-dvd" to access
it no matter whether it is onnected to USB bus or Firewire and whether
there are other devices (disks) on USB or firewire. It is possible to
do with udev creating a link to /dev/sony-dvd.

-- 
Dmitry

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> > Cdrecord includes the needed features to do what you like, but do not
> > asume that you will be able to force me to make nonportable and Linux
> > specific interfaces a gauge for the design of a portable program.
> > If you read the cdrecord man page, you know that you could
> > happily call cdrecord dev=green_burner.....
> > 
>
> No, that static mapping is not good. I have an external enclosure that
> does firewire and USB. I want to be able to use "sony-dvd" to access
> it no matter whether it is onnected to USB bus or Firewire and whether
> there are other devices (disks) on USB or firewire. It is possible to
> do with udev creating a link to /dev/sony-dvd.

I am not sure what you like to do.....

But what you claim is simply impossible.

As you started to introduce the allegory with the colors, let me make 
an assumption based on your claim:

-	Buy two identical drives and varnish one in red and the other 
	in green.

-	Connect both drives to your computer to let the OS "learn" the
	drives.

-	Do any setup you like

-	Now disconnect the drives and after that, connect the green one
	the way the red one has been connected before. 

-	Connect the red one too.

-	Insert a medium into the green drive

-	Let your software try whether it is able to connect you
	to the green one.

If this always works as expected, then you are a magician!

So let me sum up: Never rely on things that cannot be made 100%
unique in case you like to run security relevent software like cdrecord.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Markus Plail]

Joerg Schilling <schilling@fokus.fraunhofer.de> writes:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>
>> > Cdrecord includes the needed features to do what you like, but do
>> > not asume that you will be able to force me to make nonportable and
>> > Linux specific interfaces a gauge for the design of a portable
>> > program.  If you read the cdrecord man page, you know that you
>> > could happily call cdrecord dev=green_burner.....
>> > 
>>
>> No, that static mapping is not good. I have an external enclosure
>> that does firewire and USB. I want to be able to use "sony-dvd" to
>> access it no matter whether it is onnected to USB bus or Firewire and
>> whether there are other devices (disks) on USB or firewire. It is
>> possible to do with udev creating a link to /dev/sony-dvd.
>
> I am not sure what you like to do.....

He wants to be able to access his dvd recorder via dev=/sony-dvd. And it
should not matter how it is connected (USB/firewire).

> But what you claim is simply impossible.

No it is not.

> As you started to introduce the allegory with the colors, let me make
> an assumption based on your claim:
>
> -	Buy two identical drives and varnish one in red and the other 
> 	in green.

That is indeed impossible, but as soon as there are two different
drives, it is possible with udev and not possible with a static
assignment.

regards
Markus

Re: OT] Joerg Schilling flames Linux on his Blog

[Dmitry Torokhov]

On Monday 30 May 2005 04:07, Joerg Schilling wrote:
> Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> 
> > > Cdrecord includes the needed features to do what you like, but do not
> > > asume that you will be able to force me to make nonportable and Linux
> > > specific interfaces a gauge for the design of a portable program.
> > > If you read the cdrecord man page, you know that you could
> > > happily call cdrecord dev=green_burner.....
> > > 
> >
> > No, that static mapping is not good. I have an external enclosure that
> > does firewire and USB. I want to be able to use "sony-dvd" to access
> > it no matter whether it is onnected to USB bus or Firewire and whether
> > there are other devices (disks) on USB or firewire. It is possible to
> > do with udev creating a link to /dev/sony-dvd.
> 
> I am not sure what you like to do.....
> 
> But what you claim is simply impossible.
> 
> As you started to introduce the allegory with the colors, let me make 
> an assumption based on your claim:
> 
> -	Buy two identical drives and varnish one in red and the other 
> 	in green.
> 
> -	Connect both drives to your computer to let the OS "learn" the
> 	drives.
> 
> -	Do any setup you like
> 
> -	Now disconnect the drives and after that, connect the green one
> 	the way the red one has been connected before. 
> 
> -	Connect the red one too.
> 
> -	Insert a medium into the green drive
> 
> -	Let your software try whether it is able to connect you
> 	to the green one.
> 
> If this always works as expected, then you are a magician!
>

It will not work if drives are absolutely identical, however if there is
something even slightly different about them (serial number, model,
firmware version - anything) you can set up udev to produce "stable" name.

FWIW, my example was about a single drive that can "change" it's X,Y,Z
depending on how and when it was connected.

> So let me sum up: Never rely on things that cannot be made 100%
> unique in case you like to run security relevent software like cdrecord.

Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
Because for the most types of devices out there they don't make any sense
and just provided for compatibility with legacy software.

Also, from a bit different perspective - do you also want users to mount
the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
If not why writing application should use different addressing? 

-- 
Dmitry

Re: OT] Joerg Schilling flames Linux on his Blog

[Måns Rullgård]

Dmitry Torokhov <dtor_core@ameritech.net> writes:

>> So let me sum up: Never rely on things that cannot be made 100%
>> unique in case you like to run security relevent software like cdrecord.
>
> Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
> Because for the most types of devices out there they don't make any sense
> and just provided for compatibility with legacy software.

Like cdrecord.

> Also, from a bit different perspective - do you also want users to mount
> the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
> If not why writing application should use different addressing? 

Let's start referring to files by device and inode number instead.
It's so much easier than using pathnames.  Maybe we can even force
them into a bus,target,lun scheme.  Then the device files and the
corresponding scsi addresses will automatically collapse, and all
problems will be solved.

-- 
Måns Rullgård
mru@inprovide.com

Re: OT] Joerg Schilling flames Linux on his Blog

[Brian O'Mahoney]

This thead has become ultimately boring, Joerg's views are
irreconcilably anti linux and pro Solaris,

there are, fortunately, alternatives to cdrrecord that work,
especially for DVD,

let us just thank Joerg for his work and move on quietly!

-- 
mit freundlichen Grüßen, Brian.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

"Brian O'Mahoney" <omb@khandalf.com> wrote:

> This thead has become ultimately boring, Joerg's views are
> irreconcilably anti linux and pro Solaris,

If you are anti Linux, just try to stay quiet......

This is the first time that I experienced a non insulting
discussion at LKML.....


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Dmitry Torokhov <dtor_core@ameritech.net> wrote:

> > So let me sum up: Never rely on things that cannot be made 100%
> > unique in case you like to run security relevent software like cdrecord.
>
> Are you talking about <bus>,<target>,<lun> numbering by any chance ;) ?
> Because for the most types of devices out there they don't make any sense
> and just provided for compatibility with legacy software.

Well, this is the way most OS on the planet deal with SCSI. 

And please explain me why the Linux kernel internally uses these numbers
for driver instancing? Is the Linux kernel a piece of legacy software?


> Also, from a bit different perspective - do you also want users to mount
> the CD they burnt using not device (/dev/xxx) but <bus>,<target>,<lun>?
> If not why writing application should use different addressing? 

Using SCSI addresses is just the way that works more universally for
sending SCSI commands. There are several OS that don't support /dev/ names
and all other UNIX like OS do not artificial hide the SCSI addresses 
from userland programs.


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> [...]
> > 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.
>
> My problem is the speed of the network or the fragmentation of my HD, RT
> privileges won't do the magic needed here[tm]. In fact, even a kernel
> compile while doesn't harm. On a reasonably busy system, I would probably
> have to reconsider.

If you have fragmentation problems, do you use the wrong filesystem type?
I never had any similar problem on a ufs type filesystem.

With network speed, you should set up a sufficiently designed infrastructure.
If you like to write a CD in 32x, you need 5.6 MB/s which easily goes over
a 100 MB/s network connection.


> > 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 or ultra speed CD-RWs or cannot do other things....
>
> If I need them, I'll notice and I can ask for them to be added.-) Your
> patch will just hide this need, but that's what your otherusers will need.

There are many other commands needed by cdrecord.
The initiator of the good/bad SCSI op code table hack claimed to have checked
cdrecord for a list of used commands. If you check the current table, you may
easily find that this cannot be true.


> Maybe the failed command should be stored and printed after burning the 
> CD, so new comands will get added quickly?

Please try to check the cdrecord source in order to understand the background.


> You'll want to grant raw disk access for some databases, which will run as
> a unprivileged user. These databases should not be able to kill HDDs.

A database may kill a hdd in many other ways. It is higly improbable that
a trustworthy database includes the knowwledge to set up a firmware to the
drive that us accepted by the drive but does not work. The same applies for
your kernel. You need to trust your database the same way as you need to trust 
your kernel.


> > The good/bad SCSI commands table that is currently used is a really bad and
> > ugly (incorrect) hack and much worse than my proposal.
>
> Your proposal has it's limitations, see above.

It has less limitations that the good/bad SCSI commands table has, see above.

> > > The fix is wrong: You're asuming root is capable of everything. This
> > > doesn't need to be true (missing CAP_SYS_RAWIO) and you'll run into a
> > > loop in that case.
> > 
> > If you are really true, then there is a design problem in Linux.
>
> No, it's a feature, see man 3 cap_get_proc.

If Linux is designed in a way that needs applications like cdrecord to be 
changed in order to include support for a Linux proprietary new security
mechanism, then the new mechanism should be rethought.


> > BTW: If Linux starts introducing fine grained rights manamement like on Solaris, why 
> > does it miss the apropriate management tools at user level?
>
> Washing dishes is faster than drying them :)

If you go into a restaurant, they wash the dishes before they serve them to you,
but they wait until they did dry before they get them out of the kitchen :-)

It is a matter of style of the kitchen personal whether to serve wet
dishes or not. 

So for the Linux equivalent: don't force users tu use interfaces that are not
yet ready for the public.


> > On Solaris, I could run cdrecord rootless if I use pfksh as my shell and if
> > the roles database would include cdrecord with its needed privilleges and me
> > as a member of the cdwriters role.
>
> There was some discusssion on LKML about non-root access to RT privileges. 
> Maybe there is something in the queue.

So it makes sense for the Linux to have a look at the Solaris implementation.
The database is much simpler to manage than what is present for Linux.

BTW: it would also make sense to implement the new holey file interface 
I designed together with the Solaris kernel crew for star.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> > If you have fragmentation problems, do you use the wrong filesystem type?
>
> No, just small writes to random locations in large sparse files on filled 
> disks.

Did you ever try to compare this behavior with UFS?
The last time I did notice fragmentation problems on UFS is more than 15 years
a go when I had full news feed with B-news running on a Sun-3/50 and did a 
higly selective expire.

I am still sure that your problems are a problem of the filesystem 
implementation you use.

> > With network speed, you should set up a sufficiently designed infrastructure.
> > If you like to write a CD in 32x, you need 5.6 MB/s which easily goes over
> > a 100 MB/s network connection.
>
> Mostly it does, but sometimes there are other users on my server.

This is why cdrecord puts itself into the highest priority real time class
on every OS that supports this. If you voluntarily decline on this feature,
please don't blame cdrecord.


> > There are many other commands needed by cdrecord.
> > The initiator of the good/bad SCSI op code table hack claimed to have checked
> > cdrecord for a list of used commands. If you check the current table, you may
> > easily find that this cannot be true.
>
> So we'll need a function to add more commands to the allowed list of each 
> device.

No, the command list was an ungly hack from the beginning and it just is not
suitable for what it is used.

	If you like decent and reliable security, you need privillege separation.

-	Disallow sending SCSI commands via ioctl() on /dev/hd*

-	Tell people that they have to use /dev/sg* in order to send SCSI 
	commands to devices.

-	Introduce a privillege check for /dev/hd* that is suitable for the
	users of a block device interface.

-	Introduce a privillege check for /dev/sg* that is suitable for the
	users of a SCSI pass though interface.

The current problems in Linux are just a result of mixing unrelated interfaces
together.


> > > You'll want to grant raw disk access for some databases, which will run as
> > > a unprivileged user. These databases should not be able to kill HDDs.
> > 
> > A database may kill a hdd in many other ways.
>
> IMO, those should be plugged, too, and I'm sure they will.

See above: the clean solution is privilleges separation.


> > It is higly improbable that
> > a trustworthy database includes the knowwledge to set up a firmware to the
> > drive that us accepted by the drive but does not work.
>
> A database may very well have exploits or provide system access to the 
> database admin. Neither should result in raw SCSI access.

See above: If you have clean privilleges separation (and Linux did have it 
before the unsuited SG_IO ioctl was introduced on /dev/hd*) you don't even come
close to similar problems.

Just give the database an interfase that allows the database to do what a 
database needs to do (reading and writing to a media) but not more.


> > The same applies for
> > your kernel. You need to trust your database the same way as you need to trust 
> > your kernel.
>
> NACK. Databases can't be trusted.

Wunderfull, so you are also a fan of privillege separation. Let us together
vote for removing ioctl(sg_IO) from /dev/hd* and similar devices.


> > > No, it's a feature, see man 3 cap_get_proc.
> > 
> > If Linux is designed in a way that needs applications like cdrecord to be 
> > changed in order to include support for a Linux proprietary new security
> > mechanism, then the new mechanism should be rethought.
>
> You don't need to implement that, but you shouldn't asume root to be more 
> special than other users.

In contrary to many other programs, cdrecord is cleanly written and does not
make such assumptions! It will have no problems as long as the environment
is not contradictive.


> BTW: IIRC, it was ported from solaris. There will probably the same issue.
>
> > So for the Linux equivalent: don't force users tu use interfaces that are not
> > yet ready for the public.
>
> You're not forced to use it, but you might be served non-dirty plates.

It seems that you did not understand this, so let me explain it in a different
way: If you start to implement a new security mechanism, either do it in a way 
that does not affect software that assumes historical UNIX interfaces at all,
or keep it private for developers untill it is suitable for the mass.

> > So it makes sense for the Linux to have a look at the Solaris implementation.
> > The database is much simpler to manage than what is present for Linux.
>
> This is a userspace issue. The kernel doesn't enforce anything.

An OS is the kernel _and_ the user space support software.
Even a "kernel only" subsystem like Linux cannot ignore these facts when
trying to introduce interfaces that need special useland programs in order
to mahe use out of it.

> > BTW: it would also make sense to implement the new holey file interface 
> > I designed together with the Solaris kernel crew for star.
>
> Google gives no good pointers.

If it did, soneone would have ignored his NDA. The current interface is not
yet 100% stable, it will be officially published when it is closer to something
that could be used by anyone. If someone from LKML is really interested in 
implementing the interface soon, I would be willing to give away basic
details that allow to implement 99% if the code. The error handling is 
still in dispute.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Bodo Eggert <7eggert@gmx.de> wrote:

> > No, the command list was an ungly hack from the beginning and it just is not
> > suitable for what it is used.
> > 
> > 	If you like decent and reliable security, you need privillege separation.
> > 
> > -	Disallow sending SCSI commands via ioctl() on /dev/hd*
>
> > -	Tell people that they have to use /dev/sg* in order to send SCSI 
> > 	commands to devices.
>
> - Each CD player would have to run suid. I'm talking about programs 
>   running a GUI, peeking in CDDB databases and doing other ugly stuff.

If you don't already have fine grained process permissions ready, you are right.
In the other cases, pfksh or somethign similar would know about the special
rights of a program from checking the databases in /etc/security/ and call
/usr/bin/pfexec to set up only the needed rights and then call the program
in question.

Note that in case you call the ability to send SCSI commands a security
risk, then you need to implement all the consequences.....


> - Each CD player will have permission to erase the firmware on all 
>   installed devices.

As you may not know which SCSI commands are used for a specific device, this
is correct.


> - You've seen how ugly scanning for the correct sg device is, and udev 
>   will make it site-dependant. You are no longer "guaranteed" to find any 
>   /dev/sg* devices.

As it seems that this program called "udev" (if I am right) does some strange
lookup and setup which is basically the same from editing /etc/default/cdrecord
why is this program not implemented to give full support for Linux users and
_does_ edit /etc/default/cdrecord?

I don't know that program but in contrary to the concepts of Solaris where
a similar program (devlinks) that exists since 1992 creates links based only
on information found in the names from /devices, and crerates links to /dev
like this one:

lrwxrwxrwx   1 root     other         45 Jul 14  2003 /dev/scg0 -> ../devices/pci@0,0/pci-ide@7,1/ide@1/scg@0,0:
lrwxrwxrwx   1 root     other         39 Jul 14  2003 /dev/scg1 -> ../devices/pci@0,0/pci1000,f@9/scg@0,0:

it seems that the program udev either has access to private kernel data 
structures (from the definition of the people who like to deny access to 
this information to cdrecord::libscg) or does other strange things.

On Solaris, handling of driver instances is done inside the kernel and used
to set up device names.

You should rethink whether you still believe that udev is a clean program while
cdrecord is not.....

Please note that /etc/default/cdrecord must likely predates udev by many years
and polite authors of such a program would have added support for not only
creating links to /dev but also for adding device aliased into 
/etc/default/cdrecord.



> > In contrary to many other programs, cdrecord is cleanly written and does not
> > make such assumptions!
>
> It does asume not to get permission denied errors after seteuid(0) was 
> successfull.

Wrong: please check the source..... 

It does not make _any_ asumption based on uid values except for the fact that
it still tells you to become root in case something did not work.

So if there was a useful framework for the current attempt to implement 
fine grained process privilleges into Linux, cdrecord would be a candidate 
for testing....


> > It seems that you did not understand this, so let me explain it in a different
> > way: If you start to implement a new security mechanism, either do it in a way 
> > that does not affect software that assumes historical UNIX interfaces at all,
> > or keep it private for developers untill it is suitable for the mass.
>
> It's not new. My manpage is from 1997, and the function was ported from 
> solaris (IIRC).

What are you talking about?


> > An OS is the kernel _and_ the user space support software.
>
> The linux kernel is just the linux kernel. Unlike other systems, no
> special userland is enforced (with minimal exceptions like /sbin/init).
> You can run supervise, busybox, sysvinit, use pam or classic login etc.
> If you like, you can get rid of /dev and put it somewhere else.

If you really make this assumtion, you would not be allowed to implement 
fine grained process privielleges into Linux because you could not support
it at shell level. It just makes no sense to add special (currently) nonstandard
features to a kernel without providing the supporting user land programs.



> > Even a "kernel only" subsystem like Linux cannot ignore these facts when
> > trying to introduce interfaces that need special useland programs in order
> > to mahe use out of it.
>
> If you're developing a monolithic OS, you can hide the interface untill
> you've written the applications, but you can't do that for a standalone 
> kernel. The interface is mostly(?) there, and as soon as somebody starts 
> to care enough, it will be used.

You can do the same for something like Linux. You just need to implement the
interface in a way that does not contradict or influence historical UNIX
practice that made it into POSIX. 

> > If it did, soneone would have ignored his NDA. The current interface is not
> > yet 100% stable, it will be officially published when it is closer to something
> > that could be used by anyone. If someone from LKML is really interested in 
> > implementing the interface soon, I would be willing to give away basic
> > details that allow to implement 99% if the code. The error handling is 
> > still in dispute.
>
> I'm too lazy to implement that, but I'd like an abstract.
> (I suspect it's something like 
> http://www.olafdietsche.de/linux/capability/)

Did you forget what question from you I was replying to?

I see no relation to a holey file interface here.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Patrick McFarland wrote:

>I was refering to the 2.6 permissions bug in cdrecord. It wouldn't work using 
>a non-root user, even if they had the correct permissions. 2.6 changed (for 
>the better, mind you), and Joerg refused to fix cdrecord. (I don't know if 
>its even fixed now). Theres been other cases of cdrecord breaking on Linux 
>only, but I can't think of them atm. 

Well, it seems that you are uninformed about the facts :-(

So let me quote a mail I send to LKML on Aug 17 13:14:59 2004:
/*--------------------------------------------------------------------------*/
If Linux believes that there should be enhanced security similar to Solaris and  
if Linux is a true open Source business, then I would expect that there is  
cooperation. If I change things in e.g. mkisofs or cdrecord that could result 
in problems for my "users", I send a notification mail to the XCDRoast & k3b  
authors early enough. 
 
If Linux plans to implement incompatible changes, I would expect that  
"important users" are informed in advance so that it is possible to discuss the  
problems an to have a planned smooth migration. As this did not happen, the  
change needs to be called a bug. This is even more obvious if we take into  
account that cdrtools curently is in code freeze state as a 2.01-final will  
come the next days. 
 
For this reason, I would recommend that Linux immediately goes back to the old 
behavior and informs "important users". A change that has effects that are as 
widely as this one should not be tried again within the next 3 months. Then  
there is a change to have a smooth migration...... 
 
BTW: I try to inform my "important users" more than a year before I introduce 
important changes. 
/*--------------------------------------------------------------------------*/

Note that this was a few days before cdrtools-2.01 final have been published
(after nearly two years of planned work on a new version).

The changes to Linux did neither fix the problem (just check the mailings on 
LKML from last year) nor has there been a need for introducing incompatible 
changes. If the cause for the change really was the "security problem" caused 
by the fact that Linux did allow to send SCSI commands on R/O file descriptors
it would have been sufficient to require R/W permissions on the fd. After
this putative small change, the supposed problem would have been fixed and 
cdrtools as well as other users of the interface did work as before.

What the change on Linux did was not to fix a problem but to break cdrtools.

I am not unwilling to fix cdrecored, as a non broken program does not need
a fix. I was even willing to add a workaround for the incompatible interface 
change. But this may obviously not happen in a code freeze state.

Sorry - The problems between cdrtools and Linux is only a result of the 
missing will for cooperation from the Linux kernel crew.


BTW: Due to missing time (I like to see a good cooperation between my work
and the support code in an OS, so I am now actively working on OpenSolaris
and I am very busy...). My planned OpenSolaris based UNIX distribution
"SchilliX" should be available soon after the public availability of the
OpenSolaris source in Q2/2005 which is only a few days from now. Fortunately,
I believe that I will be able to boot my first "SchilliX from scratch" 
compiled CD today.

P.S.: About 10 days ago, I made an attempt to include a workaround for the
interface changes in Linux, check cdrtools-2.01.01a03


Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Kyle Moffett]

On May 25, 2005, at 09:15:33, Joerg Schilling wrote:
> If Linux believes that there should be enhanced security similar to  
> Solaris and
> if Linux is a true open Source business, then I would expect that  
> there is
> cooperation. If I change things in e.g. mkisofs or cdrecord that  
> could result
> in problems for my "users", I send a notification mail to the  
> XCDRoast & k3b
> authors early enough.

There was a security hole in the CD burner support.  The Linux Kernel  
developers
fixed it quickly.  They were not planning to wait 6 months for you to  
get an
updated version of cdrecord out the door in any case.  If you want more
information on the Linux Kernel security policy, please see a recent  
copy of the
linux kernel for the file Documentation/SecurityBugs.  To quote the  
relevant
part:  "It is reasonable to delay disclosure ... or for vendor  
coordination.
However we expect these delays to be short, measurable in days, not  
weeks or
months."  Part of this policy includes "we'd like to know when a  
security bug is
found so that it can be fixed and disclosed as quickly as possible."   
This seems
to imply that the security team is not likely to wait 6 months to fix  
a critical
hardware-damaging vulnerability.

> If the cause for the change really was the "security problem"  
> caused by the
> fact that Linux did allow to send SCSI commands on R/O file  
> descriptors it
> would have been sufficient to require R/W permissions on the fd.  
> After this
> putative small change, the supposed problem would have been fixed  
> and cdrtools
> as well as other users of the interface did work as before.

I will not debate this issue with you.  Please see the copious  
quantities of
emails when this issue was brought up a while ago.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$  
r  !y?(-)
------END GEEK CODE BLOCK------

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Kyle Moffett <mrmacman_g4@mac.com> wrote:

> On May 25, 2005, at 09:15:33, Joerg Schilling wrote:
> > If Linux believes that there should be enhanced security similar to  
> > Solaris and
> > if Linux is a true open Source business, then I would expect that  
> > there is
> > cooperation. If I change things in e.g. mkisofs or cdrecord that  
> > could result
> > in problems for my "users", I send a notification mail to the  
> > XCDRoast & k3b
> > authors early enough.
>
> There was a security hole in the CD burner support.  The Linux Kernel  
> developers
> fixed it quickly.  They were not planning to wait 6 months for you to  
> get an
> updated version of cdrecord out the door in any case.  If you want more
> information on the Linux Kernel security policy, please see a recent  
> copy of the
> linux kernel for the file Documentation/SecurityBugs.  To quote the  
> relevant

Looks like you did not read the mail from me you were replying to.

The best way to fix a problem is to fix the problem and not to do something 
else and to change the interface.

The problem was that you could send SCSI commands on R/O fds and fixing the
problem would have been to forbid sending SCSI commands on R/O fds.

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Bill Davidsen]

On Thu, 26 May 2005, Joerg Schilling wrote:


> Looks like you did not read the mail from me you were replying to.

Let's start a technical discussion with a personal attack...
> 
> The best way to fix a problem is to fix the problem and not to do something 
> else and to change the interface.

When possible, correct.
> 
> The problem was that you could send SCSI commands on R/O fds and fixing the
> problem would have been to forbid sending SCSI commands on R/O fds.

IT DOESN'T WORK THAT WAY. You *can't* disallow sending commands, that's
how you do a read on a SCSI device, by sending commands like "seek" and
"read." What is needed is to limit the commands allowed to be sent, and
pass only known appropriate commands depending on access.

It is true that the first implementation didn't have all the legitimate
commands in the table of allowed commands. But once the idea of doing bad
things to a CD by sending evil commands was well-known, it was important
to have protection in place quickly.

It is true that some developers have been very unhelpful, and replied with
canned "you don't have permission" messages to reports that legitimate
commands aren't in the allowed table.

It is true that the implementation is overly complex, instead of using
only read and write, other things are checked, resulting in some
unexpected behaviour, like blocking programs being setuid.

What is NOT TRUE is that any of this was done just to piss you off. That
was just a fringe benefit to fixing the security issue quickly. AFAIK all
of the commands for burning single session CD/DVD are working as intended.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: OT] Joerg Schilling flames Linux on his Blog

[Joerg Schilling]

Patrick McFarland wrote: 

>As everyone knows, Joerg Schilling has a blog, and he often pushes his
>pro-Solaris agenda, and flames the LKML about how Linux breaks cdrecord
>(instead of just admitting cdrecord is broken) or how much more awesome
>Solaris is compared to Linux.

>Well, he just fired yet another salvo at the Linux community:
>http://schily.blogspot.com/2005/04/value-marketing-and-freedom.html

As it seems you don't understand, let me explain: this is definitely not an 
anti Linux Blog but rather a reply to the anti Solaris article of a pro 
Linux Bigot who calls himself a writer....


>I commented on his blog entry, but I am afraid of being censored as my views 
>do not align with his, so I am including the text of my comment here: 

Strange thoughts. Why should someone who fights for freedom even think about
removing a comment that is not a personal infringement? As you seem to think
about this posibility, let me ask: should we be rather afraid of you?

...

>Linux developers code, OpenSolaris developers sit around and flame Linux=20
>developers instead of coding. Which operating system would _you_ choose?

A nice self contradicting statement.....

Jörg

-- 
 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  
       schilling@fokus.fraunhofer.de	(work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily

Re: OT] Joerg Schilling flames Linux on his Blog

[Patrick McFarland]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

Joerg, when replying, please don't break threading.

On Wednesday 25 May 2005 08:50 am, Joerg Schilling wrote:
> >I commented on his blog entry, but I am afraid of being censored as my
> > views do not align with his, so I am including the text of my comment
> > here:
>
> Strange thoughts. Why should someone who fights for freedom even think
> about removing a comment that is not a personal infringement? As you seem
> to think about this posibility, let me ask: should we be rather afraid of
> you?

Someone who fights for freedom wouldn't remove the comment. You are not that 
someone.

-- 
Patrick "Diablo-D3" McFarland || pmcfarland@downeast.net
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd 
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: OT] Joerg Schilling flames Linux on his Blog

[Markus Plail]

Patrick McFarland <pmcfarland@downeast.net> writes:
> Joerg, when replying, please don't break threading.
>> Strange thoughts. Why should someone who fights for freedom even
>> think about removing a comment that is not a personal infringement?
>> As you seem to think about this posibility, let me ask: should we be
>> rather afraid of you?
>
> Someone who fights for freedom wouldn't remove the comment. You are
> not that someone.

But you DO realise that your comment was *NOT* deleted, do you? It isn't
now and it wasn't when I first read the blog entry, which wasn't long
after you posted your message here.

regards
Markus