YouTube has a major challenge with their adoption of HTML5, they want to leverage the new format and capabilities, but they don't want to make it easy to download videos. This is going to be one of the biggest challenges youtube faces until they realize that allowing users to download videos will not reduce their market position or decrease ad revenue.

Originally with the flash version, downloading youtube videos was as easy as copying the unstreamed files from /tmp/ assuming you are using linux. With the introduction of HTML5 videos (both .h264 and webm videos) they made it a little bit harder, because HTML5 videos were not stored in adobe's cache, but in your browsers further obfuscated cache. This was overcome by disabling a content blocking box that they put over the video.

Round 2 of Downloading YouTube Videos

Now it seems they have updated the site again, and some additional sleuthing was required to see what they were doing. They are now using javascript to capture and ignore the right click event when you click on the video. I have expanded my bookmarklet to fix this issue as well. I left the original unblock code in there just in case they try multiple techniques. Drag this bookmarklet to your bookmark bar. This bookmarklet unhooks the context menu capturing event, and removes a blocker box if one is found.

I love the guide found at http://ubuntuforums.org/showthread.php?t=786095. It's one of the best guides for getting ffmpeg working with a lot of the "encumbered" codecs and capabilities. In order to make the process simpler, I have updated the ffmpeg connection from svn to git, and put the entire set of commands into a single spot. Simply copy and past the following into a console to run the entire set.

As of 2010-08-07 it is safe again to update to the chromium nightlies without losing large amounts of functionality. As of chromium-browser 6.0.487.0~svn20100806r55176-0ubuntu1~ucd1~lucid, the issue with <video> and <audio> tags has been fixed, and these pieces of HTML5 are working again. This means that my HTML5 video gallery is working again in chromium, as well as the YouTube HTML5 preview. Hurray!

X11 forwarding (AKA X Forwarding) is a slow but manageable way to run a program remotely, accessing a remote systems disk, memory, CPU, and filesystem, but sending all user interactions and display over the internet to be shown on your computer. X forwarding allows my to run visual diagnostic tools like kdirstat, or even pull up my home photo management program (fspot) without needing to install a local copy, or connect to the remote disk and deal with those complexities.

Typical X Forwarding Use Case

Let's image for a moment you just want to browse the remote filesystem with dolphin.

Step 1 - ssh server01 -XYC The XYC flags will enable X forwarding, compress the communication, and enables "trusted" X Forwarding.

Step 2 - Run your program, for example kdirstat / This command will run kdirstat using the memory, cpu, etc of server01, but the display will be shown, and interact with the mouse and keyboard of the client.

Multiple hop X Forwarding

Unfortunately it's not as easy to chain X11 forwarding as it is to chain normal SSH connections. The workaround is to use SSH tunneling. The general strategy is to create an SSH tunnel which you can open a second SSH connection with.

Using these commands in two terminal windows (the first one will just be a normal SSH connection to server01 that you will need to leave open) will open kdirstat / using the CPU, memory, etc of server02, on the display of the original client, as desired.

After about two years in the wild, Google Wave has been declared dead. Several important pieces of Google Wave were open source, and even more of the closed source pieces, will live on elsewhere on the internet and in Google's other services. Despite this, Google Wave, which I consider to be one of the most important and fundamental advances in communication will cease to exist. Google is no longer maintaining and developing Google Wave.

Google seems to have made a lot of mistakes with Google Wave that lead to it's demise. The first mistake was their slow private beta release. With a communication tool designed to replace email and IM and other forms of communication, the tool was almost pointless when you couldn't communicate with those you wanted to. Another mistake was not building a transport mechanism to connect Google Wave to other existing communication tools. Their final mistake that was quite likely the death blow was that their implementation was slow and buggy. Often users of the wave would experience a crash (similar in spirit to "oh snap" from the Chromium browser, but far more frequent.

I'm hoping other tools such as pygowave that implement the wave functionality more fully, with built in federation continue to grow and mature, and I still believe that a threaded dynamic open-ended communication will be the future, and will replace many of the existing tools we use today. We will just have to wait until the market is ready for such an advanced and capable tool.