Hi, Dotzler! Good to see you here. You don't have to be anonymous, you know :)

From there, I want to expand the do not call registry. Right now, it only covers telemarketers. I want to also ban solicitations from charities, surveys, and political groups. I want a "leave me the fuck alone" registry. If you aren't one of my friends, customers, or suppliers, or someone I've given permission to call, then I don't want to talk to you.

How about a "do call" registry? Ban solicitations from said marketers, charities, surveys, political groups, et cetera to any number not on the list, and have all new phone numbers start off-list.

You're not hacking at the BIOS level, you're hacking at the bootloader level. But even if the malware were to try to tinker with the BIOS, that vaunted TPM could just deny it access to that part of the CMOS (or flash or what it is that holds the key/hash). So the UEFI would work like this: in either its own flash or in CMOS, there's a region that stores a hash or set of hashes. The computer comes with the hash for well-known bootloaders and, on boot, checks if the loader hashes to one of them. If not, it checks if it hashes to the user override. If neither, then up goes the warning -- and if the user presses "accept", the new hash gets loaded into the user override field. In any event, after this has been done, the TPM (or UEFI, or whatever is responsible for it) locks access to that part of flash or CMOS so that it can't be attacked from the outside.

Yup, the SSH way. If the bootloader changes, pop up a "WARNING: key has changed!" text, with a revert-loader option. If the UEFI is passworded, require the user to input the password if he wants to proceed without reversion. This means that corporate desktops won't be compromised this way (since the end user doesn't have the password and Mitnick doesn't either), and should give other users some reason for concern. If the other users press "go on ahead" anyway, well, there's only so much you can do against a dancing bunnies attack. As another poster pointed out, if users are that gullible, the malware could just as easily do a denial of service attack by asking the user to stick a fork into the nearest outlet.

Let's try that again. The original poster's point is that if you want a Magical Zero-Emissions Hydrogen Storage System, you just take the hydrogen you were to use, combine it with carbon (from CO2 from the air), then ship your hydrocarbon around. The guy at the other end then burns the stuff and the CO2 you used is released back into the air. Voila, zero emissions.

(I still think sodium or lithium borohydride would be a better reversible energy carrier, as it has a greater energy density than gasoline and can be easily used in direct borohydride fuel cells, but first they have to get the "recharging" working at better than 10% efficiency.)

Hm, why do you think we haven't evolved with perfect memory? Could there be a good reason?

The standard answers to this kind of question are:

1. Local optimum: Evolution is a black box optimization process. No black box optimization process that progresses in reasonable time can cover all of the search space, so they will get stuck in local optima. The eye is a good example of a local optimum. The nerve fibers are on the wrong side of the eye, so you get a large blind spot where the fibers go "out of the eye" and into the brain. However, to fix this suboptimal design would require a rather large trek through solution space, and some of the intermediate solutions would be so bad that evolution would weed them out. Therefore, the eye remains as it is. The same may be the case for memory structures in the brain.

2. Shifting tradeoffs: Evolution is also quite slow. Therefore, its tradeoffs are based on an environment in which we no longer reside, where food was scarce and one had to save energy lest one died. This sort of wrong-tradeoff optimization is evident everywhere you have obesity, for instance.
In this case, perhaps near-perfect memory was too heavy a weight to bear in conditions of scarce resources. If it was, evolution would not have optimized in that direction, because the losses (due to having to expend more energy) would be greater than the gains (of greater planning or what have you). Now, on the other hand, we do have much more energy available, but evolution hasn't caught up.

So to sum all of that up: to the degree that the evolutionary process visits close to optimal solutions, it is slow, and to the degree that the evolutionary process is fast, it skips certain solutions that might be very good. In both of these cases, technology can cover what evolution does not - when evolution is blind, technology can be less so; and when evolution has its blind spots, technology have others so they can make up for each other's partial coverage.

Given their rather long latencies from speed-of-light delays, they might be using forward error correction to fix errors ahead of time. This works more or less like PAR files in that if less than a given fraction of the bits are corrupted, the data can still be recovered without problem, and that would seem to be much quicker than having to do a SYN/ACK type "Hey, these don't CRC out right, give me them again" scheme.

He must have been digging into Moussa Ibrahim's secret stash.

It's possible to make a low-res realtime version of photon mapping. See https://www.youtube.com/watch?v=GckOkpeJ3BY for an example. It isn't as good as proper photon mapping, but it *does* give indirect lighting.

I've always wondered what happens after Skynet wins. Does it just twiddle its thumbs and go "Oh well, that's that, power down lads"? It's not like it knows how to do much but fight - it's a military AI after all.

Etch them, then coat them with glass, then add another coating of diamond using CVD. That should last! I'm only keeping the glass because, theoretically, diamond is metastable. Perhaps you could replace the diamond with some sort of boron-containing compound (cubic boron nitride, B4C, rhenium boride), which would be fully stable and very hard, but I don't know if they are transparent.

No, he's Greedo. Don't you know? We've always been at war with, err... Greedo always shot first.

Even since the original Quake, I never understood the concern - those who were playing it at the time never complained about the palette until much later, if at all - and still don't know. It's a post-apocalyptic, dust-track racer. What colour did you *EXPECT* to see? Even if you had the ruins of something-or-other-colourful, it would be dust-covered and aged by the time the game is set.

First there was Quake. Quake was brown because of technology limitations. Then there was Unreal. Unreal wasn't brown: it even played on the "dank environment" trope by making the first level dark and machine-like, then surprising the player once he got out of there. Half-Life was less brown than Quake, too. So why does every modern FPS have to have the same limited postapocalyptic palette?

Oh well. Hopefully there will be some non-brown areas - like the place with the mutant in Fallout 3.

This looks a lot like sparse voxel octrees. As a concept, SVO is nothing new at this point, and id has been considering using it as part of their id Tech 6 engine.

A sparse voxel octree is basically a hierarchical structure for points in 3D space. The advantage of using a hierarchical structure is that you can stop looking at any time, and so zooming works very well: you just traverse the tree until you get so far down that further detail won't be visible, then you render. If the player moves closer, that simply means you'll go further down the tree, but you'll cover a smaller space so the load doesn't really change.

Now, the sparse voxel octree both gives and takes away. It enables detail at all scales, but since the structure is hierarchical (log n insertion and deletion, AFAIK), moving large numbers of points about is going to be really hard, not to mention actual deformation or changes of the objects themselves. One would probably use an SVO to show world detail: landscapes and "3D textures" - and then use simple polygon skeletons for collision detection, moving critters around, etc.

Sparse voxel octrees work, and they work very well on the kind of static-but-detailed data shown in the demos, so it seems quite likely that's what they're doing. But sparse voxel octrees aren't New And Revolutionary Unique Technology only available to the Australians here. Here's an nVidia demo, another demo (not by nV), and an example of the kind of tricks you can do by combining SVO and procedural generation.

(And remember, higher levels of taxation lead to lower levels of economic growth, and thus lower revenue generated to the government.)

Only if you're to the right of or at the optimal point on the Laffer curve. The supply-siders kept saying the US was to the right of it, again and again, but two can play that game. In truth, the Laffer curve probably looks like this, a chaotic mess at any significant distance from 0% or 100% taxation.