Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn From: gwyn@brl-smoke.ARPA (Doug Gwyn ) Newsgroups: comp.arch,comp.unix.wizards,comp.os.misc Subject: Re: Shared libraries Message-ID: <6467@brl-smoke.ARPA> Date: Fri, 25-Sep-87 08:35:21 EDT Article-I.D.: brl-smok.6467 Posted: Fri Sep 25 08:35:21 1987 Date-Received: Sat, 26-Sep-87 20:05:04 EDT References: <2067@sfsup.UUCP> <2903@phri.UUCP> <6461@brl-smoke.ARPA> <2906@phri.UUCP> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 34 Xref: mnetor comp.arch:2349 comp.unix.wizards:4486 comp.os.misc:238 In article <2906@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >My background is engineering. In engineering school they teach you >to follow the rules and design things according to sound theoretical >principles. They also teach you that when push comes to shove, it's >sometimes better to break the rules and put a bag on side rather than not >have it work at all. Sure, design it so it works like it's supposed to, >but just in case, leave the hooks in so you have someplace to hang that bag >from if you ever have to. I hope they also taught you how to migrate forward with progressing technology. I, too, come from a "production shop" background, but we knew enough to keep our sources around and (in a non-shared library environment) would recompile everything at regular intervals, simply to ensure that our applications matched the current state of the system software. Naturally, we had test procedures.. I don't see that the situation with shared libraries is appreciably different from that without them, other than that your application will breaker sooner (when the new library is installed) rather than later (when you have to rebuild the application for some reason, such as making a small change). The causes for breakage are the same either way. I stress the library interface specifications because that is the "treaty point" on which the application programmer and the system implementor must agree. As to the people with dusty decks not being in a position to maintain their own code, I can't sympathize very much. Most code like that that I have seen has given the appearance of "working" but in fact was producing various degrees of garbage. I don't know what the solution to this is, other than to have more qualified professional programmers available to help others exploit computers more robustly and effectively. It's a problem here (BRL), too.