Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!apollo!mishkin
From: mishkin@apollo.uucp (Nathaniel Mishkin)
Newsgroups: comp.unix.wizards
Subject: Re: multiple-machine executables for Suns?
Message-ID: <36b9fbe5.c366@apollo.uucp>
Date: Mon, 17-Aug-87 14:15:00 EDT
Article-I.D.: apollo.36b9fbe5.c366
Posted: Mon Aug 17 14:15:00 1987
Date-Received: Tue, 18-Aug-87 05:21:02 EDT
References: <1853@megaron.arizona.edu> <639@ima.ISC.COM> <1080@ttidca.TTI.COM> <1931@umn-cs.UUCP>
Reply-To: mishkin@apollo.UUCP (Nathaniel Mishkin)
Organization: Apollo Computer, Chelmsford, MA
Lines: 29
Keywords: apollos, environment

In article <1931@umn-cs.UUCP> randy@umn-cs.UUCP (Randy Orrison) writes:
>The scheme that Apollo uses for multiple unvierses would work nice here.
>The use environment variables in their links, which allows the links to
>point to different things. e.g.
>	/bin     is a link to /$(systype)/bin
>	/usr/bin is a link to /$(systype)/usr/bin
>and they have /bsd? and /sys5.  The same system could be easily adapted for
>multiple processor types.

Not a bad idea.  However, in standard Apollo over-engineering mode (:-)
I will raise the following concern with this solution:  I might be
surprised when I do the following from my Sun 3:

    cp //one_sun_4/bin/cat //another_sun_4/bin/cat

(Use your imagination about what "//" means.) I will end up with a copy
of the Sun 3 binaries sitting on my Sun 4. Perhaps we'll all learn to
live with this phenomenon in the brave new world.  Perhaps there are
better solutions though.  The "big a.out" solution is better in that
the above wierdness doesn't occur, but it has all the problems that have
previously been raised.  It will be interesting to see how people will
react.  I can imagine plenty of people willing to trade disk space for
ease of use.

-- 
                    -- Nat Mishkin
                       Apollo Computer Inc.
                       Chelmsford, MA
                       {wanginst,yale,mit-eddie}!apollo!mishkin