winestock
Joined 15 years ago
Joined 15 years ago
I read a joke that went: In Ann Arbor, separation of Church and State is about three blocks.
The Terrible Secret of Tom Bombadil
Original Post: http://km-515.livejournal.com/1042.html
Hacker News discussion: https://news.ycombinator.com/item?id=9982237
The Tenex line of operating systems from DEC had built-in session management in the 1970s. Unix still doesn't have it. All non-trivial terminal handling was kept in user-space. Therefore, programs had to make assumptions that are now hard-coded in their very design.
To this day, the Linux and BSD kernels assume that they're talking to a VT100 with a few frills. The commercial Unix kernels were worse; I used a SunOS tutorial in the mid-90s that started me off on ed (yes, the standard editor; the man page even called it that without qualification) because Sun started out with an older version of BSD that assumed teletypes.
This has had consequences. The major reason why microcomputers took off was because an Apple ][ running VisiCalc could do things that a terminal connected to a mini/mainframe computer could not do.
Here we are, living in the future, where wristwatches have true color displays, and household appliances run webservers, but the correct, macho, hipster-approved user interface would be shamed by an Amiga 1000.
/rant
Old school Lispers are the Jacobites of the Computer Age. Their warnings were ignored, so their nightmares came true; and the world has changed so much, as a result, that few can even imagine an alternative. They were right about nearly everything, and now they are irrelevant.
So pour out a drink for the king over the water and for Genera. Curse this present dark age of bureaucrats and Posix. And then MOVE ON. The Clojurists are the first sizable community of Lispers that has done that.
Again, it's one of those things that I'll do in my copious free time.
I'm surprised that it still gets so much attention. Every few months, someone volunteers to translate it into another language (see the bottom of the page).
I wrote that essay five years ago. Nowadays, just use Clojure or Racket and ignore what I've written.
And yes, I know, I really need to update the design of the site. I wrote it when I was still a rookie web developer. I'm starting a new job so I'll redesign my site in my copious free time.
Who says Wall Street can't take the long view?
At times, I have wondered how much of the Internet would shut down if ads were forbidden. Sometimes, that thought sobers me. Other times, that thought gladdens me.
Now it's time to nitpick. It doesn't seem that there's any way to generate key-codes.
Entering text is nice, of course, but that's not all that a keyboard does. How about cursor control (arrow keys, PageUp, etc.), function keys, or scroll lock?
One can make control-key combinations, but that limits one to what's available in ASCII. For instance, there's no way to distinguish Ctrl-j from the Return key.
That last point brings up something related. In ASCII, the Control key modifies the bit representation of the key pressed. That's why Emacs in terminal mode can't tell the difference between Ctrl-j, Ctrl-J, and Return. In modern user interfaces, the Control and Alt keys are specialized shift keys that let the OS and applications tell the difference.
Of course, one could do the same workarounds that terminal emulators perform, like using escape sequences and such. Then, while using this device, one would have to know the proper sequences for xterm, or vt420, or, or, or…
Still, nice hack.
EDIT: By the way. Some poor lost soul should be forced to use Emacs with this keyboard. Any suggestions on who should be condemned?
https://news.ycombinator.com/item?id=13076098
I quote it in full, here:
OK, if you promise to stay off my lawn, I'll explain the history behind undump. Back in the 70's, the big CS departments typically had DEC 36-bit mainframes (PDP-10, PDP-20) running the Tops10/Tops20/Tenex/Waits/Sail family of operating systems. These are what Knuth used to do all of TeX, McCarthy LISP, and Stallman and Steele EMACS. Not Unix; and Linus hadn't touched a computer yet.
Executable program files were not much more than memory images; to run a program, the OS pretty much just mapped the executable image into your address space and jumped to the start. But when the program stopped, your entire state was still there, sitting in your address space. If the program had stopped due to a crash of some sort, or if it had been in an infinite loop and you had hit control-C to interrupt it, the program was still sitting there, even though you were staring at the command prompt. And the OS had a basic debugging capability built-in, so you could simply start snooping around at the memory state of the halted program. You could continue a suspended program, or you could even restart it without the OS having to reload it from disk. It was kind of a work-space model.
Translating into Linux-ish, it's as if you always used control-Z instead of control-C, and the exit() system call also behaved like control-Z; and gdb was a builtin function of the shell that you could invoke no matter how your program happened to have been paused, and it worked on the current paused process rather than a core file (which didn't exist).
The OS also had a built-in command to allow you to SAVE the current memory image back into a new executable file. There wasn't much to this command, either, since executables weren't much more than a memory image to begin with. So, the equivalent of dump/undump was really just built into the OS, and wasn't considered any big deal or super-special feature. Of course, all language runtimes knew all about this, so they were always written to understand as a matter of course that they had to be able to deal with it properly. It pretty much came naturally if you were used to that environment, and wasn't a burden.
Thus, when TeX (and I presume the various Lisp and Emacs and etc. that were birthed on these machines) were designed, it was completely expected that they'd work this way. Cycles were expensive, as was IO; so in TeX's case, for example, it took many seconds to read in the basic macro package and standard set of font metric files and to preprocess the hyphenation patterns into their data structure. By doing a SAVE of the resulting preloaded executable once during installation, everyone then saved these many seconds each time they ran TeX. But when TeX was ported over to Unix (and then Linux), it came as a bit of a surprise that the model was different, and that there was no convenient, predefined way to get this functionality, and that the runtimes weren't typically set up to make it easy to do. The undump stuff was created to deal with it, but it was never pretty, since it was bolted on. And many of use from those days wonder why there's still no good solution in the *nix world when there are still plenty of programs that take too damn long to start up.