Hard coded limits (was Re: LINK COUNT TABLE OVERFLOW)

Paul de Bra wsinpdb at lso.win.tue.nl
Wed Jul 18 18:16:42 AEST 1990


In article <840 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>...
>Sometimes I whish there were a way to put some pressure onto the
>vendors of software to *force* them to deliver the source at least
>partially, if any of these limitations come up. IMHO many many
>working hours of the software engineering people are spent to find
>work arounds for problems, which could be fixed in ten minutes or
>less if - at least parts - of the source were available.

True, but the biggest problem with these software engineering people is
that you can't stop them from changing source code, not for fixing a
bug, but for adding their own "new and improved" features.

Look what happened to Unix. The source was given to universities,
with the result that by now it has become virtually impossible to merge
all the changes back into one version of Unix.
I'm not an accountant, but it's not clear whether the amount of time
and effort that was saved by having the source around still outweighs
the effort needed to port software between Unix versions and the
effort to merge features from different Unix versions. (Just think
of the incompatibilities that already exist between the different
versions of Unix System V release 3.2... different file systems,
different stop signals, if at all available, different include files,
different X-windows, different tcp/ip, ...)

I'm all for the availability of source, and I have used it to find and
correct problems, but the possibility to add ones own features sometimes
is just too tempting, and one really should not do this.

Paul.
(debra at research.att.com)



More information about the Comp.unix.i386 mailing list