Mail Archives: djgpp/1999/06/14/06:33:24
Eli Zaretskii writes:
>> A more reasonable way of handling this (and, in my experience, one
>> often used) is to report the bug to the maintainers
>
> That would require a totally different development model than the one
> adopted by DJGPP. I'm not sure how familiar you are with the Linux
> development procedures; neither will I go into discussing here
> something which I happen to know only by hearsay. It will suffice to
> say that the development of core Linux functionality is much more
> centralized than ours
Do you really think so? I would have said that this was exactly the
opposite way around: Linux development seems to be far less tightly
organised than djgpp. Some individual GNU packages are very centralized,
but there is no single ftp site where you can get a "latest version"
of everything, compiled and tested to work properly together.
Anyone who was using Linux during the changeover to glibc will be
very aware that it is not even remotely free from library conflicts.
And I don't think that submitting a patch to the maintainers would
be an instant way to fix a problem: even if they instantly released
a new version of whichever package was at fault, it would be years
before you could safely assume that every Linux system would have
this fix in place.
It seems to me that the relative reliability of Linux systems is due
to a number of quite different reasons:
- Unix culture strongly encourages being very modular and not assuming
too much about the implementations of other parts of the system, in
stark contrast to the DOS world where people feel free to assume
whatever they like, and then get annoyed because some internal detail
of libc changes and breaks their program. The majority of Linux
programs will in fact run on any Unix variant, and if you code with
that in mind, your end product will be far more resistant to changes
in the environment.
- Most Linux programs are distributed as source, and have a whole
set of tools (autoconf, automake) to adjust this source for whatever
machine you want to build it on. You can get binary packages, but they
generally only work on the specific distribution that they were built
for. In other words, Linux binary compatibility is far worse than
djgpp, to the point that people would laugh at you if you complained
that some old binary didn't work after you upgraded your system
libraries. This system only works because most programs are distributed
as source, and because everyone has the tools/skills to build them
in-situ.
- Linux has a large number of companies who do nothing other than
collect all the different parts of the system, make them work together,
and package them as a distribution. Compare this to djgpp, where a
distribution is put together by the same people who do the technical
work, in whatever free time they have left over. I would argue that the
very need for these Linux distributions proves that the raw packages
are in fact quite badly organised, so that making all the different
library versions work nicely togther amounts to a fulltime job for
someone!
> Please also bear in mind that Linux and similar OSes benefit much more
> from shared libraries than DJGPP can ever hope, since the OS itself is
> also a user of the library.
I completely agree. It occurs to me that if you are running djgpp and
the various GNU ports on DOS, by the time you added threading and DLL
support, which seem to be the two biggest "major new feature" requests
these days, you would essentially have ended up with a duplication of
Linux. In which case why not just use Linux directly. DOS has some
advantages (wide availability, small footprint, ease of talking
directly to hardware devices), but if you want all the features of a
real OS, Linux does those far better than DOS ever could...
Shawn Hargreaves.
- Raw text -