Ask Slashdot: What Are Some Things That Every Hacker Once Knew? (ibiblio.org)
Open source guru Eric Raymond turns 60 this year, prompting this question from an anonymous reader:
Eric Raymond's newest writing project is "Things Every Hacker Once Knew," inspired by the day he learned that not every programmer today's knows the bit structure of ASCII. "I didn't write it as a nostalgia trip -- I don't miss underpowered computers, primitive tools, and tiny low-resolution displays... 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."
He writes later that it's to "assist retrospective understanding by younger hackers so they can make sense of the fossils and survivals still embedded in current technology." It's focusing on ASCII and "related technologies" like hardware terminals, modems and RS-232. ("This is lore that was at one time near-universal and is no longer.") Sections include "UUCP and BBSes, the forgotten pre-Internets" and "The strange afterlife of the Hayes smartmodem" (which points out some AT commands survived to this day in smartphones). He requests any would-be contributors to remember that "I'm trying to describe common knowledge at the time." This got my thinking -- what are some that every programmer once knew that have since been forgotten by newer generations of programmers?
Eric Raymond is still hard at work today on the NTPsec project -- a secure, hardened, and improved implementation of Network Time Protocol -- and he promises donations to his Patreon page will help fund it. But what things do you remember that were commonplace knowledge "back in the day" that have now become largely forgotten? Leave your best answers in the comments. What are some things that every hacker once knew?
He writes later that it's to "assist retrospective understanding by younger hackers so they can make sense of the fossils and survivals still embedded in current technology." It's focusing on ASCII and "related technologies" like hardware terminals, modems and RS-232. ("This is lore that was at one time near-universal and is no longer.") Sections include "UUCP and BBSes, the forgotten pre-Internets" and "The strange afterlife of the Hayes smartmodem" (which points out some AT commands survived to this day in smartphones). He requests any would-be contributors to remember that "I'm trying to describe common knowledge at the time." This got my thinking -- what are some that every programmer once knew that have since been forgotten by newer generations of programmers?
Eric Raymond is still hard at work today on the NTPsec project -- a secure, hardened, and improved implementation of Network Time Protocol -- and he promises donations to his Patreon page will help fund it. But what things do you remember that were commonplace knowledge "back in the day" that have now become largely forgotten? Leave your best answers in the comments. What are some things that every hacker once knew?
Watch Casey Muratori's Handmade Hero, where he codes a game live on Twitch from scratch with no 3rd party libraries.
His entire effort is fueled by his desire to educate the next generation of developers with an understanding of how computers *actually* work, which is something he feels is both important and has been lost.
https://handmadehero.org/
Stick a hot soldering iron through the upper-left hand corner of your 720K floppy and now you've doubled the capacity.
RS232 an null-modems are mentioned in TFA, but I'd like to add a detail:
Most of the more hackerish students where I went (ca 1990) knew the minimal pinout for a null-modem by heart so we could improvise one with 3 wires and matches/paperclips/whatever. By the time we graduated LANs and to some degree internet mane that knowledge obsolete, but it sure did save the day a few times, typically for transferring files between different platforms with different floppy formatting.
sudo ergo sum
Hexadecimal: what it is, why it is and how & why it evolved from octal.
That, and why real computer scientists often confuse Halloween w/ Christmas: 31 Oct = 25 Dec.
Error: NSE - No Signature Error
(Yes, they existed - especially in the mid-1980s) all knew:
- Interrupt 18 to force a reboot
- The memory range which was set aside for the display, and which you had to write to in order to do graphics (non-hackers used libraries but hackers mostly went for embedded assembler to try and squeeze a little more speed out for graphics work)
- The hex number for every one of the 16 colors a CGA display could show (Sierra Online took it a step further in the AGI engine and invented an early precursor of the scene-bumpmap which allowed their pseudo-3D adventure games to work by using a map-image where depth was indicated by color allowing characters to walk in front or behind objects). Unlike a true bumpmap it didn't specify height for lighting, it specified distance from the screen for movement. It allowed the Y axis to double as a Z axis
- How to read/write from the parallel port
- How to write to the PC-speaker's memory address to play sounds
- How to access extended memory
All things that went by the wayside when Unix and Win32 became available on the PC platform, acting like you are root all the time became frowned upon, libraries became the normal way of doing things, memory wasn't artificially limited to 640K. Some of the legacies of this era lived on rather longer than you'd think. As late as the early 2000's the best way to run most games on Linux was still using SVGALib - which wrote directly to video memory and didn't require resources for X, but in an age before the DRM driver in the kernel SVALib meant you had to run your game as root. I still played Quake2 that way ! The way SVGALib worked was simply a slightly larger memory region using the exact same techniques that we had used in the 1980s.
Unicode killed the ASCII-art *
What Are Some Things That Every Hacker Once Knew?
Do you mean hacker as in programmer or hacker as the media usis it to describe a digital burlgar? If you mean the former, these days it seems to be simple stuff like checking for open ports with telnet and then having fun by typing in protocol messages: http://www.shellhacks.com/en/S..., or even simpler stuff like editing documents with vi and using command line programming tools. These used to be things that every programmer knew, I learned this in school but many of our new recruits seem to be totally unaware of this stuff. I've written programs tens of thousands of lines long with nothing but vi, gcc/g++, make, tcpdump+Wireshark, valgrind, vi and a few other choice commandline monsters but these days the GUI generation seems to need a GUI editor, preferably a GUI IDE, a GUI networking tool, a GUI debugger, etc... to do simple stuff. I don't usually even need a debugger, I can normally figure out what is wrong without one. A few years ago I was handed a .NET assignment. After much complainign and whining (Unix guy through and through) I coded it up using that primitive little Windows CMD terminal, a freely available .NET compiler and vi/make before the IT department got around to installing Visual Studio. The really funny thing was that even some seasoned .NET developers were surprised to see you could (a) run vi/make and other GNU tools on Windows and (b) compile .NET code from the command line: https://msdn.microsoft.com/en-.... BTW, and this is probably heresy around here, but I really like how Microsoft seems to have a well documented API for everything as long as you are willing to bother learning .NET or Visual Basic.
The "control characters" have their own special position in ASCII, as the codes below the space character: 0x00 through 0x1F.
Yet, for some reason, there is one more sort-of control character outside that range: DEL, which is 0x7F. This bit of lore is actually from before my time, but I know why.
People used to actually use paper-punch machines to punch input tapes. What could you do if you mis-punched? There's no good way to fill in holes you didn't mean to punch, but you could go back and punch more holes. ASCII is a 7-bit standard and DEL is all 7 bits set. So, if you hit the wrong key on the punch, you could hit DEL and it would punch out all the rest of the holes, making 0x7F or DEL, and the paper tape reader would simply ignore any DEL characters it saw.
Oh, I guess anyone who can use Wikipedia didn't need me to find this out.
P.S. I didn't actually know why the carat notation for DEL is ^?, but Wikipedia explains that as well. Neat!
lf(1): it's like ls(1) but sorts filenames by extension, tersely
The zero page on e.g., a 6502 consisted of the first 256 bytes in memory, so the address of any byte therein was only a single byte in stead of two. Access therefore was faster on that page than of all other parts of memory.
The Apple II was my first computer. I bought it when I was thirty, in 1979. I then was an art historian, looking for new ways to administrate art collections. It really changed my life
Paai
Epson printer ESC codes - you embedded them in text documents and sent them to your parallel port dot-matrix printer, and they produced bold and italics and double width, and all sorts of effects.
ANSI escape screen codes - for setting foreground and background colours and other screen effects (clear screen, home) when you got bored with light grey on black.
I am anarch of all I survey.
Where I went to college, there were dumb terminals hooked up to serial lines in various locations around campus. Students would take turns using them. (They're all gone now... everyone has their own computers and it's all WiFi and/or Ethernet now.)
When you logged in to any campus computer, the very first thing it would do was print a cryptic prompt: term? [vt100]
This was your one opportunity to correctly enter a terse code that described the terminal you happened to be using. Terminals were not cheap, and nobody was going to throw away old ones when new ones were bought, so the campus had a mix of terminal types. It would have been nice if there had been a universal standard way to interrogate a terminal to find out its type (some reserved escape sequence) but there wasn't, so it was up to you to enter it correctly.
So every terminal had a little slip of paper on it saying something like: TERMINAL TYPE: vt100
There was always a default, which you would get if you just hit the Enter key. I cheated in the above examples and put vt100 but I think the default was something else; VT-100 terminals were not actually common (I think I only ever saw one!). I no longer remember what was common, just whatever they happened to buy a lot of.
If you got it right, then the system used termcap to look up the capabilities of your terminal, and it would know how to use the cursor-movement features of your terminal. In short, you could run programs like vi and emacs. If you got it wrong, and then tried to run vi and emacs, your screen would become horrible hash quickly. What on one terminal would move the cursor around might be meaningless on another terminal or might have some different effect. (Imagine if the "move cursor to X,Y" command one one terminal was "clear to end of line from position X,Y" on another brand of terminal. That sort of wackiness.)
So the two bits of lore that every computer-using student at my college needed to know: how to correctly enter the terminal type, and how to fix it if you entered it incorrectly. (Best to just stop what you were trying to do and logout!)
But here's the punchline of the above lore:
Computer geeks like me used the terminals all the time. People who had to do statistics work also used them a lot, but some students rarely used them. For some students, the only times they used a terminal was once per quarter, to sign up for classes for the new quarter.
When I started at college, this was easy. You got a paper printed class catalog booklet, you would look up the course numbers of the courses you wanted to take, and from any terminal you would login to a special account. A program would run, reading standard input and writing standard output, and it would prompt you to enter your student ID number and the course numbers. After you entered each number, you would be prompted: Is this correct? yes/no and you would answer. Simple. I don't think it even bothered to prompt for terminal type, and even if it did, it didn't use it for anything.
But then some computer science grad students went ahead and improved the system. They added browsable menus. You could use the arrow keys to browse through, drill down, find your course and pick it. You didn't need a paper catalog of course numbers! But now you actually needed to enter the terminal type correctly. All the students who rarely used the terminals had no clue what term? [vt100] meant, and usually just hit Enter, and then they were hosed.
I'm sure now it's all web forms: no need to print paper booklets, and nobody has any serious problems using it. Not all the old ways were better.
P.S. The campus had a couple of ADM-3A terminals, and I used them from time to time if nothing better was available. They had no dedicated cursor arrow keys, but had arrows printed on H J K L pointing left, down, up, and ri
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I'm seeing a plethora of 6, 5 and even 4 digit userids post here for this one. Good to see we ain't dead yet...
WDD1100 jumpers, ABit dual CPU mobos w/ peltior plates.
My Yellow card, Abend Aid was an amazing help when looking at 40Meg bal360 dumps.
Trips over to the data center to nail down the last couple slashes for some JCL
Late afternoon games of snipes on Novell 2.15 networks
Using that 3270 terminal/XT PC in my cubical farm nest - SNA and IPX/SPX
programming the Gigi keyboards to mess with others in the college computer labs
replacing miles of coax with Cat5 as a sign of the change of times.
Now I get to sit on the porch here in sunny south Georgia and chat with other old timers. TV studio eng, Packet radio guy,
and so many others. The poor kids of today don't really understand how good we had it.
For signed numbers, >> 2 and / 4 are not the same operation, so the compiler cannot do it for you.
Of course it can.
Compilers aren't AI, they can do any 'trick' the compiler writer knows, eg. using a shift instruction that preserves the sign bit. You need to disassemble some compiler output sometime and see the impressive amount of tricks they know. It's almost as if the compiler writers take pride in their work.
No sig today...
I worked in a building numbered 2600 with a bunch of developers for a few years. One day I pointed at the massive street numbers on the side of the building and said something like, "How appropriate." None of them had any idea what I was talking about.
Most kids these days have no idea what phreaking is, what a black box is, or a blue box, etc... Don't get me started on the contents of the anarchist's cookbook.
Most of them don't know what a MUD, MUSH or MUX was or how to program one, let alone about common door games (Trade Wars was the best).
Heck, I remember key cards which worked by perforations. Really easy to duplicate with a piece of cardboard. Remember core memory? Many "technical" folks nowadays probably can't do Boolean logic and wouldn't recognize most of the symbols. let alone binary operations or PEEK'ing and POKE'ing.
Thanks guys, now I'm starting to feel old. :)
The party of stupid and the party of evil get together and do something both stupid and evil, then call it bipartisan.
Ah... 80 column punch cards. And walking down the stairs with a 20 cm stack of data plus program, and dropping them, and then having to sort them by hand...
Paai
The protocol, not the frog (which it was named after).
Ubi dubium ibi libertas: Where there is doubt, there is freedom.
Nobody remembers this. Postscript printers? Oh, well, just another driver from the list. Postscript files? Oh, just another format to store text or graphics.
I needed to make a rotary quadrature encoder of a specific number of pulses per rotation. I took the gap encoder (like these found in ball mice) and needed a disk with the right number of gaps. With gap width of order of 0.3mm. How to get that? Oh well, I'll have a transparency printed with the pattern.
Now... how to generate such a pattern? If I try raster graphics, I'll need enormous file to get the resolution I need. It will take a lot of time to generate. Well, maybe write it in Postscript?
Some search, some learning, and soon I had the postscript file, maybe 500 bytes long., with a bunch of code discs of various diameter and various number of cycles. Packed it onto a pendrive, took it to a print shop and asked to have it printed.
"It's half a kilobyte. Are you sure this is the right file?"
"Yeah, just import it into your graphics program."
"uh... okay." The file loads, the guy scrolls through two pages of of extremely detailed patterns. "Is that it?"
"Yeah. Print it on transparency, at as high DPI as you can."
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Ahh yes the good old days of XOR-based linked lists.
Someone had to do it.
For some of us, it's today... I have two processes where the data arrives as EBCDIC plus binary data, and the files are constructed to emulate a 200-byte tape record. I got to learn all about how COBOL represented numbers in various fields to get these running in 1991 and 2000, and still have to remember them when the people source the data need help remembering how it works.
They keep saying they want to sunset the applications that generate the EBCDIC data, but, in 15 years of saying that, they have yet to create a viable alternative.
In .NET, no. About 6 years ago I was tasked with rewriting our base-64 encoder/decoder. We were using MS's built-in encoder and is was too slow to handle a multi-GB inbox (we sold a shrink-wrap email server for ISP's). First I rewrote it in regular math operations, and it was faster, but not fast enough. I rewrote it again using bit-shifting operations and it was an order of magnitude faster. I really had to reach back into my days coding MUD's in C for that. We really take our faster computers for granted, and our code is far from the level of optimization we were once required to achieve.
Eric's history is interesting and valuable as long as you realize it is based on his stove-piped career. There are glaring omissions. In particular there was this company called IBM that dominated the data processing industry for most of the 20th century. The end of the 36-bit era and the universal use of addressable 8-bit bytes began when IBM introduced the System/360 in 1964, not when DEC finally stopped making PDP-10s in 1983. ASCII did not grow out of anything, it was a fresh creation of a new standard. IBM even pretended to support it, though it used its own 8-bit code, EBCDIC. The short Unix commands were optimized for Teletype machines. Video displays were not cheaper than Teletypes at first, they succeeded because they were much faster and far more user friendly, not because they saved money on consumables. Many early minicomputers supported the native "current loop" interface to the Model 33 Teletype. Tektronix storage tubes deserve a mention. They made graphical computing possible when memory was far too expensive for display buffers. RS232 is still alive and well in the Arduino world; level shifting there means 5 volt to 3 volt. I would mention the 16-bit programming address space that almost all minicomputers had, which forced programs to fit in 64K byte segments. It made it hard to grow software because it forced you to constantly restructure to fit in small overlays. I once had an argument with Gordon Bell of DEC about this when the PDP-11 was introduced; he thought any program larger than 64K *should* be broken up. In general hardware people had a greater influence on computer design in the early years. Early microcomputers adopted the same 16-bit addressing scheme. The Motorola 68000, introduced in 1979, was the first to allow a larger address space (24-bit at first, but architecturally 32-bit). Line printers and multi-part fan-fold paper forms also deserve mention. IBM printers used to be controlled by a loop of paper tape with holes that allowed a fast move to the top of a new page or even a point in the middle, hence form-feed and vertical tab. USB's popularization by Apple deserves mention too, especially since the are now leading the push for USB-C.