Sex, software, politics, and firearms. Life's simple pleasures…

Main menu

Post navigation

I haven’t announced a reposurgeon release on the blog in some time because recent releases have mostly been routine stuff and bugfixes. But today we have a feature that many will find interesting: reposurgeon can now read BitKeeper repositories. This is its first new version-control system since Monotone was added in mid-2015.

This time: The Break key. uuencode/uudecode. Why older Internet protocols only assume a 7-bit link. The original meanings of SO/SI. WRU and station ID on teletypes. BITNET and other pre-Internets.

There is one respect in which working on this is changing my historical perspective. The section now titled “WAN time gone: The forgotten pre-Internets” started out just being about UUCP but has gradually expanded to include the BBS scene, commercial timesharing, and academic networks in the period 1978-1996 (and especially 1981-1991).

At the time those of us exposed to more than one of these networks saw mostly differences – differences in capability, differences in addressing schemes, differences in underlying protocols.

Now, twenty years later, I’m finding that it’s the similarities that look more significant. These experiments were all evolving in parallel, offering services that converged over time.

Wide-area TCP/IP was the eventual winner, of course. It’s not hard to see why: being designed for internetworking and not being gated by proprietary IP gave it two insuperable advantages.

I’ve been thinking a lot about language design lately. Part of this comes from my quite successful acquisition of Go and my mostly failed attempt to learn Rust. These languages make me question premises I’ve held for a long time, and that questioning has borne some fruit.

In the remainder of this posting I will describe a simple syntax extension in C that could be used to support a trait-centered object system similar to Rust’s (or even Go’s). It is not the whole design, but it is a simple orthogonal piece that could fit with several different possible designs.

The pace of suggested additions and corrections has slowed down a lot; I think this thing is stabilizing.

I gave in and added the one bit of paper-tape lore people have been bugging me to include, about why DEL is 0xb1111111. Learning that the NSA still distributed crypto keys on paper tape until last year smashed that one through my relevance filter.

There’s a short addition on the Trek family of games, a mention of xyzzy, and some minor corrections and typo fixes as well.

The response to this document has been nothing short of astonishing. More than half of my non-spam mail over the last three weeks has been people writing to suggest additions and corrections or just to thank me. The count of respondents must be over a hundred by now.

Here’s the 1.7 version. Substantial new material on the BBS scene – this is my answer to the people who have been bugging me to at least mention XMODEM/YMODEM/ZMODEM.

The expository approach I’m taking is to bin all of UUCP, the BBS scene, and commercial dialup services like AOL as parallel contemporaneous attempts to figure out what kind of store-and-forward messaging people actually wanted.

Alas, I had to drop the reference to the Space Cadet keyboard. Turns out it shipped a 32-bit status word and this had nothing to do with 9-bit bytes at all. The indirect reference to the SAIL extended ASCII keyboard is still in.

Patrick Maupin’s revelation about the AT prefix is summarized.

The fact that UUCP was a hack around the old two-tier structure of phone rates is mentioned.

There’s more about TTL serial. Gary Miller, my very hardware-savvy lieutenant and now acting lead on the GPSD project, thinks this didn’t become a common way to ship data off peripherals and daughterboards until after 2000, with GPS chips leading the way. This matches my recollection, but I was pretty oblivious about that sort of thing until the last decade so I don’t consider my recollection very good evidence. Commentary an correction invited.

I’d like to pin down the year cathode-ray tubes disappeared. I know the leading display vendors ceased production in 2005, but I think the transition might have been as much as two years sooner. Again, corrections welcomed.

On “common knowledge at the time”, I think the problem with dismissing things as “fascinating but obscure trivia” means too much exclusion of the real facts behind things that were already forgotten or inaccurately known, and reduces its value as a historical document. There’s also the fact that the intersection between, say, the Lisp and Unix hacker spaces seems to have been tenuous enough to cause some things to have been lost in translation […] – maybe there was never really anything every hacker once knew, just some things some hackers once knew, and other things other hackers once knew, all worth preserving. I think arbitrarily drawing lines around “provides too much historical context” runs the risk of the document being better described as “Things Eric Once Knew”.

I think this comment raises real issues that deserve to be squarely engaged. I’ve omitted one sentence that I think is based on a a factual misunderstanding in order to focus on the large questions.

New content in this one is an expanded section about outboard modems, their descendants in today’s technology, and the curious survival of the Hayes AT command set.

I had actually received a couple of previous requests to add material on the Hayes AT convention, but rejected them on the grounds that it had no relevance to current tech. This turned out to be not quite true!

Once again I emphasize that this document was not written as a nostalgia trip, but rather to assist retrospective understanding by younger hackers so they can make sense of the fossils and survivals still embedded in current technology.

The response to this document has been remarkable. I’ve received a flood of feedback and gratitude in my mailbox, often from people much more sentimental about the old days than I am.

I invite everyone who values this content to contribute at my Patreon page; this is exactly the kind of thing I couldn’t do if I couldn’t pay my Internet bills or had to get a $DAYJOB, and I’m currently in my sixth month of operating without institutional funding. $5 or $10 a month from enough people could fix that.

Your dollars will also go to fixing critical infrastructure, so please give generously – the civilization you save could be your own.

The response to this piece has been remarkably broad and positive. I have to note, though, that I didn’t write it as a nostalgia trip – I don’t miss underpowered computers, primitive tools, and tiny low-resolution displays.

At least people did notice that it isn’t a you-kids-get-off-my-lawn grumble. I think it’s good for younger hackers to know these things, but it’s no fault of theirs that the technological context has changed so much that they don’t absolutely need to to get work done. In fact it’s a sign of progress.

Yes, you’ll occasionally trip over old tech for which forgotten common knowledge is important – and RS-232, in particular, is still important in niche applications. But the real reason to remember these things is less tangible, and unfortunately difficult for many people to talk about without sliding into sentimentality.

In any kind of craft or profession, I think knowing the way things used to be done, and the issues those who came before you struggled with, is quite properly a source of pride and wisdom. It gives you a useful kind of perspective on today’s challenges.

The real reason I wrote this is to encourage that kind of perspective.

Updated version here. With: more about the persistence of octal, current-loop ASR-33s, 36-bit machines and their lingering influence, ASCII shift, a bit more about ASCII-1963, and some error corrections.

In my last blog post I expressed my severe disappointment with the gap between the Rust language in theory (as I had read about it) and the Rust language in practice, as I encountered it when I actually tried to write something in it.

Part of what I hoped for was a constructive response from the Rust community. I think I got that. Amidst the expected volume of flamage from rather clueless Rust fanboys, several people (I’m going to particularly call out Brian Campbell, Eric Kidd, and Scott Lamb) had useful and thoughtful things to say.

I understand now that I tested the language too soon. My use case – foundational network infrastructure with planning horizons on a decadal scale – needs stability guarantees that Rust is not yet equipped to give. But I’m somewhat more optimistic about Rust’s odds of maturing into a fully production-quality tool than I was.

Still, I think I see a problem in the assumptions behind Rust’s development model. The Rust community, as I now understand it, seems to me to be organized on a premise that is false, or at least incomplete. I fear I am partly responsible for that false premise, so I feel a responsibility to address it square on and attempt to correct it.

Every once in a while I post something just to have it handy as a reference for the next time I have to deal with a galloping case of some particular kind of sloppy thinking. That way I don’t have to generate an individual explanation, but can simply point at my general standards of evidence.

This one is about accusations of sexism, racism, and other kinds of prejudice in the open-source culture.