Hacker News new | ask | show | jobs
by msla 2429 days ago
There's also the unavoidability of narratives, and how they influence what people look up to begin with. For example, there's a Unix history narrative which begins at Bell Labs goes to Berkeley and then out to the world; this is already extremely limited, in that it ignores Wollongong (where the first Unix port was done, to the Interdata/32, and where important work on TCP/IP networking was done) and what AT&T did with Unix after they closed the sources and what the Research Unix people were up to after Seventh Edition, but I think the biggest loss is that it completely sells Multics short: Unix began when Bell Labs left the Multics project, so Multics, in this narrative, is frozen in time as this unfinished thing that Our Heroes are already bailing out of, and that's what gets handed down, as if Multics never progressed an inch beyond 1969. Heck, you can even see this as Myth #1 on the multicians.org site:

https://multicians.org/myths.html

> 1. Myth: Multics failed in 1969. Bell Labs quit, Multics survived.

Now that we can use Multics about as easily as we can use Ancient Unix versions under emulation, you can spin up a perfectly functional 1980s-era Multics and see that, no, really, Multics evolved into something you can do stuff on.

That's the problem with narratives: They're both inevitable and inevitably limiting, narrowing the focus to what makes a comprehensible story as opposed to a day-by-day list of what happened. Humans create narratives as naturally, and as unavoidably, as breathing, but we have to be aware of what they do to our comprehension of history.

4 comments

Specially annoying with that narrative, for those that care about computing history, is as C and UNIX are sold as the first of their kind, invented on magic moment, hand-waving what everyone else was doing.

Since history belongs to winners, if it wasn't for the accessibility of old conference papers and computer manuals, that would be indeed the only one we had to believe on.

I always thought one of the most interesting insights into this was the Unix Haters Handbook https://web.mit.edu/~simsong/www/ugh.pdf especially Dennis Richie's anti forward:

The systems you remember so fondly (TOPS-20, ITS, Multics, Lisp Machine, Cedar/Mesa, the Dorado) are not just out to pasture, they are fertilizing it from below.

Your judgments are not keen, they are intoxicated by metaphor. In the Preface you suffer first from heat, lice, and malnourishment, then become prisoners in a Gulag. In Chapter 1 you are in turn infected by a virus, racked by drug addiction, and addled by puffiness of the genome.

Yet your prison without coherent design continues to imprison you. How can this be, if it has no strong places? The rational prisoner exploits the weak places, creates order from chaos: instead, collectives like the FSF vindicate their jailers by building cells almost compatible with the existing ones, albeit with more features. The journalist with three undergraduate degrees from MIT, the researcher at Microsoft, and the senior scientist at Apple might volunteer a few words about the regulations of the prisons to which they have been transferred.

FYI if anyone visits Sydney and is in to the novel experience due to an interest in Unix history, you can request a window seat on the right side of the plane to typically see Wollongong[0] down the distant coast (past the Royal National Park[1]) slightly after takeoff.

[0] https://en.wikipedia.org/wiki/Wollongong [1] https://en.wikipedia.org/wiki/Royal_National_Park

Speaking of Multics, I am reading "IBM's 360 and Early 370 Systems". In passing, the narrative mentions an early public rejection of S/360 by MIT and Bell Labs because it didn't have hardware-aided dynamic address translation used in time sharing. Instead, they went with a GE 600 series which lead to the development of Multics.
For what it's worth, this is one of the topics Kernighan's book covers. He goes over the breakup in pretty good detail and does talk about the further evolution of Multics.