Android does have this feature. It is part of ashmem (Android shared memory) which is a patch to the Linux kernel. Under memory pressure the kernel can discard the pages and when the application goes back for them it is notified that they are gone.

I do understand encapsulation. I've been writing and maintaining code for nearly 20 years and I've seen how helpful it can be. If it was part of a class that was exposed as a public interface I would totally use getter and setter functions, if I absolutely had to. I find it is generally a lot better to set everything up front in the constructors and mutate the object state in response to verbs. Position->Move() rather than Position->setX().

You sound like you don't understand when to abandon encapsulation. I imagine you write Java or C# software and your class definitions contain 30 lines of useless code before you even start to write anything.

What kind of IDE do you use that can't quickly find every use of the x member variable and convert it to a function call?

In my experience this is a good way to hide your locking problems and avoid thinking about them. Which leads to deadlocks and excessively slow code. Because now if you want to modify 2,000 objects you have to lock each one individually instead of locking once and doing them in a batch. Then to fix that problem instead of rethinking the locking from the top and doing it correctly you get quick hacks like adding get_unlocked and set_unlocked to each object.

There's zero difference between a public getter/setter pair and a public variable. Encapsulation and future proofing the interface? In a game codebase? You'll never use it, and if you did need it the code editor can search and replace for you. Meanwhile, writing piles of getter/setter functions is a waste of time. Unexpected modification of public values doesn't get any better when its done through a setter function.

You need hardware support to securely encrypt a hibernation file. Otherwise it is a chicken and egg problem. Where do you get the key to decrypt the hibernation file? It would have to be in the hibernation file.

Either that or ask the user for the security code on resume. Which is valid but obnoxious.

Sure, why not?

It's still less stuff than you have to install to make Gnome Shell usable. I've got five plugins installed just to make it work vagely right.

120 GB is plenty of space. I ran Windows 7 plus some apps like Firefox and LibreOffice on a 30 GB SSD in 2010 so I know it can be done. My current laptop has 128 GB and is only half full.

Everyone seems to understand meters, centimeters, millimeters and kilometers; bytes, kilobytes and megabytes.

Yet when I try to describe the distance from Denver to Chicago in megameters my friends look at me funny.

I find it especially lame when astronomers describe distances in millions of kilometers. Are they too stupid to understand metric and use gigameters?

In almost every case a previous property owner has already sold the mineral and water rights. Especially in the cities and suburbs. Or your legal jurisdiction may not recognize such rights.

Some places have no private water rights and all water is distributed via statute. For example, some land may come with access to a percentage of a stream, but that percentage cannot be sold and any contracts involving it automatically terminate when the property ownership transfers, and the controlling government can change it at will.

Same with mineral rights in some places.

It is relevant because in 2007 running 64-bit didn't suck. The operating systems and drivers were all in good shape by then.

Unless of course you were using a Pentium 4 in which case most 64-bit operations were the same speed or slower than 32-bit.

I've been running 64-bit Windows and Linux since 2007. Where is this suck you speak of?

I suppose you could have been one of the sad few who used a Pentium 4 instead of the much better Athlon 64 chip.

Since the Supremacy Clause is part of the original constitution and the 10th amendment is an amendment, the 10th amendment takes priority in any cases that conflict.

I don't know if this one does, but you should keep it in mind.

I have personal evidence that the default original install of Windows 7 on a Samsung Series 9 uses less power than a default install of Fedora 15.

Now, after I tweaked the Linux install using PowerTop and a rc.local script, Linux uses less power. This took some time and specialized knowledge of Linux systems.

So for an average computer user just installing an operating system, Windows 7 would use less power and have better battery life.

Highly compressible data only applies to Sandforce SSD controllers. I'm not aware of other controllers currently using compression. If you are planning to buy an SSD with a Sandforce controller then you should read the reviews on reliable sites that test using data of various realistic types. I like Anandtech myself.

SSD IOPS and RAID IOPS are quite different. A RAID made of hard disks may have a very high IOPS rating when it is using a high queue depth, but when using a queue depth of 1, its IOPS will be the same as a single drive. An SSD on the other hand, will have a very high IOPS rating even when using queue depth of 1. And most desktop software only issues requests at QD 1.

If you are planning to read 2 GB of images a single SSD will still beat a single HD. If you are using 6 Gbps SATA for the SSD you'd need at least 5 10K hard drives to match the transfer speeds.

And for compiling large sources, again the SSD wins because of how silly build tools are. As another commenter pointed out, current build software reads one include file, then the next one, then the next, etc. It reads one library file at a time. It reads or outputs one object file at a time. So it makes inefficient use of NCQ or RAID. Plus, some build tools seem to like to sync the build results to disk for no real reason (Visual Studio I am looking at you!).

Are you claiming that holy water blessed by a level 10 Cleric is the same as that blessed by a level 1 Cleric?

Well, you're right. It's a level 1 divine spell with no level modifiers.