michaelkirkland.org/blog


svg_graph

I've decided to release a tool I developed for the self quantification system I'm building. svg_graph is a Javascript object that builds timeline graphs and injects them into XHTML documents.

I've tested it on Firefox, Chrome, Safari and Opera, and it should work on any browser that supports XHTML and SVG. Unfortunately IE doesn't support either, so it won't work there.

More information and download here.

1514 Comments >> Bookmark and Share

Google releases a browser

Today Google released their new browser, Chrome. It's very pretty, sleek, and it implements an idea that's a been sorely needed in the browser space for a long time.

Chrome separates each tab into its own process, so if a page or plugin (*cough* Flash *cough*) causes a crash, it can only take out that tab. The rest of your tabs and browser instances keep going on their own.

This has been desperately needed in browsers for years. Most people keep at least one, and often several browser instances open at all times so it's quite a nuisance when some silly plugin brings the whole show down. Firefox has made some kludges to handle this, like the ability to restore a session after a crash, and they probably would have moved in this direction eventually.

Chrome also has a new, streamlined Javascript engine, v8. This, along with the robustness that a multi-process browser brings, makes Chrome an excellent platform for the web applications (like Gmail and Google Docs).

That's what Chrome is really about. If they can get it installed widely, they (and anyone else) can make an end run around Microsoft's OS monopoly. The clincher is an open document standard, which is why Microsoft has been fighting the Open Document standard so viciously, and trying to force their proprietary format through the ISO process. Without that, Microsoft can hold on to their OS monopoly by withholding Office from any serious competitors.

There are a few disappointments with Chrome. There's no ad filtering, and as yet no extension mechanism to implement it (though they've promised to rectify the latter).

Google is, of course, not going to be terribly keen about people stripping advertisements from the web, but they also will have to face the fact that it's necessary. I realize they have to walk a fine line with this, but they're in a great position to help mediate between the extremes of filtering absolutely everything (as many Firefox users do with Adblock Plus and EasyList/Element) and the downright offensive lengths some advertisers will go to to annoy the crap out of people.

Google could start a clearing house for web advertising with a voluntary code of conduct requiring advertisers to tag their ads appropriately for filtering by the browser. Public key encryption could be used to verify that an ad is released by a member in good standing. Users who don't want to see animated ads, ads with sound, ads for porn or whatever could filter those and let less obnoxious advertising through to support the sites they visit. There could even be an automatic negotiation between the browser and ad server. A user who may be willing to accept text ads could be presented with those instead of being forced to block all ads to keep the annoying ones out.

853 Comments >> Bookmark and Share

On lots and lots of cores

Ars Technica reports on an Intel blog warning developers that we need to adapt an open ended number of cores.

Intel, of course, is primarily worried about making sure people are buying the n-core chips they'll be selling in the years ahead. Of course, that doesn't mean they're wrong, but I don't think the changes, from a coder's view, are going to be as generalized as some seem to. You're not going to get the people smearing their VB on the walls or poking Sharepoint with a stick to wrangle threads. Most of those folks can't even handle pointers without cutting themselves. If they're to see any benefit, it'll have to be done for them at a lower level, and that's fine.

Now, I'm not saying we won't see big changes in how we code. We certainly will. My point in this post is that it doesn't matter. We're going to go through interesting times, and there will be lots of attempts at getting parallelization right, but this is a revolutionary rather than evolutionary change.

The really cool stuff will spring off from the side, where no one was looking. Ars correctly points out that we won't be getting "free" performance upgrades in terms of periodic increases in clock speed anymore. What's important to note is that we will, suddenly, start getting "free" processors no one really cares about because they're idling.

Expect filesystems to get a lot smarter. Need to clear IO cache? Throw a spare core at compressing it rather than just tossing it. This is easy to parallelize, so throw all the idle cores at it.

Expect virtualization to get thrown at all sorts of problems. Need backwards compatibility? Keep whatever you need running on a core in the background.

You'll likely only be running local servers for sensitive or frequently accessed large stores of data. Renting virtual server instances is going to get cheap. When you can fit a few hundred cores into 1U, the price of renting one will probably be rolled into the cost of bandwidth.

Keep in mind, Intel is far from wrong. We still need to find ways to sensibly use lots of cores for singular tasks, but the really neat things will come out of the slack that arises when we don't keep up with them.

1 Comments >> Bookmark and Share

What I've been reading

Here are some amazingly haunting long exposure shots of crowds faded into a ghostly fog.

code_swarm is a project that makes some really neat visualizations created from the history available in source code repositories. Processing, the library used to create the tool that made these videos looks like it might be fun to play with.

0 Comments >> Bookmark and Share