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.

What are you talking about? Amazon has never sold copies of 1984 or Animal Farm in digital format, and to suggest otherwise is treasonous.

To display an image, at some point in some program, you'll see, if image is PNG, send it to libpng; if image is jpeg, send it to libjpg; .... We're just arguing about where that code belongs.

You could put it in the browser. Then you get a program that links directly with libfoo to display all the images it wants. My guess is that browsers do this now. It'd be the same thing to have Firefox link directly to x264 and libogg to display movies.

The alternative is to use another layer of indirection. Have a new library/system service that a browser can throw a buffer at and say "go render this." The service then discovers its type and calls libpng, libavg, .... This would be something like linking with VLC.

I think that just running a Tor relay, even one without an exit policy, is still beneficial. The core infrastructure could probably use the extra bandwidth, even if isn't going directly out to the web.

Any time you read about a product that guarantees perfect fault tolerance, there is always a list of constraints that must be met for that claim to hold. You probably won't ever see this list marketed, but it's there somewhere.

I haven't looked into this, but it sounds like ZFS is fault-tolerant given a system model where data can change once it's on-disk, but otherwise system components are fail-stop. So if you ask a hard disk to perform a write barrier and flush its data to disk, the disk will either do so and report success, it will issue an I/O error, or it will catch on fire. Any way, ZFS will handle the situation correctly.

Of course, the immediate next question is whether that failure model is realistic. Turns out it isn't. Some hardware will report 'write barrier complete' when it still has unwritten data in its buffer.

If you can't count on your hard disk to flush its caches or even order writes correctly, I don't think it's possible to build any fault-free file system on top of the drive.

As far as I understand it, wake-on-lan would let me SSH into one computer so I can send a magic packet to my real to computer to wake it up, and then I can SSH in to the computer I wanted to in the first place.

Somniloquy gives the same functionality transparently, without needing that extra step, without any other network user being aware that the computer was asleep in the first place.

If you read the referenced paper, they do talk about why they don't like wake-on-lan in section 6.