Slashdot Mirror
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
(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 *
Every hacker over a certain age knows what is meant by the term "overlay", from minicomputers to CP/M to MS-DOS. And it fills them with dread to this day.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
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
9600,8,N,1,XON/XOFF
DB9:pins 2/3/5
DB25: pins 2/3/7
My ism, it's full of beliefs.
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...
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
IBM Series M keyboards.
TeamOS/2. These was one of the scenes you hung out in, if you wanted to be a PC-hacker.
Tag Lines: eg OS/2: because a 386 is a terrible thing to waste. or OS/2: a multi-threaded suite.
AT (and other pretentious terms that dated just too quickly).
Floppies (of all sizes).
OS/2 - because choice is a terrible thing to waste.
Use the -d flag with pkunzip, otherwise, you might end up with a big stinking mess.
Why was this not the default?
Probably because CP/M didn't have directories, and PKZIP had a definite familial relationship with LBR, which came from CP/M and therefore had no directories; and with ARC, which was cross-platform, including a CP/M port.
Hi 73 here. First program at University using Fortran and punched cards. Still know and remember 90% of the ASCII character table in my head. Use the ASCII sort procedures to this day in some of my file names to force them to come to the top of a file list.
Spent a lot of time learning the HP Printer control procedures in the early 90's and became quite proficient programming HP printers. Learned quite a bit about the Hayes modem command set. Experimented a lot on Centronics printer interfaces and RS232. I used to make and sell Centronics and RS232 cables and made decent money at the time - early 1980's.
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
I rememer still how Commodore 128 had both 65xx and Z80 prosessors and little trickery you could change cpu you were running in middle of program...
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.