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.
“The history of the Trek group is too complex to summarize here. The thing to notice about them is that the extremely crude interface (designed not even for VDTs but for Teletypes!) hid what was actually a relatively sophisticated wargame in which initiative, tactical surprise, and logistics all played significant roles.”
I never thought of it that way, but you have a point. Like many others, I spent hours playing those – and yes, even on 33 ASRs. Eventually, I settled on what I thought of as “the crispy Klingon method”: go to the nearest starbase, tank up, warp directly into a sector either known to have Klingons or else completely unknown, get the really close Klingons with phasers, blast away with photon torpedoes, fry all of the Klingons, lather, rinse, repeat. That method makes use of all of those concepts, though I didn’t think of them in those terms.
It’s worth noting that one of the more popular demos for Hercules is a Trek, too…
Another ASCII addition: SI did get use on (at least) Unix, but as the discard command rather than shifting between character sets. ISTR using it to cancel excessively-large runs of output in the days when you actually dialed in to a getty instance with a blazingly-fast 2.4k modem.
The Trek game I was alluding to in the previous thread was actually netrek, a real-time combat sim based on Empire. It’s weird that I completely forgot about the turn-based Trek, considering that I wrote a full version of it from scratch on my dad’s EGA-monitored computer in order to learn OO Pascal.
Speaking of Empire, ISTR another game called Empire that I frequently saw on Mac 2s. Turn-based ground combat on a grid, arguably a precursor to Sid Meier’s Civilization (the looks-and-feels were very similar).
>Speaking of Empire, ISTR another game called Empire that I frequently saw on Mac 2s. Turn-based ground combat on a grid, arguably a precursor to Sid Meier’s Civilization (the looks-and-feels were very similar).
Yeah, that sounds like one of the Empire variants. Does this seem familiar?
Is the repo for this document hosted anywhere?
>Is the repo for this document hosted anywhere?
Yes, on the Great Beast. :-)
No, I haven’t pushed it to GitLab or anywhere yet.
esr:
That’s great news news :-)
“2007: iPhone and Android (both with Unix-based OSes) first ship.”
That is probably a better solution in the scope of the document than trying to nail down the “first smartphone.” Smartphones in general are irrelevant to “things hackers knew”, but the intrusion of Unix into the pocket is relevant.
Yeah, that sounds like one of the Empire variants. Does this seem familiar?
A screenshot of the UI itself would clinch it, but I’m very certain this is the one.
In the late ’70s, I used teletype terminals that had attached paper tape punch/readers. I could turn on the punch and “print” a program to the paper tape. (high school computer club, screwing around at the local technical college.)
In the early ’80s, at the University, I saw some sort of PDP zipping backwards and forwards through fan-fold paper tape. IIRC, I was told that the tape held the software that was running.
Re. Empires: There was a similar game which I found on one of my dad’s Compute! Magazine discs from the late ’80s. Sorta Risk-like, but with three types of armies: infantry, cavalry, and archers, and instead of dice, a 3×3 matrix of how effective each type was against each type, plus a rule that infantry could not attack enemy archers until the enemy infantry was defeated.
My dad’s blazing 66MHz 486 was too fast for the game: it used a delay loop for in-game messages and I’d usually find myself stuck with no clue what was wrong beyond an error message which blinked past too quickly to read. And when (in the early 2000s) we dug up from the school computer lab some sufficiently-ancient 8086-based PCs, I found my father has already thrown out the magazines and the discs. 😞
@Jay Maynard:
> Like many others, I spent hours playing those – and yes, even on 33 ASRs.
ISTR playing some variant of Trek on the Apple IIs in the back of one of my 5th grade classrooms. The gameplay I recall seems to match Trek, but the interface doesn’t: I clearly recall that the game I played had no map, while pretty much every Trek variant I can find reference to seems to have featured one: it simply gave text descriptions of the action and took text commands. Between this and being around age 10 or 11 at the time, I didn’t grok the strategy and had a kill:loss ratio that was likely well south of 1:10.
Any idea what this might have been? Were there mapless Trek variants?
>Were there mapless Trek variants?
There were. I’ve played one, though the name and context escapes me. It focused on dialogue with the bridge officers and engineering – sort of a text-adventure Trek.
I definitely appreciate the inclusion of the Trek clade. I came of age in the 90s, and I distinctly remember the experience of playing a Trek (I’m pretty certain it was EGA Trek) at a friend’s as a child. A Short History of Trek Games helps me place myself in a lineage that goes Way Back and continues in some ways today.
@esr:
> There were. I’ve played one, though the name and context escapes me.
Actually having just tried out Linux trek, I don’t think the variant I played was mapless, I think 5th grade me wasn’t smart enough to figure out srscan. I was probably playing plain old Apple Trek.
Other than trek, one of my stronger memories of those Apple IIs at school is:
Foo
SYNTAX ERROR?
Bar
SYNTAX ERROR?
Baz
SYNTAX ERROR?
Foo with parameters
SYNTAX ERROR?
10 year old me did not really grok the command line.
In the bit on the SOH character, you might mention that it is still currently used as intended in the FIX protocol (https://en.wikipedia.org/wiki/Financial_Information_eXchange#FIX_message_format_layout). FIX is central to equities trading (stock markets).
>In the bit on the SOH character, you might mention that it is still currently used as intended in the FIX protocol
Fails the common-knowledge filter.
A possibly interesting note for the section on modems is that the three blasts heard at the beginning of every Emergency Alert System message are not just attention tones, but actually a 520 baud FSK encoding of the details on the alert being transmitted.
>A possibly interesting note for the section on modems is that the three blasts heard at the beginning of every Emergency Alert System message are not just attention tones, but actually a 520 baud FSK encoding of the details on the alert being transmitted.
Wow, does that fail common knowledge.
Trek variants were popular on BBSes as well.
And due to a commercialized Empire variant (PC-DOS) using a MIDI version of Hall of the Mountain King as its “soundtrack,” I have Empire irrevocably associated with HotMK in my mind (and vice versa, of course)
But I’m glad for these threads!
> Wow, does that fail common knowledge.
The reason I find it noteworthy is that, while the fact that the blasts contain data isn’t generally known, *everybody* knows what it sounds like and comes into contact with it on a reasonably frequent basis. It’s not some obscure proprietary thing that you only come across if you work in a certain industry: if you live in the US and consume TV or radio at all you *know* that sound, and the format is publicly documented. Any interested hacker could probably write their own decoder and cobble together their own weather radio.
What I find so intriguing is the combination of pervasive general knowledge of the signal with lack of general knowledge of its content, even among the technically knowledgeable. It’s hidden in plain sight.
I recognize I’m not really much help in this project. I was on the sidelines for most of it, in college in the ’70s, military in the ’80’s and business in the 90’s. But I’m enjoying memories and recognition of some hackerish events I saw from the stands, thanks.
There was, as I recall, a debate or at least a concern about screen-savers. The old amber or green screen CRT displays would get burn in of the prompt characters, or other default text left on, unchanging, for long periods. DP (data processing, the pre-IT branch of the organization) would recommend at least turning off the CRT overnight if not during un-used periods of the day. Energy, electrical, savings were also claimed. Some DP types worried the users would turn off the PC from power switch (without shutting down programs cleanly correctly) but leave CRT still powered on. Or vice versa. As monitors got bigger and better some argued the “Burn In” problem was a myth. Sometime around late 80s or very early 90’s there was an app thing called “Flying Toaster” and all of a sudden this gimmicky toy software would get written into user package specs right along side WordPerfect, 123, and Paradox. We could tell which users were well regarded by the DP team by whether or not the toaster request was approved and forwarded for procurement
Another trick a DP guy showed me for DOS (no idea about UNIX) that may have been common was installing ANSI.SYS escape code control characters in the prompt line in the config and autoexec files to create a colorful custom prompt — Texas Flag was popular in my offices. Also used ($p$g) to show current path — without codes in config file a less informative prompt was presented. Don’t know if this was an “everybody” kind of thing or not. In any case running a custom “autoexec” batch file for each user helped screen burn issue slightly by varying the prompt that might be left up overnight and which user may have forgotten to shut down.
MS Windows, IIRC, arrived with a timed screen saver as part of the standard default installation — in line with the TREK theme already discussed one option was a field of bright specks growing and radiating to the screen edges, intended to look just like the main screen star field shown from the bridge of the Enterprise. This was in my vicinity considered pretty neat.
While on the subject of Old School Things that have gone by the wayside, or maybe not, I was surprised to find this still orking:
finger bofh@wisc.edu
[wisc.edu]
102:There was 1 match to your request
-200:1: name: Your excuse is…
-200:1: text: electro-magnetic pulses from French above ground
-200:1: : nuke testing.
200:Ok.
> >A possibly interesting note for the section on modems is that the three blasts heard at
> >the beginning of every Emergency Alert System message are not just attention tones,
> >but actually a 520 baud FSK encoding of the details on the alert being transmitted.
> Wow, does that fail common knowledge.
Yeah, I found out about that in 2015 helping someone troubleshoot delivery of EAS alerts over a CDN. I didn’t know it was 520 baud though.
IIRC there are servers in various areas using software defined radio that listen for those alerts and trigger insertion into news/tv video streams based on geoip. (The latter part is for certain, at least as of 15 months ago, it’s the software defined radio I’m not 100 percent sure on).
Basically this is more or less how cable companies inject EAS alerts into on-demand or live streams to IP based devices (older set tops boxes are WAY easier).
You almost touch on it in several places but don’t directly mention binary to text (or ASCII) encoding, which is something that was widely known and frequently performed by users, and still lives on, more obscurely perhaps today. There were two primary drivers for such encoding: to send binary data over communications channels that weren’t 8-bit clean; and for transmitting or storing binary data on printed medium (paper).
Though there were obscure text to binary encodings, mainly used to publish free programs in paper magazines where extraordinarily patient users could type them in; the first widely used encoding system I remember was UUencode. Yes it was part of UUCP, but it was also widely used on its own, in the form of the Unix uuencode and uudecode commands, as well as being widely used in USENET messages. Until the uuencoding convention became near universally adopted and newsreader software was developed that automated it, it was quite common for people to manually use uuencode/uudecode along with cut/paste into a news message.
Also, aside from the purposes you mentioned of the XMODEM and family of protocols, another almost as important purpose of those programs was to transfer binary files over an ASCII, or 7-bit connection (frequently modem-based)n as they had built-in binary to ASCII encoders, of various flavors.
While talking about 7-bit connections, where the 8th bit was often stolen as a parity bit, this also necessitated an encoding mechanism for truly binary data. That still lives on today in the SMTP email protocol. Even the modern version of SMTP (RFC 5321) is still essentially a 7-bit protocol, though modern end points can sometimes optionally negotiate 8-bit data these days. This is one of the reasons MIME was invented (among others), and which gave us the now ubiquitous Base-64 binary to ASCII encoding … which once again is still widely used in lots of contexts.
Oh, on a different topic, JavaScript is also one of those languages that inherited C’s dangerous 0-prefix octal numbers, but in similar fashion mentioned in your footnote, has now eliminated that lexical syntax in the latest version in “strict” mode.
> binary to text (or ASCII) encoding, which is something that was widely known and frequently performed
Thanks, some of this is going in. It is exactly in accord with the purpose of TEHOK to explain why Internet protocols still in use are designed around the assumption that high bits might be clobbered.
>communications channels that weren’t 8-bit clean
Can anyone, at this late date, still identify non-8-bit-clean WAN protocols?
I think BITNET had this problem. JANET? EARN? X.25 in general? I don’t know, I never had to pay much attention to those.
@ Brad Ackerman:
> Another ASCII addition: SI did get use on (at least) Unix, but as the discard command
> rather than shifting between character sets.
I remember this (Ctrl-O) from PDP-11s and VAX/VMS (which probably means that it has a DEC heritage going back further), but never realised that it was supported in Unix until you mentioned it. It seems to be provided for in Linux but doesn’t work, according to the man page and by experiment. It works in Solaris, though.
> MS Windows, IIRC, arrived with a timed screen saver as part of the standard default installation — in line with the TREK theme already discussed one option was a field of bright specks growing and radiating to the screen edges, intended to look just like the main screen star field shown from the bridge of the Enterprise. This was in my vicinity considered pretty neat.
Windows still includes screensavers by default, though they are no longer turned on by default and the starfield screensaver is no longer included, having disappeared either in Vista or 7. However, if you can get ahold of the executable (preferably from an old windows hard drive rather than dredging it from some shady download site) and drop it into system32, you can still set it up as your screensaver on Windows 10.
“…the three blasts heard at the beginning of every Emergency Alert System message are not just attention tones, but actually a 520 baud FSK encoding of the details on the alert being transmitted.”
And the three short end tones are EOMs, sent thrice since the system blind-forwards through radio stations, with no answer-back. Many stations automate relay of genuine alerts and the required monthly tests — and woe betide everyone downstream if their upstream source cuts away before the EOMs, because they’re stuck relaying until someone in control notices or an EOM happens along. That has happened, most infamously in CA; commercials and promos that use the real tones are one of the worst sources of this.
Line printers – the name survives as the lp command, meaning print to the default printer.
>Line printers – the name survives as the lp command, meaning print to the default printer.
Good catch! I’ll add that.
@ esr
Better late than never…
Please accept my sincere apology for suggesting, some time back, that all your blog needed was for the [SJW] “undesirables” to leave. I was out of line.
And, to make a clean sweep (I hope)…
@ John Bell
Back when we were financing the Great Beast, I said, a couple of times, “What John and I are doing…”. I should not have said it that way, leaving the impression that we were doing anything together (other than both of us making non-trivial donations to the cause). I am not sure if this is an issue; if it is, I am very sorry.
@ esr
Actually, what I did was suggest that I knew you agreed that the “undesirables” should leave – a content-free insult to a variety of people on your behalf. I am very sorry.
> Can anyone, at this late date, still identify non-8-bit-clean WAN protocols?
I don’t remember any WAN protocols that suffered this, certainly in terms of any always-connected addressable networks. Though certainly serial-based point-to-point communications were unclean; especially direct modem to modem connections or hard-wired null-modems. This was of course prior to or outside of general networks like SNA or TCP/IP, and the encapsulating protocols like SLIP, CSLIP, and much later PPP which made using them over point-to-point connections possible. SLIP, being the earliest such encapsulating protocol I remember using, required an 8-bit clean line, which usually required hardware EIA (RTS/CTS) flow control rather than inline XON/XOFF controls.
This is, I think, why the email protocols and formats we still use today are mostly 7-bit at heart, because being a store-and-forward system designed when TCP/IP was still somewhat exotic it was never known how a message might make each hop. Certainly it could be over non-TCP/IP transports. I remember writing a highly modified version of sendmail that could relay mail between Unix and IBM mainframe PROFs, and aside from the obvious nastiness like EBCDIC conversions and mailbox naming translations, I’m almost certain it could not rely on any 8-bit clean transport, though the details are hazy at this point.
I think this is also why the FTP protocol still has a lot of 7-bit crud left; though it was also trying to do much more such as character set conversions and such.
@pouncer: Screen burn-in was absolutely a thing. I vividly remember an amber monitor on a Novell server that was running for years on which you yould see the box characters used to draw the main menu even when it was turned off!
We also had the After Dark screen saver collection with the flying toasters on our PCs, but I liked the aquarium better.
@Brian Marshall –
> @ John Bell
> Back when we were financing the Great Beast, I said, a couple of times, “What John and I are doing…”. I should
> not have said it that way, leaving the impression that we were doing anything together (other than both of us
> making non-trivial donations to the cause). I am not sure if this is an issue; if it is, I am very sorry.
No problems here. I didn’t think you were stealing my thunder, or anything like that. The issue was bigger than either of us; I’m glad for your contribution.
More importantly, Eric is.
Thanks, John.
When I found this blog, I went:
John Bell. Looks like a professor. Professor John… Bell? PROFESSOR JOHN BELL??
But no. You aren’t that old.