Still using Firefox because privacy matters

I am still using Firefox as my number one browser, occasionally switching to Opera, and occasionally trying out Chrome (on my Laptop). Why am I so stubborn, some Chrome fans will ask? And why am I not using the default Android browser on my slate? And why did I not end up buying an iPad?

It all boils down to two points: The browser ecosystem and the browser ethos.

The web is more important than apps

Sometimes I hear people say it's all about the apps. I disagree. The web is the only one truly open and life changing platform. I did not chose Android over iOS because of usability or design concerns. I'd say it is still slightly – but only very slightly – behind. My new phone is a Nokia N9. Neither Android or iOS, but Meego! And yes, it has a few hundred apps, including a Dropbox client and a Google Reader.

(By the way, the user interface on the N9 is just fantastic, it beats both the iPhone and Android!)

However, both the Android Tablet and the Meego Phone lets me run Firefox. And that is nowadays a sine qua none for me when choosing a device.

Every major browser has an ecosystem nowadays

Of course all browsers can surf the web and in that regard the web is their ecosystem. But in addition to that they come with additional features.

• Internet Explorer's ecosystem is that of corporate intranets, Windows and the occasional web site that still requires ActiveX. I know of few people who enters this ecosystem by choice, except gamers, but it is easy to get support. And all your games are playable on the hardware that is far cheaper than anything from Apple. And Windows does really have the best graphics drivers and infrastructure for sound.
• Chrome's ecosystem is of course Google products: G-mail, G-cal, G-reader, G-docs and G+. You're at least considering getting an Android phone and think that Chrome OS has a lot more potential than it has shown so far. You are obviously not so concerned with the privacy of your data.
• Safari's ecosystem is of course the Apple products. If you are into Apple, you're using a Mac, and every program in sight that starts with an i. You had an iPod and now have an iPhone and you will get an iPad, not because you need it, but because its made by Apple. In short, you enjoy the shiny prison of being locked in to Apple. Censorship and authoritarian control of the platform be damned – the bars are golden!
• Opera thrives on the mobile and on devices. They have managed to make web surfers out of millions of people who never could afford a modern smart phone. In some ways though, they struggle since the entire web universe basically is their ecosystem – except for sites made by incompetent developers that shut Opera out for no good reason. There are things like Opera Link and Opera Unite, but they have not got the buzz they so rightfully deserve. The fact that Opera pioneered many things now common to all browsers, like tabs, and have always been a true champion of standards, even before Mozilla appeared, makes them worthy of tons of respect.

So, what makes Firefox ecosystem so special? It boils down to one thing. Firefox is everything!

• It is not the oldest champion of web standards among browser vendors, as that honor goes to Opera, but they are a good runner up, and it was Firefox that de facto wrestled the web away from Internet Explorer, providing room for all other browsers to exist as well. Firefox paved the way for both Safari and Chrome!
• It is not the true speed king, as that title goes to Chrome or perhaps Opera, that are faster on most – but not all – benchmarks as far as I can tell. But it is fast enough. And it championed the cause of being lean – once upon a time! Even today it consumes far less system resources than most other browsers.
• It is, however, the true champion of add-ons. And it has the best add-ons for my needs.
• Firefox has the best sync. First of all it is client side encrypted, meaning no data mining opportunities for Google or anyone else. But what makes it stand out is the syncing of tabs. It's a time saver and a life improvement factor! I sue it all the time, moving between computers, my phone and my tablet.

The right focus for the future

The economy of the future in IT is data driven. In a world of ubiquitous computing stewardship of our data in the cloud is the main prize for all big players to fight about. Through pads, tabs and boards data will be accessible in lots of places. But whoever is in control of the cloud is the winner of the future.

But will cloud stored data be accessible to all? Or only a select few that use the right brand?

And will it be inaccessible to anybody except those that I chose to share my data with? Or will the host continually mine my data and in the worst case scenario share it without my consent?

In this regard, Apple's guiding principles fail totally. The company shows close to zero interest in interoperability and since the margins go down when selling cheap devices this becomes a global problem. By building digital walls around the data in the richest countries, we are once again failing all non-western countries.

By the way, the Arab spring was not brought to the world by Apple, but by Nokia…

Google might not have failed yet. Interoperability is high on their agenda and so far their data mining seem to be mostly anonymized. But when one single entity sits on too much data and control the complete surrounding ecosystem, we are providing someone with enormous temptations. Sooner or later that temptation will become too strong!

Therefore we need truly anonymized cloud technologies. We need user owned and controlled data. We need stuff like browser id to replace the usage of id-solutions provided by Google, Facebook, Twitter, Microsoft or Apple.

In short, we need what Mozilla and Opera are championing. And for me personally that means that if you see me using a browser for anything but testing, that will still be Firefox for the foreseeable future, unless I change to Opera!

Will my next laptop be a Thinkpad?

It’s time to move on from my trusty old Thinkpad z61p. It has been a dear friend, but its simply not anywhere near state of the art anymore. Still, having lasted over 4 years and many thousand hours of heavy duty use is high praise indeed.

So what do I want? I had hoped for an upgrade of the Thinkpad W701, to use Sandy Bridge and Thunderbolt – but instead the series seems canceled. Where is the follow up to the W701? Why, oh, why have you forsaken me Lenovo? (I actually don’t know. Lenovo’s web site is basically useless.) It takes a ton of work to find the information I actually want.

I want a workstation, movable but not ultra portable. More power. And it may weigh a few kgs.

Stuff the computer must have

• A trackpoint – a high quality, usable Trackpoint. Does any other line of Laptops except Thinkpad have those?
• A really good keyboard. Once again, can I trust any other manufacturer than Lenovo?
• Preferably 17 inch, high resolution (1920px wide), high contrast – matte. Not glossy! (Maybe I must settle for 15 inch, but it would be very disappointing.)
• A high speed SSD, as big as possible.
• It should run Linux with no hickups. My distro of choice is Fedora. For testing purposes I may shrink and keep the Windows partition, but it will see very little usage. (If buying an OS-less laptop was an option, I’d chose it.)
• Firefox and Chrome should be able to run WebGL on Linux, thus the graphics drivers must be on their whitelist.
• Display port or HDMI
• Service should be available in Sweden, so lesser known brands are out of the question.

All of the above are top priorities. And I am prepared to spend quite a lot of money on this purchase.

Then there are a few things that goes without saying

• High end modern CPU, like the 2920XM or one step down from that one.
• At least 8GB of RAM DDR3 or better.
• Gigabit Ethernet.
• IEEE802.11abgn.
• Bluetooth 3.0.
• At least one USB 3.0 port,
• Large and high performance SSD,

And there is also a list of nice to have features on my wish list

• Spill proof keyboard.
• Back lit keyboard.
• Thunderbolt
• 2nd drive for storing large files that I do not use very often, video, images, sound. (Yes, the W701 had 2 drives...)
• A Firewire interface

I prefer a 2nd drive to optical media. If there is only room for one drive, chances are high I will ditch the optical drive and use that space for an extra hard drive.

So, what are my choices? Right now the list looks like this:

1. Thinkpad W520, but it has only got an 15 inch screen…
2. HP EliteBook 6760w, but will the Trackpoint be good enough… (and I can't find a model with the 2920XM processor, OTOH I can get it with a better graphics chip, up to the Quadro 5010M, but that GPU consumes a whopping 100W and is probably a bit too much, even for me.)
3. Fujitsu Celsius H910 The specs looks nice. I can have up to 2 x 250 GB SSD but the keyboard and Trackpoint is not comparable to a Thinkpad.

Given my set of requirements, what other options do I have?

And the key question: Is there any hope for a 17 inch Thinkpad W7xx to be released within the next 3-4 months?

(And no Mac is not and never has been an option. And, yes, I have plenty of experience with Macs and know perfectly well how they compare to Thinkpads.)

Firefox Aurora and Nightly on Linux

Automated download and install Firefox Aurora and Nightly on Linux

ffupdate.sh

#!/bin/bash
FTPDIR="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly"
AURORA="firefox-5.0a2.en-US.linux-i686.tar.bz2"
NIGTHLY="firefox-6.0a1.en-US.linux-i686.tar.bz2"
DLDIR="Hämtningar"
#
cd ~/${DLDIR}
rm -rf firefox*
test -d /opt/aurora || sudo mkdir /opt/aurora
wget ${FTPDIR}/latest-mozilla-aurora/${AURORA}
test -f ${AURORA} && tar xjf ${AURORA} || \
  ( echo "Aurora download fail" &&  exit 1 )
sudo rm -rf /opt/aurora/*
sudo mv firefox/* /opt/aurora/
rm -rf firefox*
test -d /opt/minefield || sudo mkdir /opt/minefield
wget ${FTPDIR}/latest-trunk/${NIGTHLY}
test -f ${NIGTHLY} && tar xjf ${NIGTHLY} || \
  ( echo "Nightly download fail" && exit 1 )
sudo rm -rf /opt/minefield/*
sudo mv firefox/* /opt/minefield/
rm -rf firefox*

To be improved and adjusted when new versions appear, but it does the job for now.

Excerpt from .bashrc

alias ff36="/usr/bin/firefox -no-remote -P ff36 &"
alias ff4="/opt/firefox4/firefox -no-remote -P ff4 &"
alias ffclean="/opt/firefox4/firefox -no-remote -P clean &"
alias ffbeta="/opt/ffbeta/firefox -no-remote -P beta &"
alias ffaurora="/opt/aurora/firefox -no-remote -P aurora &"
alias minefield="/opt/minefield/firefox -no-remote -P minefield &"

Tidy5 aka the future of HTML Tidy

UPDATE 2011-11-19: The most immediate of my concerns have been addressed by Björn Höhrmann who has submitted basic support for HTML5 in Tidy to a forked version available on Github.

I have been a long time fan of Tidy, a tool to clean up and do some basic checks on the code. However, the tool is not really being updated any more, and since I have moved to using HTML5 and ARIA on all my new projects, it has lost much of its usefulness.

I also see no momentum picking up and thus think it should be considered folding Tidy into html5lib. By that I mean using html5lib to get Tidy like functionality.

Today I wrote a mail that I cross posted to the discussion list for Tidy and the help list for WHATWG. This blog post is essentially a longer version of that email.

Tidy must go HTML5

Here is the deal with HTML5. Pretty soon every browser will have an HTML5 parser. Except for IE, browsers do not have multiple parsers.

This means that tokenization and DOM tree building will follow the rules defined in HTML5 – as opposed to not really following any rules at all, since HTML 4 never defined them.

Simply put, there is no opt out of HTML5. An HTML 4 or XHTML 1.x doctype is nothing more than a contract between developers. Technically all it does is to set the browser in standards compliance mode.

Thus, I do not see any future in a tool that does not rely on the HTML5 parsing algorithm. Tidy can not grow from its current code base, but needs to have the same html5lib at its core that is in the HTML5 validator, which basically is the same as the one being used in Firefox 4.

Additionally, Tidy suffers from:

• Implementing WCAG 1 checks in a world that has gone WCAG 2.0.

• Not recognizing ARIA, which is an extremely valuable technology on the script heavy pages of today.
• Not recognizing SVG and MathML.

I know one can set up rules to enable Tidy to recognize more elements and attributes, but for full HTML5 + ARIA + SVG + MathML (and perhaps RDFa), that is simply not doable without superhuman efforts.

The merge

A basic Tidy5 implementation could look like this:

1. Parse the tag soup into a DOM.
2. Serialize HTML from that DOM.
3. Compare the start and the end result.

Perhaps any error reporting can be made during the parsing process. Henri Sivonen could probably answer the question if that is possible.

However, there is also talk about having a lint like tool for HTML, that goes beyond what the validator does. So in addition to the above, there can be settings for stuff like:

• Implicit close of elements. Tolerate, require or drop all closing tags?
• Implicit elements – tolerate, require or drop (maybe require body but drop tbody...)?
• Shortened attributes – tolerate, require or drop?
• HTML 4 style type attributes on <script> and <style> – tolerate, require or drop?
• Explicit closing of void elements – tolerate, require or drop?
• Full XHTML syntax (convert both ways)
• Indentation. Preferably with an option not to have block elements with a very short text content not to be broken up into 3 rows as in Tidy today.

Besides purification and linting, such a tool/library can be used for:

• Security. This will require the possibility of white and/or blacklisting elements and attributes. And preferably also attribute values.
• HTML post processing. This will enable authors to see indented code, that is explicit, while at the same time such "waste" can be removed before gzipping. This would be akin to JS minification and it could be performed on the fly from within PHP, Python, Java, Ruby, C#, server side JS or whatever. It can also be done manually before uploading from the development environment to production - or it could be integrated into the uploading tool!

Checking templates

The main feature that Tidy has today, is the ability to handle templates, by preservering/ignoring PHP or other server side code. To what extent the HTML5 parser can be modified to handle that feature I do not know.

From a maintenance and bug fixing point of view, I see huge wins in having a common base for Tidy, the HTML5 validator and HTML parsing in Gecko.

In fact, a very radical idea for Firefox (or any other browser using html5lib) would be to actually integrate these tidy-inspired features directly in their development tools, re-using the existing parser! A Firebug extension that lets me validate as well as tidy up my code directly within the browser would be super awesome!

But the actual possibility thereof is beyond my technical knowledge to evaluate, so I need to hear from people who know this stuff better than I do.

Integration with accessibility checking

Although automatic testing can not not substitute manual tests, they can give a developer an in the ball park idea about the accessibility of a page and fix the most obvious mistakes.

The fact that Tidy today do integrate WCAG 1.0 is better than nothing and any implementation of Tidy5 should strive to integrate WCAG 2.0 in a similar fashion. That really is a no brainer. Having to use only one tool and getting all errors in the same buffer (for programmers) or the same console (for manual checks) is certainly convenient.

OK, that was my two cents. What do you think?

How to know if you are watching a bad JavaScript tutorial for beginners

Answer: You are watching it. There are no good tutorials for beginners anywhere!

People who actually know enough to teach JavaScript properly either don't have the time to teach, since they get paid to work for clients and when they do teach, they do so at conferences or seminars in front of their peers, not to newbies. That means that what's available on-line for beginners is stuff taught by people who do not know enough to actually teach.

For me as a professional teacher that means that I have to devote considerable time to warn my students about bad habits, thus wasting valuable lesson minutes, which turn into hours. And there are always someone who missed a class, and tried to compensate by Googling or YouTubing – something teachers normally would encourage – but will turn in bad work, that I have to give a lower grade. Thus, the worst case scenario is that students are actually punished in a way for taking an initiative.

Bad pedagogy

One of the things I've learned developing for the web for 15 years and teaching it the last 9, is that it is way more effective to learn things the right way from the start, and then be warned about some bad or outdated habits to avoid. Learning bad stuff, and then un-learning will harm students' motivation, confidence (how can I trust anything I read?) and slow down the learning process.

Also, to a newbie it is not immediately apparent why a particular way of doing things is bad, so they tend to stay with their bad practice, even though they may hear that they shouldn't. But it works! of course I answer something like Yes, but it's fragile, not scalable, hurts performance and violates good style, but it will take a very long while until I can actually show them that this is the case, and a demonstration is more worth than a thousand words.

And habits, once formed, have a tendency to become automatic, instinctive. They are hard to un-learn.

Don't believe me? Look at the praise in the comments for this super crappy JavaScript tutorial on YouTube. People are saying thing like now I know how to do it, when they should be saying that now they know how not to do it.

What's out there?

My students belong to the YouTube generation. They prefer videos to words, demonstrations to articles, images to text. Thus, nowadays the first place I look for material to use is on sites like YouTube or Vimeo, but every single beginners tutorial I've found so far is crap. They all exhibit most of the following features:

documen.write()

All by itself, document.write() is bad and should be avoided. This is way more important than keeping the "hello world" tradition alive. If you really must do that, at least use alert() since it does not alter the DOM and thus does not give a wrong impression…

document.write() is giving the impression that JavaScript has a linear execution model and that document.write() works like echo in PHP, or cout.

The faster students get into an event-loop/event-driven programming mindset, the better!

Inline event handlers

As PPK says,Don't use it.

Hiding JavaScript from old browsers using HTML-comments

Yup, in the year 2010 some wannabe teachers think you should still be nice to Netscape 1.2 and early versions of Mosaic! Monkey sees, monkey does.

Setting the language attribute on script tags

Now that we are learning that even the type attribute is not needed any longer, I still see people use the language attribute.

It is OK to omit semi-colons on the end of a statement

This is telling students that it is OK to rely on automatic semi-colon insertion.

I am teaching this stuff for a living and you really do not need any of the features listed above as an intermediate step to learning. When I teach my students, I only mention these in passing, saying that:

• If you use them, I will fail you on the course, or at least give you a low grade. (Yes, I will!)
• If you receive a tip from someone on a forum, or by Googling, suggesting that they are used, do not listen any more to that person. Learn to use these only as a sign of bad advice.

Which brings us right back to our problem. Where is the good advice?

There are some good things to read, but as I've said, I want videos as well.

What I do as a teacher today

I recommend watching the way too advanced videos, but only the first couple of minutes, originally meant as a rehash only by the speaker. I tell my students to watch the first 20 minutes of this video with Robert Nyman and the first 18 minutes of this one with Douglas Crockford.

That is not something they do instead of listening to me or reading, but this semester I have occasionally been called away on other business and also missed a few days due to illness (nothing serious).

If not for these, I might as well let my Swedish students look at this one. At least they won't be taught something bad!

(No, I do not speak Hebrew and I have no clue if that is a good video or not.)

And I enforce the following rules:

• You shall validate your HTML early and often.
• You shall validate your CSS early and often.
• You shall learn how to use JSLint and use it early and often.

Linting is not an advanced topic. It is an essential tool to encourage good habits for newbies. Besides, validation and linting are not something you do at the end of your development process just to get a stamp of approval. They are tools to help you along the way.

In a similar fashion, I introduce PhpCodeSniffer very early in my teaching of PHP. In fact, with every year of teaching, introducing these tools have come earlier and earlier. My web design students this year were introduced to the HTML validator the very first lesson that I devoted to HTML.

Cursing darkness or lighting candles?

This blog post basically is me ranting again. However, I do have have put in some considerable effort (if I may say so myself) to make the JavaScript teaching world a better place, by my work on the InterACT curriculum for DOM-scripting for the Web Standards Project.

If you are somewhat knowledgeable about unobtrusive JavaScript, and the good parts of the language, please take a look at the competency table and provide a video explaining one or two bullet points from it. You do not have to be Douglas Crockford, but should at least have heard a couple of his speeches and have read his book.

In so doing you will not get the reputation of being a ninja or guru. You won't get a chance to show how clever you are, but guess what? Rookies eventually grow up to become intermediate programmers, and they may very well evolve to become rather advanced one day. They will go to conferences and hear you speak on the advanced topics – one day. If you did provide them with something of real value when they took their first steps, they might just value that experience and return to hear some more in the future.

Bonus teaching tip

Use the JavaScript shell, while talking about basic things like types, variables, operators, expressions, statements and blocks.

Since the students are not in the browser environment, they are less likely to transfer bad habits to real work. The fact that they are in a shell makes it very clear that what they are seeing is not definitive. Even so, I will nevertheless point that out to them, again and again. One must never take stuff like this for granted, and as a teacher one always have to repeat oneself…

Oh yes, when teaching PHP I use the PHP shell as well.

The better version of this post

Chris Williams talks about how JavaScript education must be revolutionized (and other things) in this talk from JSConf.eu 2010. (transcript)

Why H.264 is disqualified from being a web standard

In short: H.264 can never become a standard for web video as long as the patents are not released according to W3C patent policies.

The MPEG-LA consortium so far has showed no interest whatsoever to release their patents in a W3C compatible way. Thus the question is answered, H.264 is not even a candidate for becoming a web standard. It can't win that race, since it's not even in the running!

The W3C patent policy

The goal of this policy is to assure that Recommendations produced under this policy can be implemented on a Royalty-Free (RF) basis.

You see, it's not a case of Mozilla and Opera being obnoxious. In fact they are only fighting for the same thing as the W3C is: An open web. Video should be open just like HTML, CSS and the DOM is open.

Yes, the W3C mandates that all standardized web technologies should be free for all and for all types of usage and that as far as they are affected by patents, the owners of those patents legally commit to not stopping such usage.

But H.264 is implemented natively in the browser

Yes, it is. In fact there is no law against implementing anything that is not a standard or being considered for standardization. Google implements Flash, within the browser, but that does not make Flash a web standard.

H.264 is usable, and since the drivers are mature technically still the best option for delivery on mobile platforms (more on that later). In fact, would the MPEG-LA consortium consider releasing their patents in a W3C friendly way, it would be an excellent web standard. I don't see that on the horizon, though.

The fact remains that H.264 is a proprietary, patented and closed technology. Some vendors have bought themselves the right to use that technology and others perhaps could, but that is not the kind of freedom web standards should be made of. I find it very ironic that people fighting for free and open web standards for markup and stylesheets, for scripting and for graphics (PNG, SVG, etc) and for net neutrality and universal access are so quick to sell out their ideals when it comes to video.

Since H.264 video is implemented natively is some browsers, we can do stuff with it that we otherwise perhaps could not. But there is still precious little we can do that could not be done in Flash. Really. At least when you look at the end result, not at how it's done.

Don't get me wrong, I like having native video in the browser, but native does not equal open.

An aside: The bigger issue

There is one ideal solution to this problem of course. The USA should change its patent system, that is flawed and broken beyond usefulness. Patents are granted for user interface ideas, algorithms and all kinds of obvious stuff.

If I'd been an American I'd write my congressman and ask him or her what they are doing about this. And if I'd not be content with that answer I'd vote for somebody else, and I'd let everybody know i DID. If the USA would change its laws, most of the world would follow.

However, since a change in US patent laws not is going to happen soon, we are stuck in this mess for the foreseeable future. So what do we really do about it?

Could the MPEG-LA consortium be persuaded to change its mind?

Here is an idea: Let's have Hixie add H.264 to the HTML5 spec and release that spec in such a way as to start the W3C patent clock. That would mean that any patent holder who feels that their patent is being infringed must protest.

There could be two outcomes. The MPEG-LA could show its true colors and protest or they might succumb to the pressure and actually change its policies. The first alternative would perhaps silence everyone who thinks H.264 is free enough, the second alternative would really make H.264 free enough!

I doubt Hixie would include H.264 in the spec in order to float a balloon like this, though. But it's a fun thought.

The real solution: Solve problems that can be solved

The one strong argument in favor of H.264 is hardware acceleration, especially on mobile platforms like phones, netbooks and pads. But bringing VP8 to a comparable state is within our grasp. The hardware acceleration problem can be solved and it is an easier problem to solve than flawed US patent laws or changing the minds of stubborn MPEG-LA patent bureaucrats.

In order to understand this we must consider two things: What exactly is hardware acceleration and what is the expected lifespan of a web standard compared to the lifespan of current chip sets?

I'll start with the former. Video codecs will probably improve over the next couple of years, regardless of them being standardized. Smart people will conjure up better ways to reduce file size while increasing quality, or at least improving one of the two without hurting the other too much.

The question thus becomes, has H.264 been implemented in the layout of the transistors of modern GPUs in such a way as to make any other algorithm, or any variation of the algorithm impossible? That is, are the calculations required to encode or decode H.264 implemented in silicon in every minute detail and will electrons flow from transistor to transistor in a sequence that exactly matches H.264 encoding or decoding?

If that's the case, we have really dug ourselves into a hole. If that's the case, we've made it impossible to improve anything at all! Since new ideas can not use the GPU, they are doomed to be bad ideas!

But since it still takes a whole lot of code to actually write an H.264 encoder or decoder, the answer is of course no. Hardware acceleration of H.264 is not a magic black box.

A GPU is just a slightly different processor, optimized for some kinds of arithmetic that a normal CPU is not. There is no magic to it. It's just a layout of transistors. In the 80's and early 90's most CPU's could not do floating point arithmetic effectively. One had to buy a separate piece of silicon to get that (the 8087, the 287 and the 387). IBM recently introduced a CPU that has a core for decimal (sic!) arithmetic and does cryptography in the hardware.

It's actually not about doing some stuff in the hardware as opposed to other stuff in software. Last time I looked, the CPU was a a piece of hardware! It's a matter of letting the right piece of hardware perform the kinds of computational stuff it does best. It's matter of writing and compiling your programs to use the integer part of the CPU when that's appropriate, the floating point part when that's appropriate and the GPU when that is the most effective solution.

There is no technical barrier preventing VP8 or ogg/theora, or indeed any other software, from using the GPU. In fact, Microsoft is using the GPU to speed up core JavaScript arithmetic in Chakra. That's just one example of modern programs using the power of the GPU to do calculations that are not graphics related at all. So if that's possible, what says it's impossible to move arithmetic calculations to the GPU in the case of non H.264 encoded Video?

Mozilla has gotten CPU usage decoding ogg/theora down from 100 % on the Nokia n900, to just 20 %. And the main thing preventing that number to drop is the fact that the sound is decoded only in the CPU. But that's an obstacle that can be overcome as well.

Lack of so called hardware support for ogg/theora or WebM is in fact not really a hardware problem, but a software problem. The decoders (and encoders) have not been written in such a way as to optimally harness the arithmetic power of the GPU &ndash: yet! I expect this to change rapidly, though.

But maybe current hardware has been made with H.264 in mind, making it impossible for VP8 to fully catch up? Well, if the web industry would show a clear support for the VP8 codec, AMD, NVIDIA and Intel will soon implement some alterations to their transistor layouts in the next generation of chip sets, making the playing field even.

In a very short time we will see WebM video implementations that move enough calculation to the GPU to make it usable in portable devices, using today's silicon. But for the sake of argument, let's suppose that looking at WebM video would drain the battery of your cell phone 10-20 percent more than H.264. How bad is that? It is still within a reasonable limit, I say. And HTML5 still let's you provide H.264 as progressive enhancement to any client. But what's being argued (at least in this article) is what we should consider as a baseline, what can become a true standard for web video.

Let me say this as emphatically as I possibly can. Even if H.264 could be considered somewhat better than VP8 from a technical point of view, it still is not a good enough reason to let go of our freedom. Anyone who is valuing a slight short term technological advantage over long term freedom, needs a reality check and an ethical wake up call!

What about submarine patents?

Microsoft and Apple keep talking about submarine patents, that it is a hazard to everyone implementing ogg/theora or WebM and the MPEG-LA likes everyone to believe that they soon will smack down on the VP8 codec used in WebM video. Since not everyone smells the FUD, let's argue about this for a while.

If indeed VP8 is trespassing on H.264 patents does that mean that anyone implementing a VP8 encoder or decoder can be sued? Could Microsoft be sued? Could Apple?

The premise for such a thought is that the patents for H.264 not only stipulate algorithms but prohibits anyone licensing those patents from doing any kind of alteration not only to individual patents, but to the exact combination of those patents.

This is thus a legal variation of the hardware argument. It stipulates a lock-in mechanism to H.264 that prevents any kind of experimentation or improvement. All by itself that would be a bullet proof case against H.264. Who would like to lock the web into such a solution?

But of course this is not the case. One may use individual algorithms from H.264 together with new or altered algorithms. Anything else would be plain stupid!

And since Apple and Microsoft are licensees of the MPEG-LA patent pool (as well as contributors to it, although Apple has not really contributed as much as Microsoft has), they are authorized to use those patents. They have bought themselves the right to write software that use those patents! So even if we admit – for the sake of argument – that the VP8 codec indeed does infringe on H.264, what risk does that pose to Apple or Microsoft? None whatsoever!

If Mozilla and Opera are willing to take the risk of implementing VP8, without licensing anything from MPEG-LA, what risk is that to Apple? In what way is that a threat to Microsoft? Having bought themselves the right to use all MPEG-LA patents that risk is absolutely zero.

Bottom line: MPEG-LA will not sue Apple if they implement the VP8 codec. Nor will they sue Microsoft.

(Of course, one option for Apple would be to let anyone submit any driver they'd like to IOS. If it was a truly open platform, we would see a WebM enabled version of Mobile Safari tomorrow, without Apple lifting a finger, without Apple programmers having to write a single line of code!)

H.264 advocates can not both have the cake and eat it too

On one hand we hear that VP8 is so similar to H.264 that it probably infringes on the patents guarding that codec. On the other hand we hear that it is so vastly different that we can not get hardware decoding. But which one is it?

If the algorithms are so similar, that there is a patent infringement going on, it goes without saying that GPU accelerated VP8 encoded video must not be hard to implement. If that's the case, the silicon has been wired to do these exact calculations.

On the other hand the algorithms are so different that decent GPU accelerations is impossible, what makes anyone think that the MPEG-LA could sue you for using them?

I wish H.264 advocates would chose which of these two dangers we are supposed to be afraid of, because they are mutually exclusive.

Another example of mutually exclusive claims is that MPEG-LA supposedly owns so many patents that is is virtually impossible to write a video codec that does not infringe on their patents and the fear that there might be some third party, that is not participating in WebM or Theora video, nor in the MPEG-LA, but holds patents in secret, waiting for someone to implement it. A Paul Allen, but with an actual case. A troll with infinite patience that will strike just when WebM has taken off.

But if VP8 is so akin to H.264 that it infringes on their patents, what space would that leave for this third party troll? Very little I'd say.

Once again, I am not saying that the one of these propositions is true. In fact I believe them both to be untrue. But I wish that H.264 advocates would agree on one argument, when mere logic dictates that one being true by definition means that the other one is not.

What kind of power does Apple and Microsoft wield within MPEG-LA?

Speaking of lawsuits, the MPEG-LA is a consortium and it must act according to the will of its members. So if Microsoft and Apple really cared about open video, I have suggestion for them. Use your muscle within that consortium, that you are part of, and convince your fellow members that truly open video is a good thing™. Convince them to release H.264 in a W3C patent policy compliant way. Show us that you are submitting such proposals to the board, show us that you are arguing the case. Only then will your opinion be worthy of consideration.

Until that happens, H.264 can not be a web standard. Until that happens, it can in fact not even be considered for standardization.

Chrome's auto update argument has just been disabled

A short note: When I have criticized Chrome for putting out half baked features on the web, the usual defense is that Chrome auto updates and that the release cycle is so short that developers will not be locked in to a version where the feature is half baked only. OK, but now Chrome is available as an MSI packet, and that changes everything!

I was anticipating that move, having experience not only in web development, but also in network administration. The key to getting into any organization is deployment through Active Directory group policies. Setting up and deploying an MSI-packet is expensive and not something an organization will do on a bi-monthly basis, unless there is some really critical security fix needed. They will not do it in order to fix a broken HTML5 feature.

What does this mean

If corporations, universities, schools, hospitals and other organizations decide to use Chrome, we will see a significant rise in the usage of old versions.

So providing an MSI-package makes it more appealing for corporations to roll out Chrome, but it still is work to do all local modifications, like setting proxies and home page. That's a hurdle big enough to discourage most organizations from updating on every release. Such aggressive updating will not happen. Are we clear on that?

Ergo: Rolling out half baked features in Chrome just became a really important problem for us all and failure to see that from the Chrome team is simply irresponsible. You can't have the cake and eat it too, and that simple rule applies to Google as well as everybody else.

Update

It seems that the Chrome MSI-package is half baked as well! How ironic. It's basically just a wrapper around the install exe-file. Furthermore, this means I've not yet been able to determine if the auto-update feature is disabled. But if not, what sysadmin in his or her right mind would allow self-updating software on the computers of the network?