|
One of the most interesting aspects of this manual was that it did not follow the typical "Unix Man command" style. Instead of offering a printed command manual with some hardware pages as was the common approach, the 375 came with an online man function (early UNIX boxes often didn't do this to preserve disk space).
Since specific commands were already referenceable, I wrote the manual entirely from someone trying to get some useful work out of this computer, from plugging it in to writing and compiling programs.
Fortunately, I'd already worked with BSD at Berkeley in programming classes, where we were expected to know how to write, compile, and debug our assignments. However, students weren't allowed to administrate these expensive timesharing systems at Berkeley, so this manual was also an exploration of Unix sysadmin functions - and here BSD was found sorely lacking.
During the course of writing this manual, I would frequently complain about arcane and silly acronyms, overly-complicated commands, and inefficient processes that would be best automated. Since Symmetric was a small company, it wasn't hard to get people to "make BSD Unix more friendly", and commands were introduced ranging from "nu" to add new users with one simple command (instead of the older manual modification of many different files) to formatting a floppy with fdformat (instead of the more arcane "format" command). Everything was simplified, redone, and pared down to make administration simpler - a plus for anyone at Symmetric who got "phone support" duty, since we eliminated the most common support calls and reduced our support headaches by about 60%.
Since Internet connectivity was a novel experience, a tutorial on Internet configuration and use was written, discussing TCP/IP, DNS, IP addresses, and all the host files we still have to manually configure today. Everything from backups (both simplified and the Tower-of-Hanoi model), serial and parallel communications, resource and account control, error mapping and handling (both hard and soft - does anyone remember bad144?), modem support, ftp and UUCP were included. Finally, an extensive writeup of the hardware, including a comprehensive and unique ROM monitor for initial program loading of the operating system, was done. Through use of the ROM monitor alone, one could diagnose hardware and kernel issues - something of value to real kernel programmers. I doubt many programmers could ever understand how to use such a feature today. This manual has become somewhat legendary, given how concise it was while still covering all the elements required to administrate a Unix system.
Unlike the later fad in "Dummy" books, I presumed the customer was an intelligent person who was not interested in becoming a system administrator or a kernel hacker, but instead was a serious scientist or engineer using a computer to get some work done. Interestingly enough, it still is a good quick reference guide for many key items which underlie all Unix systems today, and many of the "quicker" commands and hardware work such as "disklabel" went right back into Berkeley Unix releases for others to use - not surprising, since the manual got review and feedback as it was written by people at Berkeley and it got passed around a great deal.
However, given that many of the deeper architectural innovations in Symmetrix and 386BSD have never been incorporated into other Unix systems precisely because they make Unix "friendly", you'd have to either 1) find a 375 to enjoy its many innovations, or 2) find a copy of 386BSD Release 1.0 or later. Since most of the 375s were sold to aerospace and government, I doubt you'll find it easy to get a hold of one - we've shown a few still nicely running dating from the mid-1980's at the Vintage Computer Faire, including the wire-wrap prototype, and they've lasted far longer than any PCs we've used since - but if any are still running in some lonely government office somewhere, they probably are not accessible to the general public.
In the case of 386BSD, the uncertain degradation of CDROM media
at the time makes it unlikely
that copies from the Dr. Dobbs Journal CDROM are as viable as they once were to use. Finally,
later versions of 386BSD stayed in the lab and were not put into general release because
they were considered "too far ahead" of the time. The real reason was much simpler - removing a
problem through innovation and architecture also removes the raison d'etre for the "expert". Alas,
even changing a simple command gores someone's ox.
Related
