sefunix%sefe.decnet@nwc-143b.arpa (SEFE::SEFUNIX) (05/09/87)
We are in the process of trying to obtain a supercomputer and have
reached a roadblock as far as operating systems/operating system interfaces
are concerned. The debate is over UNIX on a supercomputer and what are the
pros and cons. The following are viewpoints from two individuals expressing
their concerns over UNIX. Some of the comments tie to supercomputers and
some tie to UNIX in general. To set the stage, the majority of systems in
the center are DEC systems running VMS.
To protect the innocent, I have replaced the participant's names
with identifiers (e.g., USERA, USERB, ...).
We would appreciate any constructive input that the UNIX community
could provide. Your comments will help us not only with a supercomputer, but
its overall introduction to the center.
Sorry, if you receive this both on INFO_UNIX and UNIX_WIZARDS.
-----------------------------------------------------------------------------
USERA'S DISCUSSION
Last week I received a mail message from USERC about an incident on
the MIL/ARPAnet that was the result of some experimenting by a UNIX user. In
thinking about the incident, and speaking about it to others, it seems that
we have arrived at UNIX without having subjected that selection to any
rigorous evaluation. Why should we select UNIX over a hardware bidder's
default operating systems? What are the risks we incur in selecting this
operating system, when at this point, it is not available as the default
operating system on any SUPERCOMPUTER system? Given our likely environment,
(scientific computing) how well will UNIX serve us?
I don't have an axe to grind. As a matter of fact, since UNIX will be
the operating system on the MINISUPERCOMPUTER, and we will have over a year
of UNIX support and operations under our belt when the SUPERCOMPUTER is
installed, a superficial conclusion would be that UNIX makes sense for the
SUPER. But this follows only from the criterion of familiarity. If, on the
other hand, UNIX requires lower level support than other operating systems,
we could need more people to support two UNIX systems than one UNIX and one
proprietary out-of-the-box operating system, such as MVS, or COS. The point
is, we haven't bothered to develop factors that speak for and against UNIX
as the SUPER operating system, and contrast UNIX against proprietary operating
systems in terms of these factors.
Before I go any further, here is a description of the MIL/ARPAnet
incident. An experienced UNIX system administrator at U.C. Berkeley,
discovered that a UNIX command might enable one to write a series of
characters to an unknown number of terminal screens on the MIL/ARPA net. So,
he tried it, apparantly deciding against an incremental experiment. And after
he had entered the command, he left his terminal and went off to do something
else. When he came back, he had written his character string to 70+ terminals
all over the net (including that of the Inspector General of the Network at
the Pentagon), so he stopped the job. His reaction, as posted on the RISKS
bulletin board was that he had found a "interesting" and "curious" problem.
Further, this guy had the documentation IN HIS LAP while he was working, but
the explanation, according to him, was so ambiguous that he didn't know WHAT
would happen. This spoke very clearly to me about the UNIX environment vis-a-
vis our own environment.
The more examples I see of UNIX users finding new holes - or
features, if you will - in the operating system, the more I tend to discount
the opinions of those who advocate it for the large scale, operational, SUPER
environment at the center. There is no one in our code who has a deep
understanding of UNIX and of our user environment who is not an official
advocate of UNIX. How do we get to a clear idea of what we will have to do
to make UNIX fit the environment we plan to establish for the SUPER; and what
this will mean in terms of support over succeeding releases. Our one expert,
USERD, is an advocate. This is appropriate, given his charter, and under-
standable, given his background. Everyone else, whether advocate or opponent,
and that includes me, USERC, and USERD, doesn't know the first thing about
UNIX. So that the debate over UNIX is not over the internals of the operating
system itself, but other things.
I personlly worry about UNIX from the standpoint of large scale
operations. I think I see the requirement for a much lower level of operating
system support than we have to furnish now. Compared to NOS or VMS, UNIX
syntax is cryptic and more difficult to master, the utilities and
documentation are thin to the point of transparency, and site-specific
routines have to be developed, maintained, and applied to new releases. This
translates into either more people or less support than we currently provide,
for an operating system that is more difficult for a user to recall and use
than VMS. Until DEC, IBM, CDC, or one of the other big hardware houses
masters their version of UNIX and provides it as the default operating
system, it's flat going to take more people to support than a proprietary
operating system.
What really gripes about this drive to UNIX is that it is, with the
exception of USERD, led by people who do not know what our supercomputing
environment will be, have never supported an operating system, and are so
fixated on "trends in operating systems" (as if that meant anything at all),
that they discount the opinions of those who ARE familiar with our environment.
This Center has a reputation for off-the-shelf, no nonsense engineering; yet,
here we are, rushing to buy a product that, on most systems, is a lightly-
supported option. What IS the hurry? What ARE we going to be left out of?
What's to prevent us from buying the default operating system now and migrating
to our vendor's version of UNIX once it has been designated as default, and we
have talked to the HOARDS of happy users? If the vendor changes operating
systems, he provides a migration path.
With VMS, (or NOS and MVS, for that matter) we have an O.S. that was
formally developed as a commercial product, so there is some sense of it's
limitations and holes, concern about it's bugs and features, and a corporate
entity that is responsible for providing real support for real money. UNIX
grew like topsy and is constantly being discovered by it's happy community.
That's great for those who view computers as an object of study, especially
if they're looking for a thesis topic. For those of us at this center that
view a computer as a tool, whether user or system manager, it's a less than
endearing feature.
And the response I keep hearing, that UNIX can be changed on the fly
to suit any need, is not reassuring. First, because it's not clear WHO will
make the change(s), WHEN or HOW the changes will be maintained under each new
release, or WHY we should deliberately choose an operating system that
requires us to build and propagate patches for it. Second, because the idea
of an O.S. that can be easily altered makes me feel uncomfortable; if it's
that easy, it will be that much more difficult to troubleshoot a problem in a
user's environment. Third, because it indicates to me that support for this
software cannot be as deep as that offered with a default Operating System like
NOS, MVS, or VMS. When it's 2:00 A.M. on Sunday and I'm trying to get the
system going, I would rather not have to depend on bulletin boards for
operating system support.
When I really internalize the fact that there are NO UNIX super-
computers outside of BETA test sites, and that accounting and archiving
software will have to be written for our system immediately, I realize that
much of SUPER UNIX will be resting on the shoulders of ONE new center's
system programmer, and that makes me stare at the ceiling in the middle of
the night. All of us in support will have to provide some operating system
support on the SUPER, whether we help with FORTRAN, JCL, third party
products, or try to keep the system up. That's just the way it will work out.
Will we be able to sew this operating system up? Will USERD help us to write,
support, and propagate our home-grown routunes to suceeding releases of the
O.S. until we are old and grey(er)?
------------------------------------------------------------------------------
USERB'S DISCUSSION
USERA raises some significant questions concerning the choice of UNIX
for a supercomputer. How suitable is UNIX for our contemplated supercomputer
operation? Is UNIX an operating system for supercomputing? What are risks
are their associated with UNIX? The progress of vendors toward a production
implementation of UNIX was overestimated. There is not a supercomputer under
consideration that is yet running a production version of UNIX. In viewing
the possible alternatives, the following list results:
(1) UNIX operating system interface (IEEE 1003);
(2) UNIX operating system
(2) Vendor default operating systems;
It may be advisable to simply reserve judgment on which operating system to
select until it is seen which machine is chosen and how well their UNIX is
working at that time. If UNIX is not obtained initially, it is always an
option to change operating systems later as company development efforts
proceed and base utilization of ASECS evolves.
OS Criteria:
1. Reliability-will we have frequent crashes due to the operating system? Is
there an extensive installed base through which bugs have been identified and
eliminated?
2. Vendor support-will there be quick answers to any problems that may
arise? Is documentation adequate? Does the vendor have adequate experience
with and commitment to the operating system?
3. Completeness-will extensive local code have to be written to support
routine operations? Are all necessary functions provided? What will be the
effect on the systems support function? What utilities are available with a
vendor's UNIX to assist system management and operation?
4. Software portability-is needed software available for the machine if this
operating system is installed? How easy will it be to port desired programs
from other center machines?
5. Communications-will the supercomputer talk to the other nodes in the
center's network if this operating system is chosen? How readily?
6. Security-is the OS rated highly enough to allow jobs of the same
classification level to run together? Is it possible to control hackers?
Are files adequately protected?
7. Efficiency-how well does the supercomputer run with the operating system?
Are benchmarks affected? By what percent? Do we cut into our CPU charges
due to any inefficiencies?
8. Familiarity-will we have other experience with this operating system that
will help us to work more readily with this machine? Will experience with
this machine help us with others we will be getting? Will users experience
additional difficulty due to a multiplicity of operating systems to deal
with?
9. Competition-will competition be restricted through our specification of
the operating system?
10. Interactive processing-does the operating system provide an adequate
interactive capability?
11. Trends-is the trend of the SUPER industry toward this operating system?
12. Cost-will software costs be higher or lower with this operating system?
13. Permanence-if we select this operating system now, how easy is it to
change later if our workload distribution, bad experience, or product
improvements would dictate?
A Rating of UNIX vs. Default Operating Systems {Strawman}
1. Reliability: OS hangups and other problems may result from a choice of
UNIX at this time since its use is in such a preliminary stage. Plan on a
buggy operating system that we will have to help fix! There is no question
that the installed base is in the companies' own proprietary operating
systems. It would be a good idea to keep an eye on the UNIX sites to
monitor progress here. There are no other UNIX supercomputer sites from any
vendor at present.
2. Vendor support: Cray is committed to support of UNICOS for the long
haul. We assume they will not change their minds. The other vendors plan to
offer UNIX, but there is no evidence that UNIX will be their primary focus.
UNIX documentation is said to be obtained to some extent through E-mail
bulletin boards because manuals are notoriously terse.
3. Completeness: UNIX is a bit sparse and the philosophy is that local
additions can be easily written in C. This requires a time commitment from
UNIX experts not now available at NWC - or a considerable committment from
our current expert, USERD. Furthermore, implementation of new versions of the
operating system could conceivably be a problem. To a great extent,
utilities for system management and operation are developed by the vendor for
his/her UNIX, so eveluation here is vendor specific; one generalizartion
is that UNIX has fewer utilities than proprietary operating systems. It would
be good to see some of the public domain utilities ported over to, say our uVAX.
4. Software portability: At this point UNIX is not the customary
environment for supercomputer software development for any vendor. To the
extent that the code is OS independent this is not a factor. UNIX
facilitates porting to and from other UNIX machines on base including the
MSCS.
5. Communications: Capabilities seem to be there for ethernet
communications regardless of the operating system, with the possible
exception of one Japanese company.
6. Security: "'Secure UNIX' is a contradiction in terms." COS has been
utilized which provides the benefit of a precedent. Other proprietary
systems provide better security than UNIX. CTSS may be superior on this
score. Details here should be carefully researched, because our ability to
run classified in certain ways may be restricted because of UNIX.
7. Efficiency: Since production UNIX is not available, no comparisons can
yet be made! Should we blithely assume the superiority or parity of UNIX
here? In terms of system management and use of staff, operating a system with
furnished utilities seems to be inheriently more efficient than writing our own
routines or adapting public domain products.
8. Familiarity: One of the strong arguments for UNIX is that we would be
able to have a common interface to deal with at all levels of computing on
the base. All proprietary systems would be unique to our supercomputer.
9. Competition: Will all vendors be able to bid a working UNIX system.
Everyone has a proprietary operating system with some reasonable installed
base, however.
10. Interactive processing: COS is batch only. The others would probably
allow interactive processing. UNIX has a clear advantage here, although if
desired CTSS could be utilized for a Cray instead.
11. Trends: There is no question that there is some substantial momentum in
moving toward UNIX. Further, CRAY currently expects to discontinue
enhancement of COS. Remember, though, that CRAY is only one candidate
machine; and major computer vendors such as IBM, DEC, GOULD, DATA GENERAL,
and CDC offer UNIX only on part of their line, and only as an option.
Although there may come a day when UNIX will be standard, our enthusiasm
should be tempered by memories of "PASCAL, THE STANDARD PROGRAMMING LANGUAGE
FOR THE EIGHTIES" and other proposed all-purpose standards. Even if UNIX
becomes standard for supercomputing, will this be soon? Lets face it, at
present, using any measure you care to choose (sites?, transactions?), the
prevalence of UNIX is still more rhetorical than factual. What are we willing
to sacrifice to help move the world to UNIX?
12. Cost: UNIX costs are generally lower, but not by a high percentage for
supercomputer needs.
UNIX Risks
1. RESERVED
2. We may be restricted in our ability to do classified processing; single
job may be the only mode.
3. We may end up with a buggy operating system and place a severe strain on
our staff and our reputation.
4. We could end up with problems from hackers. Remember when the 50
UNIX/VAX's at Stanford were siezed by a hacker? They didn't know who it was,
where he/she was, nor could they do anything about it, short of shutting
down the systems. Doesn't that sound problematic to you?
5. Our machine could have reduced efficiency contributing to greater CPU
charges per job and limited capacity.
6. We could end up with a need for additional systems analysts to deal with
the lack of utilities, resulting in greater costs.
7. The otherwise superior choice may not yet be ready with UNIX.
8. Major software packages may be written only for the proprietary OS.
9. We could have inadequate system management resulting from inadequate
utilities, inadequate documentation, and inadequate budget for system
analysts. We could also end up without accounting or archiving software, or,
for that matter software for backups to the 3480 disks.
UNIX Benefits
1. We move toward a standard OSI at the center. (But DEC VMS is here to
stay, it appears! A version is being developed for parallel and vector
hardware that completely compatible. DEC should not be expected to stand
still, and VMS offers some very fine features, which make it less than
desirable for many codes at the center to switch away from.
2. Cray has committed to UNIX for the future for system upgrades. What
about the status of other vendors. (Will this be provided for discontinued
supercomputer lines?)
3. There will be some cost savings.(#$?)
4. Higher levels of portability, interactivity, and communications will be
obtained. (degree?)
5. As long as satisfactory operation is provided, no OS changes will be
required at a later time.
6. We will already have UNIX experience on the minisuper.
---------------------------------------------------------------------------
Thanks,
Gene Guglielmo
sefunix@nwc-143b.arpa
Naval Weapons Center
China Lake, Ca.
------mike@BRL.ARPA (Mike Muuss) (05/09/87)
Gene - Your message raises a lot of issues. These happen to be issues that the Army SuperComputer program wrestled with several years ago, and which to a certain extent are still discussed. If you don't know me, my name is Mike Muuss, and I'm the leader of the Advanced Computer Systems Team (ACST) at the U. S. Army Ballistic Research Laboratory (BRL) in Aberdeen Maryland. In addition to our primary task of doing advanced research, my team is also responsible for the support of the installed UNIX "system software", as well as the design, implementation, and support of BRLNET, our TCP/IP (MILSTD-1777,1778) campus network. For SuperComputers, we presently have installed a Cray XMP48, with three processors running COS, and one processor running UNICOS (UNIX SysV), all in "production" status. We are in the process of implementing a conversion to full UNICOS operation on the XMP. In addition, our Cray-2 should be installed in July, and it will run only UNICOS. BRL installed it's first UNIX machine (an 11/70) in May of 1978, and in the early 1980s standardized on UNIX as the preferred operating system at the Laboratory, long before UNIX became fashionable. In 1983 BRL adopted TCP/IP as the protocol family for BRLNET, the BRL campus network. In both cases, we have derived tremendous benefits from having identified emerging trends early on: we are now on our 5th generation of UNIX machines, and our 3rd generation of LAN technology, yet the user interface to the systems software and network has remained substantially unchanged in nearly a decade of operation. With a staff of nearly 800, the "force multiplier" is substantial. This period has not been without difficulties, but the difficulties we had have generally been minor in nature. (Insignificant in comparison to, say, VMS 3 to VMS 4 conversion, or similar "vendor transitions"). I'll try to tackle some of your specific questions (at the risk of attempting to write a small book :-) ), but first there are some statements that I would like to make. INITIAL STATEMENTS. *) Army procurements for SuperComputer systems are competative, and permit any hardware to be offered. However, the operating system must be UNIX, and TCP/IP must be supported. The first system was a Cray XMP48, the second and third were Cray-2 systems. Two more systems will be acquired next year, also requiring UNIX and TCP/IP. *) NASA's NAS project recently acquired a SuperComputer. They too specified that the operating system must be UNIX, and TCP/IP must be supported. They selected a Cray-2. *) You will find that UNIX is usually considered the preferred operating system for interactive computing by many government agencies, mostly because the widespread availability of UNIX prevents sites from suffering "vendor lock-in". *) Price/performance. Most interesting new hardware runs UNIX. For about $500k I can (and have) bought super-minicomputers with speeds 50-100 * VAX11/780 performance. How fast is your VAX 8800, and what did it cost? How about your IBM 4381? *) Look for some absolutely mind boggling workstations (running UNIX, of course) to come on the marketplace next year. Some are domestic, some are foreign. I'm not allowed to say more. *) Cray has announced that no new features will be added to COS after the next release (116), and that support for COS will start to be phased out in 5 years. *) Cray has also announced that for the forseeable future, UNIX will be their standard (and in the case of the Cray-2 and Cray-3, only) operating system. *) Amusingly enough, I/O performance on an XMP is better under UNICOS (native0 than it is under COS; 3-10% on disk I/O, 10-200% on SSD. Computational performance is identical for compute-bound programs. Something to do with the enormous size of COS. Each "module" takes more than a box of paper to print. Did you know that a source listing of COS stands nearly 3 stories tall? It topples from it's own weight. *) There is a lot to be said for being able to have the same environment on all your computers, *especially* when developing supercomputer applications. I have UNIX on my Sun workstation, I have UNIX on my Silicon Graphics IRIS workstation, I have UNIX on the VAXes, Goulds, and Alliants I use, and I have UNIX on the Crays. Even though these systems are not identical, they are very close. I'm tempted to claim that they are 99.44% compatable, realizing that 83% of all statistics are worthless. Being able to develop software on any machine, and run it on any machine allows me to choose which system is best for the task I'm attempting. For example, it would be pointless to run our Command&Control software on the Cray, because it's highly interactive and does little computation; on the other hand, I have to be very patient when I run my ray tracing on a workstation; it's more fun on an Alliant or Cray. ANSWERS TO YOUR QUESTIONS. *) Is UNIX good for scientific computing? For compute-bound programs, the choice of operating system is nearly irrelevant. For programs written in portable languages (eg, FORTRAN-77 and C) and avoiding vendor extensions, the choice of operating system only affects the I/O portions of the program (typically the OPEN statements). Nearly any operating system gives you this much. For the rest of the picture, consider the development and debugging environment. Generally, UNIX is considered to be an excellent interactive development and debugging environment. *) What are the security implications of the Sun-RPC based "wall daemon" incident? Very few, except to point out that many system administrators do not take the time to familiarize themselves with the capabilities of their systems. In this case, they accepted the default configuration of the Sun-NFS package to run the "network write all users" daemon. At BRL, we run the wall daemon on our workstations (to find our when fileservers are going down, etc), but do NOT run it on our large, general-user machines, to keep from pestering lots of people who are probably uninterested. I wonder how many other configuration options the "affected" sites neglected to consider? Most sites seem to spend weeks choosing all the configuration options for their DEC and IBM systems; why do people believe that UNIX can be installed and configured without thought? *) What are the tradeoffs between UNIX and a vendor-specific OS? Generally, it is believed that vendor-specific operating systems will be more efficient on their own hardware than some portable system. Surprisingly, UNIX tends to perform as roughly as well as the vendor OS on a given piece of hardware. If the vendor OS is an older system, UNIX often performs much better. The efficiency of the compilers being used is also an issue. When most people bring up the "UNIX performance problem", if you look deep enough, you usually find out that they heard that the AT&T VAX FORTRAN-77 compiler for UNIX generates code that is substantially slower than the VAX VMS FORTRAN compiler. (This is roughly the same compiler that you find in Berkeley UNIX for the VAX). Note that the key phrase here is "VAX". The compilers provided by Gould, Alliant, Sun, SGI, Convex, and other vendors are often quite good; I know the Alliant one produces *excellent* code, and the Convex one is also reputed to be excellent. *) What level of support does UNIX require? First, this depends on how you define support. I prefer to divide support into several categories (a) user consulting, (b) troubleshooting, (c) bug fixing, (d) evolution (eg, new releases, adding devices, etc), (e) operations. [a] The amount of user consulting services your site will need will varry only slightly with the choice of operating system, as the users are likely to encounter similar conceptual difficulties regardless of the OS. However, some OSs make it harder to do simple things than others. UNIX was originally designed to be "expert friendly" -- to not frustrate the sophisticated computer users. One aspect of this is that commonly used commands have short names, to reduce the amount of typing required. However, casual users of UNIX systems tend to be intimidated by it's terseness, economy of expression, and command-language power. Novice users quickly come to appreciate these advantages. Persistant casual users sometimes find it irritating. [b] troubleshooting a non-network-attached UNIX system tends to be fairly straightforward. Functionality is distributed among the various processes in a logical manner. Often the hardest problems to troubleshoot are RS-232 terminal wiring/configuration problems, because there is so much more than just the computer involved, but UNIX isn't the difficulty here; UNIX actually simplifies this somewhat. Network attached UNIX systems require much more configuration, and there are lots more opportunities for trouble; keeping mail flowing across the InterNet is often the most challenging task on UNIX systems, because your local problems convolve with problems on the receiving machines (of all OS varieties) to create tangled difficulties. UNIX makes this fairly easy to debug as well. The ballance of difficulties you will encounter are usually simple configuration errors, or hardware problems. [c] If you get vendor support for your UNIX system, bug fixing isn't something you have to worry about. Due to UNIX's long history, it tends to be fairly bug-free, although sometimes vendors introduce surprises when they "port" UNIX to their own hardware. Vendors selling UNIX on their hardware tend to support it as well as they support their own proprietary system, and sometimes they support it even better. If you don't feel like depending on vendor support for your system software, you need to shell out $16k (government) or $40k (commercial) for an AT&T source license, plus whatever source fee your vendor requires. This gives total control, but most facilities are likely to prefer the safety and stability (and slowness and expense) of vendor support. [d] Evolution of UNIX systems tends to be remarkably painless. Installing new software packages is easy, and even upgrading to a new release of the operating system is non-traumatic (although some vendors like to provide some vendor-specific trauma for their customers). [e] UNIX systems were designed to operate without an online operator. Other than handling tape mounting for file backup and file recovery, feeding the printers, and rebooting the machine after power failures, operators don't have much to do on UNIX systems. *) What is the state of UNIX documentation? We currently provide our users each with a 1 foot stack of paper for their basic manual, very little of which was added at BRL -- the rest is excerpts from the manuals that our vendors provide us. One set of manuals is sufficient for most uses of any our our machines; additional machine-specific manuals are available as well. Most users simply can't deal with that much information, and many sometimes wont bother looking things up, again not a fault of UNIX. In addition, UNIX has become a very popular subject among authors, and there is quite a selection of commercial textbooks about UNIX, available for quite a variety of target audiences. UNIX courses are taught by numerous professional training companies, and UNIX courses can be found in most colleges and universities. The investment of a few days of study will pay off handsomly; for our users at BRL, that investment has already paid off, in terms of 4 new systems that didn't have to be learned as we moved through 5 generations of UNIX hardware (4 of which are still in active use). *) How many bugs does UNIX have? UNIX is a system which has existed in it's modern form since 1976; the changes since then have been fairly evolutionary. The basic utilities have been stable for a long time. Bugs, when encountered, tend to be in little used system calls, and newer facilities (like shared memory and networking). However, most vendor-supplied, binary-only UNIX machines that I have worked with have astonishingly few bugs, and no show stoppers. Considering the richness of the tools provided, this is significant. Of course, some vendors have created badly botched versions of UNIX (I know of two), so as always, you must be a smart shopper, or confer with your more experienced friends. *) How reliable is UNIX? UNIX systems on the whole tend to be very reliable, as you would expect from any mature operating system. Hardware problems and power failures tend to be the two major causes of system crashes. Some hardware is more reliable, and the quality of power varies from place to place, but it is quite common to see systems that only go down once a month (for full dumps); systems that don't go down for full dumps stay up as long as the power does. Your local conditions and practices can affect this, and your mileage may varry. Void where prohibited or taxed. *) How many features of UNIX will surprise people? A great many of the features should be a pleasant surprise, few should be astonishing. However, I expect that this question was asked in the context of the "remote wall daemon". If your system administrator does not take the time to read the manuals and exercise some care in preparing your configuration, expect to be unpleasantly surprised. This feature is not unique to UNIX either. (Nobody would *think* of turning on a 500W laboratory laser without careful study of the manuals; why do people think an expensive computer is any different? Computers have not (quite) reached the stage of being commodoties yet). *) Is UNIX easier or harder to use than NOS, VMS, COS, or MVS? This depends a lot on your individual perspective. If your desire is to run some big (debugged) batch programs over and over with different data, UNIX is about the same as any other system. If you desire to interact with the system, or to perform complex file manipulations, UNIX is much easier to use that NOS, COS, or MVS, and similar to VMS. If you want to perform truely difficult file manipulations, then UNIX is (at least somewhat) superior to all other systems I have used (and I have personally used most of them). No JCL, no REWIND,DN=FROB. statements, no //DATAFILE DD DSN=SYS1.BRLCAT.MIKE.DATA,RECFMT=FB,UNIT=TAPE, .... crap. Of all the alternatives, VMS comes the closest to being as easy to use as UNIX, with TOPS-20 right behind it, and all the rest vastly outdistanced. *) What are the trends in operating systems? Well, they seem to be getting larger. Aside from that, most small and medium sized companies with a new hardware offering that is unlike their previous offerings are likely to use UNIX. It is possible for a small, ambitious company to do a very solid port of UNIX to a new machine in something like 5 man-years, which contrasts sharply with the roughly O(1000) man-years that building a new operating system would require. Thus, economics will result in very few new vendor-specific operating systems being created, with most of those probably comming from the large multi-national corporations. On the other hand, as the $2,000 32-bit workstation becomes reality next year, I predict that you will see no new faces, with the great majority running UNIX. Allow a few years to pass, and UNIX Personal Computers will be ubiquitous, and the youth of America will be spared the ravages of MS/DOS. *) Are migrations from one operating system to another easy? Rarely. If you are changing operating systems without changing hardware, the brunt of the change is in "job control" (JCL, procedures, shell scripts, whatever), while applications programs that stay out of the operating systems's knickers should port painlessly. (An example of this is the switch from COS to UNICOS. We should be able to pull it off in less than 6 months). When you change the OS and the hardware at the same time, more work is required (eg, moving from IBM MVS to DEC VMS). Vendor-specific programming practices are uncovered in all but the most carefully written applications programs. File opening and naming conventions tend to be wildly differnt. Binary I/O and binary datasets tend to be handled differently. The list of potential pitfalls is substantial. In any case, the worst part of a migration is usually not your core set of applications -- their users are likely to have a big interest in switching, and there are not too many such applications. The real cost will come from the effort of moving the hundreds of less frequently used applications. The sheer quantity of code is likely to be staggering, and the user community will usually be much less interested in having to cope with change, since all those programs are, individually, fairly unimportant. But, even having to invest a half a day for each one can eat man-years in mindless conversion work. If you have the opportunity, plan with a long view, and invest in UNIX now, rather than waiting to be overtaken by events. I suspect that BRL will have painlessly evolved through ten or more generations of UNIX hardware before the successor to UNIX is identified. (I'll keep my eyes peeled for it!) *) "With VMS, (or NOS and MVS, for that matter) we have an O.S. that was formally developed as a commercial product, so there is some sense of it's limitations and holes, concern about it's bugs and features, and a corporate entity that is responsible for providing real support for real money." Three topics here, (a) formal development, (b) vendor concern, and (c) standard vendor support. [a] I'm not certain that claims of OS/360, NOS, or VMS having been "formally developed" by large hordes of people makes me feel especially reassured. I'm rather more comforted by the knowledge (and the results!) of the fact that UNIX was designed in large part by Dennis Ritchie and Ken Thompson at Bell Labs, and that the remainder is due to such Computer Science greats as Aho, Weinberger, Kernighan, and the rest of the crew at Murry Hill. Their vision was to create a system that would be easy and productive for their favorite scientists to use -- them. They succeeded. [b] There is no reason to believe that a vendor who sells you a lump of hardware with UNIX on it will support their UNIX software significantly differently than they support their own proprietary software. I'm certain that there are examples of this, but DEC is a good counter example. They seem to be doing comparable jobs providing support for ULTRIX and VMS. For many new products, UNIX is the only offering, and if that vendor wants to survive, you can be certain that they will emphasise support. [c] If you expect your vendor to always fix everything for you in a hurry, you have succumbed to the myth of Standard Vendor Support. If you expect your vendor to help you find workarounds to your bugs, and fix some of them when the fabled Next Release is delivered, then you have a more reasonable expectation. This too is true regardless of who your vendor is, and what OS you are running. *) Given that UNIX is easy to change and extend, WHO, WHEN, HOW, and WHY should it be changed or extended? Early in my UNIX career, back in the V5 and V6 days, I spent a lot of time modifying and extending UNIX, partly for additional performance or features, partly for the fun of it. These days, there is very little about UNIX that I get very interested in working on. Modern versions of UNIX are "good enough" to do the most demanding applications on. We now invest our energies more towards investigating network protocols, distributed operating systems, distributed applications, and real science. While we at BRL take each new UNIX system we obtain and add some special security features, and port over the hundreds of locally collected utilities (including our bag full of favorite editors), it is certainly the case that these days an "out of the box" UNIX system (System V Release 2 or above, or Berkeley 4.2 BSD or above) is "good enough" that it can be just configured, installed, and used. If you introduce CHANGES to your UNIX system (as opposed to just ADDING new programs), you run the risk of having a system that diverges from the main streams of UNIX, and you may face additional work when porting your software to more ordinary versions of UNIX. *) Does the ease of modifying UNIX make it more difficult to troubleshoot a user's problem? In general, no. Unless you engage in serious kernel work, in which case your kernel errors may induce all manner of bizzare behavior. *) Are there any production supercomputers running UNIX? All except one of the 9 Cray-2s manufactured to date are running UNIX. Of the XMPs: Bell, Berkeley, Apple, BRL, and Cray (Mendota) run UNIX. *) Is UNIX an operating system for SuperComputing? Yes. Why not? If all you are doing is crunching, the choice of operating system is not significant. If you expect more out of your OS, then why not use a powerful, modern, portable operating system? And, for better or for worse, you are unlikely to see VMS on a SuperComputer in this lifetime, and VMS is the only other reasonable choice. *) What are the risks of using UNIX? The worst risk is accidentally buying your UNIX from a bad vendor. Another risk is that UNIX might not do something that you have become very accustomed to, or very dependent on, on some other system, and the difference might really bug you. *) What are the file backup and file migration capabilities of UNIX? The standard utilites DUMP and RESTORE are quite good for normal file backup and recovery. Standard UNIX does not presently have file migration, partly because of the notion that UNIX machines don't have online operators. However, there is at least one commercial concern that is offering a file migration package for a very reasonable price. Also, Cray is currently working on a fancy file migration package for some future release of UNICOS. And, NASA Ames and some of the NSF Supercomputer sites are doing some interesting work on file migration as well. (Ask me about this again in a month when we get BRL's plans for our MASSTORE systems firmed up). *) Portability. (a) is UNIX software portable? (b) is existing software portable to UNIX? (c) are needed packages available on UNIX? [a] Well written UNIX software is the most portable software I have encountered. The worst difficulties in porting UNIX software are usually caused by code (in any language) that makes assumptions about the sizes of the various data types. Excessive cleverness with pointers can also cause troubles. These things are usually due to carelessness, or uninformed attempts at optimization. This type of difficulty has fortunately become less common. The UNIX utility "LINT" goes a long long way to identify these problems in your code. Having UNIX running on two rather different hardware architectures (eg VAX & 68000) and making sure that your software works on both is a pragmatic way to eliminate any portability difficulties that remain after LINT is happy. [b] Existing FORTRAN software tends to port very well to UNIX, assuming that vendor-specific language extensions and vendor-specific library routines were not used. [c] Many of the popular packages are available on UNIX. One of the most common packages that is not well supported on UNIX is DISPLA. However, there are good alternatives, and ISSCO got bought out and seems headed for troubled times. (If you want color graphics, as opposed to plotting, can I interest you in a free copy of the BRL CAD Package?). *) How well does UNIX communicate ? AT&T UNIX, ironicly enough, does not communicate very well at all, unless running UUCP and KERMIT over terminal lines qualifies. Berkeley UNIX, and all AT&T UNIX systems with vendor-added TCP/IP capability, communicate very well indeed. I assume that TCP/IP capability is important to you. If you are looking for other procotol support, there are numerous vendors that provide X.25 and SNA boards and softare. And, both DEC and Sun offer UNIX systems that can communicate with DECNET. Network Systems supports NETEX for UNIX, and Cray even supports STATION (ugh). *) Can UNIX be used to run Classified work? Yes, using UNIX in a "system-high" processing mode works very well. At present, there are no supercomputers that have NSA appoval for multi-level secure operation. Don't expect this to change anytime soon, it's not easy. However, system-high operations combined with period processing (if you need more than one classification/compartment at your facility) are workable. Call for more information. *) "Is it possible to control hackers" [on UNIX]? Certainly. There are two categories of attack: (a) attack from outside, and (b) attack from an existing user. With proper safeguards and administrative controls, it is possible to provide excellent resistance to outside attach. This includes addition of logging and disconnect policies, required pasword change intervals (standard on SysV), and a more restrictive version of the password changer that refuses to allow "dumb" passwords, including those in 4 dictionaries. The attack from a user already authorized to log into your system is harder to deal with, because the system has no easy way to know what actions are benign blundering, and what is attempted hacking. However, if your systems has been installed at all carefully, and is occasionally checked for glaring system administrator oversights, cracking UNIX security is very difficult indeed. In this department, UNIX is at least as secure as it's peers, and typically much more secure. (If your VMS machine runs DECNET and you believe it's secure, guess again. I have these friends...). *) Is UNIX file protection adequate? Adequate, yes, exemplary, no. The Read/Write/Execute for Owner/Group/World is quite adequate. However, the simplicity of this approach means it tends to be used well. There are occasions where access control lists would be better. I have a copy of an implementation of ACLs for UNIX, but have never felt the need to try and install it. *) Will specification of UNIX restrict competition? No. In fact, in order to foster true competition while still requiring a specific operating system, you only have two choices: UNIX, or an IBM operating system. Otherwise, by specifying the operating system, you have specified the vendor. However, *not* specifying a specific operating system may open you to the possiblity of getting an operating system that you are wildly unhappy with. And, these days, software costs tend to dominate the hardware costs, so this could be an expensive mistake. *) Does UNIX have fewer utilities than proprietary OS offerings? Almost ceratinly not. Standard UNIX systems come with hundreds of utilities that range from the usual file tools and edit/compile/link/ debug tools to sophisticated source code control systems (SCCS, RCS), compiler-compiler and lexical analysis utilities, MAKE, and many many other programs. Then, in addition to that, there is a vast body of public domain software that is readily available. Finally, there are quite a few commercial concerns that offer specialty software packages for UNIX. As the costs of small UNIX workstations continue to plummet, the supply of "cottage industry" software offering for UNIX will soar. *) Is UNIX interactive? Yes! There is nothing quite as wonderful as running an interactive scientific application on a Cray and having your commands result in immediate color graphics sent across the network to your workstation. Closely coupling the power of a supercomputer to your scientists, with good visualization tools, will lead to significant increases in scientific productivity. It is working for NASA/Ames, and it is working for BRL. Best, -Mike Muuss (301)-278-6678 AV 298-6678 FTS 939-6678 ArpaNet: <Mike @ BRL.ARPA> Postal: Mike Muuss Leader, Advanced Computer Systems Team Systems Engineering and Concepts Analysis Division U.S. Army Ballistic Research Laboratory Attn: SLCBR-SECAD (Muuss) APG, MD 21005-5066