Yeah. Why teach the applications practical to 95% of white collar jobs instead of programming, which most kids won't be interested in, fewer will 'get' and hardly any will ever do professionally?

You could say the same about cellular biology, chemistry, quantum mechanics, calculus, and music taught at the high school level. Most people won't professionally develop those skills, but they're better off for having been exposed to the fundamentals. Any maybe out of the breadth of subjects you throw at a young student, they'll find their passion and stick with it. Why exclude programming from that mix?

Forget cars, how long will it be before I can a pair of eyeglasses with this coating? The night vision coating could go on one side of the lenses, and the anti-glare coating goes on the other side. What more could a geek need?

While servers may be "old hat," the new breed of social networking and cloud computing sites are still innovating in this area. The traditional idea of large, fast machines running big relational databases is dying. Check out the recent rise of Bigtable, MapReduce, Memcached, and especially NoSql among service providers.

There's real innovation happening on the server side to enable the current generation of mobile devices. The handheld clients may be the sexy part of computing right now, but they couldn't do much without data centers backing them up.

Well, to quote their tech report:

The malware detection algorithm involves the following steps on the client machine:... (5) Policy: Execute the verification policy. This could involve reporting the memory contents of the client device to the verifying party, or the execution of any task that should preferably be run in a safe environment. This may be done using whitelisting or blacklisting approaches, and may involve the use of heuristics to scan the swap space and secondary storage in general. The implementation of the policy is beyond the scope of this paper, as we only deal with how to assert the absence of active malware herein. [orig. in italics]

So you're right, their technique really only catches against one thing: a malicious (or infected) operating system that guards its dirty bits from an OS-level verifier by playing tricks with the verifier's address space. You still need another checker to catch all the conventional viruses out there that don't play this particular game.

I'm sure the CPU time limit would be generous enough that it won't matter if your programming language is interpreted 10x slower than hand-tuned assembly. They want to make sure you aren't using a brute-force O(n^3) algorithm when a linear one would work well enough.

Plus, the judges need a rule to allow them to terminate programs that may be stuck in infinite loops. Otherwise, a contestant could delay the results of a competition indefinitely.

(Imagine: "This competition was rigged! The judges killed my program before it had a chance to finish. It was working fine, and I was the first one to submit answers to all the problems. What? So it has a long start up time. You don't have a rule against 100-hour programs.")

SLIME looks very useful, so long as the only thing I need to debug is Emacs itself. I can't find the part in the SLIME manual where it helps me write and debug programs written in any of the languages supported in Visual Studio. The one I care about is C.

If SLIME really can help me, I'd love to use it. It does look quite nice.

As an aside, if you believe that open source developers write tools to scratch their own itches, does this mean that more people need to debug Emacs than need to debug any other program? ;)

My main computer with its 24-inch monitor is where I get my coding done. Specs: Core 2 Duo 3GHz w/ 4GB RAM. Its normal workload: xterm and a few emacs windows, with an occasional compile.

For everything else, the laptop on the side (with 12-inch display) runs my email, IM, IRC, RSS, iTunes, and calendar. Specs: 667 MHz PowerPC, 640 MB RAM. Yes, my workload is backwards :)

Reading the research paper, the 6% overhead looks like it comes from having the kernel call into the hypervisor every time it allocates or frees an object that contains a kernel hook (a.k.a. function pointer). The designers explicitly state that they use non-paged memory to store the protected kernel hooks.

It's a little disingenuous to label traveling through a wormhole as FTL travel. It's just taking a different, shorter route. What speed do you get if you shine a light through a wormhole?

By having different UIs for each platform, life becomes more difficult for add-on designers. Anything that does more than add a new toolbar button suddenly becomes platform-specific.