Jeff Duntemann's ContraPositive Diary

Pete Albrecht sent me a link to an article that means well but doesn't quite hit the bullseye. No one seems to be asking, Is Vista really necessary? What does all that complexity actually buy us? Why is Vista better than XP? Or how about that now mostly abandoned but still pertinent question, Why is XP better than 2000? I'll allow myself a little cynicism to state that much of what Microsoft is doing these days seems focused on making the world safer...for Microsoft. There doesn't seem to be much in Windows evolution for the rest of us, and my suspicion is that Vista will reach new heights of un-trusted computing—meaning that we will not be able to trust it not to turn on us under the suspicion that we're pirates.

We need to completely re-invent the idea of an operating system. I myself envision something eight or ten years from now taking full advantage of hardware-assisted virtualization along with eight-core CPUs. I see every app as running in its own virtual machine, over a custom kernel based on Linux or BSD that exposes the API that the app was written to use. Wine isn't that bad, and with a few more years to mature, most non-MS Windows software will run on it.

Let's call a compact kernel plus an API emulator like Wine a KUP (Kernel with User Presentation) and when we install an app, the hypervisor prepares a KUP for it, and the software is installed in the KUP. Each KUP has its own network stack and IPv6 address. The software in the KUP assumes that the KUP is the OS, and it writes its data files locally to the virtual machine.

Outside the virtual machine is a hyperfilesystem, which periodically peeks into the KUP to see if new files have been written. If so, the hyperfiler reaches in and copies out the most recent copy of any changed files. The hyperfiler keeps a second virtual machine running for each KUP, in which backup copies of the KUP's data—and the KUP's execution image—are stored. The KUP's shadow VM stores a compressed snapshot (or series of snapshots, depending on the configuration) of the KUP, as well as software to test the files saved by the app in the KUP. The hyperfiler attempts to open the KUP's files in the shadow VM, and it watches for execution activity. Unless the app is known to be something that generates executables (i.e., a developer suite) the presence of attempted execution tells the hyperfiler that malware has infected the KUP. The KUP's last known clean VM snapshot is then written over the infected KUP. Beat that, Mr. Rootkit!

Even if no malware is detected, a clean execution snapshot of the KUP is swapped in every 24 hours, and its data updated from the shadow VM. The desktop interface manager is just another (slightly) privileged app in a KUP, and the hypervisor peeks into the desktop KUP every few milliseconds to see if any of the app KUPs need repositioning, clipboard data management, or shaking-by-the-neck.

The really important part of an OS, the only part that carries any enduring value, is the API libraries. Everything else is just gears and clutches, and can be replaced by a sharp little kernel running over a hypervisor. If computing stagnates in the coming decade, it will be because we can't bring ourselves to rethink what really matters. The hypervisor's job is not to integrate separate pieces of software (as we sometimes think OSes are supposed to do) but in fact to keep applications from seeing one another at all. This may make certain "cool hacks" impossible, but it may compensate by making computing a lot more stable. The hypervisor can see into every KUP, but nothing in any KUP can see the hypervisor, or anything beyond the boundaries of the KUP. The hypervisor itself will run its essential components in electrically protected memory, and will be designed to defeat subversion.

It's a tall order, but that's the end point toward which I see a lot of modern virtualization technology converging. We'll need more memory and more cycles, but we get more of those every year. Sooner or later cores will be cheap, RAM almost free, and Microsoft mostly a seller of APIs—even if they don't want to be. Let's see: Install Vista, delete everything but the API files, and then pour what's left into a KUP.

I'll drink to that!

Back in 2001, I saw previews of a movie called Final Fantasy: The Spirits Within, and my initial strong reaction was, Yukkh! That's creepy! The film attempted photorealistic human characters, and did about as well with the animation as one could do circa 2000, but many people commented that the CGI humans were a serious turn-off. Since then I've read of animators tweaking CGI human faces to make them just a little less human-looking (this was done in the Shrek movies and in The Incredibles) because when animated humans are too close to real (without quite being fully convincing) they inspire in people either revulsion or a kind of nameless dread. I've known of the effect for years, but today was the first time I knew it had a name: The uncanny valley.

Explaining the term itself may require a graph. I borrowed the one below from Wikipedia, and if you're interested in the concept I encourage you to read their very detailed article on the concept.

If you start with something as unlike a human being as a robot welder, people are basically indifferent to it. (They may correctly choose to stay out of its way, but that's a different issue.) As you move toward things that begin to resemble the human form, emotions engage and people respond more positively, especially if pains are taken to avoid well-known negative images. (The Devil, Hitler, etc.) Even odd anthropomorphic figures (think Pluto or Reddy Kilowatt) are generally well-received if they smile and don't do obnoxious things. At some point, when your representation of a human being gets close enough to photoreality, acceptance goes off a cliff, and the figure becomes creepy and disturbing. At some point further on, if the representation becomes indistinguishable from a healthy human face, acceptance rises again.

The Wikipedia article doesn't speculate as to why all this should be so. The only reason I can think of for the uncanny valley is an adaptive subconscious tendency to avoid diseased people or corpses. We are very good at recognizing real faces, and there comes a point along the continuum between a cartoon and a photo where the cartoon becomes so lifelike that this ancient machinery kicks in, and instead of a cartoon we see a face without the many subtle indications of healthy life. The dragons of the subconscious suggest zombies or mythic supernatural creatures instead, and we get low-level willies.

This is significant to me because I'm tinkering with a new novel that involves AIs being evolved within an artificial world called the Tooniverse. The AIs are initially animated as obvious, simple cartoons (think Cartoon Channel things like "Fairly Odd Parents" and further on, "King of the Hill") and as they evolve more closely to human levels of intelligence, they are given more lifelike animated human figures. The primary AI (named Simple Simon) understands the risk of coming to appear a little too human. "I don't want to actually be human," Simon says to one of his fellow AIs. "I just want them to take me seriously." This is hard when you resemble Homer Simpson, but Simon doesn't want to creep people out, either.

By the way, is it just me, or should bunraku puppets (which always seemed like high-resolution Muppets to me) be on the opposite slope of the uncanny valley?

Yesterday's meltdown didn't go especially well. The Intel D865PERLK motherboard needs a slew of drivers for its chipset, but the drivers wouldn't install, the disk formatted weirdly, and I'm beginning to think that something, somewhere, messed up the 137 GB barrier fix that I applied last April when I put the system together.

Some of you may know that there's an ATA disk interface (both parallel and serial) limitation of 28 bits for addressing hard drive logical blocks, and while that may have seemed like a lot of logical blocks 10 years ago, we're way past that point now. What this means is that using hard disk drives with greater than 137 GB capacity takes some care and some screwing around. I used a 200 GB drive for the bootable drive in my system, and in looking back I think that that was a mistake. I don't store data on my C: drive unless forced to, so even a partition as small as 40 GB will take a long time to fill.

There's a nice white paper on the topic from Seagate here. Ultimately I'm going to have to use Seagate's bootable formatter disc to reformat the whole 200 GB drive, but given that all but 25 GB or so were empty air, I've decided to duck the issue and install a 120 GB SATA drive instead. That will still give me three chunky boot partitions and (one would hope) fewer inexplicable failures. More as I learn it.

In the meantime, I moved my data back into the 1.7 GHz Dell Xeon box that I bought in 2002 and will be using that for my main system for awhile. It's a little noisy, but quite fast since I filled it with RAMBUS memory a few months back. I still have a few apps to install, but it's most of the way to where it should be.

There are times when I think I should have been a farmer instead.

My main system here burped yesterday and then refused to boot. (I got it running again with a couple of files on a floppy disk; a trick I'll explain in a day or two.) It's been showing some odd signs of instability for several months, and what bothers me far more than that is that I have no idea why—and I'm typically more careful about these things than most people. So today I'm going to do a system meltdown and then rebuild it. I may not post tomorrow at all. We'll see.

In the meantime, Amazon seems to be shipping my novel ahead of its stated 4-6 week time delay, and there are new copies available through ABEBooks that can be shipped in a day or two. Maybe we're making progress.
Now, back to the battle...