Mar 14

Semantic locality and the Way of Unix

An important part of the Way of Unix is to try to tackle large problems with small, composable tools. This goes with a tradition of using line-oriented textual streams to represent data. But…you can’t always do either. Some kinds of data don’t serialize to text streams well (example: databases). Some problems are only tractable to large, relatively monolithic tools (example: compiling or interpreting a programming language).

Can we say anything generatively useful about where the boundary is? Anything that helps us do the Way of Unix better, or at least help us know when we have no recourse but to write something large?

Continue reading

Mar 12

Ones-complement arithmetic: it lives!

Most hackers know how the twos-complement representation of binary numbers works, and are at least aware that there was an older representation called “ones-complement” in which you negated a binary number by inverting each bit.

This came up on the NTPsec development list recently, with a question about whether we might ever have to port to a non-twos-complement machine. To my utter, gob-smacked astonishment, it turns out ones-complement systems still exist – though, thankfully, not as an issue for us.

I thought I could just mumble something about the CDC 6600 and be done, but if you google “one’s-complement machines” you’ll find that Unisys still ships a series of machines with the brand “Clear-Path Dorado” (latest variant introduced 2015) that are emulations of their old 1100-series mainframes running over Intel Xeon hardware – and these have one’s-complement arithmetic.

This isn’t a practical port blocker for NTPsec, as NTP will never run over the batch OS on these things – it’s about as POSIX-compatible as the Bhagavad-Gita. It’s just weird and interesting that ones-complement machines survive in any form at all.

And a bit personal for me. My father was a programmer at Univac in the 1950s and early ’60s. He was proud of his work. My very first interaction with a computer ever was getting to play a very primitive videogame on the oscilloscope-based video console of a Univac 1108. This was in 1968. I was 11 years old, and my game machine cost $8M and took up the entire ground floor of an office building in Rome, Italy.

Other than the 1100, the ones-complement machines Wikipedia mentions (LINC, PDP-1, and CDC6600) are indeed all long dead. There was a ones-complement “CDC Cyber” series as late as 1989, but again this was never going to implement POSIX.

About other competitors to twos-complement there is less to say. Some of them are still used in floating-point representations, but I can find no evidence that sign-magnitude or excess-k notation have been used for integers since the IBM 7090 in 1959.

There’s a comp.lang.std.c article from 1993 that argues in some technical detail that that a C compiler is not practical on ones-complement hardware because too many C idioms have twos-complement assumptions baked in. The same argument would apply to sign-magnitude and excess-k.

UPDATE: It seems that Unisys is the graveyard of forgotten binary formats. I have a report that its Clear-Path Libra machines, emulating an ancient Burroughs stack machine architecture, use sign-magnitude representation of integers.

Mar 08

How to change the world in Zen easy lessons

This morning I stumbled over a comment from last September that I somehow missed replying to at the time. I suspect it’s something more than one of my readers has wondered about, so here goes…

Edward Cree wrote:

If I’m really smart enough to impress esr, I feel like I ought to be doing more with myself than toy projects, games, and an obscure driver. It’s not that I’m failing to change the world, it’s that I’m not even trying. (Not for want of causes, either; there are plenty of things I’d change about the world if I could, and I suspect esr would approve of most of them.)

Obviously without Eric’s extroversion I won’t be as influential as him, but… dangit, Eric, what’s your trick? You make having a disproportionate effect on the course of history look easy! Why can I never find anything important to hack on?

There are several reasons people get stuck this way. I’ve experienced some of them myself. I’ve seen others.

If this sounds like you, dear reader, the first question to ask yourself is whether you are so attached to having a lot of potential that you fear failing in actuality. I don’t know Edward’s age, but I’ve seen this pattern in a lot of bright young people; it manifests as a lot of project starts that are potentially brilliant but a failure to follow through to the point where you ship something that has to meet a reality test. Or in an opposite way: as self-constraining to toy projects where the risk of failure is low.

So my first piece of advice is this: if you want to have “a disproportionate effect on the course of history”, the first thing you need to do is give yourself permission to fail – as long as you learn something from every failure, and are ready to keep scaling up your bets after success.

The second thing you need to do is finish something and ship it. No, more than that. You need to make finishing and shipping things a habit, something you do routinely. There are things that can be made to look easy only by cultivating a lot of self-discipline and persistence. This is one of them.

(The good news is that once you get your self-discipline to the required level it won’t feel like you have to flog yourself any more. It’ll just be habit. It’ll be you.)

Another thing you need to do is actually pay attention to what’s going on around you, at every scale. 99% of the time, you find important things to hack on by noticing possibilities other people have missed. The hard part here is seeing past the blinding assumptions you don’t know you have, and the hard part of that is being conscious of your assumptions.

Here’s my favorite example of this from my own life. After I described the many-eyeballs-make-bugs-shallow effect, I worried for years at the problem of why nobody in the hacker culture had noticed it sooner. After all, I was describing what was already a decades-old folk practice in a culture not undersupplied with bright people – why didn’t I or anybody else clue in faster?

I remember vividly the moment I got it. I was pulling on my pants in a hotel in Trondheim, Norway, idly chewing over this question yet again. It was because we all thought we knew why we were simultaneously innovating and achieving low error rates – we had an unexamined, unconscious explanation that suited us and we never looked past it.

That assumption was this: hackers write better software because we are geniuses, or at least an exceptionally gifted and dedicated elite among programmers. Our culture successfully recruits and selects for this.

The insidious thing about this explanation is that it’s not actually false. We really are an exceptionally gifted elite. But as long as you don’t know that you’re carrying this assumption, or know it and fail to look past it because it makes you feel so good, it will be nearly impossible to notice that something else is going on – that the gearing of our social machine matters a lot, and is an evolved instrument to maximize those gifts.

There’s an old saw that it’s not the things you don’t know that hurt you, it’s the things you think you know that ain’t so. I’m amplifying that: it’s the things you don’t know you think that hurt you the most.

It’s not enough to be rigorous about questioning your assumptions once you’ve identified them. The subtler work is noticing you have them. So when you’re looking for something important to hack on, the question to learn to ask is: what important problems are everybody, including you, seeing right past? Pre-categorizing and dismissing?

There’s a kind of relaxed openness to what is, a seeing past preconceptions, that is essential to creativity. We all half-know this; it’s why hackers resonate so strongly with Zen humor. It’s in that state that you will notice the problems that are really worth your effort. Learn to go there.

As for making it look easy…it’s only easy in the same way that mastery always looks a skill easier than it is. When someone like John Petrucci or Andy Timmons plays a guitar lick with what looks like simple, effortless grace, you’re not seeing the years of practice and effort they put into getting to where that fluency and efficiency is natural to them.

Similarly, when you see me doing things with historical-scale consequences and making it look easy, you’re not seeing the years of practice and effort I put in on the component skills (chopping wood, drawing water). Learning to write well. Learning to speak well. Getting enough grasp on what makes people tick that you know how to lead them. Learning enough about your culture that you can be a prophet, speak its deepest yearnings and its highest aspirations to it, bringing to consciousness what was unconscious before. These are learnable skills – almost certainly anyone reading this is bright enough to acquire them – but they’re not easy at all.

Want to change the world? It’s doable. It’s not magic. Be aware. Be courageous. And will it – want it enough that you accept your failures, learn from them, and never stop pushing.

Mar 06

Reposturgeon recruits the CryptBitKeeper!

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.

Continue reading

Feb 20

Things Every Hacker Once Knew: 1.10

And the latest revision:
Things Every Hacker Once Knew.

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.

Feb 19

The simplest possible method syntax in C

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.

Continue reading

Feb 17

Things Every Hacker Once Knew: 1.9

I’ve shipped another revision of Things Every Hacker Once Knew

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.

Feb 14

Things Every Hacker Once Knew: 1.8

Heritage games. The legacy of all-uppercase terminals. Where README came from. What “core” is. The ARPANET. Monitoring your computer with a radio. And more…

Things Every Hacker Once Knew

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.

Continue reading

Feb 13

loccount: A faster SLOC utility

Here’s my first new project in a while – loccount, inspired by David A. Wheeler’s sloccount tool but much faster and with broader language coverage.

I actually wrote this as a learning exercise in the Go language. You can find more details in my NTPsec blog post on Grappling With Go.

If you like it, please remember that open source may be free but my time is not and join my Patreon feed.

Feb 09

Things Every Hacker Once Knew: 1.7

Did I say Things Every Hacker Once Knew was stabilizing? Silly me…

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.

Feb 08

Things Every Hacker Once Knew: 1.6

The newest version is here.

I think it’s stabilizing. The rate of comments and submissions has been dropping.

Changelog:

     How VDTs explain some heritage programs, and how bitmapped
     displays eventually obsolesced them. Explain why the ADM-3
     was called "dumb" even though it was smart.

There’s also a mention of RS-323 on network gear.

Still nothing about XMODEM/YMODEM/ZMODEM – that’s probably the most requested addition left, but I really don’t see what could be interesting to say about them at this late date.

The reaction to this on my Patreon feed has been impressive. It seems to have driven $300-$400 of new subscriptions.

Feb 06

Things Every Hacker Once Knew: 1.5

The 1.5 revision of Things Every Hacker Once Knew is out.

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.

Feb 05

In defense of recording folk history

One of my regular commenters on A&D, Random832, wrote the following in response to my inclusion criteria for Things Every Hacker Once Knew.

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.

Continue reading

Feb 03

Things Every Hacker Once Knew: 1.4

New version 1.4 at:

http://www.catb.org/esr/faqs/things-every-hacker-once-knew/

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.

Jan 29

Things Every Hacker Once Knew: 1.2

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.

Jan 25

Tools generate culture: a trivial example

If I were the kind of person who grumbles about feeling ancient, I’d have been doing it today.

I got reminded that younger hackers don’t know the bit structure of ASCII like their tongues know the back of their teeth. Man, we all grokked that back when I was new at this.

Nowadays not so much. I’ve actually seen younger hackers be confused about, say, how to generate a NUL from the keyboard. And I’m all, like, “How can you not know this?”

I’m bothering to post because I think I’ve figured out why this changed. The kids are OK, it’s conditions around them that have shifted.

Continue reading