I still work for the same group of people at USGS - renamed several times, currently Western Region Coastal and Marine Geology. I'm in charge of IT support for 150 scientists and support staff, with about 5 IT support staff working for me. I spend way too much time responding to commands from headquarters, shielding my staff and scientists from the latest waste of time.
We run a multi-platform shop, with several varieties of Unix, Linux, Windows, and Mac OS. Every time I write significant software on Unix, I recall the well-engineered software environment of Multics and shake my head. Every time we get hit by another round of malware, or need to respond to the latest security buzzwords, I recall Multics and sigh.
I remember many years ago attending a presentation on the "new" Intel 386 architecture, and remarking how much it resembled the Multics architecture. Apparently there were rumblings about porting Multics to the 386, but I never heard anything more. Imagine the possibilities...
Here are some brief recollections of Multics in near random order:
USGS-M was located in the "Shell Building" at 275 Middlefield Road in Menlo Park, CA -- a few blocks from SRI and a few miles from Stanford University. Shell Oil originally built the building as a research center, and the Shell logo was still present in various architectural elements. That building has since been torn down and replaced. The computer room was pretty standard design for that era, with raised floors, and massive air conditioning units. We didn't have backup power at first; when we lost electrical power, we lost data (somewhat mitigated by core and drum memory) and sometimes fried hardware. We ran some "batch" jobs; we had IBM keypunch machines, and card readers attached to Multics. We had 7-track tape drives and 9-track tape drives. We also had a large Calcomp pen plotter, used primarily for creating geologic maps. All of this was in place when I started working for USGS in December 1978 as an application programmer for research scientists. In the early 80s, we installed a large motor-generator unit to take over when power was lost -- though sometimes the motor-generator would fail and take Multics down with it.
Originally, Multics was funded "off the top", meaning you could use as much as you wanted. We were audited at one point, and forced by government regulation to charge users and projects for login time, CPU time, and disk space. Our "shell" prompt was modified to print how much money we'd spent so far in the current login session, a definite damper on experimentation. When "super" minicomputers (32-bit address spaces and virtual memory, e.g. DEC VAX, DG Nova) hit the marketplace, major projects started buying and running their own minicomputers. USGS Multics usage started declining by 1982. One by one, USGS Multics sites were shut down, starting with Menlo Park. We weren't completely kicked off Multics; we had leased lines connecting us to Denver, and I was one of the last users on the last USGS Multics system in Denver when it was shut down.
Running RJE (using an IBM mainframe protocol) on a SuperBrain (Z80 processor) with CP/M, and a serial-to-parallel converter connected to a line printer, over a 56 Kbps DDS line to Multics.
Using Multics to ARPANet when it ran NCP using IMPs, HOSTS files from SRI, no DNS, Telnet and FTP reigned supreme, getting a guest account at MIT-AI ...
Downloading KERMIT for various computers via ARPANet, and using KERMIT to move files from Multics to other computers that weren't on ARPANet.
Writing an impassioned paper pleading with USGS management to keep our ARPANet connection (which was quite costly). USGS was off ARPANet for several years before another backdoor project restored our connections. I believe the USGS Multics systems were some of the last computers running NCP as ARPANet switched to the newfangled TCP/IP.
Remembering my joy at discovering TECO was available on Multics, having learned it a few years earlier on a PDP-10 system of some sort. "Command lines indistinguishable from line noise". I really disliked ted, and didn't grok regular expressions until many years later.
Trying to create my own full-screen editor using TECO and a Tektronix 4025 terminal - a $7,000 graphics terminal in 1980! Our sysops wouldn't allow Emacs to be installed.
Getting tired of telling users to "new_proc and try again" to solve problems.
Using dialup from my office with a Xerox daisy-wheel terminal to connect to the Multics 50 feet down the hall. Almost everybody used dialup in that building, on rotary phones with acoustic modems!
Crawling through the ceiling to run a serial line from Multics to my office, getting covered in white dust, thinking to myself "this couldn't be asbestos, this is a Government building", and finding out years later it was asbestos.
Having to get special permission to use the serial line at 9600 baud, because that might steal too many front-end cycles from the dialup users. Justified because I was working on complex map graphics.
Learning the joys of multi-language programming (I mixed a lot of FORTRAN and PL/I), truly dynamic linking (stopping the program and substituting another library!), very good debuggers, ...
Living with constant access to Multics operating system source code was a joy for both debugging and learning. That experience influenced my switch to Unix as a programming environment, in the days of very expensive source code licenses from AT&T Bell Labs and driving to Berkeley to pick up the latest 2.x BSD and 4.x BSD tapes with source code.
Writing drivers for various graphics terminals and pen plotters (using the old Calcomp routines), to be used over 1200 and 2400 baud dialup lines, while praying for no line noise during long plot jobs.
Discovering "virtual files" in FORTRAN, and dramatically speeding I/O on graphics programs by writing to an array in memory, then forcing that array into a file when the program exited. The 1 MB limit wasn't an issue.
Using continuum to "network" with people all over the country.
Hoping the Multics system operators could keep the drum memory working as long as possible, because that really sped up paging.
Telling users, that no, we had no way to read old 9-bit-byte/9-track Multics tapes with binary data (or even character data), on Unix systems using 8 bits and ASCII. [see mxload.html -- editor]