Not a particularly useful use of the inode table. The filesystem is great for a few hundred or even a few thousand records, but when you're dealing with billions of records, that adds up to a lot of wasted space.

I'm pro-paperless because it's a blasted mess.

Burning my karma kandle at both ends.

that our government is sliding towards communism!

( ) Killing them that way is not slow and painful enough

Pray tell, what level of vigilante justice would you consider to be slow and painful enough?

Right. They are ignoring the huge volume of legitimate mail that hotmail/msn silently deletes in violation of the RFCs.

Hotmail doesn't represent the majority of e-mail accounts, and usually it seems to be down solely to the incompetence of whoever is administering hotmail, rather than intentionally violating RFC. Same difference, I suppose, but it's certainly not a majority of the legitimate e-mail they get to them, anyway.

Wrong - the auto-update feature is new to 7.x, so actual sites running 6.x (or earlier) doesn't benefit from it. Also, the new feature will only install and update modules and themes, not 'core', so I'm guessing updating core from 7.0 to 7.1 is probably going to require about as many manipulation steps as you need to go from 6.14 to 6.15. I don't have a lot of experience, but I would not say it's "extremely easy": the stable 6.x version requires you to do a lot of file and configuration manipulation just to go from 6.14 to 6.15 (if you follow all the recommended steps, which I did for my test site recently). It's not hard, it's just not automated.

If you set everything up properly, you just overwrite everything not in the sites directory with the new files, and then possibly run the database update script. Quite trivial.

I actually set up Drupal sites by symlinking to a main drupal installation for files and common modules. All the benefit of the /sites directory without having to use a single root favicon, deal with script-loaded sitemaps, etc.

...on my servers come from hijacked IE6 machines or bots claiming to be IE6.

Nail cannot come too soon.

PHP's primary issue in the database department is it doesn't have a clean way of say, maintaining prepared statement declarations across connection instances. Which is frustrating. APC's handling of shared memory is not the best, either, and the memcached extensions for it need polish. Don't get me started on how PHP treats constants.

Where PHP really fails, however, is in memory usage. It takes up dozens of times as much RAM as a well-built C program would. Facebook would not reduce their computer count by a factor of ten because PHP is that much less efficient at its job, but because more memory would be available in a given machine to handle more instances at once.

Note: PHP 5.3 addresses a lot of this, but though I haven't tested it, I doubt the memory efficiency of PHP is going to get far into the double-digit percentiles of C++ in one shot.