Re: cdrtools cdrecord/cdrecord.c
Joerg Schilling wrote:
Steve McIntyre <steve@einval.com> wrote:
The full set of Debian patches against cdrecord are:
02_cdrecord_default_conf.dpatch:
Set up reasonable default values in the cdrecord config
It is unreasonable to deviate from a standard OS independen default.
---> rejected
Do you not see you look like a fool on this? You put in Linux dependent
stuff which is totally WRONG (see below) but you say configuration which
SHOULD be how the program learns about the environment must not contain
useful information about the execution environment.
06_dautipps.dpatch:
Little patch to extend error information
This patch causes incorrect output
---> rejected
You spelled "useful" wrong, s/incorrect/useful/
17_argv0_beautify.dpatch:
Remove the Debian specific suffix from the executable filename
A patch caused by the fact that Debian is missing fundamental knowledge on
version incompatibility and is uneducatable!
You cannot expect a cdrecord compiled on Linux version N to run on Linux
version N - X
You can if the person who designed the build system is competent.
18_donotopen_hda.dpatch:
dev=ATA:1,0,0 uselessly opens /dev/hda, breaking non-root
access. See #228215
Trying to patch a problem caused by incorrecty usage (the man page clearly
states which provilleges you need to run cdrecord).
---> rejected
So the program needs extra permissions because you aren't competent
enough to avoid doing something not needed?
21_makefile_fix_for_kernel.dpatch:
Fix problems with kernel include doing wrong things.
Unneded at all at least if the Linux kernel include files are non-buggy.
In addition, the autoconf utility already tests for known Linux kernel bugs.
---> rejected
Whoever wrote the autoconf clearly doesn't understand how to program.
The process looks for include files which may not exist and may not be
correct. User programs should be using the released headers, and it is
the job of the user to get them.
22_linux_rawio_capability.dpatch:
Add linux specific rawio capability allocation to work with
kernels > 2.6.8
Needed only because fine grained privileges are not yet ready for general
use. It is a general rule to wait until a newe feature has grown up from
the experimental state.
---> rejected
Again, this is the correct way to get capabilities, programmers who are
living in the past don't know about it.
23_o_excl.dpatch:
Open devices with O_EXCL to stop other programs from interrupting
writes
general rule: Fix the other programs that are broken
---> rejected
That's stupid, you can't fix or even IDENTIFY all programs ever written
to prevent problems. Shows a total understanding of how the real world
works.
27_scsi_buffer_size.dpatch:
If we can't get a buffer as big as we would like, shrink the
desired size until it works. Bug #330371
This is only a workaround for a bug introduced into the Linux kernel by Jens
Axboe (better fix the kernel).
---> rejected
Another case of not having the skill to adapt the application to fixes
in the O/S.
35_ultra_speed_media.dpatch:
Simple bug fix for ultra high speed RW media detection
This problem has been fixed in cdrecord more than a month before Debian
---> rejected
So you see: not a single patch is senseful.
Jörg
Unfortunately it's clear that you learned how to interface with the
kernel a decade ago and are not longer able to keep up with the
technology. Symtpoms of alzheimer's include inability to adapt to change
and being argumentative. Time to find a version of the tools which are
maintained to work as things are, rather than as someone would like them
to be. Thanks for the work you did in your prime.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Reply to: