Let's keep this pertinent to Hacker News: The nicely intoned computer voice of SID on UFO was way more advanced than the clunky monotone of the Star Trek TOS ship's computer.
The first episode of Star Trek: The Original Series where we hear the ship's computer speak is "Mudd's Women" filmed starting June 1966. UFO had SID talking from the very first pilot, filmed starting April 1969. So, less than three years apart, and not much time for the public's perceptions to change. On the other hand, HAL showed up on screen in the interim, so maybe that helped. And big shout out to Lost In Space's Robot B9, with more personality than all of them put together, and who showed up before for all of them, in 1965.
There is a torrent. Objectively it’s uneven but the I’m biased toward it because I watched it on release. Space Bastard Travis is a terrible villain but Servalan is very attention getting. The simple fact that none of the characters felt safe made it compelling on first viewing and Avon’s cynicism vs Blake’s idealism makes for satisfying viewing despite the obvious budget constraints on the screen. Definitely seek it out but don’t expect Firefly production values.
A favorite Knuth story to illustrate: He was re-writing the 8080 code for the processor that ran our new Alphatype CRS Phototypesetter, since the manufacturer's code wasn't suitable. Real-time, 7 levels of simultaneous interrupt stuff, since it controlled two stepper motors that moved the lens around the photographic paper, plus four custom font outline-tracing S100 cards that flashed vertical segments of characters at just the right moment on the CRT that the lens then focused onto the paper. No debugability other than a 4x4 keyboard and a 15(?) character display. I was responsible for the code on the other end of the RS232 port that connected it to the DEC mainframe, sending down character outlines on the fly to the very limited memory on the 8080, along with the properly-sorted character placement info ultimately from TeX.
Anyway, we'd been doing morning, noon, and night debugging sessions together for a number of days. On maybe the 3rd morning, I arrived at his office and was speaking with his secretary of many years, Phyllis Winkler, when Knuth came in. He handed her a stack of maybe a dozen or two pages, saying "Here's a paper I wrote; please type it in." When? When did he write it? It's still a mystery to me.
TeX was developed on DECsystem-10/20 machines (36-bit words, your choice of byte size). The various operating systems (Tops20, Sail/Waits, ITS) were superior to Unix in a few ways, one of which was that when a process was suspended (think control-Z, or even control-C) you could issue the built-in shell SAVE command that would save the entire state of the suspended process into a new executable, data segment as well as code. So, on these systems, you could run TeX, have it load a bunch of macros and such, and then SAVE the result as a real, pre-configured executable for the world to run. Easy-peasy.
This was true for the original TeX78 written in Sail, as well as the ultimate TeX82 written in Knuth's WEB macro language on top of Pascal (that nowadays typically gets transpiled to C). Other programs did similar stuff; the feature was in the OS way before TeX started.
(Gory detail: Actually, TeX went a little further, to free up all possible address space for the final executable: The version that could initialize various hash tables and hyphenation trie tables could dump (nee serialize) a binary file of the resulting data structures; then a slimmed-down version that didn't have that code would read the binary info back in to recreate the initial data structure state, and that's what you'd SAVE the production executable from.)
For the unix-y versions of TeX, there was effort made to mimic this sort of thing in user-land with "undump", but admirable as it was, it was a hack, I'm told. These days, everything is so fast, it's not clear that this feature would be worth it anyway.
I really wish that would be possible. I sometimes suspend things, but I would really be able to store them to disk. Sure sometimes you can suspend the whole OS to disk, but that's worse and also doesn't scale. You can't suspend to disk, boot normally, suspend a second time, boot into the first, etc.
I don't think undump is a hack except to the extent the whole thing is a hack. Linux shoves a lot of stuff to userspace that other operating systems put in kernel space; this is just another one of them.
The program loader is not magic - it just reads a list of things to mmap and then mmaps them. If you write a thing that writes a list of what's mmapped and call it the unloader... fine?
Hey, DVI was my suggestion and initial implementation; Knuth's comments in the TeX source code acknowledge this, and they mention plenty more people than Frank Liang who made significant contributions to TeX82: Leo Guibas, Michael Plass, Lyle Ramshaw, Robert Sedgewick, Luis Trabb Pardo, Howard Trickey, Doug Wyatt, and Ignacio Zabala.
Also, Nixie Tubes were absolutely not “tiny.” Typically, they were about the same size as a vacuum tube you’d find in the back of your radio or TV. They were universally used on electronic equipment; less so on consumer devices.
Not so about the Linotype. Back in 1980, I personally ran the Alphatype CRS phototypesetter (bought by DEK for the purpose), in the basement of Margaret Jacks Hall, that produced the entire camera-ready copy of The Art Of Computer Programming, Volume II, Second Edition. The DVI files and Computer Modern fonts were created by the early, Sail-language, 36-bit versions of TeX and Metafont that were later redesigned and implemented to be more cross-platform. Knuth rewrote the firmware that resided on the Alphatype (in 8080 assembly language), and I wrote the code that translated from DVI and drove it from the DEC20 mainframe over a serial line (trickier than it sounds; see our joint paper "Optimal prepaging and font caching" ACM TOPLAS Vol 7 Issue 1).
One point concerning Metafont and Computer Modern (and TeX): A key overall goal of the whole kit and caboodle is that a document written in TeX and using the default fonts would produce exactly the same output on all capable computers and output devices, indefinitely into the future, with the same line breaks, page breaks, character shapes, etc. And in fact TeX files from over half a century ago still produce pixel-perfect results.
This requirement meant that the default fonts had to be portable between printers and typesetters with various resolutions (and other optical filtering attributes). There was simply no other way at the time to accomplish this than using a tool like Metafont to author a home-grown font family like Computer Modern (and even then it was a bit of a hope and a prayer).
And don't even get me started on how 5pt super-super-scripts aren't just 10pt characters scaled down by half, contrary to how post-hot-lead typesetters operated, and not fully addressed commercially until decades later.
thanks for the pointer, were you one of the two students tasked with writing the program during DEK's stay in China? As you mention the problem of smaller fonts it seems font hinting was an invention of the nineties, how did you solve it?
Nope, that would be Michael Plass (thesis title: "Optimal pagination techniques for automatic typesetting systems," though his line-breaking work is what showed up in TeX) and Frank Liang ("Word Hy-phen-a-tion by Com-put-er"). I wasn't there yet.
Metafont users can specify point size, boldness, slant, and whatever other parameters they choose (plus device-specific info like resolution) that can then be used in the simultaneous equations that determine the coordinates of critical points and shapes of pens used to draw the characters. So, for the smaller-font issue, the width of the pen may be a non-linear function of the font point size; ditto for the x-height, etc. In Metafont, it's the responsibility of the font designer / coder to handle it all; there's no automated algorithmic monkeying with the pixels other than what you write. This all becomes much clearer with a perusal of The METAFONTbook.
Kind of astonishing that they managed to retain the institutional / folk knowledge to be able to create a new vacuum tube product, never mind the machinery and inputs to manufacture them.
There have been multiple companies coming back to try to make small batches of vacuum tubes.
It’s not a mysterious process that depends on arcane knowledge. It does require some tooling and process refinement, but the only real obstacle is getting enough demand to pay off the investment in tooling and process refinement.
It's basically the same process as making an incandescent lightbulb. Which is why vacuum tubes took off in the first place. It's more parts and more metal working, for sure. But really it's shaping and dealing with thin films and a vacuum chamber.
In the 90s China bought the whole Mullard factory and shipped it over from England.
If you buy cheap Chinese valves, you're buying Mullard ones which seem to be made to a higher standard than they ever managed in the 80s. Any two random EL34s out of the box will be a closer match than the crazy expensive "super matched pairs" that we used to buy.
Do you have some more info on this? Background, do they still exist? Where is the factory? I visited one older tube factory in China but it was converted to an art/consumption district.
reply