agn@unh.cs.cmu.edu (Andreas Nowatzyk) (02/11/91)
While this post is somewhat related to the ongoing UNIX vs. ??? flame-fest, it does belong in comp.arch because it shows how a particular OS can influence the structure of the hardware. Some time ago, I was shown this truly awesome DOS shop. They had evolved from a small office with one or two lowly IBM-PCs. It probably took 5 years or thereabouts to grow to their current installation (which was shown with considerable pride). The primary problem with their PCs was that they do only one things at a time. So they bought more and more ...and ran out of desk space for all those keyboards and monitors. The solution was to put the PCs in a machine room - all 200-300 (!) of them. These are high end 386/486-machines. All the video outputs of all the assorted *GA's were fed to a giant *ANALOG* cross-bar switch that connects this PC collection to assorted color monitors in the office. Each user has a few monitors plus one generic keyboard that connects to a keyboard multiplexor. Result: instant multi-tasking and multiple windows to boot. The user connects his keyboard to a PC, routes the video appropriately and is in business (of sorts). The keyboard multiplexor and video switch are controlled by a small embedded controller. It also takes care of the speaker in the PC, but cannot handle mice (yet). All PCs are connected by an ethernet to share files. Like the rest, this is a kludge of gigantic proportions: file system names are restricted to single character names, and there are only 26. So after you connect to a PC, you better reboot it to make sure that disk Q refers to the files you are used to. The software is in similar shape. It is composed of a multitude of shrink-wrapped packages, each with their own view of the world. Trouble is that they need to move data between many different packages. So they are tied together with lots of command files, scripts, format converters, etc. The mass of glue software (much in interpreted languages, Basic and others) easily matches the real application software. The interesting part is that this system evolved very naturally (and very slowly). Each decision that ultimately led to this mess, was reasonable. Furthermore, the people involved didn't (and probably still don't) realize their problem. There are many happy PC salesmen and the proud owner of a multi-million$ PC-based multiprocessor. It was quite a shock to them when they rolled in a mid-sized UNIX workstation. In a few weeks, a PC-application was moved to the UNIX box. What used to be a combination of various spread sheets, plot packages, data base programs and assorted glue, became a shell script with a few primitive C programs. Things that used to run for hours on PCs became a matter of seconds on the Unix box. This has nothing to do with CPU power, but a lot with how problems are solved in different OS architectures. DOS got them started very quickly and did most of what was needed. It also runs out of steam quickly once the application becomes complex and the data volume grows. -- -- Andreas Nowatzyk (DC5ZV) [now with Sun Microsystems. Inc.] E-mail: agn@eng.sun.com or agn@unh.cs.cmu.edu (415) 336-3167 P-mail: c/o: SUN Micro, 2550 Garcia Ave. MS 17-10, Mountain View, CA 94043