According to Daily Tech News Show headlines show yeterday, 25 years ago, April 22, 1993, the NCSA Mosaic v1.0 web browser was released to the Internet. Back then I was Sr System Manager and Facilities Manager at a small compiler company, KAI. I was in charge of all Unix/OSF/Linux/VMS servers, workstations, X terminals, and Windows PCs.
In addition to all the computers, I also ran the facilities, all of the office building, not just the computer room, all the electrical power, HVAC, burglar alarm system, combination door locks, vendor management, and all computer networking, from running cable, soldering AUI connectors for thick-net, crimping coax cable for thin-net, crimping RJ45 connectors for 10baseT or 100baseT all the way to writing my own protocol analyzer to figure out what turned out to be ARP issues with old ethernet controller hardware.
I recall compiling Mosaic on multiple workstations to get it working. Windows PCs didn’t have native Internet Protocol built in yet, and NCSA Mosaic had multiple plugin drivers for specific ethernet cards (3com 3C501 ring a bell anyone?) and you have to buy a card carefully. I remember buying some PC IP stack, Chameleon NFS, because we were very much a UNIX shop, we had no PC servers, we had NFS and NIS, and the Internet was long distance dialup to UUNET. Did you know Microsoft IE was originally based on NCSA Mosaic? I believe it’s still in their license agreement somewhere.
I remember when I setup a terminal room in the unused office next to the computer room, so people could play solitaire and mahjong after work and at lunch. I cut holes in the wall, and installed 3 workstation class systems on a long table along the wall, with the cables run through the wall to the 19″ monitors, keyboards and mice in the terminal room. There was a deskside workstation with multiple 68020s, and an HP-UX workstation, and a DEC Alpha workstation joining in.
My email signature at KAI used to include “if it ends in *ix, we’ve got one”, because we had 45 *IX systems running 23 entirely different operating systems. One guy challenged me once, “How about Okidata?” I smiled and replied “Okix? Yep, we have one workstation from them.”
KAI had the worlds smallest Intel Paragon supercomputer – 4 nodes. Even the system engineers would do a double take when they heard how small it was. We also had a much larger multicabinet installation from Kendall Square Research, that was fun getting installed. We had multiple Sequent servers, one FX-8 from Alliant, and multiple systems from Silicon Graphics, HP, Apollo, Sun, IBM, Motorola, Data General, and a couple smaller government system suppliers which I shall not name.
I recall getting systems that were ripped from someone’s desk, slapped in a box, and mailed to my office. No manuals, no root password, no info on the software management processes, like backups. I had to coax the root password out of business partners multiple times so I could install the software upgrades they sent me. Some business partners treated us really well and sent us great hardware, like Sequent and SGI. Most just leant us a small workstation. A few tried to sell us their hardware, so we could support our software on their platform. One traded us a big multiprocessor server for a compiler, but we ended up paying them back for yearly support, so eh.
We were lucky enough to have serial number 14 DEC Alpha workstation, running alpha Alpha OS software (hee hee). Back then OpenVMS required license keys be typed in to unlock the compiler updates every month – what a PITA DEC licensing was. Ugh. All the Alpha systems we had were dual-boot – OpenVMS and OSF/1, which later on was renamed as DEC UNIX. I had to setup setuid root programs on both OSs so the developer/QA tester could switch from one to the other.
Back then, we didn’t give root access to mere users. Nobody had root access to anything, not even their own desktop workstation, except me. My boss had the root password in a sealed envelop in a locked cabinet drawer in his office, otherwise he didn’t want to know either. We took product security very seriously. Every time we hired a new kid from college, I’d have the same argument. “But I NEEED root access!” “No you don’t. This is NOT ‘your’ workstation, this is the companies hardware, and you aren’t the only user. If you want something installed or changed, that’s my job, I’ll take care of it for you.” “Nooo, you don’t understand…” Every time. They got used to it, mostly.
Once the bosses got cheap, and decided I didn’t deserve an expensive SGI Indigo graphic workstation on my desktop, because I wasn’t a developer, I was *JUST* a System Manager. You can see their point, a VT220 clone was $400, a 19200 baud port on a terminal server was already paid for, but a new Indigo was about $20k. So I gave mine up and went back to using the screen program on a 24×132 VT220 clone terminal. Because I didn’t have the same workstation as the developers, I could no longer experiment with SGI software and update and improve the SGI user experience. After a few months of missing that, the developers spoke up, and informed management that I deserved an Indigo, just like them, that they needed my regular improvements and ability to resolve their issues quicker. That was pretty cool, and I got my own Indigo again.
I worked on lots of open source software back then, and really gave back a bunch. My name is in the manpage or the README for C-Kermit, tcsh, perl, screen and a few others. I’ve published a few packages of my own, but nothing really major. I collaborated with another on a multicast FTP program that we used to distribute huge libraries and binaries to all the developer workstations every night.
When I started in 1985, KAI used to do weekly compiles of their own product, because it took about 24 hours on a DEC VAX-11/750. A couple years later, we were loaned a Sequent S81 server, and we upgraded our Balance 8000 to an S27, and moved all our dev and QA efforts to them. By 1993, we had a system setup where each developer’s Indigo workstation would poll a central server across the network, to get the next filename to compile. It would then process it, return the resulting object file back to the server, then repeat the whole process. The parallel sync of hundreds of files of the latest checked in version of source code took about 10 minutes, a distributed Indigo compile step only took about 30 minutes, the link step on the server was another 30 minutes, and the parallel distribution of the huge resulting link library to all workstations for the next day’s dev efforts added a final 20 minutes. From 24 hours on a single 3.125 MHz cpu VAX 11/750 VMS server, down to under 4 hours on a 10 cpu 20 MHz 80386 Sequent S81 server Dynix, down to 100 minutes on a cluster of 20+ SGI 33 MHz MIPS R3000 Irix workstations.