Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!mrlaxb.mrl.uiuc.edu!scheinin From: scheinin@mrlaxb.mrl.uiuc.edu (Alan L. Scheinine) Newsgroups: comp.sys.apollo Subject: Essay on Domain O/S for PA-RISC Message-ID: <1991Apr28.215042.131@ux1.cso.uiuc.edu> Date: 28 Apr 91 21:50:42 GMT Sender: usenet@ux1.cso.uiuc.edu (News) Reply-To: u10534@uy.ncsa.uiuc.edu (Alan L. Scheinine) Organization: Department of Physics, University of Illinois, Urbana Lines: 161 Originator: scheinin@mrlaxb.mrl.uiuc.edu 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