Möglicherweise wird das Faxgerät der GEZ doch außertariflich entlohnt und wäre auch gestern verfügbar gewesen: Es scheint, als ob die Faxnummer der GEZ, die mit 0185 (nicht: 01805) beginnt, nicht aus dem sipgate-Netz (d.h., von meinem VoIP-Anbieter aus) erreichbar ist. Fail! Was es mit dieser sondersamen Sonderrufnummer auf sich hat, weiß ich übrigens nicht. Bleibt nur der Brief.

Also die Faxvorlage (die ich ohnehin ausdrucken, unterschreiben, dann wieder einscannen musste) in einen Briefumschlag, "GEZ, 50656 Köln" drauf, Briefmarke dazu und ab die Post.

Es bleibt spannend.

Read more…

Das Abmelden von den deutschen Rundfunkgebühren, da ist sich das Internet weitgehend einig, ist schwer. Da ich beruflich bedingt in ein paar Monaten nichts Gebührenpflichtiges mehr in Deutschland "bereithalten" werde (ja, ganz legal), komme auch ich nun in den zweifelhaften Genuss, das Verfahren einmal ausprobieren zu dürfen.

Einmal abgesehen von der angsteinflößenden Webseitengestaltung, klingt das Ganze auf der Abmeldungsseite auf gez.de eigentlich ganz einfach: "wer sich abmelden möchte, kann hierfür das Formular downloaden: Einfach das Formular ... ausdrucken, ausfüllen und uns per Fax oder Post zukommen lassen".

Gesagt, getan: Ich fülle das Formular aus und versuche -- erstmal -- die Methode per Fax. Das ist am günstigsten und wenn es nichts wird, habe ich immer noch jede Menge Zeit, einen Brief zu schicken.

Und siehe da, die erste Hürde: Es scheint, als ob die Idee von Internet-Sendezeiten sich auch bei den Faxgeräten durchgesetzt hat: Obwohl ich ernsthaft bezweifle, dass bei der GEZ ein Raumvoll handelsüblicher Faxgeräte stehen, die jeden Morgen von einem Mitarbeiter akribisch angeschaltet, und nach Dienstschluss eines nach dem anderen abgeschaltet werden, geht das Fax (und auch ein zweiter Versuch, eine Stunde später) nicht durch. Ist ja schließlich Sonntag.

Ich werde es also morgen noch einmal versuchen -- wenn das Faxgerät aus seinem wohlverdienten Wochenende zurück ist und wieder seiner tariflichen Arbeitszeit nachgeht.

Read more…

Here's another addition to the happy family of fail pets from across the Internet: The online merchant Zappos is well-known for executing an ordinary shopping experience (for shoes) extraordinarily well on the Web. They have RSS feeds, Twitter and Facebook integration and -- of course -- a "fail pet":

I wonder if Dash the dog knows what the Zappos people all blame on him there?

By the way: Not to be outdone, I just replaced the picture on my own 404 page with a photo of my dog out of the recent dog content collection.

Read more…

Over on the Mozilla Webdev blog, I just posted about a new library of ours, django-mozilla-product-details. This tongue twister allows you to periodically update the latest Mozilla product version information as well as language details from our SVN server.

The geeks among you are surely wondering, isn't that going to lead to a lot of useless traffic if the data does not change as frequently as it is being updated?

You are right. Because re-downloading unchanged data is evil and because we like our servers, we are using a fun little trick to keep the data transferred as little as possible:

Every time the update script is run, we first issue a HEAD request to the SVN server: A HEAD request is a type of HTTP request that asks for some location from a server, but instead of receiving the actual data in return (an HTML document, for example, or some binary data), the server only returns the response headers, not the actual data.

From these headers, which are very small, we can read the Last-Modified timestamp and compare that to the time we last updated our local copy of the product data. If the timestamp hasn't changed since then, there's no need for us to download further data.

Instead of blindly downloading the data files on every update, we send the time of our last successful update along to the server, in a If-Modified-Since HTTP request header. If the files have changed since then, the server will send us the updated list, but if nothing has changed in the meantime, the server will just return a "304 Not Modified" status.

This is how we ensure that (almost) no matter how often you choose to update the product data, neither your nor our resources will be wasted.

This is not only a good idea for this specific library: Next time you consume RSS feeds or other "pull" data from various places on the Internet, make sure to query for updates before downloading unnecessary data. Caveat: This method only works if the server can handle an If-Modified-Since header. Servers that serve bogus timestamps or no such header at all leave you no choice but to download and investigate the feed itself.

Update: A few readers pointed out that the If-Modified-Since request header would be an even better method to update the data conditionally than an initial HEAD request. They are, of course, right, which is why I updated the library accordingly. Thanks, everyone!

Read more…

On occasion, people claim I blog about too much geekery, so here you go with some dog content:

Yup, that's Lizzy, playing with her brand-new rubber chicken. She picked it herself at the store and oh-so-appropriately, it is a Bavarian chicken sporting Lederhosen.

Given her usual aversion to having photos taken of her, I was impressed that I got a set of four pictures before she bailed.

Read more…

The latest versions of Ubuntu do not appear to have the tool udevinfo anymore, which is vital to find information about devices connected to the computer.

There is, however, a new tool called udevadm, and with a little syntax trick you can get it to spit out your familiar udevinfo syntax:

udevadm info -a -p `udevadm info -q path -n /dev/sdb`


Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:13.2/usb2/2-1/2-1:1.0/host5/target5:0:0/5:0:0:0/block/sdb':

  looking at parent device '/devices/pci0000:00':

If you use this more often and don't like the idea of entering a huge line of code for such a simple command, drop the following into your .bashrc file (all in one line):

udevinfo () { udevadm info -a -p `udevadm info -q path -n "$1"`; }

Now (after starting a new session or typing source ~/.bashrc), a simple udevinfo /dev/sdb will do the trick.

Also helpful: A long time ago, I wrote a blog post about udev rules, showing what rules I used at the time to have consistent device names for my USB drives, no matter in what order I connect or disconnect them. The devices I mention there are long gone, but I keep going back to that post every time I need to write a new udev rule.

Read more…

I am delighted to report that in the project I am currently working on, I get to play with a lot of smiley faces:

Hope that lightens up your day a little :)

(Yes, you guessed right: For every smiley page there is an equivalent with a frowny face, but sheesh, don't tell anyone ;))

Read more…

It's the 30th anniversary of the arcade classic Pac-Man, one of my all-time favorite computer games.

Apparently, Google agrees, so they celebrate it with a playable (that's right) Google logo: Today, Google is most certainly distracting more people from work than Facebook.

This is awesome. Make sure to try it out before the end of the day!

(If you missed it, I am confident it'll show up in the Google's doodle gallery soon.)

Update: Tobias and JP point out the Google's Pacman logo now has a permanent residence on the web. Great!

Read more…

When you look at the bottom of your GMail window, you'll notice links in the footer, cycling through more or less helpful tips as well as Google advertisements.

For years now, one of these links has been to the GMail Notifier for Mac:

Sadly though, this link to http://mail.google.com/mail/help/notifier/index.html (forwards to http://toolbar.google.com/gmail-helper) has, also for a long, long time now, been a not found error. As you can't open a bug report with Google, I've emailed the GMail service people about this before, but I guess dead links in production software are not on top of their todo list.

Ah well, maybe they google for "Gmail fail" sometimes and find the bug report this way ;)

Read more…

Everybody knows Mozilla makes Firefox. But there is a lot more software at work here at Mozilla that you might not be aware of. For example: What happens when you go to getfirefox.com and click on the download button?

By clicking on the button, you ask our servers to send you a specific file, for example: Firefox 3.6.3, for Windows, in German. On a small website, the server would just fetch the file and hand it to you. But if you need to handle millions of downloads a day like we do, a single server can't handle it all by itself, so it gets more complicated. In order to provide you with downloads, updates, etc., as fast and conveniently as possible, Mozilla collaborates with a number of mirror providers that have volunteered to host Firefox and other downloads on our behalf, thus sharing the load of our numerous downloads between a number of servers all over the world.

For some years now, we have been running a bundle of software called "Bouncer" to handle our downloads for us.

Bouncer consists of of three components: The user-facing bounce script, an administrative interface called Tuxedo, and a mirror checker called Sentry.

First, the bounce script. It is the only component the "ordinary user" gets to interact with. It essentially does the following after you click on a download link:

  • It determines if the product you asked for exists.
  • Out of our list of mirrors, it picks one that has your file. Initially, it would pick one at random. Over the years, the logic has become more elaborate though: Meanwhile, it takes into account in what country you currently are, as well as how strong the mirrors are (stronger mirrors serve more downloads, weaker ones serve less).
  • A split-second later, Bouncer refers you to the server it decided on, and that server will send you the file you asked for.

But wait, there is more! How does Bouncer know what products are available, for what operating systems, and in what languages? That's where the admin interface comes in. We have a release engineering team who work hard every day to deliver the newest software versions to you in handy little packages. Previously, during every release, an engineer would manually tell Bouncer that a new version was available for download. But just last week, we improved this process by introducing a new interface to Bouncer, with a project called Tuxedo. The release engineering team can now, fully automatically, feed new versions into Bouncer at the time of release, with no manual intervention. With less time spent on repetitive tasks, we can spend more time making Firefox awesome.

Finally, the Sentry component is a script that periodically checks the health of our mirrors, and adjusts our settings accordingly. This is to ensure that a situation where you are forwarded to a mirror that is currently unavailable is very, very rare. So far, these mirror checks happen from Mozilla Headquarters, and therefore reflect the connectivity we get to the mirrors from here. In the future, we want to improve that by taking into account more how our users' connectivity is to the specific mirrors (for the geeks out there: Network proximity != geographical proximity), which has the potential to result in faster download times, less expenses for mirror providers, and general happiness.

As you can see, there are a lot of things happening behind the scenes before Firefox makes its way onto your computer at home, and we are constantly working on improving the way we are doing things. Plus, as always: Bouncer is completely open source, and we have a public bug tracker, so if you notice any problems or see room for improvement, make sure to let us know.

Photo credit: "directions", CC-by licensed by Phillie Casablanca.

Read more…