scheinin@mrlaxb.mrl.uiuc.edu (Alan L. Scheinine) (04/29/91)
Domain Operating System
-----------------------
Though I have disagreed with some of Don Mark's past editorials,
what he wrote in the March 1991 issue of HP Professional is quite
sensible. I hope I don't need permission to quote a few sentences.
"UNIX remains the primary modus operandi for open systems, client-server
computing. Perhaps SOMEDAY [emphasis mine], through the efforts of
standards coalitions like the OSF, we will see a new standard operating
system evolve out of UNIX." (To put his remarks into context, he goes
on to say: HP's NewWave Computing strategy offers the most coherent
articulation of a truly open systems architecture. I read the article
"Understanding NewWave" and I still don't understand NewWave.)
In my opinion, the best operating system for Apollos would be a
robust UNIX operating system with Aegis enhancements implemented as UNIX
utilites. The Domain O/S operating system seems to use Aegis as a
foundation. Apollo and ADUS should work with users to increase the
UNIX flavor of most operations, such as system administration, with the
understanding that the Aegis foundation will eventually vanish.
Sometimes it is not possible to stop a job with kill -9, yet
/com/sigp -blast will apply the coup de grace. One often gets the
feeling that only Aegis can be relied-upon in Domain O/S. The SysV and
BSD UNIX on Apollo systems needs to be improved in many ways.
In the March issue of HP Professional, Andy Feibus describes his
experience with porting an application. Though he did not port to an
Apollo Domain O/S, the article is interesting. He describes the
application code as combining features of System V, POSIX, and BSD.
I think it is sensible to see System V, POSIX, and BSD as a trio
that must be handled well by any decent UNIX system. My impression
from reading the article is that porting an application is like finding
one's way through the woods along faint paths. The distinction between
bsd4.3 and sys5.3 using the SYSTYPE environment variable in Domain O/S
is an excellent approach to mapping those woods. Now if only /sys5.3/bin
and /bsd4.3/bin in Domain O/S were more robust.
What was most refreshing in the article by Andy Feibus is the
description of the real world as now being a mixture of System V, POSIX,
and BSD. Such a situation is ugly, but realistic. Not surprisingly,
the HP operating system was described as the easiest to port to. On the
other hand, in article 5771 of comp.sys.hp Jim Reid writes:
" ... HP-UX is an awful thing to port code to. The kernel is BSD
dressed up to look like System V. ... HP has its own object file
format which makes life hard if you're writing a debugger/linker
etc. ...
Practically nothing can be installed without tweaking makefiles
or config files. In my experience, it has never, ever been possible
to install anything on HP-UX simply by reading in the tape and just
typing make, as can be done on other platforms like SunOS. This is
because of the schizophrenic SysV/BSD OS. If you say the OS is
System V, most software assumes you don't have sockets (you've got
streams instead) and you've got COFF format. Neither assumption is
true for HP-UX. If you say you've got BSD, the compiles fail because
they see SysV include files and #defines.
Unfortunately, not many people write code to cover the case where an
OS has BSD sockets, System V include files, a non-standard object
format, a System V C library with some BSD bits flung in, ..."
So I will again say that the distinction between bsd4.3 and sys5.3 using
the SYSTYPE environment variable in Domain O/S is an excellent idea.
OSF/1 should not be described as a practical solution to any current
problem. Its time will come, but it is not sensible to describe OSF/1 as
a way to make a cluster of PA-RISC and Apollo M68040 machines, for
example. I wonder if it would be accurate to say that most HP workstation
users and most Apollo workstation users would prefer to use UNIX for the
next several years? I would not want to use OSF until its second
generation.
Many of the useful features of Aegis should be implemented in UNIX and
OSF/1 as utilities. I will explain what I mean by with a specific example
from the ADUS Ring Newsletter. The answer to the question is from
Rose O'Donnell.
"Question: At present under Domain/OS, we can do things like
'pst -n //fred' and the interrogation is handled by magic in the
kernel of the other node. No special process or configuration is
needed. Is this kind of facility available in OSF/1 also?
Answer: Sigh. These features are embodied in the Domain kernel
and are Domain-based protocols. No equivalences exist in OSF/1
and we have no plans to add them (not standard). As you can
divine, we deem it very important to be seen as not adding
proprietary features; if something can't be made to work on all
vendors' versions of OSF/1, we have to think real hard before
offering it on our version. Of course one could build and NCS-based
client/server set that would implement pst-like functionality
(without kernel modifications); but we have no plans to do that
at this point. Of course you can rsh and ps locally."
The answer frightens me. I do not know of any previous example of a
computer company that has argued against enhancing their operating system
to add value. I recently sat down at an IBM RISC System 6000 workstation
and needed to decide what machine should I use for a long job. I wanted to
get an overview of the cluster, but could not easily see what all nine
machines were doing. At that time, the thought occured to me as to how
much better was the Apollo system. The statement made by the Apollo staff
member, "Of course you can rsh and ps locally" is exactly the attitude that
I am arguing against.
I advocate a unified "machine interface" such as POSIX or OSF. (Reality
advocates System V and BSD as well.) But having established that uniform
foundation, much can be built upon it. Some aspects of Aegis, such as typed
files, cannot be carried into the future. Yet, many aspects of Aegis
provide ready inspiration for useful utilities.
I've read a broad spectrum of opinion with regard to OSF versus UNIX.
My own opinion has probably added nothing to the discussion. What would
be interesting -- even if not a statistically valid sample -- would be
comments from people who are familiar with the needs of many different
Apollo sites. Has anyone maintained an archive or a particular utility
used by many sites? How long do you think it will take for commonly used,
publically distributed software to be ported to OSF? I have in mind
packages such as Latex, NCSA's HDF, inet, etc. For companies that write
applications for sale, used by many Apollo sites, what is the expected
time-frame for having the application run well under OSF? This relates to
my previous comment: it is not sensible to describe OSF/1 as a way to make
a cluster of PA-RISC and Apollo M68040 machines -- not yet. That comment
is wrong if our applications will run under OSF in 1992. Apollo intends
to continue to improve Domain O/S for several years, so the reason one would
think that a problem exists relates to integrating PA-RISC into existing
Apollo clusters.
Domain O/S for PA-RISC
----------------------
By the time an HP-Apollo M68040-based computer reaches the speed of
first generation RISC, second generation RISC will be commonplace.
Consequently, Apollo workstation users must be active in influencing the
software available on PA-RISC. For all Universities, for most government
labs, and for many businesses, their wealth depends upon holding-onto old
equipment as well as buying new equipment. (Of course it would be foolish
to hold onto old equipment if new equipment paid for itself in productivity
gains, or if the old equipment was unsafe.) From what I've seen of
universities, they need many more workstations than they can afford to buy.
Older workstations are useful for editting files, communicating with the
world, debugging programs, and so forth. Existing Apollo sites -- at least
at universities -- will have the money to buy some of the newest RISC
workstations, yet will find it necessary to continue using their DNXX00
workstations as well, for the next three to five years. What is the
situation at government labs and businesses?
It would be immensely useful if PA-RISC could be integrated into Apollo
clusters by porting Domain O/S to the HP Series 700. HP has a good imple-
mentation of UNIX, but even so, maintaining two different operating systems
is difficult. The decision not to provide Domain O/S for PA-RISC seems to be
based purely on cost considerations: the cost of writing the port versus the
amount of sales to be expected from Apollo sites. If HP-Apollo were to port
Domain O/S to PA-RISC, then the work needed at Apollo sites would be reduced.
The units of measure that must be used are not person-hours, but rather
dollars, e.g. sales lost. I don't think HP's decision can be changed by the
cogency of anyone's logic. But suppose, for the sake of discussion, that
porting Domain O/S to PA-RISC would pay for itself in increased sales. That
does not mean that HP will do it, because companies often don't make logical
decisions. So how might Apollo users influence Hewlett-Packard? Would a
massive letter writing campaign -- to and about HP -- have an effect?
Sites with many Apollos and a large budget will probably not want to
make any public statement along the lines of: give us Domain O/S on PA-RISC
or we will buy from other vendors. The reason is that large purchases
should be done by competitive bidding and the evaluation of those bids
cannot be tainted by expressed biases.
I really don't know what would be the best course of action. What I
think I know is that: the time to try hard to get Domain O/S on PA-RISC
machines is either now or never.
Disclaimer: These are my opinions unless specifically attributed to
someone else -- even in the latter case, selective attribution reflects
my own biases. Nothing herein reflects the policy of any organization.
Alan Scheinine, Graduate Student email: u10534@uy.ncsa.uiuc.edu
Loomis Laboratory of Physics Phone: 217-333-1065
1110 West Green Street FAX: 217-333-9819
Urbana, IL 61801