The same, unfortunately, applies to Venus

Care to elaborate? It has 95% of earth's mass, and as it orbits at 0.72 au, it suffers from roughly twice the radiation from the sun. (assuming all radiation follows 1/r^2) I assume that if it had a magnetic field, it should be able to hold on to it's hydrogen.

Actually, there's a time-honored tradition of spies posing as journalists. Because it gives them an excuse to be snoopy, and at least in Western Europe and the USA it's considered bad form to execute journalists even when they stumble upon something they shouldn't have.

Yes, but it doesn't really matter to spies because just being a spy is a war crime. Spies that get caught get executed anyway, so what's a little more?

They asked Fark for help.

You can have as many cards and screens as you can fit, but note one thing;

To use more than one card in a multi-monitor setup and be able to move windows from one screen to the other you'll need to use Xinerama.

But the use Xinerama disables compositing. That means no wobbly windows, compiz, etc.

There's a hack to fudge around that by using Xorg over xserver-xgl but it isn't perfect though.

I've only had it running with KDE successfully.

http://mugginix.com/articles/2009/Nov/12/Xinerama_Composite_Fail/

No, the application needs to call madvise(2) for the memory regions it thinks it can share.

To make this work automatically for all similar pages, the kernel would have to compare every page in memory against every other page in memory, not something you want to do.

Note that something similar already works for normal applications -- shared libraries and program images are shared between applications until their memory regions are written to. If a program forks, every page it has is shared until it's written to.

A cache line on a modern Intel/AMD processor is actually 512 bits, or 64 bytes.

A memory bus 512 bits wide wouldn't really help much, though -- right now when dealing with memory, most of the time is spent in the various latencies. When you are fetching a lot of memory sequentially, you can get insane speeds even today. But that's not how you usually read memory -- instead, you read a few words from different locations, and the memory controller needs to activate the correct bank, row and column before you get what you need. On typical PC-10600 DDR3, that means at least 15 bus cycles just waiting around for the memory to adjust. Making the bus 512 bits wide would speed up the actual transfer to one bus cycle from the 4 what it takes currently, but that would only mean an improvement of about 15% -- at a huge cost for having to accommodate those 384 extra data lines on the chip, socket, motherboard and ram. It's better just to try to speed up the memory so burst transfers happen "fast enough".

I don't know about nvidia cards, but at least for ati the card doesn't actually have a 256 bit memory interface -- instead, it has 4 completely separate 64-bit memory channels connected to a fast ring bus. The interleaving of data on those separate memory channels is done very coarsely -- basically, entire textures and such are allocated on a single channel. This means that when that texture is being fetched, the 3 other channels can serve other requests.

This is the way I see cpu's evolve too -- even on current hardware, namely phenom 2, you get better performance when you ungang the memory channels, and wait 8 cycles for a single memory transfer instead of 4, because that way you get to wait on separate latencies on the separate channels at the same time. Of course, in the perverse case all the data you want to access resides on one of the channels, but the chance of that happening by accident is pretty much nil.