Social Computing, before the Internet

Author's Note: Recently, on Mastodon, Jason Self posted a nice little blurb in celebration of the 57th anniversary of the Incompatible Time Sharing (ITS) operating system (OS), enumerating some of its cool features. His list was good, but there's a feature of ITS that I've always felt isn't given its due, so I responded at length with my thoughts about that. Lars Brinkhoff suggested that I should put those thoughts in a more easily-referenced place, so that's what I'm doing here. I've done some light editing to make this read better of context. No attempt was made to make this a precise mirror. Let's call the original a rough draft and this cleaned up version the official version.

Oh, and in my personal experience, this operating system is pronounced as three separate letters (“I-T-S”), not like the possessive pronoun (though see notes at end for some exceptions). Glad we got that cleared up. Now let's dive in.

The big, underappreciated thing about the ITS operating system, too easily seen as a weakness, was the nearly complete lack of security. Seriously.

Today, of course, security is absolutely essential. But the luxury of working without it back then resulted in a huge productivity gain, enabling us to do early experimentation with ideas that otherwise were destined to seem impossible for another few decades.

What do I mean by a lack of security? Well, ITS existed on the net (ARPANET, not yet Internet) for years with

• no file security,
• no protection against any user (even a not-logged-in user) shutting down timesharing,
• tools that let any user spy on any other, and
• commands to read interactive messages or email that took a command line argument of whose messages to read.

Yet the level of abuse of these gaping security holes was negligible/tolerable for a long time. You heard me right. Years.

It was partly an artifact of the time. Maybe some combination of

1. most folks not thinking to make mischief in the first place,
2. most users knowing how precious it was and being asked to behave like adults and respect it,
3. using those same tools to see what others were doing and mutually policing,
4. using spy tools to make sure people weren't floundering and frustrated but helped to succeed,
5. treating even guests (tourists) with respect,
6. "security through obscurity" still worked back then.

I didn't understand how critical this was until I started using a Digital Equpment Corporation (DEC) commercial TOPS-20 OS on basically the same (PDP-10) hardware. I felt suddenly way less productive and was at a loss for why. I went back to an ITS host and enumerated all the programs in the system directories (SYS, SYS1, SYS2, and SYS3) to see what was missing.

One realization was that most of that software just supported other ITS software. It wasn't what was missing.

The other realization, something I then had no name for but with benefit of history I now do, was that ITS was an early form of social media. I think that's a better, less nutty way to make sense of its spying capabilities, such as the DDT (shell) command called “os” (for “Output Spy”) to say whose console to spy on.

What passed for display back then was more primitive than you may be thinking. In most cases, and I'm not going to go into exceptions here, it wasn't even bitmapped, just 7-bit ASCII characters assumed to be in a fixed font determined by the console display device. If you saw that device, you might imagine it to be a personal computer, but it was just a display. All computation was on a centralized mainframe operating system the size of a room, and running the ITS operating system, a timesharing system that let multiple users be connected at once.

Note that this was not camera spying. There were no cameras on these machines. No real provision for that kind of thing. This was just a view into the stream of character text and display codes that were rapidly flying by on the way to the user's console. The “modern” (or, perhaps better, “surviving”) analog would be the ANSI escape codes you can use on things like a Linux terminal window to get simple display effects without presuming much about the specific font size or family.

Like in Star Trek TNG episode “I, Borg”, TOPS-20 made me feel like Hugh did: There were “no other voices in my mind”, voices of other users that I might “hear” on ITS. (Metaphorically “hear”. We had no audio back then.) The difference between ITS and TOPS-20? I was lonely, just as Hugh was. I could send messages on TOPS-20, but only private ones. Socializing information, knowing what others were doing, sharing work? All very hard on TOPS-20. The silence was deafening.

Similarly, you might ask: Why would anyone be allowed to see somebody else's screen? Why would that ever not be creepy? Why would someone want you to read their messages to/from others?

Well, isn't that what we do on Facebook in the modern era? Or on tools like Slack at work? Somebody starts a conversation and others arrive to see it, see what's been said so far, and add to it. That's how ITS felt. The metaphor used by these other systems is not “spying” but in practice it's very similar. You'd login, notice friends were online, read their recent messages to find out what was going on, and then (once caught up in conversations), join in. Details were different, but in the social media paradigm it's easier to see why it felt not so much creepy as fabulously useful, especially compared to the isolation of other OSes of the time—and even some now, though that's finally changing, catching up with ideas we explored decades ago. In the context of the era, it made us enormously more efficient than you might have expected by creating synergies not available on commercial systems that had to try to be secure.

And the ability to watch somebody else's screen? Well, we do that in zoom today by screen sharing, though we now elect when we do it and when we can't. Still, it's powerful. In fact, ITS had mechanisms to let someone else not only watch but intervene in and type to your console as they watched. That was more powerful than you can do with simple screen sharing now, though more elaborate tools do exist. It's all a matter of trust, and back then we afforded ourselves more trust than one might today imagine.

Social trust, more often called “freedom” is a tricky thing. It accepts a certain risk along with almost a prayer that people will use it wisely. Once it's abused, it's quickly a tragedy of the commons. Preserving such trust, such freedom, is more important than people realize. It wasn't enforced by programs, but by social conventions, by who we revered and who we did not. There is an analogy to be made to real world society and politics today, but for brevity I'll leave that as an exercise to the reader.

My point, though, is that people too easily imagine it was uniformly more primitive back then. There were technical limitations, certainly. But it was different too. Not easy to compare. No camera, just screen, and no ability to opt out of sharing it. And it wasn't really the screen you were sharing, just the codes that had been sent to draw on it, obtained starting from an arbitrary point in the output buffer (a sort of low-level, ephemeral event queue). Often it looked crappy on a slow terminal trying to watch a fast one because of data loss trying to keep up, or trying to watch a screen with sophisticated display capability from a screen (or even “paper terminal”) lacking such capability. And it could be hilarious or frustrating if you spied on someone who was spying on you, with those characters just going back and forth in an endless loop. Even so, most of the time, it worked pretty well. You could usually tell what someone else was doing.

It was also an early interactive, collaborative development environment. Programmers worked with each other and users (who they could watch using those programs to learn directly how well they worked). We had no lack of ideas and a very specific sense of what was working and what wasn't in the things we had. A lot of today's “new inventions” may be things we knew we wanted. We were limited by what tools were implemented, so progress started slow. And processors were slower than today, so that didn't help. But people were clever, and much more careful with time/space efficiency than today.

As just one example, I recall Emacs starting in about 3 seconds on ITS, on a PDP-10 with 10-15 users. I'm sure it took longer with 20 or 30 users logged in at the same time. Today, on much faster personal hardware, Emacs starts fast but still not instantly. Of course, more happens now under the covers. And more flexibility— and sloppiness—are allowed. But Emacs (then implemented in TECO, not yet Emacs Lisp) was a real wonder in both size and space efficiency.

Back then if something didn't work, you sent a bug report. Bug reports were something everyone learned to write as part of their civic duty to make sure stuff got better over time. Another social detail. You could report a bug on anything by mailing to BUG-whatever. Host names were optional, defaulting to the local host. It was a small community. If there was no actual whatever corresponding to the bug address sent to, the mail was delivered to BUG-RANDOM-PROGRAM to make sure nothing got lost. Someone seeing the report, who might be a maintainer or even just someone casually peeking in on that maintainer's mail, might say “show me”. So you'd reproduce the bug on your console and assume they were able to watch along as you did. Again like Zoom (the screen sharing part, not the video).

Most stuff lacked formal documentation. If there was a "Help" option in most programs, it usually just told you that documentation would get there eventually. A major exception was Emacs, because TECO libraries forced you to document each function, and most people did. But most other programs had no help at all. I remember being surprised, years later on a commercial system, that someone was able to figure out a program. “I looked at the documentation,” they said. “Oh, I replied, people are actually doing that now?”

But lack of formal documentation did not mean ITS users went without help. Many just typed queries to the DDT (shell) command line, vaguely like you might do with Copilot in a modern system. The user would probably see a syntax error if they typed such a question that way, but often someone would be spying on them, especially if the user was new, to make sure they were doing OK. So they might volunteer an answer based on what they saw the user doing, syntax errors and all, maybe before the user asked. ☺

It was primitive tech, but we pushed it to its limit. And the lack of security helped a lot by not wasting programmer time, program memory, and execution time doing things we had no need of.

We built many sketches of our imagined futures. ITS was all about that in a way other OSes of the time were not.

---

Author's Notes:

If you got value from this post, please “Share” it.

The two PDP-10 photos were taken by me.

Sources for a meticulously reconstructed approximation to the ITS environment are available at GitHub. It is intended to run on an emulation of PDP-10 hardware (the KLH-10 or the SIMH emulator). Although you might want to join the ITS-Hackers discussion forum and find an existing emulation. It's a social system, after all, and you'll have more fun and learn more if you find a place where there are others to commune with.

I'm told by Lars Brinkhoff, subsequent to publishing this article, that some people did pronounce “ITS” like the single syllable “its”! He cites Barbara Liskov and some “Zork people” as having confirmed this. There were four ITS machines (AI, ML, MC, and DM). DM (“dynamic modeling”) was where Zork arose, and always seemed to me a community slightly more insular from the other three. Perhaps this was a result of that same cultural separation. I'm just speculating, though.

Some follow-up discussion about this essay occurred on a Google groups thread.

Automated Departure Message

Symbolics was a Lisp Machine company (1980-1996) and incidentally also the first .com domain name (symbolics.com). If memory serves, it had something like a thousand employees at its peak. It was an extraordinary place to work, with amazing products and some of the most talented coworkers I've ever had the pleasure to work with, doing work that was decades ahead of its time.

There have, of course, been a great many important advances in speed and functionality of computers, computer languages, and computer interfaces since that time. But even now, almost three decades later as I write this, there are features of that programming environment that are unparalleled in modern computer environments. It was a travesty that this evolutionary line was cut short, but as I often say, “you can be the lizard best adapted to life in the desert, but if you can't swim on the day of the flood, your time is up.” And so the company fell for reasons that had little to do with the technical capability of the products.

Layoffs came depressingly often as the company size fell to I think a couple hundred before it hit me. With each round, we got more and more efficient about them. I vaguely recall that for the early layoffs they had people in to help us manage our grief, or some such hand-holding. After a few, we could recognize the signs that one was happening as we arrived, so we just headed to the room where we'd get the list and then headed to our offices to read all the departure messages. We got it down to where we were back to work within an hour or two.

At some point, I started to see trends and patterns in the messages, and we were a company that was always trying to automate every last detail of routine action, so I joked about Zmacs, the Lisp Machine's Emacs-like text editor, needing a command called something like m-X Insert Departure Message to help you compose your departure message via form-filling. On further reflection, it seemed both easily doable and potentially useful, so I implemented it.

Ellen Golden, a senior documentation writer and long-time colleague and friend, was kind enough to write me a documentation page:

---

Author‘s Notes:

If you got value from this post, please “share” it.

For those not familiar with the Lisp Machine keyboard, it has a lot of shift keys. Shift, Control, Meta, Super, Hyper, and Symbol were the ones Symbolics keyboards used in the timeframe this story is about. The notation “m-X” (sometimes written, and always pronounced, “Meta-X”) was the chorded key combination that, when issued, prompted for a long-named editor command (“Insert Departure Message” in this case). Of course, you got command completion on the name, so you rarely had to type all of those characters. And, like all things LispM, it used a completing reader much better than modern completing readers. (You could just type something like m-X I D M and it would figure out the rest, since there were probably no other commands with words that started with those sequences.)

I've done slight editing on the picture of the doc page to contract out some vertical whitespace and fix a typo. The greenish tint is something my editing tool, GIMP, did without me asking. The original was black on white. But it gave it a sort of aged look, and it set off the picture nicely, so I just left it.

I was actually laid off twice. This refers to the second time. The first time got cancelled. Story for another day, though if someone else has already told that story, please suggest a hyperlink. :)

Flexible Support Options

Quite some years ago, I worked at a company that has long since vanished from the technology landscape. I loved working there, but it occasionally made strange marketing and internal administration decisions that drove me nuts. To cope, I often wrote parodies of the policies, mailings, and whatnot and posted them on my office door. In retrospect, I suspect the kinds of issues I had were completely generic to the computer industry, and so I have friends who may find some of these issues are relevant even today.

Here's one of them that came up in response to a bundle of several support options the company offered for one of our products when really we only had one guy—named Dan—who was on the other end of all that support, no matter how many different ways the support was offered. In writing this, I followed the basic structure of the actual marketing press release, making adjustments as seemed necessary to make the text read in a way that I felt was more accurate. You can probably guess how it originally read:

A Broad Range of Dan Options Now Available for OurBigProduct

OurBigProduct’s Adaptable Customer Services (DAN), the Cool Technology Group’s new support program, has been expanded especially for you, the adaptable customer. These new products compound the service requirements of the increasingly sophisticated product claims made by OurBigProduct. Through the combination of enhanced service claims and promises, you have increased flexibility in your decisions about how to feed our revenue stream.

Full Dan is the complete OurBigProduct software support offering designed to ensure that you are always at the leading edge of OurBigProduct technology. Full Dan includes Dan’s phone number, Dan’s home address, and a picture of Dan so you can spot him on the street and ask him questions. Each participant in this service option is entitled to Dan’s full-time cooperation on any project you undertake.

Basic Dan is a lower priced service option designed to help chintzy OurBigProduct customers keep whatever money they can scrape up coming our way without our having to do anything specific.

Right-To-Copy (RTC) Dan, designed for sites with big bucks, gives you the opportunity to make the most of your revenue-providing capabilities by providing us with lots of bucks even if you don’t want to take personal advantage of Dan. RTC Service permits you to make unlimited copies of Dan, as well as his associated software, hardware, and documentation.

Separate Service is for experienced OurBigProduct customers who see through the above options and want an itemized bill. Available services include software updates and enhancements if they happen, subscriptions to the OurBigProduct Newsletter, telephone and on-site visits from Dan, and Dan’s training seminars.

Perhaps if he'd gotten overwhelmed, we might have added more people rather than just letting him drown, but at the time it seemed outrageous to me. Plus I was younger then, and not terribly patient with or forgiving of things that didn't work as I personally wished they would.

Also, I'd probably be safe using the real name of the company and product, but I don't want to create any embarrassment for anyone so I've changed the names to protect everyone's happy memories. If you know who this is about, please don't volunteer the information. I think it's enough just to look back and smile, perhaps even to learn, from the safety of historical distance.

---

Author's Note: If you got value from this post, please “Share” it.

Originally published October 7, 2012 at Open Salon, where I wrote under my own name, Kent Pitman.

Tags (from Open Salon): technology, corporate politics, internal politics, parody, satire, humor, marketing, sales, support, staffing, support options, technical support, coping, dan, history, software, support contract, pricing, support pricing, support pricing options

Hacking, before the Internet

The term hack has existed for quite a long time in various forms. MIT uses the term to describe playful pranks some members of the community have played. These tricks are intended as benign although they have sometimes played out in unexpected ways. If you want some samples, you can find summaries around the net (for example, click here) or you can see the movie Real Genius, which is a lot more true to life in many respects than you might imagine.

When I arrived on the MIT computer scene in the latter part of the 1970's, the term “hack” had taken on an even more generic meaning than this prank sense. For all intents and purposes, a “hack” was simply a synonym for “do”, often with a sense of cleverness or inventiveness, though at MIT that aspect was so taken for granted that it was rarely spoken. Not surprisingly at an engineering school, it was all about doing things, leading someone later on to coin the phrase “hackito ergo sum”—that is, presumably, “I hack [or do], therefore I am.”

Note: The New Hacker's Dictionary will describe the meaning of the term slightly differently, but not in what I think is a material way. Even so, since I lived through the era, I'm exercising my right to describe things as I perceived them directly and not to be burdened by references written by others.

In that era, which was still that of an older, non-public network called the ARPANET that preceded the public Internet, someone might routinely be heard to ask, as a simple greeting and with no intent to challenge, “what are you hacking?” It meant, literally, “what are you doing?” but really in a more figurative and non-confrontational way, as if the speaker had asked just “what's up?”

A hacker, then, was just someone capable of doing something, and the term was often used with great reverence as in a doer of great deeds. Our online profiles on one of the computers contained the fill-in-the-blank “Hacking task-name for supervisor” where you would fill in the task-name and the supervisor, where mine might have said “Hacking the time/space continuum for the future of mankind.” (We weren't always very good about putting in actual supervisor names.)

Of course, as these things go, the computer community got bigger and not all deeds done (not all hacks hacked) were good. After a while, there were people doing bad things, too. I was around when this happened generally, but did not witness whatever event it was that caused the sudden shift of the use of the name. I've only managed to piece together what I think must have happened.

I imagine that one day someone finally did something bad with computers, and someone from outside the community asked who had done it, my bet is that a terminological confusion resulted from someone responding “probably one of those hackers,” leading the listener to believe that the purpose of being a hacker was to do something destructive, perhaps with a machete, rather than that the purpose of being a a hacker was merely to do things and that some things one might do are good and some things one might do are bad.

I do know that it was around the time of the movie Wargames and that I was working at the MIT AI Lab as a programmer. I had gone out for a walk around Boston, as I often did in the afternoons then. I returned to the lab and a bunch of people rallied around me and said, “Kent, Kent, Ted Koppel called. He wants to interview a hacker about the movie Wargames. We said they should talk to you.” (To this day, I don't know why in such a community of much more talented folks than I, they picked me, especially since I wasn't to be found, but so it goes.) I tried to call back, but we couldn't get them on the phone. I later figured out they'd gotten someone from Carnegie-Mellon University (CMU) and so didn't need me any more. Ah, the chance for fame can be so fleeting.

But it was just as well because they were apparently operating under this new meaning of “hacker” and I would have been totally thrown by the questions they were asking, which seemed to presuppose that if I was a self-identified hacker, I was the sort who'd be breaking into computers or something. That wasn't what hackers I'd known did, and I didn't either. We had things to build. So they interviewed this guy from CMU. It was someone I knew of, I just don't now recall his name.

This is how we came to the belief they don't do those things live, because we saw he was logged in to his console in the interview and we all quickly scrambled during the broadcast (hackers came out at night, so we were all watching from the Lab) to try to send him a message (the equivalent of an instant message) hoping it would come out on his screen while he was on the air. But it didn't. Another chance at fame lost.

Fortunately for ABC News, this person seemed to know the new meaning of “hacker” and gave them a competent interview. But we were all saddened at the tarnishing such an important word had taken. It was part of our daily vocabulary and veritably wrenched from us for this stupid use.

There was an attempt by a number of hackers to get the media to use the term “crackers” instead, but it failed. And the term was essentially lost. From time to time, you'll still see someone of my generation refer to themselves as a “hacker (original meaning)” in some wistful attempt to reclaim the memory of a time when hacking was just doing.

The moniker “netsettler” that I use in some discussion forums (such as Slashdot) harkens to that era. I often feel an empathy, even if the experience is only metaphorically equivalent, with the displacement Native Americans must have felt when the modern world moved in and took their land. The net, and indeed the whole world, was such a different place before it was the Internet. Most people see the arrival of the Internet as the beginning of something, but some of us saw it also as the ending of something.

---

Author's Note: If you got value from this post, please “Share” it.

This article was originally published November 16, 2008 at Open Salon, where I wrote under my own name, Kent Pitman. A discussion thread is attached there which I did not port forward to here, but you can still read by clicking through to the version on the Internet Archive's “Wayback Machine.”

Tags (from Open Salon): hackito ergo sum, hackity-hack, hacks, hack, cracker, hacker, clever, programming, technical, prank, pacific tech, caltech, mit, history, linguistic evolution, linguistics, language, terminology, jargon