On Mon, 15 Sep 2003, Michael Richardson wrote:

:   I'll tell you why I don't like dynamic linking, particularly for critical
: system components: file and system management.
:
:   Do you know how many times I've had to rescue RedHat systems when the
: (DUE TO SECURITY VULNERABILITY!) to the shared libraries left the system
: in a state where the PAM (YES!) was broken and nobody could login? Or worse,
: you can even type "ln" because /lib/ld-linux.so.2 is incompatible with
: /lib/glibc-X.Y.Z?

: Debian seems to do better - but only because they understand that making
: be upgrade things to get security patches doesn't fly.

Given the Debian GNU[tm]/NetBSD project attempt, it seems to me that a
sizable fraction of the smarter Linux minds use Debian.  My current employer
uses Debian GNU[tm]/Linux heavily too, and after finally getting over my
last bits of learning curve between different distributions, I've come to
understand why.

The biggest problem afflicting most Linux distributions is that of too many
ladles in the soup.  Things like glibc, login, su, etc. are released
separately on their own random release schedules.  Though not a direct cause
of the compatibility-drift problem, this fosters an approach to development
that leaves backwards compatibility as a rarely executed afterthought.
Debian attempts to counter this mindset by testing for compatibility in a
more active manner at each critical package's release.

Traditional *BSDs have a leg up on a lot of these problems, in that the base
OS is monolithic by design.  Even with the fledgling concept of NetBSD
system packages still hanging in limbo, the plan is not to split out all
manner of system code into separately tracked release schedules; the OS is
released as a whole.  This helps encourage more extensive testing of fixes
to the infrastructure (libc, ld.so, etc.) against the OS as a whole, not
just against a static dejagnu testsuite.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>