Re: cdrtools-2.01a37 ready
> > ... _ non-zero _ pad bytes ... > > A short "is ok" or "better pad 300 kB zeros" would be of help. > Joerg > I cannot tell, better you use zeroes. Thanks, Joerg and Volker, for the advice. I'll keep padsize=300k with CDs. > > tradition suggest that TAO mode does not need to know the > > track size in advance. > Well there are writers tha need the track in advance size regardless of the > write mode, so I see no problem. If one is smitten with such a drive, ok. Let me tell you my fresh cdrecord-ProDVD impressions : It is easy to describe to users how to find out the burner's address. (Kudos for -scanbus) I plugged it into my software and it did a nice job with ISO images buffered on disk. About 4250 MB each. cdrecord-ProDVD even is 10 seconds faster than growisofs when writing such an image to DVD+RW . But because mkisofs needs nearly 10 minutes to build the image on disk and because growisofs only loses about 2 minutes by waiting for mkisofs in a pipe, there is a net disadvantage of 8 minutes per DVD. 24 minutes vs. 16. That is significant. As stated, i am not always able to tell the size in advance. So i eventually need the disk buffer to determine it reliably without refering too much to the data format (ISO, afio, whatever). A disk buffer is by any means cumbersome compared with a pipe. It consumes disk space, interferes with other system activities, needs decent security settings ... I was happy about burnfree hardware and fast computers to get rid of buffer files. Now they are back again. Larger than ever. Nevertheless, i now offer my users to employ either growisofs or cdrecord-ProDVD. If a drive or kernel is on strike with the one program then it might still work with the other. So thanks for providing your program for free. (I qualify for a research license, i hope) > > simulate a media overrun at 1 GB rather than to demand the > > size in advance. > I don't like to be made responsible for damaged media. I see your point again. (being too much into RW media) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
[EMAIL PROTECTED] wrote: > > The tracksize was unknown -> man cdrecord tells you how to > > deal with this problem. > > I have read that. But the man page as well as cdrecord > tradition suggest that TAO mode does not need to know the > track size in advance. Well there are writers tha need the track in advance size regardless of the write mode, so I see no problem. > For my purpose, with TAO from stdin, it would be better to > simulate a media overrun at 1 GB rather than to demand the > size in advance. I don't like to be made responsible for damaged media. > May i ask for a little favor ? > I do not know where to dig for the answer to the following question : > > Are there objections against having the only track of a CD > ending with 300+ kB of _ non-zero _ pad bytes rather than the > padding provided by cdrecord padsize=... or mkisofs -pad ? > > A short "is ok" or "better pad 300 kB zeros" would be of help. I cannot tell, better you use zeroes. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> Are there objections against having the only track of a CD > ending with 300+ kB of _ non-zero _ pad bytes rather than the > padding provided by cdrecord padsize=... or mkisofs -pad ? > > A short "is ok" or "better pad 300 kB zeros" would be of help. If this 300kb (150 sectors, 2 seconds) is to separate the tracks from each other, the spec is that it must be silent, i.e. zeros. If the padding is purely to work around the kernel bug which reads more blocks than will ever be used, the actual data content is irrelevant. If you want to store data (e.g. checksums) past the end of the filesystem, write the filesystem first, then your data (any size, obviously within limits of recording capacity), then 150 blocks of zeros. From the drive's point of view, it's only interested in the zeros. From the filesystem's point of view, it's not interested in any block beyond the last one belonging to the filesystem. With dd, you can easily access anything but may run into trouble for accessing the last 150 blocks; with Linux you will run into trouble before then. You could consolidate all requirements by writing: * filesystem blocks * your additional data blocks * sufficient number of rubbish blocks to keep the kernel happy (150 minimum), I'd use 500 esp on a dvd, there's no reason not to use zeros * 150 blocks of zeros Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
me>> >> cdrecord: Must specify track size(s). >> Next i set the CDR_SECURITY variable and shwoops >> my pipe did work. It is reproducible: unset CDR_SECURITY >> spoils it again. Joerg > > Without CDR_SECURITY, a max size if 1 GB os allowed I see your point. > The tracksize was unknown -> man cdrecord tells you how to > deal with this problem. I have read that. But the man page as well as cdrecord tradition suggest that TAO mode does not need to know the track size in advance. There is the technical problem that i do not necessarily know the size of the track in advance if i format and write on the fly. This is especially true with compressed archives but also with mkisofs -print-size on directory trees which are not absolutely frozen. For my purpose, with TAO from stdin, it would be better to simulate a media overrun at 1 GB rather than to demand the size in advance. This would bring cdrecord-ProDVD without CDR_SECURITY nearer to the behavior of home compiled cdrecord as long as usual CDs are to be burned. I myself got no problem with setting CDR_SECURITY . But it is about twice as complicated to describe how to install cdrecord-prodvd.sh as cdrecord and cdrecord-prodvd-2.01b31-i686-pc-linux-gnu as cdrecord-ProDVD rather than just to overwrite the old binary and set the s-bit. Since my original proposal was to provide a substitution binary for the mis-patched SuSE "cdrecord"s, it would be essential to have the installation instructions as simple as possible. >> ... found some typos > Thank you May i ask for a little favor ? I do not know where to dig for the answer to the following question : Are there objections against having the only track of a CD ending with 300+ kB of _ non-zero _ pad bytes rather than the padding provided by cdrecord padsize=... or mkisofs -pad ? A short "is ok" or "better pad 300 kB zeros" would be of help. The track shall be written with -data -tao, no -multi, 300+ kB of non-zero padding provided by me as data input to cdrecord, no -pad or padsize= What i read : You mentioned on August 6 in connection with read-ahead bugs : "The CD-standard requires 300 kB (150 sectors) of padding" Contemporary man mkisofs -pad mentions 300 kB to appease buggy reader software. (I checked: these 300 kB are zeros) man cdrecord speaks of a "2 second silence before each track". This leaves open wether it must be zeros if no further track is following. Would non-zero data possibly violate specs on which authors of (data) CD device drivers or producers of (data) CD drives might legitimately rely ? Have a nice day :) Thomas PS: I do not use cdrecord-ProDVD for DVD burning currently. That is more due to your last year's position towards DVD+RW rather than due to license concerns, nevertheless. I am now using cdrecord-prodvd-2.01b31-i686-pc-linux-gnu for CD-RW. No further problems encountered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Mon, Aug 23, 2004 at 12:32:10PM +0200, Joerg Schilling wrote: > Jacob Meuser <[EMAIL PROTECTED]> wrote: > > > On Fri, Aug 20, 2004 at 03:49:28PM +0200, Joerg Schilling wrote: > > > > > How do you believe that you may run cdrecord without root privs without > > > compromising the security of the whole system? > > > > On OpenBSD, members of the operator group are allowed to reboot the > > system, change tapes ... normal things that someone trusted to operate > > > > > But having suid binaries gives _anyone_ the possibility of escalating > > to root. This has already happened to the very software we are > > talking about. > > > > Using the suid bit takes away all the fine grained "access control". > > It looks like OpenBSD does not have fine grrained access control but did rather > add unwanted spacial group behavior into the kernel. There's nothing "special" added to the kernel. It's just the same old group "access control" that's been with UNIX-like operating systems since long ago. > On Solaris 10, you may use RBAC together with getppriv()/setppriv() to really > have fine grained role based rights. > > On a non "trusted" Variant, there is /usr/bin/pfexec that calls the programs > with just the rights they need. > > Jörg > > -- > EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin >[EMAIL PROTECTED] (uni) If you don't have iso-8859-1 >[EMAIL PROTECTED] (work) chars I am J"org Schilling > URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
[EMAIL PROTECTED] wrote: > > Joerg > > > Just download from > > > > ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ > > I did, but then encountered some difficulties when > burning CD-RW on the fly via cdrecord's stdin : > > Cdrecord-ProDVD-Clone 2.01b31 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg > Schilling > Unlocked features: > Limited features: > ... > cdrecord: Must specify track size(s). The tracksize was unknown -> man cdrecord tells you how to deal with this problem. > Next i set the CDR_SECURITY variable and shwoops > my pipe did work. It is reproducible: unset CDR_SECURITY > spoils it again. Without CDR_SECURITY, a max size if 1 GB os allowed > Did i find a bug ? > > To prove i rtfm'ed : probably found some typos > > README.key : > "private/nomcommercial" > "A pepliy to the incoming mail is usually send once a week" > > README.clone: > "then cdrecord will promise you a different write mode" > Did you probably mean "propose" ? I did not test - but with > "promise" this is a strange statement. Thank you Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
Jacob Meuser <[EMAIL PROTECTED]> wrote: > On Fri, Aug 20, 2004 at 03:49:28PM +0200, Joerg Schilling wrote: > > > How do you believe that you may run cdrecord without root privs without > > compromising the security of the whole system? > > On OpenBSD, members of the operator group are allowed to reboot the > system, change tapes ... normal things that someone trusted to operate > But having suid binaries gives _anyone_ the possibility of escalating > to root. This has already happened to the very software we are > talking about. > > Using the suid bit takes away all the fine grained "access control". It looks like OpenBSD does not have fine grrained access control but did rather add unwanted spacial group behavior into the kernel. On Solaris 10, you may use RBAC together with getppriv()/setppriv() to really have fine grained role based rights. On a non "trusted" Variant, there is /usr/bin/pfexec that calls the programs with just the rights they need. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Sat, Aug 21, 2004 at 11:04:41AM -0400, Albert Cahalan wrote: > > On OpenBSD, members of the operator group are allowed to > > reboot the system, change tapes ... normal things that > > someone trusted to operate the system would be allowed to do. > > Letting them write to CD/DVD is very low on the scale of bad > > things they could already do, like boot into single user > > mode and mess with all kinds of stuff, and so does not > > further compromise the security of the system. There is > > virtually no way anyone could escalate their privileges by > > simply allowing them to write to a CD device. > > Sure there is. > > Write new firmware to the device that lets you lock up > the bus or tunnel SCSI commands to another device. > You could password-protect all other devices on the bus, > format disks with non-standard sector sizes, eject > boot media, and so on. > > People have been hacking firmware, mostly to remove > annoying spped restrictions and DVD restrictions, so > don't for a moment think that obscurity will save you. Obscurity? What are you talking about? If I thought someone was going to try to overwrite the firmware on an device, they would not be part of the operator group. You apparently did not understand what I was talking about. -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> On OpenBSD, members of the operator group are allowed to > reboot the system, change tapes ... normal things that > someone trusted to operate the system would be allowed to do. > Letting them write to CD/DVD is very low on the scale of bad > things they could already do, like boot into single user > mode and mess with all kinds of stuff, and so does not > further compromise the security of the system. There is > virtually no way anyone could escalate their privileges by > simply allowing them to write to a CD device. Sure there is. Write new firmware to the device that lets you lock up the bus or tunnel SCSI commands to another device. You could password-protect all other devices on the bus, format disks with non-standard sector sizes, eject boot media, and so on. People have been hacking firmware, mostly to remove annoying spped restrictions and DVD restrictions, so don't for a moment think that obscurity will save you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> > > cdrecod. The ProDVD binaries just behave the same as the > > > cdrecord compiled from the GPLd part of the source in case you > > > do not like to get more functionality than the GPLd source includes. > > > > Except for the time bomb? > > Try to keep yourself informed before posting... It was a question. Try to read before posting... and if you do send a reply, try and put at least one informative bit into it. -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
Joerg > > Just download from > > ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ I did, but then encountered some difficulties when burning CD-RW on the fly via cdrecord's stdin : Cdrecord-ProDVD-Clone 2.01b31 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Unlocked features: Limited features: ... cdrecord: Must specify track size(s). It ends with non-zero exit value. But it works when reading a file from disk rather than stdin. Next i set the CDR_SECURITY variable and shwoops my pipe did work. It is reproducible: unset CDR_SECURITY spoils it again. Is that restriction intended without CDR_SECURITY ? I cannot find anything about that in ftp://ftp.berlios.de/pub/cdrecord/ProDVD/README Joerg > > The ProDVD binaries just behave the same as the > cdrecord compiled from the GPLd part of the source in case you > do not like to get more functionality than the GPLd source includes. Did i find a bug ? To prove i rtfm'ed : probably found some typos README.key : "private/nomcommercial" "A pepliy to the incoming mail is usually send once a week" README.clone: "then cdrecord will promise you a different write mode" Did you probably mean "propose" ? I did not test - but with "promise" this is a strange statement. Have a nice day :) Thomas PS: What i tried : -rwsr-xr-x1 root root 340036 Aug 20 20:21 cdrecord-prodvd-2.0.1-i586-pc-linux-gnu -rwsr-xr-x1 root root 372956 Aug 20 20:08 cdrecord-prodvd-2.01b31-i686-pc-linux-gnu Having a symbolic link from cdrecord to one of those binaries, i run : mkisofs ... | \ cdrecord -v speed=10 dev=0,0,0 \ padsize=300k fs=8m -eject driveropts=burnfree -data - with 2.01b31, option -tao makes no real difference. If i switch back to my selfmade binaries or the older SuSE ones, then it works again. When feeding cdrecord with a file from disk, then it works with cdrecord-ProDVD, too. I never heard of that message together with my software: "cdrecord: Must specify track size(s)." I interpret in man cdrecord option -tao (2.01a35) the absence of sentence "Note that cdrecord needs to know the size ..." in such a way that TAO is not supposed to demand that size. All alternatives to -tao seem to make this constraint (-sao , -raw , ...). - Failed runs : Cdrecord-ProDVD-Clone 2.0.1 (i586-pc-linux-gnu) Copyright (C) 1995-2002 Jörg Schilling Unlocked features: Limited features: TOC Type: 1 = CD-ROM scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.1.25 Using libscg version 'schily-0.7' Driveropts: 'burnfree' atapi: 1Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'DVDRAM GSA-4082B' Revision : 'A201' Device seems to be: Generic mmc2 DVD-R/DVD-RW. cdrecord: This version of cdrecord limits DVD-R/DVD-RW support to -dummy or 1 GB real. cdrecord: If you need full DVD-R/DVD-RW support, ask the Author for cdrecord-ProDVD.Using generic SCSI-3/mmc CD-R driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R Drive buf size : 1204224 = 1176 KB FIFO size : 8388608 = 8192 KB Track 01: data unknown length padsize: 300 KB Total size:0 MB (00:00.00) = 0 sectors Lout start:0 MB (00:02/00) = 0 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 3 Reference speed: 6 Is not unrestricted Is erasable Disk sub type: High speed Rewritable (CAV) media (1) ATIP start of lead in: -11635 (97:26/65) ATIP start of lead out: 359849 (79:59/74) 1T speed low: 4 1T speed high: 10 2T speed low: 4 2T speed high: 0 (reserved val 6) power mult factor: 1 5 recommended erase/write power: 3 A1 values: 24 1A BC A2 values: 26 B2 26 Disk type:Phase change Manuf. index: 3 Manufacturer: CMC Magnetics Corporation cdrecord: WARNING: Total disk size unknown. Data may not fit on disk. cdrecord: Must specify track size(s). - cdrecord: No write mode specified. cdrecord: Asuming -tao mode. cdrecord: Future versions of cdrecord may have different drive dependent default s. cdrecord: Continuing in 5 seconds... Cdrecord-ProDVD-Clone 2.01b31 (i686-pc-linux-gnu) Copyright (C) 1995-2004 Jörg Schilling Unlocked features: Limited features: TOC Type: 1 = CD-ROM scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Linux sg driver version: 3.1.25 Using libscg version 'schily-0.8'. Driveropts: 'burnfree' SCSI buffer size: 64512 atapi: 1 Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'HL-DT-ST' Identifikation : 'DVDRAM GSA-4082B' Revision : 'A201' Device seems to be: Generic mmc2 DVD-R/DVD-RW. Current: CD-RW Profile: DVD-RAM Profile: DVD-R sequential recording Profil
Re: cdrtools-2.01a37 ready
On Fri, Aug 20, 2004 at 03:49:28PM +0200, Joerg Schilling wrote: > How do you believe that you may run cdrecord without root privs without > compromising the security of the whole system? On OpenBSD, members of the operator group are allowed to reboot the system, change tapes ... normal things that someone trusted to operate the system would be allowed to do. Letting them write to CD/DVD is very low on the scale of bad things they could already do, like boot into single user mode and mess with all kinds of stuff, and so does not further compromise the security of the system. There is virtually no way anyone could escalate their privileges by simply allowing them to write to a CD device. On linux I have a cdwrite group that is allowed to write to the CD device, and I add users who I trust with that privilege to that group. But having suid binaries gives _anyone_ the possibility of escalating to root. This has already happened to the very software we are talking about. Using the suid bit takes away all the fine grained "access control". Security is based on trust. I don't have time to read all the code for every program on my system, so since I don't know it, I don't trust it. I do know the people who are going to be writing to the CD device, and I trust my judgement of their intentions. -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
Volker Kuhlmann <[EMAIL PROTECTED]> wrote: > > cdrecod. The ProDVD binaries just behave the same as the > > cdrecord compiled from the GPLd part of the source in case you > > do not like to get more functionality than the GPLd source includes. > > Except for the time bomb? Try to keep yourself informed before posting... Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
Volker Kuhlmann <[EMAIL PROTECTED]> wrote: > > Volker > > > > I would have provided cdrecord packages, alas I never had problems with > > the SuSE-supplied ones, therefore no point spending time on it. > > > > The binary (with DVD patch, disclaimer and all) which i > > found after system installation did not work setuid root. > > Since that method is advised by the man who must know, > > i will not advise my users to do it different. > > That is a matter of opinion, of course. I dislike suid programs, and > have only Jörg's word that it'll be ok. On the other hand I have a > binary which is modified to not require suid, which seems the better > concept to me in any case. How do you believe that you may run cdrecord without root privs without compromising the security of the whole system? > If Jörg wants me to believe he's better than the SuSE security team > (who have a bigger reputation to lose), he will have to supply better If Suse has a security team, it is a joke Last year, I have been contacted by Suse (after I send out angry news postings about broken and non-functional SuSE cdrecord binaries). The person on question did point be to a possible printf format string problem in libscg. but: He also informed me about SuSE's Resource manager patch and send me a pointer to the related source code. After I send him a reply that did explained why the SuSE resource manager is a security risk itsef I got no further reply :-( Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> cdrecod. The ProDVD binaries just behave the same as the > cdrecord compiled from the GPLd part of the source in case you > do not like to get more functionality than the GPLd source includes. Except for the time bomb? Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
[EMAIL PROTECTED] wrote: > >>> come up with suggestions how to force SuSE to follow the GPL again. > >>> Jörg > >>How about providing operational binaries for > >>SuSE users at the cdrtools download site ? > > > > ... just check: > > > >ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ > > > > I meant vanilla cdrecord for CD. > > As produced by compiling the official cdrtools source > tar balls on an official SuSE system (with a little > help by the compiling SuSE user). > 100 % GPL by refering to the source archive. > Documenting any changes which became inavoidable > and have been authorized by you, of course. > > No DVD, no special license, just a service for people > who have difficulties compiling but want to work with > the original thing and not a hack. There is only one cdrecord and I am _only_ testing the complete cdrecod. The ProDVD binaries just behave the same as the cdrecord compiled from the GPLd part of the source in case you do not like to get more functionality than the GPLd source includes. > The binary (with DVD patch, disclaimer and all) which i > found after system installation did not work setuid root. > Since that method is advised by the man who must know, > i will not advise my users to do it different. > Thus, the SuSE 9.0 "cdrecord" has to be replaced after > system installation or the users need to become superuser > to backup their data. > Really not my kind of usage model. And I received a lot of mail because of the bugs in the SuSE-9.0 binaries. > I would be glad to point to a link on the cdrtools site where > an original cdrecord binary could be obtained. > I will not publish my own binary without Joerg's permission, > because it is not from 100% original sources and i will not > start another surplus fork of cdrecord (even if it's only > about one #define HZ 100 to make it compile). Just download from ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Fri, Aug 20, 2004 at 08:10:12AM +0200, [EMAIL PROTECTED] wrote: > Volker Kuhlmann> > > Let's not forget that there are 2 separate changes SuSE makes: the DVD > > addons (daft, and I've told them so), > > About that i don't care much. > growisofs covers all my DVD needs. > > I understand, though, that these DVD "addons" are an > unfriendly gesture towards the only person who > provides CD burning on Linux and several other OSs. > > I mean, if one wants to show Joerg the middle finger > then please not by constantly forking his alpha > versions but by bringing a decent Unix style write > device for data CD into the standard kernel > - just for an example. > > > > the SuSE security team (who have a bigger reputation to lose) > > There is a security team with SuSE ? (chuckle) > > Well, at least somebody must be in charge to write > advisories like this one : > > Announcement-ID:SuSE-SA:2004:011 > Date: Thursday, May 6th 2004 22:30 MEST > Affected products: SUSE LINUX 9.1 Personal Edition Live CD > Vulnerability Type: remote root access > Severity (1-10):8 > SuSE default package: yes > http://www.linuxsecurity.com/advisories/suse_advisory-4305.html > > In that light and if i have to choose ... > ... i'll bet on Joerg. :)) really? the bug in 2.0 was only exploitable if suid. I don't know why people in this day and age still want to allow any user to run any amount of code with root privileges. face it, all software sucks; eventualy you will make a mistake. why put yourself at risk? > > > and the removal of the suid requirement. > > Exactly with that, SuSE 9.0 failed. > I would not call it "removal of the suid requirement" > if it does not work for normal users with or without > suid. > You take an old version from SuSE 7.2 and all is well. > > My software is a parasite on cdrtools and growisofs. > I am strongly interested in a low percentage of > non-working installations of both. The cdrtools hacks > produce a substantial amount of those, i can assure > you. > > > > Compiles OOTB on 9.1 > > Compiler problems come and go with versions of cdrecord > and Linux. > For a while i could safely point towards the distribution > binaries. But meanwhile i can only wish good luck. > > > Have a nice day :) > > Thomas > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
Volker Kuhlmann> > Let's not forget that there are 2 separate changes SuSE makes: the DVD > addons (daft, and I've told them so), About that i don't care much. growisofs covers all my DVD needs. I understand, though, that these DVD "addons" are an unfriendly gesture towards the only person who provides CD burning on Linux and several other OSs. I mean, if one wants to show Joerg the middle finger then please not by constantly forking his alpha versions but by bringing a decent Unix style write device for data CD into the standard kernel - just for an example. > the SuSE security team (who have a bigger reputation to lose) There is a security team with SuSE ? (chuckle) Well, at least somebody must be in charge to write advisories like this one : Announcement-ID:SuSE-SA:2004:011 Date: Thursday, May 6th 2004 22:30 MEST Affected products: SUSE LINUX 9.1 Personal Edition Live CD Vulnerability Type: remote root access Severity (1-10):8 SuSE default package: yes http://www.linuxsecurity.com/advisories/suse_advisory-4305.html In that light and if i have to choose ... ... i'll bet on Joerg. :)) > and the removal of the suid requirement. Exactly with that, SuSE 9.0 failed. I would not call it "removal of the suid requirement" if it does not work for normal users with or without suid. You take an old version from SuSE 7.2 and all is well. My software is a parasite on cdrtools and growisofs. I am strongly interested in a low percentage of non-working installations of both. The cdrtools hacks produce a substantial amount of those, i can assure you. > Compiles OOTB on 9.1 Compiler problems come and go with versions of cdrecord and Linux. For a while i could safely point towards the distribution binaries. But meanwhile i can only wish good luck. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> Volker > > > I would have provided cdrecord packages, alas I never had problems with > the SuSE-supplied ones, therefore no point spending time on it. > > The binary (with DVD patch, disclaimer and all) which i > found after system installation did not work setuid root. > Since that method is advised by the man who must know, > i will not advise my users to do it different. That is a matter of opinion, of course. I dislike suid programs, and have only Jörg's word that it'll be ok. On the other hand I have a binary which is modified to not require suid, which seems the better concept to me in any case. If Jörg wants me to believe he's better than the SuSE security team (who have a bigger reputation to lose), he will have to supply better information than the exceptionally uninformative "it's defective", "you shouldn't use it", "they don't know what they're talking about" when asked about it. Answers like those don't give me the impression I want to trust that person in security matters thanks all the same. Let's not forget that there are 2 separate changes SuSE makes: the DVD addons (daft, and I've told them so), and the removal of the suid requirement. Jörg may have a different opinion about the latter, but he'll have to learn to accept that others don't share his. Dito for other technical matters. > because it is not from 100% original sources and i will not > start another surplus fork of cdrecord (even if it's only > about one #define HZ 100 to make it compile). Compiles OOTB on 9.1, though I never used it to actually burn anything. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
>>> come up with suggestions how to force SuSE to follow the GPL again. >>> Jörg >>How about providing operational binaries for >>SuSE users at the cdrtools download site ? > > ... just check: > >ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ > I meant vanilla cdrecord for CD. As produced by compiling the official cdrtools source tar balls on an official SuSE system (with a little help by the compiling SuSE user). 100 % GPL by refering to the source archive. Documenting any changes which became inavoidable and have been authorized by you, of course. No DVD, no special license, just a service for people who have difficulties compiling but want to work with the original thing and not a hack. Volker > > I would have provided cdrecord packages, alas I never had problems with the SuSE-supplied ones, therefore no point spending time on it. The binary (with DVD patch, disclaimer and all) which i found after system installation did not work setuid root. Since that method is advised by the man who must know, i will not advise my users to do it different. Thus, the SuSE 9.0 "cdrecord" has to be replaced after system installation or the users need to become superuser to backup their data. Really not my kind of usage model. I would be glad to point to a link on the cdrtools site where an original cdrecord binary could be obtained. I will not publish my own binary without Joerg's permission, because it is not from 100% original sources and i will not start another surplus fork of cdrecord (even if it's only about one #define HZ 100 to make it compile). Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Thu 19 August 2004 14:35, Joerg Schilling wrote: > From: Volker Kuhlmann <[EMAIL PROTECTED]> > > >Obviously you're on the back foot and ran out of arguments, > > otherwise you wouldn't spend a whole email on discussing a > > minor point (so I didn't check my PPS carefully enough) and > > nothing else, instead of sticking to the 2 points in question. > > And so that even you can understand it: introducing bugs is not > > a violation of the GPL. It's a right of the GPL. > > You still did not understand the problem :-( > > A program is an artwork (this is what the European Union did > write into laws). Since both you and SuSE are in Germany, I would think that German law would apply. There are of course the Berne treaty and the EU Copyright Directive, but neither are laws. In the case of the EUCD, it is up to the member states to make local laws that implement the EUCD. Incidentally, which law are you referring to? I couldn't really find anything in the text of the EUCD. > Even though you may get the permission to modify an artwork, you > will not get the permission to create bad carricatures and call > them just "modified versions". > > The GPL requires you not to impact the original authors' > reputations, but this is what they are doing by publishing > defective variants. Which is why they stick a big notice on it that literally says that they changed it and that they may have introduced new bugs. The problem is that people don't read the notice, and then start bothering you. But can you really blame SuSE for that? What more can they do about it? Send over an employee to each buyer to explain the situation? Lourens PS: congratulations on the new mail client. It's much better. -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a37 ready
>From: [EMAIL PROTECTED] >> come up with suggestions how to force SuSE to follow the GPL again. >> Jörg >How about providing operational binaries for >SuSE users at the cdrtools download site ? If you would look a bit to the left and to the right before posting, you would know that this is true since August 2001, just check: ftp://ftp.berlios.de/pub/cdrecord/ProDVD/ Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> >Obviously you're on the back foot and ran out of arguments, otherwise >you wouldn't spend a whole email on discussing a minor point (so I >didn't check my PPS carefully enough) and nothing else, instead of >sticking to the 2 points in question. And so that even you can >understand it: introducing bugs is not a violation of the GPL. It's a >right of the GPL. You still did not understand the problem :-( A program is an artwork (this is what the European Union did write into laws). Even though you may get the permission to modify an artwork, you will not get the permission to create bad carricatures and call them just "modified versions". The GPL requires you not to impact the original authors' reputations, but this is what they are doing by publishing defective variants. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> How about providing operational binaries for > SuSE users at the cdrtools download site ? I would have provided cdrecord packages, alas I never had problems with the SuSE-supplied ones, therefore no point spending time on it. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> then why all the griping about GPL violations? If this question is in my direction: because I got fed up with constant and annoying gripes about GPL violations by someone who can't even point to a reasonable actual violation[1] and then can't comply himself[2]. Besides, I'd like to know the license status of cdrecord, and I mightn't be the only one. Volker [1] Users don't look at the source. Programmers who do, find all of SuSE's changes cleanly separated in patch files. Frankly I'm not going to waste any time on whether source files should be marked too (it's nitpicky at best), especially as Jörg hasn't even requested it. And I sure asked! [2] No disputes from anyone yet -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> come up with suggestions how to force SuSE to follow the GPL again. > Jörg How about providing operational binaries for SuSE users at the cdrtools download site ? That would help the little SuSE users because they do not have to cope with the compile time problems. That would consolidate the cdrecord fork bush because the SuSE binaries are not always operational and many little SuSE users would have reason to use your official binaries. At least SuSE would have to take the blame that the original author (and some of his users) had to take action to substitute their unnecessary hacks. (I agree with Lourens : anybody who wants to burn DVD and who does not like cdrecord's DVD license terms may use growisofs. SuSE 9.0's growisofs 5.12 binary does work.) Have a nice day :) Thomas PS: Joerg, the message about "Operation not permitted. WARNING: Cannot set RR-scheduler" is probably not due to source changes. I had it with an original cdrtools-2.01a19 which i compiled on SuSE 7.2. On SuSE 7.2 it ran without complains and on SuSE 9.0 it issued said message (setuid root). No real problems when burning, though. A cdrecord 1.6 binary compiled static on Debian in 1999 still works on SuSE 9.0 without any problems. Nowadays it is nearly impossible to produce binaries that are portable from Intel Linux to Intel Linux. DLLs. Pffft. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> However, none of this is the issue. What Jörg is getting worked up > about is that he gets email from people complaining about bugs in a > version of his software that he has nothing to do with (neither > that version of cdrecord nor the bugs). That's the real issue. I can totally sympathise with Jörg on this one. However, wielding the legal hammer is only going to get everyone worked up, Jörg included. Surely this problem is not uniqe to cdrecord. Wouldn't putting up a (user-friendly) web page explaining the problem and returning emails not about Jörg's version of cdrecord with a pointer to this page be a lot more productive? > Personally, I wish everyone would just use growisofs to burn DVDs. > It's FSF-free, Debian-free, and open source, and it's completely > unrelated to cdrecord. And it's well-supported and it works. Couldn't agree more!! Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Thu, Aug 19, 2004 at 08:47:50AM +0200, Lourens Veen wrote: > On Thu 19 August 2004 07:51, Jacob Meuser wrote: > > > > I doubt any government regards the GPL as an entity, so the GPL > > has no rights. the GPL is a contract; following the GPL gives > > entities rights. SuSE can release a really buggy version of > > anything covered by the GPL, as long as they are complying with > > the terms of the GPL. what I don't get, is that if Joerg is so > > sure SuSE is in violation, why doesn't he just take them to > > court. that's why the GPL exists; so people can be made to > > comply or pay the consequences. it's not about freedom, it's > > about control. > > That's not the point. By printing out that notice, SuSE does comply > with the spirit of the GPL (that preamble clause about protecting > the author) and by not clearly marking the source code files they > may be violating the letter of the GPL. > > However, none of this is the issue. What Jörg is getting worked up > about is that he gets email from people complaining about bugs in a > version of his software that he has nothing to do with (neither > that version of cdrecord nor the bugs). That's the real issue. then why all the griping about GPL violations? -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Thu 19 August 2004 07:51, Jacob Meuser wrote: > > I doubt any government regards the GPL as an entity, so the GPL > has no rights. the GPL is a contract; following the GPL gives > entities rights. SuSE can release a really buggy version of > anything covered by the GPL, as long as they are complying with > the terms of the GPL. what I don't get, is that if Joerg is so > sure SuSE is in violation, why doesn't he just take them to > court. that's why the GPL exists; so people can be made to > comply or pay the consequences. it's not about freedom, it's > about control. That's not the point. By printing out that notice, SuSE does comply with the spirit of the GPL (that preamble clause about protecting the author) and by not clearly marking the source code files they may be violating the letter of the GPL. However, none of this is the issue. What Jörg is getting worked up about is that he gets email from people complaining about bugs in a version of his software that he has nothing to do with (neither that version of cdrecord nor the bugs). That's the real issue. Personally, I wish everyone would just use growisofs to burn DVDs. It's FSF-free, Debian-free, and open source, and it's completely unrelated to cdrecord. And it's well-supported and it works. Lourens -- GPG public key: http://home.student.utwente.nl/l.e.veen/lourens.key
Re: cdrtools-2.01a37 ready
On Thu, Aug 19, 2004 at 04:36:05PM +1200, Volker Kuhlmann wrote: > On Thu 19 Aug 2004 12:03:07 NZST +1200, Joerg Schilling wrote: > > > you are nothing but a moron that has no clue and that is not even willing to do > > a comparison test with the real cdrecord because you are in fear that you might > > see immediately where the differences are :-( > > Yes, those differences (that SuSE does say clearly they've made mods) > were the point. Who's the moron here? > > Obviously you're on the back foot and ran out of arguments, otherwise you obviously have too much time on your hands. > you wouldn't spend a whole email on discussing a minor point (so I > didn't check my PPS carefully enough) but you used it to take a shot at Joerg; that's not all he wrote about, not that it was necessarily relevant to GPL violations. > and nothing else, instead of > sticking to the 2 points in question. And so that even you can > understand it: introducing bugs is not a violation of the GPL. It's a > right of the GPL. I doubt any government regards the GPL as an entity, so the GPL has no rights. the GPL is a contract; following the GPL gives entities rights. SuSE can release a really buggy version of anything covered by the GPL, as long as they are complying with the terms of the GPL. what I don't get, is that if Joerg is so sure SuSE is in violation, why doesn't he just take them to court. that's why the GPL exists; so people can be made to comply or pay the consequences. it's not about freedom, it's about control. > I'm still waiting for your comment on your own GPL violation(s). > Silence is for the guilty. ever wonder why Joerg is "uncooperative" to you? don't bother to answer that. everyone on the list already knows you don't really care what Joerg says, when you quote him like "blah ...". I don't know why you all don't just ditch the GPL. obviously it is bloated fluffy unintelligible legalese that just causes confusion and gives people something to whine about. so either take it to court, or quit whining, please. -- <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
On Thu 19 Aug 2004 12:03:07 NZST +1200, Joerg Schilling wrote: > you are nothing but a moron that has no clue and that is not even willing to do > a comparison test with the real cdrecord because you are in fear that you might > see immediately where the differences are :-( Yes, those differences (that SuSE does say clearly they've made mods) were the point. Who's the moron here? Obviously you're on the back foot and ran out of arguments, otherwise you wouldn't spend a whole email on discussing a minor point (so I didn't check my PPS carefully enough) and nothing else, instead of sticking to the 2 points in question. And so that even you can understand it: introducing bugs is not a violation of the GPL. It's a right of the GPL. I'm still waiting for your comment on your own GPL violation(s). Silence is for the guilty. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> >It's tempting to say you're an idiot, but it's more polite to say you're >a troll, so I'll say you're a troll. Let me try to comment your junk.. I am sorry but you just verified that you are nothing but a moron that has no clue and that is not even willing to do a comparison test with the real cdrecord because you are in fear that you might see immediately where the differences are :-( >> cat /etc/SuSE-release >SuSE Linux 9.1 (i586) >VERSION = 9.1 >> where cdrecord >/usr/bin/cdrecord >> rpm -qf `where cdrecord` >cdrecord-2.01a27-21 >> cdrecord --version VV >ZY$: Operation not permitted. WARNING: Cannot set RR-scheduler >ZY$: Permission denied. WARNING: Cannot set priority using setpriority(). >ZY$: WARNING: This causes a high risk for buffer underruns. ^^ Guess what this is? It is a bug made by SuSE! The original cdrecord will not spit out this junk for useless conditions as for command lines like 'cdrecord -version'. The string "ZY$:" in addition is caused by SuSE too, because they are using uninitialized variables. >Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling >Note: This version is an unofficial (modified) version with DVD support >Note: and therefore may have bugs that are not present in the original. >Note: Please send bug reports or support requests to http://www.suse.de/feedback >Note: The author of cdrecord should not be bothered with problems in this version. As I did already write several times: The DVD patch that SuSE is using is ignoring the data structures of cdrecord and thus definitely does not work correctly even for CDs. The text "may have bugs" is inapropriate as the SuSE binary definitely has bugs. Did you ever try out whether SuSEs junkware gives warnings for not being root when called with things different from cdrecord -version? I did never see the setpriority warnings in the mail I receive from unsatisfied SuSE customers. I do not judge from things you send here but from quoted text I receive from SuSE customers. But maybe the reason why I get mail from unsartisfied SuSE customers is that http://www.suse.de/feedback just a black hole? Why is there no similar mail from Debian users? Debian behaves different: 1) They (Debian) give support 2) They do not apply the defective DVD patch by default but let it apply theyr users if they like to compile and try it out. 3) If _they_ (Debian) have problems, they contact me for help. PS: as a nice side effect of Linux-2.6.8, SuSEs broken version will stop working as they try to avoid to be root which is now definitely needed ,-) PPS: Wer im Steinhaus sitzt soll nicht mit Gläsern werfen.. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> There is absolutely no doubt that SuSE is violating GPL. > > /*--*/ > Also, for each author's protection and ours, we want to make certain > that everyone understands that there is no warranty for this free > software. If the software is modified by someone else and passed on, we > want its recipients to know that what they have is not the original, so > that any problems introduced by others will not reflect on the original > authors' reputations. > /*--*/ > > Is very explicit and unabigouous. It's tempting to say you're an idiot, but it's more polite to say you're a troll, so I'll say you're a troll. > cat /etc/SuSE-release SuSE Linux 9.1 (i586) VERSION = 9.1 > where cdrecord /usr/bin/cdrecord > rpm -qf `where cdrecord` cdrecord-2.01a27-21 > cdrecord --version ZY$: Operation not permitted. WARNING: Cannot set RR-scheduler ZY$: Permission denied. WARNING: Cannot set priority using setpriority(). ZY$: WARNING: This causes a high risk for buffer underruns. Cdrecord-Clone-dvd 2.01a27 (i686-suse-linux) Copyright (C) 1995-2004 Jörg Schilling Note: This version is an unofficial (modified) version with DVD support Note: and therefore may have bugs that are not present in the original. Note: Please send bug reports or support requests to http://www.suse.de/feedback Note: The author of cdrecord should not be bothered with problems in this version. About as clear as can be that SuSE is complying with, as I said before, your silly whinging about preamble subclause bla bla. Now that we have established that SuSE is not violating the GPL, do you have any comments on your own violations? Volker PS: No normal user looks at the source. PPS: Some software has an obvious option to spit its version without a barf. PPPS: Ever wondered why your pet targets, the kernel developers and SuSE, seem to be "uncooperative"? -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
JS> There is absolutely no doubt that SuSE is violating GPL. JS> JS> /*--*/ JS> Also, for each author's protection and ours, we want to make certain JS> that everyone understands that there is no warranty for this free JS> software. If the software is modified by someone else and passed on, we JS> want its recipients to know that what they have is not the original, so JS> that any problems introduced by others will not reflect on the original JS> authors' reputations. JS> /*--*/ JS> JS> Is very explicit and unabigouous. This is the explaining preambula. The corresponding sentence in actual terms and conditions is like this: - You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change. - I downloaded cdrecord-2.01a27-21.src.rpm from SuSE 9.1 and had a look at the patches. And yes, the modified files don't carry prominent notices. Most modified files don't carry any notices. There is a big-enough notice at program startup AFAICS: Note: Please send bug reports or support requests to http://www.suse.de/feedback So it's about as good as Debian. Not exatly as good though: Debian seems to define SOURCE_MODIFIED so this displays some additional more prominent notices. Jörg, would it be enough if Suse would define this in their patches (I'm not speaking for Suse, just offering a possible suggestion)? -- Meelis Roos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> >> Give a better method do deal with the GPL violations. >There is absolutely no doubt that you are violating the GPL. SuSE is >not, let me remind you firmly that the GPL grants the right to make >changes, which you seem to conveniently ignore. SuSE even marks their >version clearly, yielding to your stupid antics. There is absolutely no doubt that SuSE is violating GPL. /*--*/ Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations. /*--*/ Is very explicit and unabigouous. As I receive many mails that state cdrecord is defective (which is not true for the original cdrecrod but for the patched by SuSE cdrecord) there is no way to deny the GPL violation from SuSE. Instead of writing mails like the above one, it would help more if you would come up with suggestions how to force SuSE to follow the GPL again. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> Why do you believe that a test that only hits people that are already known > for violating the GPL (SuSE) is a problem? > > Give a better method do deal with the GPL violations. There is absolutely no doubt that you are violating the GPL. SuSE is not, let me remind you firmly that the GPL grants the right to make changes, which you seem to conveniently ignore. SuSE even marks their version clearly, yielding to your stupid antics. Besides, becoming illegal is an interesting, but no excusable, response. Wer im Glashaus sitzt, ... Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
Joerg Schilling wrote: From: Volker Kuhlmann <[EMAIL PROTECTED]> What do you think chances are of people upgrading to a version of cdrecord which is non-GPL and grossly violates the terms of the GPL? As you perpetually whinge about people not complying with clause blabla of the GPL, violating the GPL yourself gives the impression that you don't know what you're talking about. Why do you believe that a test that only hits people that are already known for violating the GPL (SuSE) is a problem? Give a better method do deal with the GPL violations. Ah, software vigilante!! -- Until later, Geoffrey Registered Linux User #108567 AT&T Certified UNIX System Programmer - 1995 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
>From: Volker Kuhlmann <[EMAIL PROTECTED]> >What do you think chances are of people upgrading to a version of >cdrecord which is non-GPL and grossly violates the terms of the GPL? As >you perpetually whinge about people not complying with clause blabla of >the GPL, violating the GPL yourself gives the impression that you don't >know what you're talking about. Why do you believe that a test that only hits people that are already known for violating the GPL (SuSE) is a problem? Give a better method do deal with the GPL violations. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: cdrtools-2.01a37 ready
> It is unlikely that there will be anothe test release after cdrtools-2.01a37 What do you think chances are of people upgrading to a version of cdrecord which is non-GPL and grossly violates the terms of the GPL? As you perpetually whinge about people not complying with clause blabla of the GPL, violating the GPL yourself gives the impression that you don't know what you're talking about. cdrecord.c: * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License [plus see file cdrtools-2.01/COPYING in the source tar file] ... * You are not allowed to modify or remove the call to "linuxcheck()". ... * You are not allowed to modify or remove the following code. each time followed by some really sad excuse of why you have to violate the GPL. Volker -- Volker Kuhlmann is possibly list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cdrtools-2.01a37 ready
NEW features of cdrtools-2.01a37: Note that we are close before publishing release 2.01 final. Please test for problems that might make the cdrtools unusable. It is unlikely that there will be anothe test release after cdrtools-2.01a37 All: - Added a Note to README.linux: NOTE for all Linux 2.5.x versions and all Linux versions before 2.6.8: Linux did ship with defective kernel include files starting with 2.5.x. These defective kernel include files did prevent compilation. If you have problems compiling software and see error messages related to include/scsi/scsi.h & include/scsi/sg.h either upgrade to Linux-2.6.8 or newer or remove /usr/src/linux Libparanoia (Ported by Jörg Schilling, originated by Monty [EMAIL PROTECTED]): - Avoid buffer size problems wit non page aligned transfers on FreeBSD. A last minor problem has been removed. Libedc (Optimized by Jörg Schilling, originated by Heiko Eißfeldt [EMAIL PROTECTED]): Libscg: Rscsi: Cdrecord: - Make some symbold static to avoid problem with a badly designed libc on OpenBSD that violates POSIX by pulluting the namespace with symbols like 'pl'. Cdda2wav (By Heiko Eißfeldt [EMAIL PROTECTED]): Readcd: Scgcheck: Scgskeleton: Mkisofs (By Jörg Schilling and James Pearson [EMAIL PROTECTED]): TODO: - read Joliet filenames with multi-session if no TRANS.TBL or RR is present. I am looking for a volouteer for this task! Note that this can never be 100% correct as there is no relation between the names on the master (UNIX) filesystem, the ISO-9660 names and the Joliet names. Only the Rock Ridge names are untranslated with respect to the original files on the master (UNIX) filesystem. - add libecc/edc for CDI and similar. CYGWIN NT-4.0 NOTES: To compile on Cygwin32, get Cygwin and install it. For more information read README.win32 The files are located on: ftp://ftp.berlios.de/pub/cdrecord/alpha ... NOTE: These tar archives are 100% POSIX compatible. GNU tar may get some minor trouble. If you like a 100% POSIX compliant tar, get star from ftp://ftp.berlios.de/pub/star/ WARNING: Do not use 'winzip' to extract the tar file! Winzip cannot extract symbolic links correctly. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) If you don't have iso-8859-1 [EMAIL PROTECTED](work) chars I am J"org Schilling URL: http://www.fokus.fraunhofer.de/usr/schilling ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
