Just a quick little snippet from an apple town hall that rings true to me — whenever [my wife]’s CPU goes crazy and starts overheating it’s because of a website w/ flash content…

As for Adobe, Jobs said they are lazy and Jobs blames Adobe for a buggy implementation of Flash on the Mac as one of the reasons they won’t support it.

Apple does not support Flash because it is so buggy, he says. Whenever a Mac crashes more often than not it’s because of Flash. No one will be using Flash, he says. The world is moving to HTML5.

Those comments are bullshit.

1. Regarding speed — Flash now supports hardware acceleration, but Windows is the only OS with hooks for it. Video would be much much quicker if it could use the Mac’s hardware acceleration. Counterargument is Apple should be allowed full control of their hardware and not have to expose access to it, but I don’t buy it. How do games access the video chip?¹
2. Regarding bugginess — Chrome and the current Safari are architected such that if a plug-in crashes, the whole browser does not go down. Firefox will eventually be like this too. Arguing Flash can cause a Mac to crash just makes the Mac sound poorly architected, and it’s not.

There is a reasonable story I’ve read for not supporting Flash (or any popular third party plug-in): the desire for more agile control over the OS. For example, Apple is moving to an entirely 64 bit OS, but Flash is only 32 bit. This means in order to ship a 64 bit Safari they had to write a sandboxed plug-in system that 32 bit apps could run in.² However, they really don’t want to deal with this crap on iPhone OS. Imagine if they want to support a different mobile processor architecture? They want to compile and go, not have to wait for some other company to port their ware.

There’s a pretty good article that covers much of this by pro-Apple³ John Gruber.

But let’s focus on the statement about the future:

No one will be using Flash, he says. The world is moving to HTML5.

Jobs is referring to the HTML5 <video> tag. This gives a simple, non-Flash based way for browsers to know when to show video. Earlier drafts of HTML5 also specified using Ogg Theora as the video codec. Theora provides a patent unencumbered, open source implementation anyone can use. Basically, in 2007 HTML5 solved the problem of how everyone could watch video on the web without all the problems Flash brings. But Theora was pulled out of the spec in large part due to Apple (and Nokia) weakly arguing about submarine patents. When it comes down to it, Apple cares far more about media and content control than fast, bug-free video. They’re backing a DRM enabled codec over a working web. Performance issues and bugs are a red herring.

1. Uses of Flash go far beyond just video, but really, video is the main way we experience Flash. If all those embedded videos didn’t suck up all that processing power, there would probably be a lot less complaining.
2. One could argue this was a good thing do, regardless.
3. Fanboy

Sad. I just discovered EtherPad and one of my favorite things is its ad-hoc nature. Want to start collaborating on a document right now? Just go to the site, start a new pad, and pass around the URL. You could even make up the URL path ahead of time! No account is required; it Just Works.¹

Contrast this with Google Wave where I need to be signed into my account, everyone I want to share with must have a Google account, those accounts need to be in my contacts, etc.² The risk is losing the momentum and the moment. It’d be faster and easier to jump onto an open wiki.

Is my weight on a quick & easy ad-hoc solution a geeky, open source enthusiast desire? Maybe I’m feeling similar to the way Zed Shaw is feeling about Google Groups. Maybe this is part of what we are warned about in The Web in Danger. At the very least, it makes me feel pretty good about having become a software developer: I can stop bitching and start coding.

Update: Apparently I wasn’t the only one who was upset. In response to its user base, EtherPad is Back Online Until Open Sourced.

1. Of course, I’m speaking of the free and open portion of EtherPad, as that’s what I’m interested in.
2. Let’s just skip the poor “everyone has a Google account” argument.

How David Beats Goliath: When underdogs break the rules

http://www.tweenbots.com/

(I guess this was a good candidate for my first twitter tweet.)

Check out their use of pepper spray and especially how they deal with a bystander yelling during last week’s New School building occupation:

If you were living under a rock last year, here is the video of a bicyclist being thrown from his bike that got mainstream media coverage:

It’s interesting to read about some of the things the mayor would like to see happen in San Francisco. Of course, he won’t be in office to make good on his desires, but these kinds of comments are probably smart if you want to run for Governor of California.

The biggest thing that has kept us on Python … well, there are two huge things. One are the libraries. There’s a library for everything. We’ve been learning a lot of these technologies and a lot of these architectures as we go. And, so, when I didn’t understand connection pools, I can just find a library until I understand it better myself and write our own. Don’t understand web frameworks, so we’ll use someone else’s until we make our own. Don’t understand a lot of stuff. And Python has an awesome crutch like that. And now, as we’ve been learning more, pulling more stuff back in house — just so we can have things the way we like them — it’s made the transition super super easy.

The other thing that keeps us on Python, and this is the major thing, is how readable and writable it is. When we hire new employees … I don’t think we’ve yet hired an employee who knew Python. I just say, “everything you write needs to be in Python.” Just so I can read it. And it’s awesome because I can see from across the room, looking at their screen, whether their code is good or bad. Because good Python code has a very obvious structure. And that makes my life so much easier. […] It’s extremely expressive, extremely readable, and extremely writable. And that just keeps life smooth.

The question gets asked around 25:54 on the video.

$ curl -k -I https://brainsik.theory.org/.:./wp-login.php
HTTP/1.1 302 Found
Date: Mon, 06 Apr 2009 02:08:18 GMT
Server: Apache/2.2.9
X-Powered-By: PHP/5.2.6-2ubuntu4.1
Location: https://brainsik.theory.org/.:./wp-login.php
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8

1. HINT: Compare the URL I requested, and the one I was redirected to.

A few days ago, Zed Shaw spooged about how rad Django is. There isn’t a lot of meat to his story, but there are enticing morsels like generic views, the Pinax component list, and:

Django has been pushing the idea of having discrete “applications” that act within a “site” as cooperating but separate components.

Inspired, the first thing I looked at was the ORM. The schema we’ve inherited and need to redesign is absurdly complex¹ so I suspected this is where I’d first hit limitations.

The redesign will use natural keys when possible and reasonable to help protect against duplicate data entry² — the system we inherited uses only surrogate keys and has duplicate data in a variety of places. Also, we add protection (against errors, bad data, etc.) at multiple layers, so this approach fits well with our philosophy.

When choosing a natural key, sometimes more than one column is needed to guarantee uniqueness. This is called a composite primary key. Unfortunately, composite primary keys are not supported by Django³ and their wiki page about Multi-Column Primary Key support is disheartening. The only reason they might implement this feature is to support “legacy databases (whose schema cannot be changed)”. This plus the automatic generation of primary key “id” columns tells me they have made a choice for us: use surrogate keys.

Our model is now outside Django’s current scope and there is no way to leverage another ORM that can support our needs. Sadder still, the brilliance of an entire database toolkit⁴ perfectly suited to work with the M in our MVC project is inaccessible.

This is the problem with frameworks like Django, Ruby on Rails, and others; they enforce their “pragmatic design”⁵ on you. You must use their ORM, their template language, their request dispatcher, etc. You are sequestered within their community.

In frameworks like Pylons (and others) where you get both structure and choice of base components, all the different communities of ORM creators, template engine writers, and etc. are available and intermingling. Communication between projects is high and even the frameworks themselves are mixing!⁶

Our project will be growing for years, the longevity and flexibility of the community is critical. The last thing we want is 4 years from now realizing we’re dependent on a suite of core components nobody is using.

1. We actually blew the Python call stack with our relation references when using SQLAlchemy and declarative. You might be thinking that’s because the model is crap, and you’d be right. We are actually keeping a tally how many times we exclaim “WTF!?” each day as we try to beat the beast into submission.
2. See Josh Berkus’ Primary Keyvil series for explanation of how natural keys can provide a database level way of protecting against duplicate data.
3. “Each model requires exactly one field to have primary_key=True.”
4. SQLAlchemy is not just an ORM, it’s an expression language and more.
5. From the Django project homepage.
6. TurboGears 2 was rewritten on top of Pylons.