Jon Postel, who ran the Internet Assigned Numbers Authority (IANA) for many years, used Engelbart's NLS system to manage all of the information for IANA. He used a mouse and chord keyboard. I was interested at one time in user interface issues, and I'm located in L.A., so Jon kindly allowed me to interview him and watch him work (the Internet was a far smaller and more friendly place back then). NLS was designed to use these two devices in concert. The usage model was of a hypertext, with a mouse click on an item followed by a single-letter command. The command letters were typed in on the chord keyboard, at two chords per character. The scheme was to type in 8- or 9-bit characters as bits, five high bits followed by five low bits, or the other way around, I don't remember which. The effect was that to manipulate information, as opposed to entering it, you didn't have to move your hands back and forth to and from the keyboard. Just click-chunk-chunk, click-chunk-chunk.

At two chords per character, and with pretty clunky-chunky piano-type keys on the chord keyboard, entering more than a few characters via chord keyboard was slower and more painful than using a regular keyboard. I asked Jon how many characters he would type on the chord keyboard before switching to the regular keyboard, and his answer was, "About ten."

Jon was probably the last user of NLS aside from Doug & Friends. I believe ISI, where Jon worked, kept a PDP-10 running just to support his use of NLS in running IANA.

I wonder if anyone's done an Antikythera mechanism in Minecraft?

This reply is exactly right. The OP is a troll, for all the reasons he cites.

Even if he were not, the bulk of replies are totally out of touch with reality. A head of a clinical department is never fired unless he shows up on the front page of a big-city paper (c.f. Aceveda). He is God and can do what he wants unless the hospital director and the hospital board, acting in concert, shut him down. In practice, this never happens.

So a) OP is a troll, this never happened, b) even if OP is not a troll, this never happened because no clinical head of department would have time or inclination to do it, and c) if he did, he wouldn't "take it up the chain", or come to Slashdot - he'd tell anyone silly enough to complain to his face to pound sand, THEY were fired. Until he was arrested for HIPAA violations, which would appear on the front page of a big-city paper, c.f. para. 2.

PLATO was just a platform. The PLATO Project never created any courseware of its own. It merely taught professors how to write their own courseware. They told them pretty baldly what they (PLATO folks) thought worked, and what didn't, but the results were up to the courseware authors, and their students were stuck with the results. Some were drill'n'practice types, some did thoughtful, exploratory stuff, and some (to my mind the most successful) wrote laboratory-emulation software that let the students run experiments on their own on stuff that would cost too much or take too long in the real world. PLATO's big showpiece was a bio lab called "fly" that let students breed fruit flies in emulation and see how traits were inherited. No hint of drill'n'practice or programmed courseware in sight.

PLATO lessons, like textbooks, came in good, indifferent, and truly stinky varieties. The reason people remember the games is that they operated under rapid and ruthless natural selection...unlike courseware.

Yes, exactly. Xmarks does allow cross-browser synchronization, which is why I use it, but it also allows you to redirect it away from the Xmarks server and to any other server to which you have access, including (in my case) Mobile Me. So when Xmarks closes its doors, its servers will go away, but so far as I know, my copy of the code will keep right on working. I'm unhappy that development will stop, so as browser development continues and the code becomes out-of-date and non-functional I'll eventually have to find something else, but for now, my bookmarks will keep right on synchronizing.

Hello, fatankles. Good to hear from you. :-)

I think I'm the one who taught you TUTOR.

Do you think Slashdot would improve if they hired The Red Sweater as an editor?

Well, offhand I'd say Solaris is better because its ZFS is more advanced and more mature. Obviously this is not an option if Solaris doesn't support your controller (but remember, for ZFS you don't need a RAID controller; in fact you're better off without one). If your hardware is already in place and Solaris won't run on it, then Welcome to FreeBSD!

True, I did not export the tank, but that's because on Solaris you don't have to. You should, but you don't have to. It says "Say, there's a tank out there, but not my tank." Then you can import it with a "-f" flag.

The machine was experimental so I didn't lose any data; had there been real data out there of course I'd've been more careful and exported properly.

I should mention that the tank on disk was ZFS v4, so it was not a case of the Solaris tank being of a rev level higher than what FreeBSD could handle.

Sadly, if you create a ZFS tank on a Solaris box and then move the tank physically to a FreeBSD 8.0-RELEASE machine, it won't even see that there's a tank out there. Apparently GPT table layout is different on FreeBSD or something.

Won't stop you from serving ZFS over NFS/Samba/whatever, but you can't move the tank itself around. I know, I tried. Booted FreeBSD on a machine with a Solaris-issue ZFS tank, and it was like it wasn't there. It saw the drives fine, just not the tank.

As one observer noted, most university presidents are not idiots. Any that were in there were Darwinned out during the 1960s and not replaced (my own was replaced at that time by a labor negotiator). Hence, we can assume the alternative was worse.

There's a likely scenario: Clarabelle Pickens drops her support. It's a huge chunk of change. The legislature, strapped, does not replace it. The NIH grants can't come close to covering it, not to mention the fact they're not growing anyway. Result: everything gets cut, including the athletic budget. At this point, for the first time, the alumni get PO'ed and cut their contributions, and all life on earth as we know it comes to an end.

At that point, losing NIH looks like the best of a bad lot, so the tap-dancing begins.

OpenSolaris is a pain to run on hardware which requires drivers not present in the base system. Their mechanism for adding drivers at boot time is arcane. Nevertheless I built a huge ZFS tank on a Tyan mobo and ran OpenSolaris on it (had to add Broadcom ethernet and Areca RAID card drivers to the mix).

When I recently tried to upgrade, the latest OpenSolaris flat-out refused to run on that motherboard. Something had happened in the development of the OS that collided violently with the motherboard BIOS, and upgrading to the latest BIOS didn't help a bit (though Tyan's release notes said it had introduced BIOS changes to support Solaris u1, u2 and u3, Solaris is now up to u8).

After a week of struggling I gave up. The box now runs FreeBSD 8.0-RELEASE, which came up out of the box with no problems whatsoever. I just hope the ZFS is as stable as they claim it now is.

Moral: You can try to boot OpenSolaris. If and when that doesn't work, FreeBSD is your only other stable ZFS option right now.

I forgot to explain, in the above post, that the dish being shown on the Death Star's equator in Larry's wireframe plans was not Larry's fault. The only thing he had available to use in constructing his sequence was some pre-production artwork, presumably by Ralph McQuarrie, which showed the dish on the equator. After Larry had completed his work and it was too late to go back and fix it, the dish was moved to its final position on the Death Star.

The machine was a PDP-11. It was a PDP-11/45 running a one-of-a-kind graphics OS, called GRASS, the Graphics Symbiosis System written by Tom DeFanti, a professor at the University of Illinois at Chicago (then the University of Illinois at Chicago Circle). Tom's appointment then was to the Chemistry Dept.; the GRASS system was used primarily for molecular modeling. It drove an Evans & Sutherland Picture System, a giant $100,000 vector graphics engine worth five times what the PDP-11 was worth.

Larry's work pushed the system to its limits. His work was done at night, on the QT, with Tom's permission. This was done by giving Larry his own disk pack with a copy of the system on it. Larry's use of the system worked around all sorts of bugs in that relatively early version of GRASS. The film was made by pointing a (film) camera at the E&S screen, and running a macro which would render a frame, click the camera, render a frame, click the camera... While the PDP-11 system could in fact render the Death Star trench in real time, by the time you included all the little bits and frobs, the E&S took long enough to draw it that the display flickered. Hence the need to do frame-by-frame. Also, there was no frame-sync hardware in the system; the camera and display were connected only by the solenoid that tripped the camera shutter.

I played with that disk pack a year or two after the fact and it was a hoot to fly around the Death Star by hand. GRASS pioneered the interactive control of complex graphics, so all the position (and other) variables could trivially be tied to dials, etc. I was discouraged by one thing: the final version of the run had apparently been deleted from the disk. The only version I could find had the big "dish" directly on the equator of the Death Star, not at 45 degrees north latitude as in the film.

Years after that, I happened to talk to Larry Cuba by phone about something else, and asked him about that. He said the version I saw WAS the final version. Years after that, when I went to my "farewell to Star Wars viewing of Star Wars", I saw he was right. The plans shown to the rebels show the dish on the equator. Obviously the plans were fake. Those rebels were all dead men.