Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Yet Another Solution to the ctime problem (really, shared libraries)
Message-ID: <5748@brl-smoke.ARPA>
Date: Sat, 11-Apr-87 11:48:42 EST
Article-I.D.: brl-smok.5748
Posted: Sat Apr 11 11:48:42 1987
Date-Received: Sun, 12-Apr-87 01:32:25 EST
References: <6647@brl-adm.ARPA> <176@tg.UUCP> <252@root44.root.co.uk> <18271@ucbvax.BERKELEY.EDU>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 11

In article <18271@ucbvax.BERKELEY.EDU> bostic@ucbvax.BERKELEY.EDU (Keith Bostic) writes:
- Shared libraries are not the solution to software updates.  Think about
- what happens when your C compiler (let alone init) depends on a shared
- library that you've just "updated".  The biggest advantage of shared
- libraries is that they allow you to simultaneously update all of your
- software.  The biggest disadvantage of shared libraries is that they
- allow you to simultaneously update all of your software.

There shouldn't be any problem if the shared library implements a well-
defined interface and is tested against the interface specs before being
installed.  Or is that too organized?