Dan Siemon

Two things. Both relate to Microsoft but that is just by coincidence.

The first

Apparently IE8 will allow the HTML author to specify the name and version number of the browser that the page was designed for. For example, the author can add a meta tag that says essentially “IE6″. IE8 will see this tag and switch to rendering pages like IE6 does. Apparently this came about because IE7 became more standards compliant thereby ‘breaking’ many pages, especially those on intranets which require the use of IE. The new browser version tag will allow MS to update the browser engine without breaking old pages. As a result they will be forced to maintain the old broken HTML rendering engine (or at least its behavior) for a very long time. This will consume development resources that could otherwise be put into improving IE. It will also increase the size, complexity and undoubtedly the number of bugs. As for the pages broken by newer more standards compliant browsers, what is their value? Any information in a corporate Intranet or otherwise that has value will be updated to retain its value. If no one bothers to update the page is was probably nearly worthless anyway. Also, most of the HTML pages now in use are generated by a templating system of some kind. It’s not like each and every page will have to be edited by hand.

The second

The Linux kernel development process is notorious for improving (breaking) the kernel’s internal driver APIs. This means that a driver written for version 2.6.x might not even compile against 2.6.x+1 let alone be binary compatible. This of course causes all kinds of trouble for companies not willing to open source their drivers. However, the advantages of this process are huge. It is completely normal that during the development process the author will learn a lot about how the particular problem can be solved. By allowing the internal APIs to change the Linux kernel development model allows the authors to apply this new found knowledge and not be slowed down by past mistakes. As I already mentioned this causes problems for binary only kernel drivers but if the product has value the manufacturer will update the driver to work with the new kernel release. If it doesn’t have value the driver it won’t get updated and the kernel doesn’t have to carry around the baggage of supporting the old inferior design. How does this relate to Microsoft? From Greg Kroah-Hartman:

Now Windows has also rewritten their USB stack at least 3 times, with Vista, it might be 4 times, I haven’t taken a look at it yet. But each time they did a rework, and added new functions and fixed up older ones, they had to keep the old api functions around, as they have taken the stance that they can not break backward compatibility due to their stable API viewpoint. They also don’t have access to the code in all of the different drivers, so they can’t fix them up. So now the Windows core has all 3 sets of API functions in it, as they can’t delete things. That means they maintain the old functions, and have to keep them in memory all the time, and it takes up engineering time to handle all of this extra complexity. That’s their business decision to do this, and that’s fine, but with Linux, we didn’t make that decision, and it helps us remain a lot smaller, more stable, and more secure.

So what was the point?

I don’t know what to make of these two little stories but the later has been bothering me for some time. Where does the responsibility for dealing with change belong? The Internet has taught us that we should push as much work as possible to the ends of the network. The alternative is rapidly growing complexity and inflexibility in the core. It seems to me that this applies to both of the situations I outlined here as well.

Sometimes our government surprises me. The Government of Canada has created a list of Canadian podcasts.

More and more of the tech community seems to be talking about XMPP and how it fits into the future of the Internet.

One example: XMPP (a.k.a. Jabber) is the future for cloud services

everyblock.com

What a great idea for a web application. Large scale mashups/aggregators like this have real potential to change how we interact with our communities.

CBC has been doing a fantastic job of making most of its programming available as podcasts. More recently, CBC has also upped their Internet cool factor by adding two excellent new shows: Spark and Search Engine.

Both of these shows cover the interaction of technology and the Internet with society in general. Topics range from intelligent and interesting discussion of the forthcoming Canadian copyright changes to the funeral of a main frame computer, and more recently the applicability of the publication ban laws in the presence of blogs and social networks sites such as Facebook.

What is really unique about Search Engine and Spark though is how far they go to integrate the show into the web; or maybe it’s the other way around. Both shows make extensive use of their websites for listener feedback and to look for new story ideas. If this doesn’t seem particularly novel take note of how much these shows try to integrate ‘blog culture’. Search Engine starts each episode with keywords like a blog post. All of the music used on Spark is Creative Commons licensed and linked from the show’s website. Most importantly both shows sound very personal. Almost like an audio version of a blog post at times.

On a final note, these are not geek shows. If you read blogs or publish your own or use Facebook regularly you are likely to get something out of each episode.