Re: Not everything that burns is bad or a clone of cdrecord
Joerg Schilling schrieb:
> "Thomas Schmitt" <scdbackup@gmx.net> wrote:
>
>>> Why use a clone if you may use the original?
>> cdrskin is not a clone of anything.
>>
>>
>>> Nobody so far reported a problem with the original cdrecord
>> If it is about DVD then cdrecord is not
>> state of the art since at least five years.
>
> This is wrong
>
> In contrary, cdrtools still defines new state of the art
> funtionality.
With substandard user and system interfaces, forcing CAM-like enumeration
on devices that don't enumerate, and all that crap. Or has this changed in
the past three years (IOW, can I use dev=/dev/hd* or dev=/dev/sd* on Linux
sans complaints - it makes no sense to enumerate behind point-to-point
buses you know...)? If so, sorry for missing that.
> I encourage you to have a look at the current
> features of mkisofs and _try_ them out. Cdrecord and cdda2wav
> also introduced a lot of new features that make them easier to
> use and that give new interesting functionality. Your code does
> not work on Solaris and I need to admit that I could not see any
> feature I would miss in cdrtools.
>
> As people from the related mailing lists know, I am listening to all
> bug reports and feature requests and usually fix bugs add add missng
> featues really quick.
Unless it happens on Linux, where people then see longish flamewars about
how Linux developers misbehave, violating layering (where in fact Linux
does cross-layer support when other parts of the world are still looking
for it)...
> It is of course well known that Debian has big social
> problems. The fact that I am attacked by people does
> not prove social problems at my side.
We've been through that, and after three years of silence on this topic, I
must say that offering to be proxy between the Linux folks and you was one
of the most time-consuming spare-time mistakes I made.
If you want to disprove social problems, or rather nip any thoughts of that
in the bud, constrain yourself to absolutely technical and objective
discussions. Discuss features, facilities and technical methods. Do not
ever discuss people, policies, decisions somewhere else.
If you encounter obstacles, document your technical requirement, what do
you want to do. If you have certain expectations HOW to do that, fine, keep
that separate to let other people say "fine, but our way this-and-that is
already implemented".
Note also that there is no obligation to adhere to any standard for anyone,
compliance is only required when actually offered or claimed.
Reply to: