Things Every Hacker Once Knew: 1.10

http://esr.ibiblio.org/?p=7388

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.

The simplest possible method syntax in C

http://esr.ibiblio.org/?p=7380

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.

Suppose we have two structs named snark and boojum and a function that takes one of each. That is:

struct snark {
    /* stuff goes here */
}
 
struct boojum {
    /* other stuff goes here */
}
 
int conjugate(int x, struct snark *, int y, struct boojum *, int z);
 
struct snark s;
struct boojum b;

Then my proposal is this: under almost all circumstances, the compiler
should automatically perform the following transformations::

s.conjugate(1, 2, &b, 3) -> conjugate(1, &s, 2, &b, 3)
b.conjugate(1, &s, 2, 3) -> conjugate(1, &s, 2, &b, 3)

That is, if the compiler encounters an attempt to evaluate a structure member reference followed by an argument list, for a member that doesn’t exist in the structure (that’s the “almost”), it looks for a visible function with the right name, and then tries to apply it to transform the method-like syntax into an actual method call.

The rule will fail unless the actual arguments match all of the formal argument types of the function in the right order, except that one actual argument is missing. It will also fail unless the one formal without a corresponding actual has any type other than address of the structure for which we are synthesising the method call.

(It has to be address of, otherwise these method calls could never mutate the instance – they’d get an arg-stack copy of it instead.)

I think I got this idea by miscegenating a recent language called Julia with Rust’s method syntax and some dim memories of CLOS. It has a couple of interesting advantages:

1. No front-end modifications or new syntactic tokens are required – it can be implemented entirely as a transformation on abstract syntax after parsing.

2. Entirely upward-compatible with plain C – if you try to feed this to a compiler without the extension it will break noisily at compile time.

3. Same function can be a method of multiple structures without the requirement that you make an articial commitment to which one “really” owns it. (I find this comes up remarkably often.)

Of course, as I mentioned up front, this is not an entire object system. Conspicuous by its absence is inheritance or a trait/interface system. The final advantage of this proposal is that it would not foreclose or complicate any of those alternatives.

Things Every Hacker Once Knew: 1.9

http://esr.ibiblio.org/?p=7373

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.

Things Every Hacker Once Knew: 1.8

http://esr.ibiblio.org/?p=7367

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.

A reminder: This document is not intended as a mere ramble down memory lane – it’s much more focused than that. New content has to pass three filters: (1) was common knowledge at the time, (2) has since been forgotten or seems very near forgotten, and (3) might be useful knowledge to younger hackers working on open-source platforms – or is, at the very least, entertaining.

Some matters of potential interest:

1. The largest category of suggested additions that has failed to pass my filters is facts of the form “specified set of obscure ASCII control characters was or is used in specified obscure point-of-sale or financial-transaction protocol”.

2. The most popular single suggested edition that I’ve rejected is that DEL is 7 1-bits because of the paper-tape rubout character. Sorry, guys, I had to draw the chronological/generational line somewhere; just forward of paper tape and punched cards is it.

3. I myself became a direct observer of all this in 1976, about a year after VDTs matured into their final form and at about the earliest point that they were replacing printing terminals in Ivy League computer labs (the rest of the universities lagged this by a few years).

4. I’ve had two mildly protesting emails out of a hundred or so from people who identify as hackers but came up through mainframe-land and never dealt with the whole scene around serial terminals, micros, BBSes, and so forth. Had to tell them that I can only write what I know – and that the ex post facto justification for caring about what I happen to know is that it morphed into today’s open-source culture.

And a final reminder: If gratitude were cash this document would make me a rich man. Since it isn’t, and I have no funding, please express your thanks more tangibly by joining my Patreon feed.

loccount: A faster SLOC utility

http://esr.ibiblio.org/?p=7362

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.

Things Every Hacker Once Knew: 1.7

http://esr.ibiblio.org/?p=7359

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.

Things Every Hacker Once Knew: 1.6

http://esr.ibiblio.org/?p=7356

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.

In which, alas, I must rattle a tin cup

http://esr.ibiblio.org/?p=7348

The work on NTPsec is going very well. Unfortunately, since we lost our CII funding in September, my personal situation isn’t.

Ever since the Destroy Full-time Employment Affordable Care Act smashed my wife’s legal job out of existence, we’ve felt under some pressure at Chez Raymond. While Cathy was full-time employed, my earnings from royalties and consulting contracts were what we saved against a rainy day or retirement. Since then we’ve had to live on what I make and occasional legal piecework.

The NTPsec funding came on-stream just as we were starting to worry seriously about money. That kept us out of trouble for a little over a year, but now that’s gone, and the legal piecework market is apparently flooded with attorneys whose jobs were also crushed by the ACA around the same time my wife’s was. It’s a buyer’s market and a lot of what she’s being offered these days is not just scutwork, but would barely cover her expenses after travel.

(For reasons I don’t understand, law seems to have been hit harder by the ACA employer mandate than any other professional field except higher education. I hear non-tenured faculty are even hungrier than lawyers these days.)

So now it’s been five months since either of us has been drawing anything like a salary. We’re burning savings, and Cathy – who grew up poor and thus finds a state of no income viscerally terrifying in a way I do not – has started to look like a shell-shock victim. This is damaging my morale.

The only bright spot is my Patreon feed. Right now it’s pulling $1,392 a month, which is actually rather a lot for Patreon but nowhere near enough to cover our living expenses. That would take about $3,000 a month; the big items are mortgage and medical insurance driven stratospherically up in cost by the same disastrous government bungling that cost my wife her job. Then, of course, there’s income tax; with that I figure we’d need $5K a month to be sure of keeping our heads above water.

Thus, even with the Patreon, we’re fast approaching the point where if someone were to offer me a day job, I’d have to take it. And that would be unfortunate for the long term; the infrastructure work I’m doing and expect to do in the future is tremendously important. Somebody’s going to need to design and field NTPv5 to fully cover the IPv6 transition, and it looks increasingly like that somebody needs to be me.

To everyone reading this who is already contributing to my Patreon feed as an individual, Cathy and I thank you. Someday the rest of the world may be grateful, too.

Now I’m appealing to those of you at corporations and institutions. If you use open-source software (including, say, the browser you’re reading this through) you almost certainly rely on code I wrote every day. Soon, you’ll very likely be relying on my code to provide time service for your computers.

If you have purchase authority for software, please use it to sign your company or institution up as an “Institutional Supporter” of my Patreon account. For $100 per month, you will help ensure that all 50+ of my projects stay under maintenance – and your organization will be listed as a sponsor every time I do a project release after you sign up.

Please don’t wait; do it now. Don’t kid yourself that essential infrastructure like time service is somebody else’s problem; it’s your problem, and this is how you can be sure it gets solved.