Re: mindi fails on Linux Debian system
On Tue, 15 Jan 2002 23:01, Hugo Rabson wrote:
> > I can't imagine any sane reason that a user would ever need
> >to concern himself with whether the file /sbin/lilo is a binary,
> >or a shell script, or a lisp coredump, or a symlink to /bin/true...
>
> Agreed. The user shouldn't have to know about such things.
> Nor should Debian be expected to pander to the needs of
> developers like me. However, Debian could help to
> prevent (or at least, stem the tide of) the Balkanization of
> Linux if it didn't run off & do things in its own way as often
> as it seems to. Maybe Debian is throwing out as many
> mutations as it can, to see which ones will survive & which
> won't. _That_, I could understand.
None of these things accurately reflects what happens.
Firstly many upstream developers have strange ideas about how things should
be done. One example is the discussions on the NSA Security Enhanced Linux
mailing list regarding Debianization of SE-Linux. I will make it FHS
compliant, and I will make it build in the Debian fashion without requiring
that the build process install header files and libraries in the same build
process. This is regardless of whether the upstream authors like it or not.
The next issue is that many changes from Debian packages get merged into the
upstream source. For example with the devfsd package I have made quite a
number of changes to the source, most of which have been included in the
upstream source. Now the rest of the world is becoming steadily more Debian
compatible as Richard Gooch adopts my patches! ;)
The final issue is that often changes are required for full interoperation.
An example is that the devfsd in Debian uses /etc/modules.conf as the single
(automatically generated) configuration for module loading - for everything
including devfsd usage. The upstream distribution of devfsd has it using
/etc/modules.devfs so you can get the (dubious) advantage of different
actions of modprobe depending on whether it's called by devfsd or from the
command-line. This difference may be desirable in some situations, but it
definately isn't in Debian!
> >I'm sorry you don't find Debian's way to your liking
> >but there are almost always sound technical reasons
> >for the decisions that our developers make.
>
> I figured as much. You're not bound by the same
> pressures as other outfits. Time will tell if the approach
> is a good one. I've a feeling it'll end up being Debian
> v Red Hat, Linux (Sys V Unix-compatile) v *BSD, and
> Windows v everything else.
It already is Debian vs Red Hat.
> My criticism of Debian is probably the same as Ben C's
> criticism of me: "Stop being such a pain in the a-- to get
> along with." :-)
OK. If we try to get along with you then will you try to get along with us?
--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page
Reply to: