Path: utzoo!attcan!uunet!convex!killer!mit-eddie!uw-beaver!rice!sun-spots-request
From: glenn@wheaties.ai.mit.edu (Glenn A. Adams)
Newsgroups: comp.sys.sun
Subject: Re: How well do HP and SUN workstations mix
Message-ID: <8901191605.AA08854@frosted-flakes.ai.mit.edu>
Date: 27 Jan 89 02:48:31 GMT
Sender: usenet@rice.edu
Organization: Sun-Spots
Lines: 57
Approved: Sun-Spots@rice.edu
Original-Date: Thu, 19 Jan 89 11:05:02 EST
X-Sun-Spots-Digest: Volume 7, Issue 124, message 2 of 9

schultz@mmm.serc.3m.com (John C Schultz):

> I am looking for anyone's opinions on how well this will work.

We just integrated 40 hp9000s300 systems into a large networked Sun
environment with few problems.

> How close is HP's UNIX to SunOS?

HP-UX is Sytem V based versus Berkeley derived.  This does result in some
inevitable differences.  However, with Sun incorporating more of S5R3 all
the time, and HP incorporating many Berkeleyisms, they are both beginning
to look more similar.  The main complaint with the HPs is the lack of job
control, i.e., SIGSTOP, SIGCONT, etc.

> They both have NFS so can I mount SUN disks on the HP and vice-versa.
> We use X windows on our SUNs, presumably the same software, e.g. twm,
> emacs, xgdb will work on HPs?

NFS interoperates nicely.  In fact we adopt a file system architecture on
the HPs similar to SunOS 4.0:  we moved the HP /usr to a Sun file server
under /export/exec/hp.  This required moving a few things out of /usr to
/var, e.g., /usr/spool, /usr/tmp, /usr/lib/cron, etc.  All user
directories live on Sun file servers.  This leaves only 17MBytes on the
local HP disk, giving pleny of space for swap and temp space.

We use X11R3 on both Suns and HPs.

> The only difficulty I can see is that complex software such as the GNU
> code tends to require different flags to compile/link as compared to SUN
> systems.

To solve this, we created a link tree for each system which is isomorphic
to the source tree.  Makefiles, objects, and executables are local to the
link tree, sources stay in the source tree.  For building X, your imake
template will pick up the correct macros depending on the /lib/cpp
predefines and build the correct Makefile tree specific to that system.
The same can be done with most generic systems, e.g., GNU emacs, etc.

As for installing local binaries, libraries, etc., we created an
/export/exec.local/{hp,sun3} on the Sun file servers which gets mounted to
/usr/local on HPs and Suns.  All architecture dependent files go in there.
Architecture independent local files go into
/export/share.local/{lib,man,...} which gets mounted to /usr/local/share.
Things like the emacs lisp libraries, X library directory (excluding SNF
fonts), local man pages, etc. go there.

Merging the systems certainly complicates matters a bit, but makes
updating a bit easier in that you don't have to remember where all the
copies of variants live; you can just conditionalize shared files as
appropriate for minor variants.  For example, we have default .cshrc and
.login files that live in /usr/local/share/lib/ that get run by both HPs
and Suns.  This allows us to instantiate as identical environments as
possible on the different flavors of systems.

Glenn Adams
MIT AI Laboratory