Thanks
Jim
id dvd+rw-tools installed and what version of K3B are you using
The K3b is 1.0.3 new version, never seen that one before. I kind of
think it is the underlying software not K3b that may be the problem as I
tried Brasero as well with the same results. Dvd+rw-tools is 7.0-49
Thanks
did you look at the rights of your dvd writer (/dev/sr0 or /dev/sr1), I
would guess you don't have write rights
--
Suse 10.3 x64, Kde 3.5.8, Gnome 2.20.0, Opera 9.x weekly
It acts like it writes, because the disc, is rejected if you try to
write to it with another machine, it just apparently is writing garbage.
Jim
My DVD stopped burning too however this was just before burning the third CD
(which I needed for another older machine). It turned out to be the DVD
burner itself. Can you test it with another LiveCD/DVD OS, or have you
done that already? Coincidences do happen.
--
Later,
Darrell Stec dar...@neo.rr.com
Webpage Sorcery
http://webpagesorcery.com
We Put the Magic in Your Webpages
I burned a CD with it, it burned fine, is it the same burner that burns
both?
Is this something to do with the problem?
http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#14
Perhaps you can find help at the cdrkit site
JohnK
JohnK
>
> Is this something to do with the problem?
>
> http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#14
>
> Perhaps you can find help at the cdrkit site
>
> http://www.cdrkit.org/
>
> JohnK
>
> JohnK
More on the issue here...
http://cdrecord.berlios.de/old/private/linux-dist.html
JohnK
It is actually working now. I had to slow the burner all the way down to
4x. When I did that it statred burning correctly. Everything else is
also working ok now.
Thanks
Jim
Don't believe everything you read. Somethings are true
and somethings are blatantly false. Somebody has
an axe to grind and spends a lot of time grinding it.
Somebody believes the GPL is inherently evil in all
"forms". Somebody wants to profit from their work (which
isn't wrong... just need to understand the motives).
Some people accept community involvement and others
whine when people are FORCED to do things because
somebody really didn't want anyone to help them (they
aren't really FOSS supporters... just glory seekers).
question is your dvd drive an old one because if i remember correctly that i
could not rip or burn a dvd so i got a new one and all was ok
Suse now comes with wodim instead of cdrecord.
While cdrecord supports to write DVDs, wodim does not really.....
I recommend to first upgrade to a recent original free cdrtools version
from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
Make sure to install cdrecord, readcd & cdda2wav suid root.
If you still have problems with programs like K3b, remove the file
/bin/wodim and replace it by a symbolic link to /bin/cdrecord.
This may be needed in case that somebody did modify the k3b sources
to not search for cdrecord anymore.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni)
schi...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>> Perhaps you can find help at the cdrkit site
>>
>> http://www.cdrkit.org/
>>
>> JohnK
>>
>> JohnK
>
>It is actually working now. I had to slow the burner all the way down to
>4x. When I did that it statred burning correctly. Everything else is
>also working ok now.
Instead of using the unmaintained wodim that does not even correctly support
DVDs, you should upgrade to the free original from:
ftp://ftp.berlios.de/pub/cdrecord/alpha/
>> More on the issue here...
>>
>> http://cdrecord.berlios.de/old/private/linux-dist.html
>>
>> JohnK
>
>Don't believe everything you read. Somethings are true
>and somethings are blatantly false. Somebody has
>an axe to grind and spends a lot of time grinding it.
>Somebody believes the GPL is inherently evil in all
>"forms". Somebody wants to profit from their work (which
>isn't wrong... just need to understand the motives).
It is bad to see that a few people at Debian try to attack
a free software project in order to get personal profit.
I believe that this is not OK.
>Some people accept community involvement and others
>whine when people are FORCED to do things because
>somebody really didn't want anyone to help them (they
>aren't really FOSS supporters... just glory seekers).
Correct: The people behind cdrkit are definitely no FOSS supporters
and it is bad to see that companies like Novel/Suse follow them.
> If you still have problems with programs like K3b, remove the file
> /bin/wodim and replace it by a symbolic link to /bin/cdrecord.
> This may be needed in case that somebody did modify the k3b sources
> to not search for cdrecord anymore.
That could be awkward, in some distros cdrecord is a link to wodim:
$ ls -l /usr/bin/cdrecord
lrwxrwxrwx 1 root root 5 2007-09-03 06:43 /usr/bin/cdrecord -> wodim
More to the point, in't there some way that the feud between you and the
LKML, and the one between you and the FSF, could be resolved without anyone
getting hurt?
I met you once, years ago, and you seemed perfectly reasonable then, but
in the mean time there have obviously been some issues that have gotten
seriously under your skin. Even so, how much flexibility and goodwill
on either side would it take to resolve them? Not much, AFAICSFH.
This is why I did recommend to first replace this link with a real cdrecord
binary...
>More to the point, in't there some way that the feud between you and the
>LKML, and the one between you and the FSF, could be resolved without anyone
>getting hurt?
I am not aware of such a feud.
Some years ago, there was some kind of unwillingness on LKML to cooperate
but this seems to have changed about a year ago. Meanwhile a long awaited bug
fix for SCSI DMA size is in Linux and even the Linux kernel include files
are being fixed the way I did propose years ago. It seems that I was too
early with my proposals to get understood immediately.
I know of no problem with the FSF.
>I met you once, years ago, and you seemed perfectly reasonable then, but
>in the mean time there have obviously been some issues that have gotten
>seriously under your skin. Even so, how much flexibility and goodwill
>on either side would it take to resolve them? Not much, AFAICSFH.
It seems that some people who don't know me started to fight against me
but this may be the result of being well known. I am sure that these people
will disappear soon.
>In article <13i5jj0...@corp.supernews.com>,
>Jim Jones <"okieman7 At cableone dot net"> wrote:
>>My Dvd burner worked great with Suse 10.0, but when I completely blew
>>the machine away and did a fresh install with OpenSuse 10.3 all at once
>>it'll read but not burn. Are there any know bugs that cause K3b to not
>>burn DVD's in 10.3?
Not that I've seen. Try checking the permissions of the writer. It could
be they aren't set to allow writing. Check to see if you're a member of
the correct group. On my 10.3 installation, I added my user to group
disk, my dvd device is owned by root.disk with permissions 660, and I
have no problems[0] writing to it using k3b, wodim, or growisofs.
>Suse now comes with wodim instead of cdrecord.
The switch occurred between 10.1 and 10.2.
>While cdrecord supports to write DVDs, wodim does not really.....
Strange. I've not had a problem writing the DVDs with wodim. Then again,
I still use cdrecord on 10.1, and I haven't had a problem with that
either.
[0] apart from the fact that the system is too slow to write at anything
faster that 4x without suffering from many buffer underruns.
Regards,
David Bolt
--
www.davjam.org/lifetype/ www.distributed.net: OGR@100Mnodes, RC5-72@15Mkeys
| SUSE 10.1 32bit | openSUSE 10.2 32bit | openSUSE 10.3 32bit
SUSE 10.0 64bit | SUSE 10.1 64bit | openSUSE 10.2 64bit |
RISC OS 3.11 | RISC OS 3.6 | TOS 4.02 | openSUSE 10.3 PPC
i slowed the DVD down to 4x as was suggested in another group and it
started burning just fine. I may have done that before and just don't
recall as I normally use it about once every 9 months or so when the new
OpenSuse GM dvd is ready. Thanks for all the suggestions.
Jim
>> Correct: The people behind cdrkit are definitely no FOSS supporters
>> and it is bad to see that companies like Novel/Suse follow them.
>>
>
>i slowed the DVD down to 4x as was suggested in another group and it
>started burning just fine. I may have done that before and just don't
>recall as I normally use it about once every 9 months or so when the new
>OpenSuse GM dvd is ready. Thanks for all the suggestions.
What do you get with cdrecord -atip with the medium you used?
What do you get with cdrecord -prcap
Note: I am talking about a real recent cdrecord here as "wodim" will not
give you any useful with these options. It may be that you use bad media
or that you turned DMA off.
>The switch occurred between 10.1 and 10.2.
>
>>While cdrecord supports to write DVDs, wodim does not really.....
>
>Strange. I've not had a problem writing the DVDs with wodim. Then again,
>I still use cdrecord on 10.1, and I haven't had a problem with that
>either.
If you only tro to do one of the few supported things from wodim it may
work, but note that the fact that wodim does not support the -atip option
with DVDs verifies that wodim uses guessed parameters instead of parameters
retrieved from your medium. Cdrecord correctly parameterises the values
since March 1998. Wodim ripped off working DVD support and replaced it by
simple and half baken code.
>[0] apart from the fact that the system is too slow to write at anything
>faster that 4x without suffering from many buffer underruns.
As you do not give any information on your problem, nobody can help you
with this problem.
If you use K3B then it can specify the order of the search path so that
it can use cdrecord in the default /opt/schily install directory instead
of the link /usr/bin/cdrecord to wodim.
Just sayin'
JohnK
>> JohnK
>
> Don't believe everything you read. Somethings are true and somethings
This is all I can really find on the other point of view (other than a
lot of hoohah) ..
http://debburn.alioth.debian.org/FORK
JohnK
Remember: Don't believe everything you read.
What you read in this file is not true and it is full of FUD.
>In article <13id0hv...@corp.supernews.com>,
>Jim Jones <"okieman7 At cableone dot net"> wrote:
>
>>> Correct: The people behind cdrkit are definitely no FOSS supporters
Hmm, the code is released under the GPL but they're not FOSS supporters.
>>> and it is bad to see that companies like Novel/Suse follow them.
>>>
>>
>>i slowed the DVD down to 4x as was suggested in another group and it
>>started burning just fine. I may have done that before and just don't
>>recall as I normally use it about once every 9 months or so when the new
>>OpenSuse GM dvd is ready. Thanks for all the suggestions.
>
>What do you get with cdrecord -atip with the medium you used?
On mine I get:
davjam@lion:~> cdrecord -atip
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identification : 'UJ-840D '
Revision : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Driver flags : SWABAUDIO BURNFREE
Supported modes: PACKET SAO
HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
>What do you get with cdrecord -prcap
And:
davjam@lion:~> cdrecord -prcap
wodim: Operation not permitted. Warning: Cannot raise RLIMIT_MEMLOCK limits.Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identification : 'UJ-840D '
Revision : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Drive capabilities, per MMC-3 page 2A:
Does read CD-R media
Does write CD-R media
Does read CD-RW media
Does write CD-RW media
Does read DVD-ROM media
Does read DVD-R media
Does write DVD-R media
Does read DVD-RAM media
Does not write DVD-RAM media
Does support test writing
Does read Mode 2 Form 1 blocks
Does read Mode 2 Form 2 blocks
Does read digital audio blocks
Does restart non-streamed digital audio reads accurately
Does support Buffer-Underrun-Free recording
Does read multi-session CDs
Does read fixed-packet CD media using Method 2
Does read CD bar code
Does not read R-W subcode information
Does read raw P-W subcode data from lead in
Does return CD media catalog number
Does return CD ISRC information
Does support C2 error pointers
Does deliver composite A/V data
Does play audio CDs
Number of volume control levels: 256
Does support individual volume control setting for each channel
Does support independent mute setting for each channel
Does not support digital output on port 1
Does not support digital output on port 2
Loading mechanism type: tray
Does support ejection of CD via START/STOP command
Does not lock media on power up via prevent jumper
Does allow media to be locked in the drive via PREVENT/ALLOW command
Is not currently in a media-locked state
Does not support changing side of disk
Does not have load-empty-slot-in-changer feature
Does not support Individual Disk Present feature
Maximum read speed: 11080 kB/s (CD 62x, DVD 8x)
Current read speed: 11080 kB/s (CD 62x, DVD 8x)
Maximum write speed: 11080 kB/s (CD 62x, DVD 8x)
Current write speed: 11080 kB/s (CD 62x, DVD 8x)
Rotational control selected: CLV/PCAV
Buffer size in KB: 2048
Copy management revision supported: 1
Number of supported write speeds: 4
Write speed # 0: 11080 kB/s CLV/PCAV (CD 62x, DVD 8x)
Write speed # 1: 8310 kB/s CLV/PCAV (CD 47x, DVD 6x)
Write speed # 2: 5540 kB/s CLV/PCAV (CD 31x, DVD 4x)
Write speed # 3: 3324 kB/s CLV/PCAV (CD 18x, DVD 2x)
Supported CD-RW media types according to MMC-4 feature 0x37:
Does write multi speed CD-RW media
Does write high speed CD-RW media
Does write ultra high speed CD-RW media
Does write ultra high speed+ CD-RW media
davjam@lion:~>
>If you only tro to do one of the few supported things from wodim it may
>work,
Does work. It's not yet failed with me and my systems. That doesn't mean
that it'll work on other peoples systems, but it does work for me.
>but note that the fact that wodim does not support the -atip option
>with DVDs
As posted in another reply:
davjam@lion:~> cdrecord -atip
Device was not specified. Trying to find an appropriate drive...
Detected CD-R drive: /dev/cdrw
Using /dev/cdrom of unknown capabilities
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identification : 'UJ-840D '
Revision : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
Driver flags : SWABAUDIO BURNFREE
Supported modes: PACKET SAO
HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
As to whether this is useful or not, so far wodim hasn't had a problem
writing to DVDs on my systems.
>verifies that wodim uses guessed parameters instead of parameters
>retrieved from your medium. Cdrecord correctly parameterises the values
>since March 1998. Wodim ripped off working DVD support and replaced it by
>simple and half baken code.
For half-baked code, it sure seems to do the job. And even if it didn't,
I don't need to use either wodim or cdrecord as growisofs is quite
capable of writing DVDs.
>>[0] apart from the fact that the system is too slow to write at anything
>>faster that 4x without suffering from many buffer underruns.
>
>As you do not give any information on your problem, nobody can help you
>with this problem.
I stated that the system I used is too slow to use at anything higher
than a 4x write speed, and if there is a problem it is purely down to
that. I didn't say that I had a problem with this, as I don't. However,
to fill you in on why the system is too slow to handle more that a 4x
write speed, here's the hardware details:
The system in question is a 1998 G3 iMac running at a whopping 333Mz.
The CD ROM drive has been replaced with a DVD writer and the original
6GB hard drive has been replaced by a 160GB drive.
With this system, the limiting factor is the IDE bus which tops out at
around 6.7MB/s. Since there is no possibility of speeding it up, there
is no solution to this other than to limit the write speed.
Using growisofs, since it's kind enough to be quite verbose while
writing to disc, here's the output writing the 10.3-PPC-DVD.iso to an 8x
capable blank disc:
davjam@lion:~> growisofs -dvd-compat -Z /dev/dvdrw=/mnt/hda13/openSUSE-10.3-GM-DVD-i386.iso
Executing 'builtin_dd if=/mnt/hda13/openSUSE-10.3-GM-DVD-i386.iso of=/dev/dvdrw obs=32k seek=0'
/dev/dvdrw: "Current Write Speed" is 8.2x1352KBps.
1572864/4405843968 ( 0.0%) @0.0x, remaining 280:00 RBU 100.0% UBU 2.1%
1572864/4405843968 ( 0.0%) @0.0x, remaining 420:01 RBU 100.0% UBU 100.0%
1572864/4405843968 ( 0.0%) @0.0x, remaining 606:42 RBU 100.0% UBU 100.0%
1572864/4405843968 ( 0.0%) @0.0x, remaining 746:42 RBU 100.0% UBU 100.0%
1572864/4405843968 ( 0.0%) @0.0x, remaining 886:43 RBU 100.0% UBU 100.0%
1572864/4405843968 ( 0.0%) @0.0x, remaining 1073:23 RBU 100.0% UBU 100.0%
1572864/4405843968 ( 0.0%) @0.0x, remaining 1213:24 RBU 100.0% UBU 100.0%
3702784/4405843968 ( 0.1%) @0.5x, remaining 574:37 RBU 100.0% UBU 100.0%
14811136/4405843968 ( 0.3%) @2.4x, remaining 163:03 RBU 100.0% UBU 100.0%
25919488/4405843968 ( 0.6%) @2.4x, remaining 101:23 RBU 100.0% UBU 100.0%
37060608/4405843968 ( 0.8%) @2.4x, remaining 76:37 RBU 100.0% UBU 100.0%
48168960/4405843968 ( 1.1%) @2.4x, remaining 64:50 RBU 100.0% UBU 100.0%
59310080/4405843968 ( 1.3%) @2.4x, remaining 56:11 RBU 98.4% UBU 100.0%
70418432/4405843968 ( 1.6%) @2.4x, remaining 50:16 RBU 100.0% UBU 100.0%
81526784/4405843968 ( 1.9%) @2.4x, remaining 46:51 RBU 100.0% UBU 100.0%
92667904/4405843968 ( 2.1%) @2.4x, remaining 43:26 RBU 100.0% UBU 100.0%
103776256/4405843968 ( 2.4%) @2.4x, remaining 40:45 RBU 100.0% UBU 100.0%
114917376/4405843968 ( 2.6%) @2.4x, remaining 39:12 RBU 100.0% UBU 100.0%
126025728/4405843968 ( 2.9%) @2.4x, remaining 37:21 RBU 100.0% UBU 100.0%
137166848/4405843968 ( 3.1%) @2.4x, remaining 35:47 RBU 100.0% UBU 100.0%
148275200/4405843968 ( 3.4%) @2.4x, remaining 34:56 RBU 100.0% UBU 100.0%
159383552/4405843968 ( 3.6%) @2.4x, remaining 33:44 RBU 100.0% UBU 100.0%
170524672/4405843968 ( 3.9%) @2.4x, remaining 32:42 RBU 100.0% UBU 100.0%
181665792/4405843968 ( 4.1%) @2.4x, remaining 32:09 RBU 100.0% UBU 100.0%
192774144/4405843968 ( 4.4%) @2.4x, remaining 31:19 RBU 100.0% UBU 100.0%
203882496/4405843968 ( 4.6%) @2.4x, remaining 30:34 RBU 100.0% UBU 100.0%
215023616/4405843968 ( 4.9%) @2.4x, remaining 30:12 RBU 100.0% UBU 100.0%
226131968/4405843968 ( 5.1%) @2.4x, remaining 29:34 RBU 100.0% UBU 100.0%
237273088/4405843968 ( 5.4%) @2.4x, remaining 28:59 RBU 100.0% UBU 100.0%
248381440/4405843968 ( 5.6%) @2.4x, remaining 28:44 RBU 100.0% UBU 100.0%
259522560/4405843968 ( 5.9%) @2.4x, remaining 28:13 RBU 100.0% UBU 100.0%
270008320/4405843968 ( 6.1%) @2.3x, remaining 28:04 RBU 100.0% UBU 100.0%
271056896/4405843968 ( 6.2%) @0.2x, remaining 28:43 RBU 98.4% UBU 100.0%
279347200/4405843968 ( 6.3%) @1.8x, remaining 28:33 RBU 100.0% UBU 100.0%
297861120/4405843968 ( 6.8%) @4.0x, remaining 27:34 RBU 100.0% UBU 100.0%
316407808/4405843968 ( 7.2%) @4.0x, remaining 26:29 RBU 100.0% UBU 100.0%
334921728/4405843968 ( 7.6%) @4.0x, remaining 25:31 RBU 100.0% UBU 100.0%
353435648/4405843968 ( 8.0%) @4.0x, remaining 24:50 RBU 98.4% UBU 97.9%
371949568/4405843968 ( 8.4%) @4.0x, remaining 24:02 RBU 100.0% UBU 100.0%
.....
1705967616/4405843968 (38.7%) @4.0x, remaining 9:50 RBU 98.4% UBU 97.9%
1724481536/4405843968 (39.1%) @4.0x, remaining 9:44 RBU 100.0% UBU 100.0%
1743028224/4405843968 (39.6%) @4.0x, remaining 9:40 RBU 100.0% UBU 100.0%
1746403328/4405843968 (39.6%) @0.7x, remaining 9:43 RBU 100.0% UBU 100.0%
1755152384/4405843968 (39.8%) @1.9x, remaining 9:42 RBU 100.0% UBU 33.3%
1775468544/4405843968 (40.3%) @4.4x, remaining 9:37 RBU 100.0% UBU 6.2%
1797586944/4405843968 (40.8%) @4.8x, remaining 9:30 RBU 100.0% UBU 14.6%
1817640960/4405843968 (41.3%) @4.3x, remaining 9:23 RBU 100.0% UBU 25.0%
1839759360/4405843968 (41.8%) @4.8x, remaining 9:17 RBU 100.0% UBU 22.9%
1859354624/4405843968 (42.2%) @4.2x, remaining 9:11 RBU 100.0% UBU 20.8%
1879638016/4405843968 (42.7%) @4.4x, remaining 9:05 RBU 98.4% UBU 20.8%
1901461504/4405843968 (43.2%) @4.7x, remaining 9:00 RBU 100.0% UBU 12.5%
1921974272/4405843968 (43.6%) @4.4x, remaining 8:53 RBU 100.0% UBU 4.2%
1943470080/4405843968 (44.1%) @4.7x, remaining 8:47 RBU 100.0% UBU 6.2%
1964277760/4405843968 (44.6%) @4.5x, remaining 8:42 RBU 100.0% UBU 8.3%
1984757760/4405843968 (45.0%) @4.4x, remaining 8:35 RBU 100.0% UBU 6.2%
2006745088/4405843968 (45.5%) @4.8x, remaining 8:29 RBU 100.0% UBU 8.3%
2022932480/4405843968 (45.9%) @3.5x, remaining 8:26 RBU 100.0% UBU 25.0%
2044067840/4405843968 (46.4%) @4.6x, remaining 8:20 RBU 100.0% UBU 10.4%
2065235968/4405843968 (46.9%) @4.6x, remaining 8:14 RBU 100.0% UBU 14.6%
2085683200/4405843968 (47.3%) @4.4x, remaining 8:09 RBU 100.0% UBU 12.5%
2107506688/4405843968 (47.8%) @4.7x, remaining 8:03 RBU 100.0% UBU 6.2%
2128019456/4405843968 (48.3%) @4.4x, remaining 7:57 RBU 100.0% UBU 6.2%
2148073472/4405843968 (48.8%) @4.3x, remaining 7:52 RBU 100.0% UBU 6.2%
.....
4230807552/4405843968 (96.0%) @4.5x, remaining 0:33 RBU 98.4% UBU 14.6%
4250107904/4405843968 (96.5%) @4.2x, remaining 0:29 RBU 100.0% UBU 14.6%
4271144960/4405843968 (96.9%) @4.6x, remaining 0:25 RBU 100.0% UBU 8.3%
4290478080/4405843968 (97.4%) @4.2x, remaining 0:21 RBU 100.0% UBU 14.6%
4311449600/4405843968 (97.9%) @4.5x, remaining 0:17 RBU 100.0% UBU 8.3%
4330749952/4405843968 (98.3%) @4.2x, remaining 0:14 RBU 98.4% UBU 8.3%
4350836736/4405843968 (98.8%) @4.4x, remaining 0:10 RBU 0.0% UBU 20.8%
4368171008/4405843968 (99.1%) @3.8x, remaining 0:07 RBU 100.0% UBU 6.2%
4388913152/4405843968 (99.6%) @4.5x, remaining 0:03 RBU 100.0% UBU 4.2%
builtin_dd: 2151296*2KB out @ average 3.8x1352KBps
/dev/dvdrw: flushing cache
/dev/dvdrw: closing track
/dev/dvdrw: closing disc
As you can see, the IDE bus can't keep up with the drive write speed and
so, without scrapping that system, limiting the write speed is the only
workable option. And all that means is that I have to wait another 7 or
8 minutes for the disc to complete writing. Not exactly a long time, and
I can always find something to do during that time.
There's a LOT of history that isn't present in either "faq" (things
erased from history due to embarrassment I suppose).
Joerg is correct in that his packages are well maintained.
Some of us, of course, had to pay for the privilege... some of
us remember historical things that have been sanitized from the
"faq". :-) Some of us helped fund the hammer that kept slamming
us on the head... live an learn. But with that said, it's a
free country (well... my country is anyway) and I do believe
that people can change and no... I don't expect them to apologize
for past behaviors or their inconsistent viewpoints.... the important
thing is where they are right now.
Right now, cdrtools is free (Joerg's hatred of Linux aside). And you
do have a choice.
This is NOT cdrecord, this is a defective fork that does not support DVDs.
Why don't you read that I wrote?
I asked for the output from the official program.
People who attack free software cannot be FOSS supporters.
The few people from Debian that created the "fork" started to attack the
free cdrtools project about 3 years ago. As a reesult of the FUD they did
spread on the GPL, the license for cdrtools has been changed to a license
that gives more freedom
>>>> and it is bad to see that companies like Novel/Suse follow them.
>>>>
>>>
>>>i slowed the DVD down to 4x as was suggested in another group and it
>>>started burning just fine. I may have done that before and just don't
>>>recall as I normally use it about once every 9 months or so when the new
>>>OpenSuse GM dvd is ready. Thanks for all the suggestions.
>>
>>What do you get with cdrecord -atip with the medium you used?
>
>On mine I get:
>
>davjam@lion:~> cdrecord -atip
>Device was not specified. Trying to find an appropriate drive...
>Detected CD-R drive: /dev/cdrw
>Using /dev/cdrom of unknown capabilities
>Device type : Removable CD-ROM
>Version : 0
>Response Format: 2
>Capabilities :
>Vendor_info : 'MATSHITA'
>Identification : 'UJ-840D '
>Revision : '1.02'
>Device seems to be: Generic mmc2 DVD-R/DVD-RW.
>Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
>Driver flags : SWABAUDIO BURNFREE
>Supported modes: PACKET SAO
>HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
This is NOT cdrecord but the defective fork that does not support DVDs
For this reason, I _explicitly_ asked you for the output from the the official
cdrecord. Are you interested in help? Then you should listen to me....
>There's a LOT of history that isn't present in either "faq" (things
>erased from history due to embarrassment I suppose).
The people around mr. Bloch try to avoid talking about the fact that
they initiated the problem by attacking a free software project.
>Joerg is correct in that his packages are well maintained.
>
>Some of us, of course, had to pay for the privilege... some of
Do you like to spread FUD?
>us remember historical things that have been sanitized from the
>"faq". :-) Some of us helped fund the hammer that kept slamming
>us on the head... live an learn. But with that said, it's a
>free country (well... my country is anyway) and I do believe
>that people can change and no... I don't expect them to apologize
>for past behaviors or their inconsistent viewpoints.... the important
>thing is where they are right now.
It is funny to see that the Linux kernel people now understand that
their view from the past was inconsistent....
>Right now, cdrtools is free (Joerg's hatred of Linux aside). And you
>do have a choice.
Cdrtools is free _and_ was _always_ free and I have no hate against Linux.
I am a supporter of FOSS since more than 20 years, don't try to confuse me
with people who recently started FOSS and still need to learn the background.
http://cdrecord.berlios.de/old/private/cdr-faq.html
http://cdrecord.berlios.de/old/private/dvd-source-why.html
http://cdrecord.berlios.de/old/private/linux-dist.html
There definitely was hate from Linus Torvalds against me - I don't know why...
And there is hate from Mr. Bloch that created the fork. Now the fork is dead
since 6 months. Can hate create free software? I believe no!
Free Linux distributions realized that forcing users to a defective fork
is not freedom and give their user the choice to use the maintained and free
original software. Ubuntu did get rif of all bugs in their database after
providing cdrtols again.
>In article <8ix9zQxE...@dev.null.davjam.org>,
>David Bolt <db...@davjam.org> wrote:
>>On Tue, 30 Oct 2007, Joerg Schilling wrote:-
>>>but note that the fact that wodim does not support the -atip option
>>>with DVDs
I've left that in there.
>>davjam@lion:~> cdrecord -atip
>>Device was not specified. Trying to find an appropriate drive...
>>Detected CD-R drive: /dev/cdrw
>>Using /dev/cdrom of unknown capabilities
>>Device type : Removable CD-ROM
>>Version : 0
>>Response Format: 2
>>Capabilities :
>>Vendor_info : 'MATSHITA'
>>Identification : 'UJ-840D '
>>Revision : '1.02'
>>Device seems to be: Generic mmc2 DVD-R/DVD-RW.
>>Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
>>Driver flags : SWABAUDIO BURNFREE
>>Supported modes: PACKET SAO
>>HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
And the output from wodim using the -atip option.
>This is NOT cdrecord, this is a defective fork that does not support DVDs.
Yes, it's from wodim.
>Why don't you read that I wrote?
I did. And that's why I posted the output.
>I asked for the output from the official program.
You said that wodim didn't support the -atip option. That appears not to
be that case, as wodim didn't return an error saying the option was
unsupported. It also didn't supply the same media information as
cdrtools, as shown here:
davjam@lion:~> sudo /usr/src/packages/SOURCES/cdrtools-2.01.01/cdrecord/OBJ/ppc-linux-cc/cdrecord -atip
root's password:
Cdrecord-ProDVD-ProBD-Clone 2.01.01a36 (powerpc-unknown-linux-gnu) Copyright (C) 1995-2007 Jörg Schilling
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.9'.
No target specified, trying to find one...
Using dev=1001,0,0.
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'MATSHITA'
Identifikation : 'UJ-840D '
Revision : '1.02'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr).
Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE
Supported modes: PACKET SAO
book type: DVD+R, Version (10.1)
disc size: 120mm (0)
maximum rate: Not specified (15)
number of layers:1
track path: Parallel Track Path (0)
layer type: Rewritable Area (2)
linear density: 0.267 μm/bit (0)
track density: 0.74 μm/track (0)
phys start: 196608 (0x30000)
phys end: 2491711
end layer 0: 0
bca: 0
phys size:... 2295104
Manufacturer: 'YUDEN000'
Media type: 'T02'
Category/Version A1
Disk size 0F
Disk structure 02
Recoding density 00
Manufacturer: 'YUDEN000'
Media type: 'T02'
Product revision 0
ADIP numbytes 56
Reference speed 35
Max speed 84
copyr prot type: 0
region mgt info: 0
rzone size: 40
rzone number: 1
border number: 1
ljrs: 0
track mode: 7 copy: 0
damage: 0
reserved track: 0 blank: 1 incremental: 0 fp: 0
data mode: 1
lra valid: 0
nwa valid: 1
rzone start: 0
next wr addr: 0
free blocks: 2295104
blocking factor: 16
rzone size: 2295104
last recorded addr: 0
read compat lba: 265696
Capacity Blklen/Sparesz. Format-type Type
4169920 2048 0x00 No Media Present or Unknown Capacity
And, as suggested by the wodim output, here's the output from
dvd+rw-mediainfo:
davjam@lion:~> dvd+rw-mediainfo
usage: dvd+rw-mediainfo /dev/dvd
davjam@lion:~> dvd+rw-mediainfo /dev/dvd
INQUIRY: [MATSHITA][UJ-840D ][1.02]
GET [CURRENT] CONFIGURATION:
Mounted Media: 1Bh, DVD+R
Media ID: YUDEN000/T02
Current Write Speed: 8.0x1385=11080KB/s
Write Speed #0: 8.0x1385=11080KB/s
Write Speed #1: 6.0x1385=8310KB/s
Write Speed #2: 4.0x1385=5540KB/s
Write Speed #3: 2.4x1385=3324KB/s
Speed Descriptor#0: 01/2295103 R...@8.0x1385=11080KB/s W...@8.0x1385=11080KB/s
Speed Descriptor#1: 01/2295103 R...@6.0x1385=8310KB/s W...@6.0x1385=8310KB/s
Speed Descriptor#2: 01/2295103 R...@4.0x1385=5540KB/s W...@4.0x1385=5540KB/s
Speed Descriptor#3: 01/2295103 R...@2.4x1385=3324KB/s W...@2.4x1385=3324KB/s
READ DVD STRUCTURE[#0h]:
Media Book Type: 00h, DVD-ROM book [revision 0]
Legacy lead-out at: 2295104*2KB=4700372992
READ DISC INFORMATION:
Disc status: blank
Number of Sessions: 1
State of Last Session: empty
"Next" Track: 1
Number of Tracks: 1
READ TRACK INFORMATION[#1]:
Track State: blank
Track Start Address: 0*2KB
Next Writable Address: 0*2KB
Free Blocks: 2295104*2KB
Track Size: 2295104*2KB
ROM Compatibility LBA: 265696
READ CAPACITY: 0*2048=0
While not the same, it does provide some output that is similar to that
produced by cdrecord. It also provides some info that cdrecord doesn't
supply, and doesn't provide some that cdrecord does.
>In article <Ey0znBwR...@dev.null.davjam.org>,
>David Bolt <db...@davjam.org> wrote:
>>On Tue, 30 Oct 2007, Joerg Schilling wrote:-
>>Hmm, the code is released under the GPL but they're not FOSS supporters.
>
>People who attack free software cannot be FOSS supporters.
>The few people from Debian that created the "fork" started to attack the
>free cdrtools project about 3 years ago. As a reesult of the FUD they did
>spread on the GPL, the license for cdrtools has been changed to a license
>that gives more freedom
And less. The present license for cdrtools is incompatible with the GPL,
which means code from the present releases of cdrtools can't be used in
GPL software. You should already know that, since that was the intention
behind the writing of the CDDL as stated by Sun.
>>>What do you get with cdrecord -atip with the medium you used?
>>
>>On mine I get:
<Snip what's already been posted>
>This is NOT cdrecord but the defective fork that does not support DVDs
For a defective fork, it certainly does the job here.
>For this reason, I _explicitly_ asked you for the output from the the official
>cdrecord. Are you interested in help?
I think you've got me mistaken for:
1, someone that actually needs some help with CD/DVD burning;
2, someone that gives a crap about your apparent "feud" with the cdrkit
maintainers;
And before you say you don't have a "feud" with the cdrkit maintainers,
it appears that every time you mention wodim/cdrkit, you point out how
that software is broken and/or unmaintained. It wouldn't also surprise
me if, at some other point in time, you claim it's illegal as it
breaches the GPL and/or copyright law, as you previously did with SUSE's
patched version of cdrtools.
>Then you should listen to me....
Maybe you should read what was written, including by yourself. You
posted that wodim doesn't support the -atip option with DVDs. I showed
it does. It doesn't provide the same details as cdrecord, but it does
provide output. It also says which program to use to get the media info
that cdrtools provides.
>>Then you should listen to me....
>
>Maybe you should read what was written, including by yourself. You
>posted that wodim doesn't support the -atip option with DVDs. I showed
>it does. It doesn't provide the same details as cdrecord, but it does
>provide output. It also says which program to use to get the media info
>that cdrtools provides.
What do you expect from writing such obvious lies?
Your posting _did_ prove that wodim does _not_ support -atip for DVDs.
Now you claim that it does? This is childish. Do you like help or do you like
to start a fight?
>>>davjam@lion:~> cdrecord -atip
>>>Device was not specified. Trying to find an appropriate drive...
>>>Detected CD-R drive: /dev/cdrw
>>>Using /dev/cdrom of unknown capabilities
>>>Device type : Removable CD-ROM
>>>Version : 0
>>>Response Format: 2
>>>Capabilities :
>>>Vendor_info : 'MATSHITA'
>>>Identification : 'UJ-840D '
>>>Revision : '1.02'
>>>Device seems to be: Generic mmc2 DVD-R/DVD-RW.
>>>Using generic SCSI-3/mmc DVD-R(W) driver (mmc_mdvd).
>>>Driver flags : SWABAUDIO BURNFREE
>>>Supported modes: PACKET SAO
>>>HINT: use dvd+rw-mediainfo from dvd+rw-tools for information extraction.
>
>And the output from wodim using the -atip option.
>
>>This is NOT cdrecord, this is a defective fork that does not support DVDs.
>
>Yes, it's from wodim.
And this output verifies that wodim does _not_ support cdrecord -atip
...
>You said that wodim didn't support the -atip option. That appears not to
>be that case, as wodim didn't return an error saying the option was
This is childish FUD.
>And, as suggested by the wodim output, here's the output from
>dvd+rw-mediainfo:
...
>While not the same, it does provide some output that is similar to that
>produced by cdrecord. It also provides some info that cdrecord doesn't
>supply, and doesn't provide some that cdrecord does.
What do you expect from spreadin this disinformation?
Cdrecord of course gives this information!
I did tell you to run:
cdrecord -atip
cdrecord -minfo
cdrecord -prcap
The fact that dvd+rw-mediainfo mixes a subset of the output from
three different cdrecord commands into a simplified output does
not verifiy that cdrecord is missing information. Wodim on the other
side does not support DVDs and you proved that by sending the wodim
output.
>Vendor_info : 'MATSHITA'
>Identifikation : 'UJ-840D '
>Revision : '1.02'
>Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
>Using generic SCSI-3/mmc-3 DVD+R driver (mmc_dvdplusr).
>Driver flags : NO-CD DVD MMC-3 SWABAUDIO BURNFREE
>Supported modes: PACKET SAO
>book type: DVD+R, Version (10.1)
>disc size: 120mm (0)
>maximum rate: Not specified (15)
>number of layers:1
>track path: Parallel Track Path (0)
>layer type: Rewritable Area (2)
>linear density: 0.267 μm/bit (0)
>track density: 0.74 μm/track (0)
>phys start: 196608 (0x30000)
>phys end: 2491711
>end layer 0: 0
>bca: 0
>phys size:... 2295104
>Manufacturer: 'YUDEN000'
>Media type: 'T02'
Despite the fact that you tried to use this discussion to spread FUD against
cdrtools, let me comment this media info:
wodim does have some extremely simple DVD-R support and broken DVD+R
support.
Tajo Yuden is known to be a high quality manufacturer. I asume that
the real cdrecord works find with this medium unless your drive has problems.
<snip>
>Your posting _did_ prove that wodim does _not_ support -atip for DVDs.
It doesn't provide *the same support* for DVDs as cdrecord. That is not
in dispute. Your claim was that wodim didn't support it is because it
doesn't provide the same information as cdrecord. Just because it
doesn't produce the same output doesn't mean it isn't supported.
>Now you claim that it does? This is childish.
I'll agree with this. It is decidedly childish and, at the very least, I
should know better.
>Do you like help or do you like
>to start a fight?
The OP posted that they couldn't burn DVDs using k3b on 10.3. I posted
that I can, which means it's something specific to the OPs system, quite
probably device permissions.
And, this doesn't really have much to do cdrecord or wodim anyway. When
burning DVDs, k3b uses growisofs.
<snip>
>Despite the fact that you tried to use this discussion to spread FUD against
>cdrtools, let me comment this media info:
I didn't say a thing about cdrecord. I was commenting on how wodim does
have support for DVDs. It may not be as complete as cdrecord but, as I
mention in a reply I made a few minutes ago, k3b doesn't use cdrecord or
wodim for writing DVDs. It uses growisofs, which in turn uses
genisoimage, as can be seen here:
20798 ? Sl 1:54 k3b
20917 ? Rl 0:00 /usr/bin/X11/growisofs -Z /dev/hdc /dev/fd/0 -use-the-force-luk
e=notray -use-the-force-luke=tty -use-the-force-luke=tracksize:524469 -speed=8 -use-the-fo
rce-luke=bufsize:32m
20919 ? S 0:01 /usr/bin/X11/genisoimage -gui -graft-points -volid test -volset
-appid K3B THE CD KREATOR (C) 1998-2006 SEBASTIAN TRUEG AND THE K3B TEAM -publisher -pr
eparer -sysid LINUX -volset-size 1 -volset-seqno 1 -sort /tmp/kde-davjam/k3bMpe04a.tmp -r
ational-rock -hide-list /tmp/kde-davjam/k3bs8qWSa.tmp -joliet -joliet-long -hide-joliet-li
st /tmp/kde-davjam/k3bLXf7qa.tmp -no-cache-inodes -full-iso9660-filenames -iso-level 2 -pa
th-list /tmp/kde-davjam/k3buIQrJb.tmp
20920 ? Z 0:00 [genisoimage] <defunct>
20924 pts/0 R+ 0:00 ps ax
20925 pts/0 R+ 0:00 -bash
>wodim does have some extremely simple DVD-R support and broken DVD+R
>support.
FSVO broken that appears to be adequately capable of correctly writing
to DVD+/-R(W).
>Tajo Yuden is known to be a high quality manufacturer. I asume that
>the real cdrecord works find with this medium unless your drive has problems.
Both have no problem writing to this media.
Ok...
>
>> us remember historical things that have been sanitized from the
>> "faq". :-) Some of us helped fund the hammer that kept slamming
>> us on the head... live an learn. But with that said, it's a
>> free country (well... my country is anyway) and I do believe
>> that people can change and no... I don't expect them to apologize
>> for past behaviors or their inconsistent viewpoints.... the important
>> thing is where they are right now.
>
> It is funny to see that the Linux kernel people now understand that
> their view from the past was inconsistent....
>
>> Right now, cdrtools is free (Joerg's hatred of Linux aside). And you
>> do have a choice.
>
> Cdrtools is free _and_ was _always_ free and I have no hate against Linux.
> I am a supporter of FOSS since more than 20 years, don't try to confuse me
> with people who recently started FOSS and still need to learn the background.
Ok...
>
> http://cdrecord.berlios.de/old/private/cdr-faq.html
> http://cdrecord.berlios.de/old/private/dvd-source-why.html
What did you do with all of the $100 payments for the unrestricted (key)
version of cdrecord-proDVD (available only as a binary)? Or is that
FUD?? Sorry. Maybe I just don't remember things as clearly as
you do.
It was a long time ago (well.. in internet time)... no harm done.
I apologize for spreading FUD. Wasn't my intention. Just want
to make sure that the whole story is told.
> http://cdrecord.berlios.de/old/private/linux-dist.html
>
> There definitely was hate from Linus Torvalds against me - I don't know why...
> And there is hate from Mr. Bloch that created the fork. Now the fork is dead
> since 6 months. Can hate create free software? I believe no!
I think a lot has to do with attitude. But who knows. You're obviously
a very friendly guy. Sometimes the things we do and say, or the way
we react to things determines how we are perceived.
>
> Free Linux distributions realized that forcing users to a defective fork
> is not freedom and give their user the choice to use the maintained and free
> original software. Ubuntu did get rif of all bugs in their database after
> providing cdrtols again.
>
I don't think anything in Linux is "forced". We have Solaris for that.
(sorry, had to say that one) :-)
A really strange claim from you!
wodim does not output anything related to the information on the
medium when calling wodim with -atip and you still try to tell us
it supprts DVDs?
As I mentioned more than once: the information cdrecord shows with -atip
is needed to write DVDs correctly. A program that does not support
to retrieve the related information cannot correctly support DVDs.
>> http://cdrecord.berlios.de/old/private/cdr-faq.html
>> http://cdrecord.berlios.de/old/private/dvd-source-why.html
>
>What did you do with all of the $100 payments for the unrestricted (key)
>version of cdrecord-proDVD (available only as a binary)? Or is that
>FUD?? Sorry. Maybe I just don't remember things as clearly as
>you do.
You did never pay any money for cdrecord but you claimed that you has to
pay. Would you call this the truth?
It is interesting to see that you claim wrong things that
people who _read_
http://cdrecord.berlios.de/old/private/dvd-source-why.html
would immediately identify as being wrong. A NDA prevented me from
publishing the source but the code has been freely available to you.
Please do not try again to spread FUD.
>> There definitely was hate from Linus Torvalds against me - I don't know why...
>> And there is hate from Mr. Bloch that created the fork. Now the fork is dead
>> since 6 months. Can hate create free software? I believe no!
>
>I think a lot has to do with attitude. But who knows. You're obviously
>a very friendly guy. Sometimes the things we do and say, or the way
>we react to things determines how we are perceived.
I would asume the personal offenses that Linus Toravalds send against me is
more than just "atittude"...
>In article <5Hrsaerh...@dev.null.davjam.org>,
>David Bolt <db...@davjam.org> wrote:
>>It doesn't provide *the same support* for DVDs as cdrecord. That is not
>>in dispute. Your claim was that wodim didn't support it is because it
>>doesn't provide the same information as cdrecord. Just because it
>>doesn't produce the same output doesn't mean it isn't supported.
>
>A really strange claim from you!
If it didn't support writing to DVDs, I wouldn't be able to write to a
DVD using wodim. Since I can write to DVD using wodim, and I use almost
exclusively DVD+Rs, there must be DVD support in wodim.
>wodim does not output anything related to the information on the
>medium when calling wodim with -atip and you still try to tell us
>it supprts DVDs?
As mentioned above, wodim has write support for DVDs, which you claim it
doesn't have.
>As I mentioned more than once: the information cdrecord shows with -atip
>is needed to write DVDs correctly. A program that does not support
>to retrieve the related information cannot correctly support DVDs.
It has enough support to correctly write DVDs. Over the past several
days I've written enough DVD using both wodim and cdrecord to know that,
as far as I'm concerned, and the successfully written discs, there
doesn't appear to be any difference.
??? Ok... I really thought you did charge for it... and I really
believe I worked for a company that did have to pay.... but again,
maybe you were no longer accepting payments by time we had to
use it (??). It was a long time ago... at least to me.
But you are saying that you did used to charge for commercial
use right? I guess that was my point.
>
>
> It is interesting to see that you claim wrong things that
> people who _read_
>
> http://cdrecord.berlios.de/old/private/dvd-source-why.html
>
> would immediately identify as being wrong. A NDA prevented me from
> publishing the source but the code has been freely available to you.
> Please do not try again to spread FUD.
But back then, you NEVER (afaik) said a word about why you pulled
the source back and made it non-free. You just did it.
You don't have to give the reasons why... but if you had back
then, I think people wouldn't have been so upset and all of
the desires to fork would have never occurred (perhaps?).
Again... I'm really NOT trying to spread FUD. Do feel free
to correct any of this.
Did the NDA allow you to distribute the binary version with
1G write limitation and then the "free" unlock key that you had to
constantly renew (for non-commercial use only)? Very confusing to me.
I guess I will never completely understand it all.
>
>
> >> There definitely was hate from Linus Torvalds against me - I don't know why...
> >> And there is hate from Mr. Bloch that created the fork. Now the fork is dead
> >> since 6 months. Can hate create free software? I believe no!
> >
> >I think a lot has to do with attitude. But who knows. You're obviously
> >a very friendly guy. Sometimes the things we do and say, or the way
> >we react to things determines how we are perceived.
>
> I would asume the personal offenses that Linus Toravalds send against me is
> more than just "atittude"...
>
Linux does have an attitude... that's for sure! Didn't know he was
trying hurl personal attacks against you. That's bad form. BUT,
you know, Linux and Linus are somewhat joined at the hip, and you
have been known to say some nasty things (and you still do afaik)
about Linux. He probably took some of those things too personally.
Just a guess. Not trying to excuse anything bad that Linus may
have said to you...
>> It is interesting to see that you claim wrong things that
>> people who _read_
>>
>> http://cdrecord.berlios.de/old/private/dvd-source-why.html
>>
>> would immediately identify as being wrong. A NDA prevented me from
>> publishing the source but the code has been freely available to you.
>> Please do not try again to spread FUD.
>
>But back then, you NEVER (afaik) said a word about why you pulled
>the source back and made it non-free. You just did it.
>You don't have to give the reasons why... but if you had back
>then, I think people wouldn't have been so upset and all of
>the desires to fork would have never occurred (perhaps?).
>
>Again... I'm really NOT trying to spread FUD. Do feel free
>to correct any of this.
Why then _do_ you spread FUD?
I did never pull back the source!
I did never make cdrecord non-free.
>> I would asume the personal offenses that Linus Toravalds send against me is
>> more than just "atittude"...
>>
>
>Linux does have an attitude... that's for sure! Didn't know he was
>trying hurl personal attacks against you. That's bad form. BUT,
>you know, Linux and Linus are somewhat joined at the hip, and you
>have been known to say some nasty things (and you still do afaik)
>about Linux. He probably took some of those things too personally.
>Just a guess. Not trying to excuse anything bad that Linus may
>have said to you...
???
It is bad to see that people on LKML who are publically known attack
other people. It is even worse if this is done by Mr. Torvalds.
In special for DVD+, there are many bug reports against wodim that verify that
there is no usable support in wodim.
Do you know the difference between "it may sometimes work" and "it works"?
>>wodim does not output anything related to the information on the
>>medium when calling wodim with -atip and you still try to tell us
>>it supprts DVDs?
>
>As mentioned above, wodim has write support for DVDs, which you claim it
>doesn't have.
For correct write support, there would be the need to read the "atip" info
and use the values. If wodim was able to do this, it would only be a few
printf() calls to write output for wodim -atip.
The main issue is that wodim claims to be compatible to cdrecord but it is
not.
??? You mean we could have had the source for cdrecord-proDVD
all along? Just that irritating need for a key would have
been nice to eliminate. Sheesh. Can't believe we were
all so stupid.
Still not seeing how I'm spreading FUD. I thought I
was just being honest in asking you to clarify some things
for everyone here. I really DO remember a day when
cdrecord-proDVD was distributed only in a binary manner
and it was restricted to writing only 1GB to a DVD unless
you obtained a key. I remember that you provided a
a free expiring key for non-commercial use and that you
had a non-expiring key for commercial use that you could
purchase (???). Also I remember that you would at your
discretion grant someone a non-expiring key for
non-commercial use if they filled out a brief form
and mailed it to you.
I'm serious Joerg... if this is FUD, please correct
it. I do not want to spread FUD.
>
> I did never make cdrecord non-free.
Ok... are you sure? I seem to recall a $100 fee
for a copy of cdrecord-proDVD (a version of cdrecord
that could write DVDs) without restrictions.
>
>
> >> I would asume the personal offenses that Linus Toravalds send against me is
> >> more than just "atittude"...
> >>
> >
> >Linux does have an attitude... that's for sure! Didn't know he was
> >trying hurl personal attacks against you. That's bad form. BUT,
> >you know, Linux and Linus are somewhat joined at the hip, and you
> >have been known to say some nasty things (and you still do afaik)
> >about Linux. He probably took some of those things too personally.
> >Just a guess. Not trying to excuse anything bad that Linus may
> >have said to you...
>
> ???
>
> It is bad to see that people on LKML who are publically known attack
> other people. It is even worse if this is done by Mr. Torvalds.
>
Agreed. I do find your accusations that I'm spreading FUD offensive,
but I'm willing to have you school me with regards to the truth.
And if you feel my take on the history of cdrecord and especially
what I view as the "non free" period comprising of cdrecord-proDVD
in particular is FUD... again, please feel free to correct me.
And I do apologize for any FUD I may have spread here.
>> >Again... I'm really NOT trying to spread FUD. Do feel free
>> >to correct any of this.
>>
>> Why then _do_ you spread FUD?
>>
>> I did never pull back the source!
>
>??? You mean we could have had the source for cdrecord-proDVD
>all along? Just that irritating need for a key would have
>been nice to eliminate. Sheesh. Can't believe we were
>all so stupid.
I am sorry to see that you again start to spread FUD, so let me
just answer to one of your incorrect claims:
The DVD support source code in cdrecord has never been published before
May 15th 2006, so _how_ could a non-published source be _pulled_ _back_?
I am sorry to see that you are not interested in a serious discussion.
Let us stop it now, it is most improbable that you will change.
Didn't mean to upset you so much. I think the confusion is that
there was cdrecord and then there was cdrecord-proDVD. cdrecord
was "free" and cdrecord-proDVD was not. I think that most people
thought that future development of cdrecord was in the form of
cdrecord-proDVD and thus people were frustrated that it (assuming
it WAS the future of cdrecord) was no longer free.
I apologize if you don't think this is "serious discussion". You
seem to feel that people arbitrarily started to create forks way
back when. But perhaps due to a lack of communication, people
felt that you were going in a non-FOSS direction and so out
of desperation, people started doing different projects to
replace cdrecord.
Thanks for clearing things up.... hope your the only one
that feels this discussion is "FUD". I found it to be quite
illuminating.
>> The DVD support source code in cdrecord has never been published before
>> May 15th 2006, so _how_ could a non-published source be _pulled_ _back_?
...
>Didn't mean to upset you so much. I think the confusion is that
>there was cdrecord and then there was cdrecord-proDVD. cdrecord
>was "free" and cdrecord-proDVD was not. I think that most people
>thought that future development of cdrecord was in the form of
>cdrecord-proDVD and thus people were frustrated that it (assuming
>it WAS the future of cdrecord) was no longer free.
There is and always was _one_ cdrecord source and a limited OSS distribution
that did visibly evolve.
I did always make clear what the background of that decision has been.
Unfortunately, there have been many trolls who spread dissinformation in order
to harm the project. Then there was a person called "Bernhard Rosenkränzer" who
published a defective variant of cdrtools in February 2001. He called it a
"fork" but the only work on the source was to first nake it 100% nonportable
and then trying to fix the selfmade bugs. In September 2006 Mr. Eduard Bloch
did the same. Both "forks" died after less than a year.
In the past time, cdrtools has been enhanced in major way but people still
spread FUD on the cdrtools project....
Thanks again Joerg... but I'm pretty sure I was not the only one with
the completely wrong impression of the situation. Again.. probably just
a communication problem.. but man... talk about getting things wrong.
>
> Unfortunately, there have been many trolls who spread dissinformation in order
> to harm the project. Then there was a person called "Bernhard Rosenkrnzer" who
> published a defective variant of cdrtools in February 2001. He called it a
> "fork" but the only work on the source was to first nake it 100% nonportable
> and then trying to fix the selfmade bugs. In September 2006 Mr. Eduard Bloch
> did the same. Both "forks" died after less than a year.
Ok... but I tell you my intent was not the spreading of FUD, and I hope
that you can at least see (maybe) why I was somewhat confused over
the matter.
>
>
> In the past time, cdrtools has been enhanced in major way but people still
> spread FUD on the cdrtools project....
>
My personal opinion is that many had the same impression that I did...
so maybe this thread has helped some people to better understand things
(??).
>> There is and always was _one_ cdrecord source and a limited OSS distribution
>> that did visibly evolve.
>>
>> I did always make clear what the background of that decision has been.
>
>Thanks again Joerg... but I'm pretty sure I was not the only one with
>the completely wrong impression of the situation. Again.. probably just
>a communication problem.. but man... talk about getting things wrong.
My impression is that the main problem is FUD spread by people who have been
confused by FUD from other people who are the initiators of the problem.
I am not sure about the intentions of these initiators, they do not know FROSS
for long.
It is strange to see that too many people believed these guys although I am a
long term OSS supporter while their main claim was that I don't like OSS.
>> Unfortunately, there have been many trolls who spread dissinformation in order
>> to harm the project. Then there was a person called "Bernhard Rosenkrnzer" who
>> published a defective variant of cdrtools in February 2001. He called it a
>> "fork" but the only work on the source was to first nake it 100% nonportable
>> and then trying to fix the selfmade bugs. In September 2006 Mr. Eduard Bloch
>> did the same. Both "forks" died after less than a year.
>
>Ok... but I tell you my intent was not the spreading of FUD, and I hope
>that you can at least see (maybe) why I was somewhat confused over
>the matter.
I hope to see you on the OSS side and on the side of the users un future...
>>
>>
>> In the past time, cdrtools has been enhanced in major way but people still
>> spread FUD on the cdrtools project....
>>
>
>My personal opinion is that many had the same impression that I did...
>so maybe this thread has helped some people to better understand things
>(??).
It was caused by the FUD of few people. The bad thing is that OSS community
has been reached by this FUD.
OSS today is suffering from interests of commercial companies and it seems
that these companies do not like OSS projects that are managed by strong
maintainers. They cannot influence huge projects like Linux (the kernel) but
they try to do with medium to large sized projects.
I hope that the OSS community will survive this and that maintaiers that act
to the benefit of the users are not attacked as I have been.
The FUD doesn't seem to be the reason of the fork. The reason for the
fork sounded pretty valid. It's always sad when it happens like that,
but it looks like the fork was needed to guarantee commercial usage of
the software.
You, on the other hand, claim that there is no licensing problem.
Frankly, I simply don't believe that and think that you are mistaken.
It's hard to imagine that the world created such a conspiracy just to
damage your project. They don't really care about your project. They
simply want something that works and that they can sell without "small
print" or possible copyright problems, even if it's not really certain
if there *are* in fact problems. They will take the word of their
lawyers over yours.
My personal opinion is that changing the license was a fatal mistake,
and I hope your project won't become another XFree86.
> OSS today is suffering from interests of commercial companies and it seems
> that these companies do not like OSS projects that are managed by strong
> maintainers. They cannot influence huge projects like Linux (the kernel) but
> they try to do with medium to large sized projects.
That's not a bad thing. Projects need input from commercial companies,
and also need to satisfy commercial users too, and the only way to do
that is to listen to their needs and adapt the code if possible.
Anyway, your point of view was that the new license gives for freedom to
the user than the GPL:
"Freedom in terms of OpenSource is freedom to use the code, freedom to
modify the code, freedom to publish modified versions and the freedom to
use a well maintained piece of software.
You get this freedom from the original cdrtools packages but not from
it's clones."
The GPL grants all of that. Where's the "more freedom" in the new
license? Sounds like a lie to me, sorry. Also, you're attacking the
GPL with those words, and to my ears, that's FUD too.
You believe that missing will for collaboratoion at Debian's side is
a valid reson for forking? Ware you kidding?
If you believe that suse needs the right to publish broken variants of
cdrecord, that you seem to have a real stange way of thinking.
>You, on the other hand, claim that there is no licensing problem.
>Frankly, I simply don't believe that and think that you are mistaken.
There is no license problem and the people around Bloch have not been
able to verify a license problem. You are not even willing to think
about the problem but spread FUD, please stop this!
>My personal opinion is that changing the license was a fatal mistake,
>and I hope your project won't become another XFree86.
Why is it a mistake to give _more_ freedom to the users of a software?
>Anyway, your point of view was that the new license gives for freedom to
>the user than the GPL:
>
>"Freedom in terms of OpenSource is freedom to use the code, freedom to
>modify the code, freedom to publish modified versions and the freedom to
>use a well maintained piece of software.
>
>You get this freedom from the original cdrtools packages but not from
>it's clones."
>
>The GPL grants all of that. Where's the "more freedom" in the new
>license? Sounds like a lie to me, sorry. Also, you're attacking the
>GPL with those words, and to my ears, that's FUD too.
Wrong: YOU are spreading FUD that harms the GPL. I did not attack the GPL.
The GPL cannot _grant_ you that the fork is maintained because the fork
is a result of dull hate from Mr. Bloch, and because hate does not create
free software, the fork is dead since more than 6 months.
Software that is created from real interest in free software on the other
side is maintained for a long time and so is the original software.
here I only partly agree. Software is not created from real interest in
free software. It is created because there is a need for it. Doing it
open instead of closed is just a way to do it.
The fact that it is open is a tool, not a goal. At least that is how it
should be.
The fact that the goal is to solve a need will, depending on that need,
attract more or less developers and having it open is a great way to do
so.
houghi
--
Listen do you hear them drawing near in their search for the sinners?
Feeding on the power of our fear and the evil within us.
Incarnation of Satan's creation of all that we dread.
When the demons arrive those alive would be better off dead!
Of course not, but the license change was a valid reason, and perhaps
was to be expected considering Debian's campaign against the CDDL.
That's why I think that changing the license was a mistake. You could
have always dual-license it, IMHO. Since you're the copyright holder,
you would have that right even if turns out that the CDDL is not
GPL-compatible. However, *are* you the copyright holder of everything
in cdrtools?
And if the CDDL is compatible with the GPL, it means that I can
distribute cdrtools under the GPL if I want. To do this, I will simply
delete the CDDL text from the package and replace it with the GPL. If
this is not an allowable thing to do, then it means the CDDL is not
GPL-compatible, but if it is allowable, I don't see the point to switch
from the GPL to another license in the first place.
Please think about what I just said.
> If you believe that suse needs the right to publish broken variants of
> cdrecord, that you seem to have a real stange way of thinking.
They want something that is GPL. The CDDL is usually accompanied by
"but some people think" on every online discussion of the license. It
creates uncertainty if a project switches from GPL to CDDL. Maybe
Debian is to blame for that uncertainty, but in the end it doesn't
really matter who's to blame. The end user suffers because of the more
widely used broken fork, and this is the result of a war that originated
from Debian *and* you.
>> You, on the other hand, claim that there is no licensing problem.
>> Frankly, I simply don't believe that and think that you are mistaken.
>
> There is no license problem and the people around Bloch have not been
> able to verify a license problem.
Perhaps they don't feel the need to verify a license problem, because
they know that the GPL (at least v2) works and is 100% accepted by the
distributors, while there is some uncertainty around the CDDL.
It should have been clear to you that if a distributor has a choice
between the GPL and CDDL, the GPL will be chosen. Debian doesn't have
the power to impose decisions upon, say, Red Hat and Novell. It was
their own choice to use the broken fork instead of the original, and
that just shows that the GPLv2 is *the* license most distributors (and
their lawyers) are most comfortable with.
> You are not even willing to think
> about the problem but spread FUD, please stop this!
I am thinking about the problem. My own personal conclusion is that it
was a mistake to change the license, simply because we know that the GPL
works and is accepted.
Please don't be offended; everyone has the right to chose whatever damn
copyright license he wishes for the work he creates. No one has the
right to deny/criticize that right. (Assuming of course you indeed own
the copyright of everything in your project.) However, that's not the
point here. The point is that not only Debian has people that are not
sure about the CDDL. You should have known that. You have the right of
course to change the license, but everyone else also has the right to
fork the project and keep the old license if she feels that the new
license *might* impose problems, even if that's not necessarily the case.
I suspect a change back to GPL is out of the question? If you claim
that the CDDL is compatible to the GPL, then does it really matter if
you keep the GPL?
>> My personal opinion is that changing the license was a fatal mistake,
>> and I hope your project won't become another XFree86.
>
> Why is it a mistake to give _more_ freedom to the users of a software?
It doesn't seem to grant more freedom, but rather seems to impose
restrictions to the ones who modify it that could be incompatible with
the GPL.
I am not a lawyer though and I don't think there are court cases to
confirm this.
>> Anyway, your point of view was that the new license gives for freedom to
>> the user than the GPL:
>>
>> "Freedom in terms of OpenSource is freedom to use the code, freedom to
>> modify the code, freedom to publish modified versions and the freedom to
>> use a well maintained piece of software.
>>
>> You get this freedom from the original cdrtools packages but not from
>> it's clones."
>>
>> The GPL grants all of that. Where's the "more freedom" in the new
>> license? Sounds like a lie to me, sorry. Also, you're attacking the
>> GPL with those words, and to my ears, that's FUD too.
>
>
> Wrong: YOU are spreading FUD that harms the GPL. I did not attack the GPL.
> The GPL cannot _grant_ you that the fork is maintained because the fork
> is a result of dull hate from Mr. Bloch, and because hate does not create
> free software, the fork is dead since more than 6 months.
Can we have a clarification about how and when and under which
circumstances the CDDL grants more freedom to the user than the GPL?
> Software that is created from real interest in free software on the other
> side is maintained for a long time and so is the original software.
That's not true. I can write down an endless list of software created
out of honest interest in free software but still failed horribly and
suffered a quick death.