This is the workflow Apple envisioned when they introduced the annoying quarantine flag back in the days of Mac OS X 10.4:

1. User A downloads an archive (.dmg, .tar.gz, etc.) from the Internet. The system applies the quarantine flag to the archive file.
2. User A extracts an application from the archive and places it into /Applications. The system infects the app bundle passes the quarantine flag on to the app bundle.
3. User A launches the application. The system warns about the unsafe origin of the app.
4. User A confirms that the app is safe to use. The system clears the quarantine flag. Problem solved.

Unfortunately, my workflow is slightly different: Click the "Read more" link to see what the problem is.

python-aprmd5 0.2.1 has no functional changes, it just includes a patch for a more comfortable build without having to manually edit setup.py. The patch was contributed by Juan A. Diaz - thanks Juan! I took this opportunity to move the project to GitHub. A small project page stub remains here on herzbube.ch that lets me host the source distribution tar balls for each release.

If you like a bit of computer science entertainment, this StackOverflow question has a humorous treatment of a very real world problem that I am sure has affected all of us, more or less severely.

And here is a demonstration how a light-hearted subject will always be turned into a controversy by people that are just too focused. What a pity.

The newest bugfix release 0.9.2 for Little Go has finally been released on the App Store last night. It took a bit longer than originally expected because I didn't manage to submit the binary before Apple closed their iTunes Connect service for the Christmas holiday.

0.9.2 addresses a number of crashing and memory leak issues which should help to further increase stability. As good as this sounds, I am not yet done with bugfixing because I have received reports for a new type of crash. Also I have become aware of a few changes in iOS 6 that make it necessary to revise the strategy for releasing memory when the app receives a memory warning. I don't know yet if I am going to roll these things out in another bugfix release (0.9.3), or if I will incorporate them into the next feature release. The decision largely depends on the feedback I get for 0.9.2.

The bugfix release 0.9.1 has just gone live on the App Store this morning. It fixes another glitch in the Ko detection routine (the same function I already muddled with for 0.8.1). Get the newest sources from GitHub.

Unfortunately 0.9.2 is already in the works: The new crash reporting feature in 0.9.0 has led to over 80 crashes being reported in only a few days. As sad as it is to see that the app I am sweating over is not as perfect as I would have liked it to be, it is still a good thing to see those bugs finally coming out into the open so that I can squash them. It also proves that adding both a crash reporting and a general in-app bug reporting feature in 0.9.0 was well worth the effort. If I ever start another iOS app project I will certainly launch the app with both of these QA features already in place.

The bugtracker for Little Go has now moved to GitHub. From now on everybody who has a GitHub account will be able to submit new issues without emailing me first. The few tickets that are still open on the old tracker will be duplicated on GitHub and closed on the old tracker.

Little Go 0.9.0 has just been released to the App Store. The source code for the new version is available directly from GitHub.

The main feature of the release is that there are three new profile settings that provide much improved control over the computer player's playing strength. The other major focus has been on QA stuff: You can now choose to send a crash report if the app crashes, and you can send a bug report with attached diagnostics information at any time. Last but not least there have also been a number of bugfixes; the most important improvement probably is that the game is now saved after each move instead of only when the app is suspended. A crash should now be merely annoying instead of causing catastrophic data loss.

"Voting is almost never a way to reach consensus. Rather, it acknowledges that consensus has not been reached and side-steps further constructive attempts to reach it."

-- Stefano Zacchiroli, Debian project leader (original post)

This statement is a beautiful summary of one of the big misconceptions about what democracy truly is! Click the "Read more" link if you want to see my personal comments. For once in this post I am not talking about technical stuff...

The Little Go source code repository has moved to GitHub. I will remove the old repository on git.herzbube.ch in the next couple of days.

On Mac OS X, when I mount a TrueCrypt volume from a file container while logged in as user A, I can then switch to another user B and view the mounted volume's content (e.g. in the Finder, or in a Terminal.app session). I believe this is a bug, as the content of the TrueCrypt volume should remain private. I don't know enough about the underlying issues to lay the blame on any one in particular (Mac OS X, TrueCrypt, FUSE?), but what I definitely can say is that I cannot trust my Mac to be left alone while a TrueCrypt volume is still mounted.

This is how my mounted volumes' mount points look like inside a Terminal.app session. As you can see, the TrueCrypt volume PRIVATE is mounted with permissions that make it wide open for any user to snoop around inside.

nargothrond:~ --> ls -l /Volumes/
total 184
drwxr-xr-x   1 patrick  staff   8192 12 Dez  2010 BOOTCAMP
lrwxr-xr-x   1 root     admin      1 29 Aug 21:17 Macintosh HD -> /
drwxrwxrwx   1 patrick  staff  16384 31 Dez  1979 PRIVATE
[...]

I have reported this issue on the TrueCrypt website in September 2009. I never received a reply. Today I double-checked whether the problem is still there with the latest version of TrueCrypt (7.1a): Yes, it is! In case anyone wonders: I am using Mac OS X 10.6.8.