Re: cdrtools cdrecord/cdrecord.c
Bill Davidsen <davidsen@tmr.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.
Calm down and try to get informed about what we are talking.
> >>06_dautipps.dpatch:
> >> Little patch to extend error information
> >>
> >>
> >
> >This patch causes incorrect output
> >---> rejected
> >
> >
> You spelled "useful" wrong, s/incorrect/useful/
Try to have a look at the patch in question and try to understand the
result before answering.
> >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.
If you are competent, please try to help me to educate the Debian people
to set up a correct build system.
Meanwhile you seem to agree that this patch is nonsense!
> >>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?
Well I am competent enough but I am not sure if you are...
Maybe it helps if you try to first understand the duty of a platform and
device independent SCSI generic transport library.
....
[unrelated whening removed]
...
> >>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.
Try to inform yourself about how fine grained privileges work and how to
run programs like cdrecord root-less. You are correct, it seems that you are
living in the past and still need to understand some basics in fine grained
privileges.
> >>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.
Well, it is stupid to try to patch cdrecord in a way that causes cdrecord to
fail in documented use cases. It seems that you did not yet understand how
to reliably maintain larger systems.
> Another case of not having the skill to adapt the application to fixes
> in the O/S.
Try to understand documented interfaces and try to understand that an OS
that partially implements interfaces not to follow the documented way
needs to be called broken.
> 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.
Well, it is obviously you who did not learn during the last years.
Jörg
--
EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
Reply to: