The reason I had to look this up was because the LA Times is too busy talking up the idea that California has a revenue problem to actually do any real analysis about what the nature of the problem is.

Well I found part of the answer tonight.  In 2005, California ranked number 4 in spending per capita when compared to other states.  The top five in order were:

1. Alaska $15,118 per capita
2. New York $11,803
3. Wyoming $11,089 per capita
4. California $9,501 per capita
5. Massachusetts $9,117 per capita

Other big states were much less

• Texas $6,628
• Florida $7,337
• Illinois $7,678
• Ohio $8,015
• Penn. $8,096

If California spent like Penn. which ranks number 15 compared to other states our state and local spending would be $48 billion lower and we wouldn’t have a budget crises on our hands.

Now I just have to find something that documents where the money goes and where California spends a disproportionate amount.

PS.  Share of total government spending from 1970 to 2006 was just about the same for every category except two: health and defense.  Health is up from 8% to 20% and defense is down from27% to 13%.

Sources:  Tax Foundation State and Local Spend and Tax Foundation Share of total Gov Spending

This email came from Barack himself, not one of his campaign guys. He positions Clinton with McCain as being the enemy and closes by asking for a small donation. When he asks this of the million plus on his email list, he will likely get a big combined donation and that will be in the press real soon.

The man is a skilled politician and he is using the social web like no one ever has before. Whether he wins or loses, he has changed the game.

Votes are still being counted in Pennsylvania, but one thing is already clear.

In a state where we trailed by more than 25 points just a couple weeks ago, you helped close the gap to a slimmer margin than most thought possible.

Thanks to your support, with just 9 contests remaining, we’ve won more delegates, more votes, and twice as many contests.

We hold a commanding position, but there are two crucial contests coming up — voters will head to the polls in North Carolina and Indiana in exactly two weeks. And we’re already building our organization in the other remaining states.

But it’s clear the attacks are going to continue, and we’re going to continue fighting a two-front battle against John McCain and Hillary Clinton.

I need your support right now. Please make a donation of $25:

https://donate.barackobama.com/whatthismeans

Thank you for all that you’re doing to change our country.

Barack

Dear Amazon EC2 Developer,

Many Amazon EC2 customers have been requesting that we let them know ahead of time about features that are currently under development so that they can better plan for how that functionality might integrate with their applications. To that end, we would like to share some details about a major upcoming feature that many of you have requested - persistent storage for EC2.

This new feature provides reliable, persistent storage volumes, for use with Amazon EC2 instances. These volumes exist independently from any Amazon EC2 instances, and will behave like raw, unformatted hard drives or block devices, which may then be formatted and configured based on the needs of your application. The volumes will be significantly more durable than the local disks within an Amazon EC2 instance. Additionally, our persistent storage feature will enable you to automatically create snapshots of your volumes and back them up to Amazon S3 for even greater reliability.

You will be able to create volumes ranging in size from 1 GB to 1 TB, and will be able to attach multiple volumes to a single instance. Volumes are designed for high throughput, low latency access from Amazon EC2, and can be attached to any running EC2 instance where they will show up as a device inside of the instance. This feature will make it even easier to run everything from relational databases to distributed file systems to Hadoop processing clusters using Amazon EC2.

When persistent storage is launched, Amazon EC2 will be adding several new APIs to support the persistent storage feature. Included will be calls to manage your volume (CreateVolume, DeleteVolume), mount your volume to your instance (AttachVolume, DetachVolume) and save snapshots to Amazon S3 (CreateSnapshot, DeleteSnapshot).

This new functionality is already being used privately by a handful of EC2 customers, and will be publicly available later this year. We will be expanding the private offering as we get closer to launch. Please sign up if you are interested in participating.

We hope this information is useful to you as you plan, design and deploy your applications in Amazon EC2.

Sincerely,
The Amazon EC2 Team

This from Brad Feld is a good run down on the two services.

1. The Google App Engine Q&A - an in-depth blogger-created FAQ that provides great links to other blog posts on the topic and summarizes various opinions and known facts.

2. Google App Engine for developers - Nial Kennedy’s overview from his meeting with the App Engine team leads.

3. A high level comparison (via email) from Scott Moody where he compares App Engine and Amazon EC2. Since Scott doesn’t keep a blog, following is the pertinent text from his email.

Google hides infrastructure from AppEngine users. AE programmers never (and, in fact, aren’t allowed to) think about database scaling and configuration, load balancing , fail-over, etc. In theory, the complexity of writing a highly scalable app completely disappears.

With EC2, you still have to set-up load balancers, configure multiple replicated database servers, implement scalability hacks if things grow too fast (such as distributed caching of data via memcached), keep distros and apps up-to-date, etc. Bottom Line: EC2-based companies still require sys admins, AppEngine companies don’t. That will certainly change as more companies begin offering EC2 server management services.

Google provides a non-relational datastore and that’s the only datastore available (no traditional file system, no relational databases). With EC2, people generally use MySQL or Postgresql. Amazon offers a non-relational datastore called SimpleDB, but it’s a bit *too* simple. For example, it does not support sorting of results sets. Huh? That makes it non-workable in my opinion. There’s also an issue with using EC2 virtual machines for your database servers — Amazon says that when a virtual machine crashes, all the data managed by it disappears, so virtual machine crash = hard drive crash.

With EC2, programmers can use any (non-Microsoft) language to develop their apps. AppEngine users must code in Python. Also, Google does not support sockets at this time. All cross-app communication must be done via HTTP.

At *this* moment in time, it would be difficult to move apps off of AppEngine. Doing that in EC2 is trivial. This, to me, is the biggest issue, as I believe it could make startups less-interesting from an acquisition perspective by anyone other than Google. This will most likely change as people develop compatibility layers. However, Google has yet to provide any information about how to migrate data from their datastore the best I can tell. If you have a substantial amount of data, you can’t just write code to dump it because they will only let any request run for a short period before they terminate it.

Some people are complaining about Google having access to their source code. I don’t see this as an issue. I’d rather have it be stored at Google than at some small hosting company.

One final nice little thing in AppEngine’s favor: Websites that store less than 500MB of data and get roughly 5MM pageviews per month or less can use AppEngine for free. The downside is that Google has yet to say what they’ll charge if apps go over that quota, but I have to believe that it will be reasonable. Right now, you’re prevented from going above the free-level quotas.

The comments about about the issue of Amazon’s EC2 persistent data problem should be eliminated soon. And the issue of lock in that O’Reilly seems concerned with is being tackled as well.

These services along with platforms like Facebook are going to change how the web works. It is like a layer of new functionality being layered on to the web so that things that low value work gets eliminated and we can spend our time on the interesting stuff.

Here’s a short video clip I took at the party.

And here’s a pictures from across the room. BTW that’s Marina from Hot for Words interviewing someone from Wired in the foreground.

Jason Calacanis has some good thoughts on the after party and friends here.

MS takes the cake. The second answer under a search for Microsoft Sucks on Live.com yields google.com followed by support.microsoft.com and then YouTube. It also has a university listing for MicroSoft Sucks.

Yahoo gets second prize for it’s cover up links to Yahoo sites.

Google gets the honesty award:

In short he says,

So, the story is, doing the simplest of data portability (for instance, making all systems understand when I changed my email address) is going to take a lot of work and a lot of cooperation between all of the players). Doing the toughest stuff (like sharing of some of the social graph, or making things like photos and videos portable) will take a lot longer.

For some reason, we expect this highly disparate systems to magically integrate with each other and let data flow between them without problem. Anyone who has spent time working in the systems integration arena knows that this is really hard.

I think it might be helpful to look at this differently. Today, we have human powered system integration. I am my own data portability hub carrying information about me from one place to the other and manually going to each place to update my data. Aside from the manual intensity of this process, I kind of like it. I like the fact that I have control over the data and where it goes.

Expecting disparate systems to get to data portability is going to take a long time. However, I could publish my own data portability feed. It would contain the data about me, the services I subscribe to, and include my friends feeds to designate who else I am connected to.

I would leave the security settings aside for now and let me manage my settings within the context of a service. These security settings are likely to require more privacy and will be much harder to handle.

This kind of data portability feed should not be hard to implement and would get things started sooner rather than later.