SHULL@WHARTON.UPENN.EDU (06/06/87)
Ed McGuire (MCGUIRE@GRIN2.BITNET) at Grinnell College asked in Message-ID: <8705071611.aa07975@SPARK.BRL.ARPA>, back on 7-May-1987: >We are purchasing a UNIX (TM) system in the near future. We are familiar >with VAX/VMS. One difference we have noted between the two operating >systems is that UNIX often is distributed with source code for the kernel. >Why? Are we likely to need it--i.e., does a UNIX system administrator need >to make routine modifications to the source? > >Background: we are considering SUN workstations for a Mathematics >Department LAN. The system will be used for instructional purposes, >including programming classes, TeX text processing, and things of that >nature. Kernel sources are not included with SUN systems--we would have to >pay extra bucks. I spent a couple of months last Spring with an Apollo DN3000, an HP 330, an IBM PC/RT, and a Sun 3/110 in my office for evaluation as "high-function workstations" for faculty research here at the Wharton School. We also have a large commitment to VAX/VMS, plus MS/PC-DOS, and to date we have no official support for any UNIX or UNIX-like operating systems. My conclusion is that Suns would definitely have the lowest initial capital cost, but they share the disadvantages of pure UNIX with the HP and IBM systems. The Apollo system offers a very compatible UNIX (although perhaps not pure -> see on-going discussion on the Apollo@Yale.ARPA interest group list). In addition, Apollo provides an operating system kernel that provides a transparent network-wide file system, and proprietary tools for system and account administration. I quickly saw that the amount of time I would have to spend administering the Apollo systems would be a full order of magnitude less than on the pure UNIX systems -- perhaps 4 or 5 hours per week compared to a full-time salaried position (at $30,000/year in academia). The network-wide operating system has a lot of features that Sun's NFS doesn't, critical things like file locking. How would you like to make some major changes to a file, and right before you saved it, have someone else read the old version into an editor, make a minor change, and then write over your changes right after you saved your new version? We bought 3 Apollo DN3000s, and the primary users are very happy for several reasons. First, the documentation is excellent. There is a getting started manual that tells you how to log on, edit something and log out, all in under twenty minutes. There is a user's guide that has a lot of other good stuff for beginners, and then there are the tombs of well-organized reference manuals (although the reference manuals for Apollo UNIX are just the standard UNIX ones, with their familiar feel of general disarray). Second, due to the highly intuitive nature of the Apollo's Display Manager, the faculty, having never seen UNIX nor VI before, were able to get started on their work within a couple of hours, simply by using minimal shell commands, and completely avoiding VI in favor of the Display Manager. Third, as they have had new requirements, it was easy to look up what they needed to know. Fourth, I am happy, because I have spent very little of my time taking care of system and account administration. Adding new machines as they arrived took about 45 minutes each. Adding new accounts takes at most 5 minutes, probably including giving a couple of hints to the new user. And even the installation of a major new operating system release took only a long afternoon -- from noon to 8:30 pm. In conclusion, if you go with Sun you will probably spend more time making the things work, and less time doing the things you want to do with the machines. I only saw little hints of this in my evaluation, but I have heard that the reason you can get source for the Suns is that you need to have source, and vice versa for the Apollos. Someone on the network once said that Apollo's beta releases of software were cleaner than Sun's final releases. I wouldn't be a bit surprised. -Chris Christopher E. Shull Decision Sciences Department The Wharton School shull@wharton.upenn.edu University of Pennsylvania Philadelphia, PA 19104-6366 215/898-5930 If it ain't broke, don't fix it!
guy@gorodish.UUCP (06/07/87)
> My conclusion is that Suns would definitely have the lowest initial > capital cost, but they share the disadvantages of pure UNIX with the HP > and IBM systems. ... The network-wide operating system has a lot of > features that Sun's NFS doesn't, critical things like file locking. > How would you like to make some major changes to a file, and right before > you saved it, have someone else read the old version into an editor, make > a minor change, and then write over your changes right after you saved > your new version? Some clarification on a couple of points mentioned here. First, NFS isn't a network-wide operating system, it's just one of a set of network services; second of all, there is a file locking facility that is part of the same suite of network services that NFS belongs to. One could imagine an operating system that requires any editor to use this service to prevent the situation you describe; however, UNIX isn't such an operating system. The correct comparison here isn't DOMAIN, Aegis, DOMAIN/IX, etc. (is there a name for the software that DOMAIN/IX, and I presume Aegis, sits on top of, or is DOMAIN/IX considered to be on top of Aegis?) vs. NFS, it's DOMAIN, Aegis, DOMAIN/IX, etc. vs. UNIX. Also, for a lot of cases, there are facilities in UNIX that provide this sort of locking. If you use a source control mechanism such as SCCS or RCS, you would normally check a file out for editing, which would arrange that only you would have permission to write the file, and prevent anybody else from checking it out for editing. This is not as convenient as having the editor lock the file when it is entered and unlock it when it exits (something that could be done in most versions of UNIX these days, although the locks provided by UNIX are generally advisory); however, it would (assuming people honor the locks) also prevent somebody from writing over your changes in a transaction that begins after you exit the editor (I presume the lock that the editor obtains is released when it exits). Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com