Uhh.. Have you ever heard of Conrail?

Not to mention the fact that Trucking companies pay a lot to drive on the interstate.

Your comment about weigh stations being closed betrays some naievte about their function. Truckers don't pay at a weigh station. The stations are for spot checking to verify that the trucks weight is acceptable for (1) the road but mostly (2) the truck class.

Have you ever seen those stickers on the door of the cab? Each truck is licensed and the cost of that license varies on a number of things, including the type of good to be hauled and the weight of the hauls.

Many Toll Roads charge far more for tractor trailers than cars. And there's a higher tax Diesel than Gasoline.

The government has done it's fair share for the freight railroads.

I think you can sum it up in a single word: Conrail.

FWIW, clustering doesn't have to be hard. Vertical webserver sharding can get complex. (eg, these servers load accounts, these servers handle signups, etc)

But you can simply scale out many PHP/Python/Ruby apps by storing Session data in the DB or on a NAS share. Then do a simple round-robin in the balancer.

Storing session data that way does give u a bit of a hit so you won't see try (O)N scaling. Probably something more like (0)0.9N. EG 2 servers would give you 1.8x the capacity of 1 that stores session data on a local physical disk.

This is basically rubbish. HTML Rendering is not the bottleneck. It's the DB. Tweaking the MySQL Query Cache and using memcache is the solution here.

In both cases, you'd update your cache as part of the DB update.

Any cron-driven pre-caching is just the PB to your caching jelly.

The query cache requires no add'l code to implement and can produce huge efficiencies. Simple sharding will ensure any given mysql server has enough cache resources to remain performent.

And memcache has swell libs that sit in front of an entire cluster of mc servers and make your life easy. Cache server sharding and striping are done for you.

It becomes as simple as:

function load_profile(id)
{
    memcache = memcached.instance();
    if (profile = memcache.read('profile_' + id))
            return profile;

    p = profile.instance();
    if (profile = p(id))
            return profile;

    throw new Exception('not found');

}

Unless you're, you know, not braindead and you implement opcode caching... Not to mention, those 1MM lines are no doubt spread across thousands of files, classes and functions. Only a fraction would be interpreted for each request.

And when you want to un-install all you need is a Sows Ear, 3 picas of pixie dust and a magic wand.

Seriously, though, it's easy in theory but anybody using Ubuntu or Debian for a day will see that the abstract does leak.

As much of an improvement aptget is over the "old way" it's still nothing like the Apple App Store experience many linux fans make it out to be.

Actually, he took the job at MySQL after CouchDB.

He worked on Lotus Notes (among other things) before CouchDB.

I'm a Sr dev / team lead at a .com that uses PHP predominately.

Let me tell you something about PHP developers that I've learned, myself included.

The good ones are Software Developers who just happen to know PHP. Without exception, of our 30 developers, the ones that know just PHP are Jr-Level and have much to learn.

The rest of us, there's no joy in PHP. It's a kludge of a language. The garbage collector is horrendous. The external libraries are more buggy and slower than their counterparts in python or ruby. (see: memcache).

My point is that, of all the truly good PHP developers on my team, my Team Lead colleagues, and the good devs on their teams, would much rather be programming in another language. Not necessarily .Net, but another language.

I guess my moral here is that picking off PHP developers probably isn't as hard as you're suggesting.

That is the only long-term solution to this problem.

And you're right in your last paragraph. IIRC, the entire value of all world stock markets is ~100tn. Real estate is 80tn. The idea we have 1qn in CDS contracts is absurd on its face.

Of course, the real problem with all derivatives (including CDS contracts) is that we don't really know what they're worth.

It's not the known-unknowns that kill us when trying to unwind these contracts. It's the unknown-unknowns.

The real tragedy I think is that the idea behind CDS--distributing risk across the globe--makes sense.

If I'm insuring houses in Florida it makes sense to do a CDS with an Insurance company in Japan. If I get hit by a hurricane, they're probably not going to be affected, so let's spread the risk. Likewise a natural disaster of their own.

The problem came down to unregulation and, natch, greed.

I've now heard this being called "The Great Unwind" by a few different publications. Looking back, I think that name might stick. It really is the best 3-word description I've heard of this crisis to date.

There's a quadrillion dollars in Derivatives. (That's not a hyperbole).

Many large banks hold over a trillion dollars in Credit Default Swaps.

All CDS contracts have a universal default provision.

As much as it pains us all, these banks really are too big to fail. That needs to be fixed. We simply cannot have corporations that are so essential that we taxpayers must "insure" them. But that's tomorrow's fight. Today we just need to survive.

All kidding aside, JS is a pretty good example of Functional programming.

There are far worse gigs than JS programming. Not something you want to do 40 hours a week but JS can be downright FUN compared to a lot of other web technologies.

SVN Blame, my friend. SVN Blame.

There's nothing wrong with the idea that the gross value of credit default swaps & derivatives is greater than the sum of the global product.

Global product is annualized.

It's like saying "His net worth was a few times more than his summed up household income, it had to crash"

That's a good illustration: You just injected content that I downloaded. In your case, it was the link.

Sure, there are a lot of apps that have some sort of facility for this. But there are just as many that don't.

For CSRF to work the attacker has to be able to inject his own content into your site that a victim can then come by and download.

Quite a few ways to do this, but if you take the precautions mentioned above, you'll be safe.

Tho, I would add one more IMPORTANT bullet point: Install the Suhosin Hardened PHP Patch.

And for fool-proof input sanitization, use filter_input() (and the other Filter functions PHP introduced at 5.something)