I've been happy with gkg.net. I like that they started offering IPv6 glue records very early.

The Voyager computers are awesome too. How many other 18-bit word systems are actively maintained today?

I'd love to see the source code, though I'm sure it's terribly boring.

I just wish I had more of a reason to use it. As seminal as Slashdot was in the genesis of geek culture, it's decayed. We've left the nest.

So why not apply this less-rigorous process when upgrading from Firefox 7 to Firefox 8?

How do you distinguish between a user and an application he's running? How do you do it over a network?

Any piece of information an application (here, a client-side program) can access, a user can access too. If we can't distinguish between users and applications, we're forced to rely on the user as the unit of trust.

The situation is different for a "web application" that can store information inaccessible to users. But for local applications, a secret key is pointless.

Do we really have to re-learn the same lessons every 5-10 years? Trust users, not programs; don't trust the client; security through obscurity is no security at all: these are fundamental concepts, but we keep forgetting them.

What exactly is the point of the API key? Anything an application can do, a user with access to that application can do. Spammers can extract a key from application and pretend to be that application. You stop spam at the user level.

These attacks by LulzSec, Anonymous, et. al. remind me of the old Twilight Zone episode "It's a Good Life". In that episode, a child with godlike mental powers causes untold misery when, without understanding, he compels the residents of a small Ohio town to conform to his whim. Likewise, these hacktivist groups wield previously-unknown power, and they use to capriciously destroy whatever offends their ego, whimsy, or underdeveloped sense of justice. In the process, they not only hurt innocent bystanders not only undermine the legitimacy of their cause, but actually encourage more stringent regulation of the Internet. Like a character from a Sophocles play, they hasten the outcome they would fight.

They are legion. They do not forgive. They do not forget. They do not plan. They do not show restraint. They do not not choose their battles. They do not help.

CreateMemoryResourceNotification is precisely the wrong thing for reasons the GP has already described. It fails the "what if every application did this?" test.

The right solution is better support for discardable memory. But that's a "nice to have", not a "must have" feature.

What's the worst case?

Look: you can always give up efficiency to gain predictability. That's how real-time operating systems work. If you need hard bounds on access time, you can turn off the pagefile (or lock your application into memory). But the price is much less efficient use of RAM --- when you disable paging, the OS is forced to keep useless junk in memory, making less available for useful things.

In the real world, we don't need hard realtime guarantees in the vast majority of situations. In the real world, paging is the right thing to do because it's a huge efficiency win, and because the OS makes the right page replacement decisions most of the time.

But sure, if you're writing robot control software and people will die if the velocity control routine needs to be paged in, fine. Turn off paging. Or better yet, use a realtime OS like QNX. But for the rest of us, letting the OS manage access patterns is the right thing to do because the OS knows more than your application possibly can.

handle some asynchronous task because things are taking too long takes up 1 or more megabytes of RAM

You're still working with a naive mental model of how memory works. Thread stacks don't "take up" memory when they're created. Memory is not real estate. Thread stacks take up no memory until they're used.

Yes, the kernel will set aside pagefile space to make sure it can satisfy requests for memory (unless you're using Linux and you use overcommit) --- but that's not the same as actually keeping all that memory resident.

Calling mlock() can indeed prevent memory from being paged out

And that's why it's a privileged operation. Yes, there are exceptions to the general theme, but real-world systems are always more complex than one would suppose from a distance. The presence of mlock doesn't change my overall point though: the operating system decides what gets to stay resident.

A single program that hogs memory

You don't get it. The operating system arbitrates between applications and decides whose memory is actually in physical RAM. It makes these decisions based on access-pattern information unavailable to normal applications. Yes, all things being equal, accessing less memory is better. But imagining applications as being "selfish" and as "hogging" memory is using a very naive mental model to deal with a very complex real world system. In general, that doesn't go very well.