Re: console based cd burning (wodim and burn)
#include <hallo.h>
* Joerg Schilling [Thu, Mar 15 2007, 05:57:30PM]:
> >trying to see what should I use to burn CD's from a terminal. This is on
> >an Etch bases system with only icewm installed on it. I don't want to
> >use nautilus cd burner and neither k3b, if I can help it.
>
> >How do wodim and burn compare for such a task? Any experiences with
> >these utilities? I am trying to decide which one to start and keep using
> >depending on its stability and features. And it would be great to have
> >the option of burning audio cd's with text information (never been able
> >to do so with k3b, even with checking the cd-text option).
>
> Wodim is based on _parts_ of an very outdated version of cdrtools.
Please stop throwing subjective assesment into objective discussion.
I.e. tell your definition of "very" and do it exactly. And please don't
tell weird things like "contains parts that are 2 years old". "Parts" of
the current Linux kernel may be 10 years old, so what...
> Wodim does not include the DVD burning code from cdrecord and it does not
Of course it does not. Is that a reason to be much worse? I doubt.
> include dozen of bugfixes mainly in mkisofs that have been applied during
Since those are under GPL there should be not a big problem to pull them
from the current cdrtools. Or would you dare to forbid this?
> the past 12 months. As an important issue, wodum does not use the new enhanced
"enhanced", how? As above, stop throwing subjective assesment into
objective discussion.
> version of libscg that tries to reintegrate the unwanted /dev/hd* interface for
> SCSI into the rest of the SCSI namespace from Linux.
Funny. I maybe will start believing your words when -scanbus does
actually present the native Linux namespace and not before.
> If you use the Debian surrogate instead of the original, you suffer from the
> following problems:
>
> - No support for hardlinks in Rock Ridge
Minor bug. They have diverging inode numbers and wrong link counts, but
it is not important in usual use cases because the filesystem is
read-only.
> - Incorrect permissions for many of the ".." directory entries,
> so "cd .." wo'nt work.
Unreproducible. Maybe a side effect of your sooper-dooper find
extensions not visible with the good old version?
> - Incorrect link counts on directories.
Maybe. Does that matter? Not really.
> - not correctly working deeply nested directories (level > 8)
Maybe. I have not looked at that part yet.
> - No find(1) support in mkiofs
- News at 11: Fifth wheel not important for stable driving.
> - No corretly working graft points
How "not correctly"?
> - cdrecord/readcd/cdda2wav -scanbus does not find ATAPI drives on Linux
Because "-scanbus" sucks IMHO. We have "--devices" instead.
> - No auto-target feature in cdrecord/readcd/cdda2wav (dev= parameter is
> no longer needed with the original software)
Wrong at two points. First, we do not distribute binaries called
cdrecord/readcd/cdda2wav and you know that. Second, with wodim dev=-1
(default in the config) looks for an appropriate device, even deciding
about CD-R or DVD-R type depending on the track size. The next
user-friendly feature on the list is automatic scanning all drives for a
real audio CD in icedax.
> - No correctly working DVD support from the third party DVD enhancement
> hack used by wodim.
"No correctly" and "hack" are fuzzy/subjective terms. Better tell how
severe the problem is that you claim to have found. If there is one at
all.
> While most changes in the wodim source are a result of replacing a working
> highly portable build system by something that does not work as good as the
> original, the original software has been enhanced and:
It works as good as the original in the scope that we need. And in some
areas even beyond, remember AIX5l.
> - mkisofs did replace more than 1/3 of the code (mostly for bug-fixes) since
> Debian did fetch the code
"mostly" is good. The changes that attracted most of my attention are
gazillions of meta-changes done to make the source look more closer to
the style used in your personal software zoo. Using the word "fix" or
"cleanup" (like Cstyle fixes) to describe them, ROTFL.
> - More than 2/3 of the cdda2wav code has been reworked in order to clean
> up the code, make it maintainable again and fixing bugs.
Oh, we also fixed some stupid bugs. I hope you fixed things like
potential buffer overflows in the meantime like we did. Unfortunatelly
no fixes can be pulled from your source because of the incompatible
license.
> - More than 1/3 of the cdrecord code has been replaced or added since
> Debian ffethced their code.
Yes, and? You add DVD support, we add DVD support, and the game
continues.
> If you like to use a recent cdrtools, I recommend to use the latest source from:
So, that is what your message is about? Some FUD enabled marketing?
If you wanna beat others with features, explain first:
- where is the multibyte input charset support in mkisofs?
- where is the long filename support in UTF?
- where is the large file support in UTF?
- does mkisofs still skip large files for fun, actually making broken
filesystems/disks?
Eduard.
--
<mrvn> rofl, I like tha bug
<mrvn> He probably set it to grave to keep it out of testing too.
<towo> debian_.de_, mrvn. ;)
* mrvn schmeisst mal ne Runde Babelfische in den channel.
<mrdata> '' Er stellte es vermutlich auf Grab ein, um es aus auch prüfen heraus
zu halten. ''
<mrdata> ahja... :)
Reply to: