Enigma is a great game, with a unique mixture of puzzles with mouse skills and action. If you know the discontinued game Oxyd originally on the Atari ST in the 90s (also on Amiga and one version on DOS), then you know the principle of Enigma. Except that it has tons of more levels and is Open Source.

Some weeks ago, I uploaded a 1.10 pre-release (approximately milestone 5) to Debian experimental. This is the soon-to-be-released new version, using a new level file format (with a much extended API to make level development even easier, ~50% less code per level now), new levels (of course), updated graphics (including support for new graphics modes), ...

Unstable still contains version 1.01; the reason is simple that I knew there would be another 1.01 maintainance release coming. However I believe it doesn't offer much against the current unstable version; it largely marks an upstream release containing patches already in the Debian package (since communication with upstream is really good).

So I have now two choices: refreshing the Debian unstable package to the "probably last" 1.01 release upstream, or going straight for the 1.10 milestones to give enigma some extra testing.

My parents needed a new printer, and after some research I decided to recommend them an HP OfficeJet Pro 8000. Today I gave it a try, by printing some CD covers for a CD to give away for christmas to some friends.

HP failed in a very subtle way: I had printed the covers, cut them, produced the CDs for them. Then I wanted to put the printed covers into the CD cases.

Despite the graphics being 12cm x 12cm in size, HP managed to print them in 12cm x 11.4cm. Without any notice (or giving me a choice) it had decided to scale them on the y axis. Which makes them completely unusable, since they don't fit the 12cm height of the CD case now.

After some more experiments, I decided to retry without duplex, and voila: 12cm x 12cm.

Duplex on HP OfficeJet Pro 8000 is only usable for draft printing, since it will distort your pages!

(See also this devidence in the HP forums, of people with the same issue, an attempt to investigate the margin messup happening, a report that the DJ990c driver can print duplex on this printer without messing with the margins, but is slower and offers less print quality. So it seems that this is an HP driver problem. And technically, it must be caused by the driver; at least it should be able to compensate for this!)

I also noticed another issue with the print. The bottom right corner of the graphic didn't get enough ink, it looks like the printer stopped printing a bit too early. I don't know if this also happens in non-duplex, since I worked around this by adding a header and footer to the page.

Seriously, we should send back the printer. On my first try to use it, I already encountered two bugs. I wonder how many bugs I would see if I'd use it every day?

Somehow, I'm still lacking the optimal media player application. Many popular ones are totally overloaded (e.g. amarok). Others like totem seems to be just a minimalistic frontend for a particular backend.

My current choice:

• Single-shot playback: to view a random song or video I usually open them with Totem (the GNOME default) and that works okay
• Library: I use MPD as player because it just seems to be rock stable. As UI I currently use Sonata, but I don't use it for much more than choosing a song from the currentl playlist.
• Editing: ExFalso seems to have the best ID3v4 support, in particular it also allows multiple genre fields. (Note that Vorbis even suggests you should use multiple artist fields instead of the common "Arist A & Artist B" way of filling the fields)

However, there is one thing I'm really not satisfied with: when putting together a CD compilation for friends (say, as Christmas present), they are quite useless. A key issue here is the total playlist length. Guess what, I want to make sure it fits on a single CD. So I really need to know the total playlist length. Why do so many media players (e.g. totem, alsa-player-gtk, xfmedia4, vlc, mplayer, ...) not show you the total playlist length? They did read all the files to get artist and title. Many even have the individual song lengths, just not the total sum.

In the past I've been using old XMMS1 to check for the total length, or a CD burning application like K3B by repeatedly importing my current folder.

Right now, I'm using Quod Libet (since I like the tag-editing component exfalso a lot) to arrange the playlist. It also gives me the total length, albeit I belive I've had incorrect song lengths in it before (broken VBR files?), and it's not perfect, too: being database-driven it has really long startup times for occasional users (because of updating the database) and is much more heavyweight. I also believe I've lost some playlists because I had moved my files around once ... so I'm a bit sceptical.

Anyway, there are still hundreds of media players I havn't looked at. Don't bother me to send me an email about one I havn't mentioned!

But if you are developing a media player, please consider the use case of putting together a music CD for your friends. In particular, for users that do not use your player all day.

The following User stylesheet snippet can be used to highlight particular search results (such as your own domain, if you want to quickly find it in Google search results):

@-moz-document url-prefix(http://www.google.com/search)
{
a[href^='http://www.vitavonni.de/'] { background-color: yellow; }
}

@-moz-document url-prefix(http://www.google.de/search)
{
a[href^='http://www.vitavonni.de/'] { background-color: yellow; }
}

a[href*=vitavonni.de] { background-color: yellow !important; }

This modification obviously only applies to your browser; it's meant to help you finding links to your own site more easily.

For a Java project, I wanted to give the Eclipse profiler a try. It didn't work, because it was missing a library (open the "Error log" view to see such things)

The corresponding library - libstdc++-5, and old C++ library - is no longer available in Debian unstable, so you need to grab the package from lenny. It will install fine on unstable.

Things may or may not be different on other architectures.

[Update: But TPTP is far from stable for me. It freezes Eclipse pretty much all the time.]

I'd like to make pyroman IPv6 capable. That is actually the one big thing before calling it a version "1.0".

I must admit that I havn't been very active on Pyroman (or Debian in general) the last years. This goes even so far as that "pyroman" was considered "abandoned" by Fedora or so. It is not; I use it on all my servers. It's still in use at the network I developed it for (after all there is not that much benefit for a workstation setup, where a 10 line iptables script will do the job just perfectly.).

Anyway, I'd like to get IPv6 support into pyroman, but there is one big issue here: I don't have any machine using IPv6, so I havn't used ip6tables myself yet, so I don't know about all the magic involved ...

So if you use IPv6, it would be very cool if someone would jump in to get full IPv6 support into pyroman. Madduck had already done some preliminary stuff, but I didn't get around to have a look at the integration or completeness yet.

The '--no-act' and '--print' modes of pyroman should even allow development without any IPv6 support or root permissions in the system.

Other things remaining on my pyroman wishlist:

• Fully automatic iptables firewall visualization
• Keeping traffic counters over firewall reloads
• Configuration UI
• A fancy 'arsonist' icon and a web page design

Here's a code fragment to track outgoing links with Google Analytics. As usual, use it at your own risk. I can not give you support for Google products, for obvious reasons.

To use it, you need at least understand where to put it (call it in a try-catch in onLoad) and how to adjust the variable name of your page tracker (I'm not using the default).

function trackLinks(){
  var as=document.getElementsByTagName("a");
  var ig=["mydomain.tld","google-analytics.com"];
  for(var i=0; i<as.length; i++) {
    var ignore=false;
    var oc=as[i].getAttribute("onclick");
    if(oc!=null){
      oc=String(oc);
      if(oc.indexOf('urchinTracker')>=0
      || oc.indexOf('_trackPageview')>=0
      || oc.indexOf('javascript:')>=0)
        continue;
    }
    if(as[i].href.indexOf("mailto:")<0){
      for(var j=0;j<ig.length;j++){
        if (as[i].href.indexOf(ig[j])>=0)
          ignore=true;
      }
    }
    if(!ignore){
      as[i].onclick = function(){
        var o=this.href.replace(/:\/*/,"/");
        pt._trackPageview('/out/'+o)+";"
        + ((oc!=null)?oc+";":"");
      };
    }
  }
}

This code tries to attach an onload handler to any outgoing link, ignoring internal links or links that use JavaScript. If such a link is clicked, it generates a virtual page access with an "/out/" URL that can be analyzed in Google Analytics.

A side benefit (apart from knowing which links are interesting to your visitors) is that you should get more accurate "time on page" statistics for your pages.