Rants And Raves

Bitter About Twitter

Karl von Laudermann — Sat, 17 Mar 2007 21:15:00 +0000

The Wall Stree Journal has an interesting article about the frustrations and annoyances experienced by users of the social networking site Twitter. This article confirms my suspicions about what it must be like to use this service, which is why I never had any interest in joining it or any other similar service. It serves as an anecdotal data point to help confirm a suspicion that I've long had: the popularity of social software that consists of one-way streams of information stems from the exhibitionists, not the voyeurs. In other words, everyone wants to be heard, but they don't realize that very few care what they have to say.

I first realized this several years ago when software and services that put a what-song-I'm-listening-to-now indicator on your web site became popular. I never understood the popularity of this concept. If you were to stream your music over the internet somehow so that I could tune in and listen, then I could see the value of that. Or if you're a friend of mine, a list of your favorite bands and albums might be interesting and allow me to get to know your tastes better. But why on earth should I care what happens to be playing in your personal music player right now? Especially since I don't know your opinion of it, or why its playing. For example, you could be listening to a streaming music feed over which you have no control of the content, so I don't even know for a fact that this is a song that you like, or will ever hear again.

Then I realized that these services were popular because the service itself is consumed by the person serving the information, not the person consuming the information. And the person serving the information doesn't realize that no one cares. Because clearly your taste in music is so great, and your life so interesting, that everyone really wants to know what song is playing in iTunes on your computer right now, right? Even though they can't tune in and listen along with you, they just really need to know!

So I had the same reaction when I first followed a link to the front page of Twitter. The description right at the top reads, "A global community of friends and strangers answering one simple question: What are you doing?" Well, I'm typing a blog post. And I just scratched my nose, because it itched. After posting this, I plan to go to the bathroom.

Did you really need to know that?

Daddy Needs an Open Vector Graphics File Format

Karl von Laudermann — Sat, 11 Nov 2006 04:00:00 +0000

Back in May of this year, Mark Pilgrim made waves in the Mac community when he announced that he had abandoned the Mac platform in favor of Linux. The reason he gave was that he no longer wanted to have all of his data locked up in proprietary, not publicly documented file formats. He wants to make sure that all of his data is stored in open standard file formats that he will be able to access forever into the future, and have a choice of what software to use to access it. Some responded to this by pointing out that he could simply switch to Mac applications that support open standards, and that switching platforms completely is overkill.

This got me thinking, and inspired me to do the same. No, not to switch away from the Mac platform, but to convert as much of my data as I could to open file formats. I have over ten years worth of documents stored on my machine, some of which are only readable by a single software product. And some of these products are at the end of their life, never to have another release again.

One such program is AppleWorks. I started using AppleWorks extensively about ten years ago (though back then it was called ClarisWorks), using it to create most of my text and graphics documents. Back then, it was an amazing program. Heck, in some ways it's still an amazing program. But it seriously started to show its age when Apple introduced Mac OS X. Even though they updated AppleWorks to be a fully native Mac OS X application, it never quite felt at home on the platform. And, of course, nothing else in the world can read AppleWorks documents. So it's definitely time for a change.

So, over the last several months, I've been slowly converting my AppleWorks documents to other formats. AppleWorks supports several types of documents: word processing, painting, drawing, database, and presentation. The first three of these are the types that I've primarily used it for. Finding another format for painting documents is easy, since AppleWorks can save to a number of other raster formats, and it's also easy to just copy and paste the finished painting into a program such as GraphicConverter and have access to even more formats. In fact, this is what I've generally done anyway. So I don't actually have any AppleWorks painting documents, as they've all been converted to .gif or .png files long ago.

By far, most of my AppleWorks files are word processing documents. So for these documents I needed to find a good, open styled text format. I had originally thought that the OpenDocument family of formats would be the holy grail of data interoperability. The OpenDocument formats were designed to be open standard replacements for Microsoft Office file formats, allowing office software, both open source and proprietary, from many different software vendors to be able to share data freely, and offer users real freedom of choice in office software. The OpenDocument formats were originally based on the native file formats of the OpenOffice.org office suite, but are now supported by other software packages as well, at least in theory.

So, at least for word processing documents, I figured that I would convert all of my AppleWorks documents to the OpenDocument Text format, by exporting them to RTF, importing them into NeoOffice, and saving them back out as .odt files. As it turns out, most of my word processing documents are simple enough that RTF itself is a good enough format, so for those I just stopped there. I can use Mac OS X's built in TextEdit program to edit them just fine. I only ended up converting a handful of the more complex documents to the .odt format.

This just leaves the AppleWorks drawing documents. And that's where it gets interesting.

As far as I can tell, there seem to be only two open standard vector graphics file formats: the OpenDocument Graphics format (.odg), and the Scalable Vector Graphics format (SVG). So I went looking for decent Mac graphics programs that could edit either of these formats, so I could settle on both a format that was likely to be widely supported in the future, and an application that was fully featured and very usable. The programs I tried were:

The aforementioned NeoOffice, which of course has a Drawing component that saves to .odg by default.
Inkscape, an open source, cross-platform vector graphics program that is quite fully featured. There is a Mac version, which requires X11 to run. Inkscape supports both SVG and .odg file formats.
Lineform, a recent release from the venerable Mac software house Freeverse. Lineform supports SVG.

As an aside, I will mention that even before I decided to convert my documents to open formats, I had already stopped using AppleWorks for new documents. As I said, it hasn't aged too well, and my biggest complaint about it is its complete lack of anti-aliasing. In this day and age, a vector-based circle should look smooth on screen, not pixelated and jagged. It was because of this that I purchased a copy of WouldjaDraw back in April, shortly after its first release. I also have Corel Painter, which I was using prior to that, but it's a very complex and heavyweight program, on par with Adobe Photoshop. So the point is that the ability to save to an open file format was not the only factor for consideration when evaluating the above programs. Aesthetics and ease of use are also important, because a file format is only as useful as the tools that can read and write it.

AppleWorks jagged circle vs. WouldjaDraw smoothed circle.

First I tried NeoOffice, with the OpenDocument Graphics format. As I said, I figured that the OpenDocument format was the best bet for long term accessibility. Unfortunately, the OpenOffice.org Drawing component fails on both the aesthetics and usability counts. Apparently graphics isn't the developers' forte. Or perhaps it was modeled after MS PowerPoint, since OpenOffice.org is basically a clone of MS Office. But whatever the reason, this thing is ugly as sin, and a pain to use.

First let's talk about its aesthetics. Smooth graphics? Not there, just like in AppleWorks. So that makes it unsuitable for on-screen graphics work, but still fine for documents that are meant to be printed. Which isn't much of a consolation, because I don't do much more printed graphics work than on-screen.

Then there's the ease of use thing. Doing something simple like creating a text object, moving it around, and then going back into it to edit the text was a frustrating experience. First of all, to change the font and size of a selected text object requires a trip to the Format->Character... dialog. The controls you need aren't front and center, in a handy palette or toolbar. The Drawing component of OpenOffice.org doesn't think it's a graphics editor; it thinks it's a word processor that happens to allow inserting graphical objects on the page. Second of all, I never did figure out a consistent pattern of clicks that would reliably cause it to put a cursor back into the text object for re-editing. I tried a single click, double click, triple click, click-pause-click, and preceding all of the above with a click or double click outside of the object to deselect it first. Ok, my experimentation wasn't really as exhaustive and meticulous as I make it sound. It was more like wildly clicking all over the place until the text object became editable, which seemingly occurred after a different pattern of clicks each time. This was enough to make me decide that this tool is basically unusable, and move on.

Next up was Inkscape. As I said above, this is an open source, cross-platform application that runs under X11. X11 apps tend to be very un-Mac-like, and open source projects tend to be very poor in the aesthetics and usability departments. So I was expecting an experience basically like the GIMP.

Boy, was I pleasantly surprised! Inkscape is a very powerful graphics program, with tons of features. I had little trouble finding the tools I needed when I needed them. It breaks convention with other graphics programs in terms of some of the UI controls, but in general if I took the time to look for what I needed, it was always right there, in a toolbar. And a lot of the UI was innovative, in a good way. The dialog box for aligning and distributing objects, for example, is top-notch, due to the sheer number of options it gives you, presented with intuitive icons.

Inkscape's "Align and Distribute" dialog.

Of course, being an X11 app, it looks and behaves like one. The font in its UI is tiny; it has a menu bar embedded in its window; clicking its icon in the Dock doesn't bring it to the front, but clicking the X11 icon does; and it uses Control instead of Command for all of its keyboard shortcuts.

So on to the main question: what about the file formats? Inkscape saves to SVG. By default, it saves to "Inkscape SVG" which has its own custom additions, to keep track of whatever metadata Inkscape needs. But it has an option to save to plain SVG as well.

Now, I had my doubts about SVG. Is it well specified enough to avoid different programs rendering the same document in different ways? Is SVG really a good working format, or was it indended merely as a final output format for web graphics?

It turns out that my fears were well-founded. I created a simple document, consisting of a rectangle, and two text objects. One text object used the font Bitstream Vera Sans, and the other used Helvetica. Bitstream Vera Sans is the default font Inkscape uses for text objects, and Helvetica seemed a good choice as a basic, reliable Mac font. I saved this to an SVG file. When I opened it in Camino and Firefox, the picture was mostly correct, but for some reason the Bitstream text showed up as italic, and the Helvetica text showed up as bold. Then I opened up the same document in Lineform. This was much worse: the Helvetica text didn't show up at all! Besides that, Bitstream text was tiny, and the rectangle was in completely the wrong place. So this lead me to conclude that SVG is not as portable as it needs to be in order to be my long term vector graphics file format of choice.

But wait, Inkscape can save to .odg as well! Perhaps I can choose that as my file format, while using Inkscape instead of NeoOffice as my editor? Unfortunately, no. I saved my test graphic to .odg format, and then opened it in NeoOffice. And it did not render correctly. First, the objecs were all grouped into a single object. This was easily fixed with the Ungroup command. Second, and more importantly, the text objects were invisible! This was easily fixed by changing their stroke setting, but come on now. Finally, I tried saving a document in landscape orientation, but it was in portrait orientation when opened in OpenOffice. This was easily fixed... ah screw it. If I have to fix everything after opening the file in another program, then it's not really portable.

So my next question was, will the .odg file show up properly when I re-open it in Inkscape? Guess what? It turns out that Inkscape can't read .odg files; it can only write them! Trying to open it yielded an error, using both the standard Open command and the Import command. So, using Inkscape for .odg files is a one way trip, and all subsequent edits would have to be done with OpenOffice, after fixing everything. So it's a no go.

Finally, there's Lineform. This $79.95 application supports "SVG for full document import/export" according to the web page, and has a demo version to boot. Well, I already told you what happened when I tried importing an SVG file saved by Inkscape into Lineform. But maybe the SVG that Lineform saves to is somehow more compatible, or more compliant with the SVG specification, and will be properly rendered in other programs? Well, it turns out that saving to SVG is one of the features that is disabled in the demo version. So I don't even get to evaluate the one feature that I'm considering the program for in the first place. I don't want to spend the money just to evaluate a feature, especially since I have reason to believe that it won't work properly anyway.

So, where do I stand now? Well, there are only two open standard vector graphic file formats that I know of, and neither of them are portable enough to rely on for long term maintainability. Are there any other formats I'm not aware of? Is the disparity between Inkscape's and OpenOffice.org's understanding of the .odg format the fault of the former or the latter, and if the former, is there a better tool than NeoOffice that can write (and read) it properly? I don't know. In the mean time, I'm redoing all of my AppleWorks drawing documents in WouldjaDraw, just so that I am no longer reliant on AppleWorks for accessing old documents. Unfortunately, I'm just saving these documents to WouldjaDraw's own proprietary file format, and WouldjaDraw doesn't export to any other vector graphics formats (unless you count PDF). So if I do eventually find a good open format to switch to, I'll have to redo these documents again.

And then there's Corel Painter. I have a bunch of documents in Painter's format, and these are the more complex ones, some of which took me hours to create, and some of which rely on Painter's more advanced features, which are unlikely to exist in any open source graphics program more lightweight and user friendly than the GIMP. So these may be forever locked up in Painter's format. However, Painter can export to the Photoshop file format, and this format might be enough of a de facto standard that lots of other programs can import it, so at least I may have a means of converting my Painter documents to other formats at some point in the future if I need to.

Daddy Needs A New Subversion GUI

Karl von Laudermann — Thu, 09 Mar 2006 04:25:00 +0000

I recently installed Subversion on my home computer, because a certain open source project with which I've been involved has switched from CVS to Subversion. Once I had Subversion installed, I decided it was finally time to do something that I'd been thinking about doing for a long time now: I created a repository locally on my machine so that I could gain the benefits of source control for my various hobby programs that I write in my spare time.

I then started importing all of my software projects into the repository, using the svn command line tool. Now, the command line is great and all... well, actually it isn't. At least from an ease of use perspective. The reason I own a Mac and prefer programs that are "Mac-like" isn't that I can't handle the command line, but rather that I don't want to have to.

At my workplace, where I have to use Windows, we use TortoiseSVN as our standard Subversion front end. TortoiseSVN adds a submenu, containing Subversion-related commands, to the Windows Explorer context menu. It also tags the icons of local files with overlays that indicate each file's status. So if you have a local working copy of a project, you can see at a glance which files have been modified, added, or deleted without a commit, and you can right-click on them to perform operations like diff, update, commit, etc. If you right-click in a folder that's not a working copy of a Subversion project, you still get a smaller submenu that allows you to import the folder or browse the repository.

The repository browser is particularly nice. It allows you to work directly with the files in the repository, such as moving, copying, and deleting files and folders, via context menus and drag-and-drop. In fact, all of TortoiseSVN's GUI windows are fairly well designed and handy. It even has graphical diff capability, allowing you to see your changes before you commit them, or to see what has changed between two different revisions of a file.

Unfortunately, TortoiseSVN is a Windows-only product. So I set about finding a Subversion GUI front end for Mac OS X. I found a handful of them, and tried them out, and unfortunately, none of them meet all of my needs. And I don't believe that my needs are very demanding. I need an easy to use, Mac-like program that will allow me to work with a local working copy of a project that's in a Subversion repository, and allow me to work directly within the repository itself. For working with local files, I need to:

Be able to import a new project into the repository, or checkout an existing project to a new location on disk.
Be able to determine which files have been changed locally.
Be able to determine what files have been added or deleted locally, and which of those files will and will not be added to/removed from the repository on the next commit.
Be able to update, commit, and revert easily.
Get a visual diff of files that have been changed and not yet committed.

For working with the repository, I need to:

Be able to move, copy, and delete files and folders within the repository.
See what has been changed by a particular commit.
Get a visual diff between two revisions of a particular file.

All of these tasks should be doable by pointing and clicking, dragging and dropping, and using contextual menus. None of the programs I've tried provide all of these features, and not all features that do exist are easy to work with. Here's a rundown of what programs are available, and my experiences with them.

JSVN

JSVN is a cross-platform SVN front end written in Java. It is currently at version 0.8. It is available in source form, or as a .jar file. After downloading the .jar file, I double-clicked it to launch it, and was greeted with the following error message:

The instructions on the web page say to launch the program by typing the following command on the command line:

java -jar jsvn-0.8.jar

Strangely, launching in this way worked, even though on a Mac double-clicking a .jar file is usually equivalent to executing this command. Anyway, once I got JSVN launched, I got a sparse window with which I couldn't do much of anything. The window has a menu bar, whose menus have a combined total of 5 menu items, including Exit and About. The Checkout command seemed promising, but seeing as how I already had everything checked out that I wanted to work with, I really just wanted to connect to an existing working folder, and was unsuccessful at achieving this. So, into the trash JSVN went.

Subcommander

It's probably only fair to mention that at one point I went frantically searching for a Subversion front end that could perform a particular task. You see, I had accidentally botched the import command at the command line, and checked in a bunch of files in the wrong place. So I was looking for a program that would allow me to browse the repository and easily move these files to a different folder, preferably by multiply selecting them and then dragging them to where I wanted them. Subcommander 0.15.0, which is a cross-platform (Windows/Mac/Linux) application written using the Qt library, did not fit the bill. While it was easy to figure out how to connect it to my repository and get a nice tree for browsing around in, the move function was nowhere to be found. Furthermore, the browsing functionality was a bit deficient. The repository was represented by a tree structure, where each folder had a disclosure triangle at the left side, similar to the Finder's list view. But if you double-clicked on a folder, the view would move to that folder, and there was absolutely no way I could find to go back up a level. So, Subcommander went bye-bye.

eSvn

eSvn is another cross-platform, Qt-based application, and is currently at version 0.6.8. By now you might be noticing a trend, in that none of the programs mentioned so far are at version 1.0 yet. Subversion is not that new, and you'd think there would be more finished front ends out there for it. The aforementioned TortoiseSVN is at version 1.3.2, for example. Why can't someone in the Mac space be that on the ball? Anyway, I must confess that I did not actually try this program. It was one of the first ones I downloaded, and knowing that I had a few more to choose from coming up, and assuming (wrongly) that there would be one or two real gems among them, I was more willing to dismiss applications for more trivial reasons. In this case, it was the simple fact that it was distributed as a .pkg installer. I have a general policy against .pkg installers if I'm downloading a program just to try out without knowing whether I'll want to keep it. This is because they could potentially put files anywhere on the system, and to uninstall the program you need to hunt down all the pieces and delete them. For applications, I much prefer the more common Mac way of distribution, which is simply the application file itself that you can just drag onto the hard drive wherever you want to, and just throw it in the trash to get rid of it. In the interest of fairness, I should give eSvn a shot when I'm more in the mood to deal with its installer.

SmartSVN

This brings us to SmartSVN. I had high hopes for this one. Not only is it made by the same company that makes SmartCVS, which is the CVS front end I ended up sticking with the last time I went through all of this, but it's even at version 1.1.8! Unfortunately, I wasn't able to get it to connect to my repository. Since my repository is located on the very machine that I'm using, and I don't intend for anyone but myself to use it, I have no reason to set up a server process for it. Thus, I connect to it using the file:// protocol. My attempts to connect SmartSVN to my repository using the file:// protocol were unsuccessful, and it subsequently occurred to me to check the SmartSVN FAQ. It turns out that the very first item in their five item FAQ says:

The file:// protocol is not supported, because it would be technically very difficult to implement and the svn:// protocol is a very simple to set up alternative.

Um, yeah. First of all, if the file:// protocol is so difficult to implement, how come all of the other programs I've tried support it? Plus, while I'm sure the svn:// protocol is relatively simple to set up for those who have sysadmin experience, it's something I'd rather not have to go through just to try out one particular application. It's kind of like the .pkg issue, but worse, since I'd then have a daemon running at all times that I don't even need, save for one application written by apparently lazy programmers. Listen, if I were willing to get my hands dirty with all of this UNIXy stuff, I wouldn't be looking for a GUI front end in the first place.

Besides, while the Subversion documentation is generally pretty good, they don't even get to the details about setting up and administering a repository until chapter 5. Everything before that assumes that you're just an end user connecting to an existing repository. Which I am, after having figured out and executed the one command necessary to create my repository. And that chapter isn't terribly easy for me to understand; it's obviously written towards people who have sysadmin experience, and know how to set up daemons and protocols and Apache servers.

So, for now, file:// is what I have available to me, so SmartSVN is out.

svnX

svnX 0.9.6.4 (getting close to a final version!) is a Mac OS X native application. It allows you to browse the repository, and manage local working copies. The interface is a little clunky. There's a window with a list of repositories, and a window with a list of working copies, and in both cases adding a new item to the list requires filling in a dialog box with path names; there's no drag-and-drop. But at least there's a standard file selector dialog for selecting the path of a working copy.

Once you have a repository in the list, you can double-click it to bring up the repository browser. It's not nearly as functional as the one in TortoiseSVN. Unfortunately, a painfully obvious theme throughout the program is the lack of context menus and drag-and-drop. Most operations involve selecting an item and then clicking a button or toolbar icon. Even the menus are sparse; there are no menu items corresponding to the toolbar items, which means that these commands lack keyboard shortcuts as well. So much for Mac-like.

However, svnX is the application I ended up using to move the files that I had accidentally imported to the wrong place. Too bad I couldn't just select them and then drag them to where I wanted. I instead selected them and clicked the "svn move" button in the toolbar... and was greeted by an error dialog telling me to "Please select exactly one item to move." Grrr. So I moved them one at a time. Admittedly, it was still better than having to use the command line and type all of those paths by hand.

As you can imagine, the window for managing a working copy is clunky as well, but functional. You can view the project folder either as a tree or a flat list, and when viewed as a flat list you can opt to hide all files that are unchanged. Adding, removing, committing, etc. involves selecting files and then clicking the appropriate command button. And multiple selection actually works in this case! Another neat thing is that svnX provides a visual diff between a changed local file and the repository version by handing off the job to Apple's FileMerge program, which comes with Apple's developer tools. Unfortunately, there seems to be no way to diff a local file against any version other than the latest, nor to diff two versions within the repository.

SCPlugin

Last, but not least, there's SCPlugin. This product is basically a sort of clone of TortoiseSVN, for Mac OS X. It puts a Subversion submenu in the Finder's contextual menu, and icon overlays on items in local working copies. Like eSvn, SCPlugin comes as a .pkg installer file. However, I was willing to install and try it anyway, for two reasons. First, by the time I got to SCPlugin, the pickings were slim, and I was getting desperate. Second, this software is not an application, but a set of plugins, which is exactly the type of thing you'd expect to be distributed as a .pkg file.

Since TortoiseSVN is so great, surely a clone of it must be nearly as good, right? Wrong. Where do I start? First of all, the latest news item on the web site, which is from December of 2004, states that the old code is being scrapped, and the next version of SCPlugin is being rewritten from scratch. The only binary distribution available for download is the last "old" version, which is version 269. (Wow, the higest version number of all the programs listed here!) Then there was installation. After installing the thing, it didn't work. No Subversion submenu in the Finder menu, no icon overlays in my Finder windows. So I had started hunting down and deleting all the pieces installed by the darn .pkg file, when I noticed that one of the pieces was a .prefPane file in the /Library/PreferencePanes directory. So I launched System Preferences, and sure enough there was an SCPlugin preference pane, in which I had to click a checkbox to enable it, and specify the path to the svn executable. Once I did this, the plugin worked.

Of course, there are problems. Strangely, the icon overlays don't always appear. When they're there, they're handy, but when they're absent it's annoying not to be able to see the state of the files. Another thing is that the contextual submenu doesn't contain as many items as in the screenshot on the SCPlugin web site. For example, there's no Import item for putting a new project folder into the repository. Finally, when invoking some menu commands, it presents a dialog requesting a user name and password, stating that the operation "may" require authentication. Like I said before, I'm using my repository locally, via the file:// protocol. I certainly haven't set up any user authentication, so I just leave the dialog blank and click OK. But SCPlugin doesn't remember that for the next time I invoke the command, so I have to dismiss the dialog every time.

Other features that I want, nay, need, are missing. There's no visual diff. When you invoke the diff command, all you get is a window containing the textual output of the svn diff command. In a proportional font, even. And there's no repository browser, which means no way to manage the files in the repository, nor to examine the changes made to a file between certain revisions. In short, SCPlugin does not come close to meeting all of the needs I outlined near the beginning of this post.

The Verdict

So, does this mean that I've thrown away all of the Subversion GUI front ends I've tried, in favor of sticking with the command line? Certainly not. For now, I'm keeping SCPlugin and svnX. The former is useful for some of the basic management of local working copies, and the latter is useful when I need to work in the repository itself. At some point, I'll probably give eSvn a try. The .pkg installer really isn't a huge deal, and if there's a chance that this might be the gem of a program that I've been looking for, it's worth a try. Maybe if I'm feeling really adventurous, I'll set up an svn server daemon to enable the svn:// protocol and give SmartSVN a try. But that seems far less likely. But anyway, aside from those two untried options, it seems that the current state of affairs for GUI front ends to Subversion for Mac OS X is really poor.

Free Toy Surprise

Karl von Laudermann — Fri, 23 Jun 2006 22:32:00 +0000

Some fast food restaurants offer a free prize with the purchase of a children's meal. Until this past Tuesday, I didn't realize that Subway was one of them. In fact, when I got my lunch from there, I didn't even get a children's meal. I just ordered the standard meal package, which adds a medium drink and a bag of chips to your sub order. So imagine my surprise when I got back to my office, took my food out of the bag, and found an extra gift. They gave me a knife!

Woohoo! Free knife!

Oddly, the knife doesn't appear to be new. It looks used, and rather beat up. In fact, the bits of food that were clinging to it when I got it seemed to indicate that it had been used very recently, perhaps to cut the very sandwich with which it was packaged. But hey, who am I to look a gift horse in the mouth? I mean, hey, free knife!

Don't Touch the Touch Screen

Karl von Laudermann — Sun, 08 Oct 2006 23:30:00 +0000

I finally broke down and bought myself a Nintendo DS Lite. As you know, the DS stands for "dual screen", as the the system has two screens, one of which is a touch screen.

Now, being an electronic device, it comes with instructions detailing exactly what you shouldn't do with it. And some of these points are unreasonably restrictive, so you just know that the device is expected to be used in a manner contrary to these instructions, and they're just covering themselves for legal purposes so no one can blame Nintendo when their device malfunctions due to normal use. For example, regarding the touch screen, the instructions state "...operate the screen by using the included stylus." and "Use only a Nintendo-licensed stylus on the Touch Screen." Yeah, like the stylus from my Palm PDA isn't safe for the oh-so-fragile touch screen on a device expected to be used by school kids.

Not only am I skeptical of the idea that only Nintendo-approved styli1 are appropriate, I question the idea that one is expected by Nintendo themselves to never use anything other than a stylus to operate the screen. Exhibit A: New Super Mario Brothers. In New Super Mario Brothers, if you get a power-up item while you already have one, this second power-up item goes into a reserve box which is displayed on the touch screen. If you want to use the reserve item, all you have to do is touch it on the screen, and it will appear near Mario, where he can then grab it. I want to point out two things here:

This is an action game. Sometimes you need the reserve power-up item right now, in the heat of the action. Pulling out the stylus from the holder just to perform a single tap would be mighty inconvenient.
The power-up item on the screen is just the right size to be pressed with your fingertip. It just beckons you to do so.

Now, being the paranoid sort that I am, I want to protect my $130.00 purchase. I've owned a Palm PDA of one sort or another for the last decade or so, and I've always made sure that the screen was protected from scratches by using a screen protector. For those not aware, a screen protector is basically just a clear plastic sticker that is slightly smaller than the size of the device's screen. The adhesive on the sticker is weak enough that it can be peeled off for replacement without risking damage to the screen in the process. After extensive use, I have seen my screen protectors acquire tons of small hairline scratches, and I'm always glad that it's not the screen itself getting scratched. I've even gotten into the habit of using a screen protector on my wristwatch, as I'm not always careful about what it bangs into. So, it seemed a good idea to use a screen protector on my DS.

Here's what Nintendo's instructions have to say about screen protectors:

If you use a screen protector on your Nintendo DS, use only a Nintendo-Licensed screen protector, and use it only on the Touch Screen.

Again, aparently not just any plastic sticker intended for touch screens will do. Anyhow, I went to my local Best Buy, where they didn't have any PDA screen protectors, but they did in fact have ones made for the Nintendo DS, made by Pelican. So I bought these.

First of all, it came with two protectors, one for the touch screen and one for the regular screen. Now, this contradicts the instructions from Nintendo quoted above. But that's okay, I had no intention of protecting the top screen anyway, since it's never going to be touched except for the occasional cleaning2. So, I proceeded to apply the touch screen protector, and found two problems. The first was that the sticker was exactly the same size as the screen itself, rather than being slightly smaller as I'm used to. This means that, due to the screen being recessed into its frame, it would be impossible to ever remove, since there's no margin in which to stick a fingernail. The second was that this screen protector was made of a rigid plastic, unlike the PDA protectors I'm used to which are very soft and flexible. Due to these two problems, I had a hard time getting it down onto the screen without getting air bubbles trapped underneath, or having the edges pop back up due to imprecise alignment. I never succeeded in getting it applied properly, and I'm actually glad, because I don't like the idea of never being able to remove it. So, I tossed it out. Boy, that was a waste of four dollars. Actually, it wasn't a complete waste, because the package also included a lint-free cloth for wiping the screens with. I'm keeping that.

I then went out to Staples and bought a pack of Belkin brand screen protectors for Palm PDAs, cut one to the correct size for the DS touch screen, and applied it. I'm happy with this solution, though despite the fact that I tried to be careful, and cleaned the screen before doing this, I managed to get a fairly noticable piece of dust trapped under the sticker near the bottom of the screen. But at least I can always peel it off and try another one; the package inclued 12 of them.

1. Yes, it's a word, look it up.
2. Using the fog-it-up-with-my-breath-then-wipe-it-with-a-tissue method.

How to Watch "War of the Worlds"

Karl von Laudermann — Sun, 31 Jul 2005 18:19:00 +0000

I recently saw Steven Spielberg's new film War of the Worlds. Overall, it was excellent. The visuals were incredible, without a hint that any of the elements were computer generated, though logically many of them had to have been. And I like how tension was maintained by having absolutely no background music during a lot of the more intense scenes. Heck, I can't remember now if there was any background music at all. All in all, it was everything that I had originally hoped Independence Day would be when I first heard of it. (Read my review to find out how bad I thought that film was.)

However, I'd heard that the very end of War of the Worlds is exceptionally lousy, and completely ruins everything that came before. In a War of the Worlds thread on a message board that I read, people were suggesting that one should walk out of the theater before the end. They said that one should walk out during the scene where a crowd of people are walking past a "Welcome to Boston" sign.

My girlfriend saw the movie before I did, but I told her about this piece of advice before she did. She didn't follow it, and thus unfortunately had to endure the ending. But she told me afterwards that, while the ending was awful, walking out at the aforementioned moment would have been too soon. The really bad part isn't until a few minutes after that.

So when she and I went to see it together, we walked out right after the scene where the military shoots down an alien tripod, and the door of the tripod opens, and an alien falls partway out and dies. So I haven't seen what happens after that.

And because of this (or so I hear, anyway), I can truly say that Spielberg's War of the Worlds is an excellent film.

Announcing Zendomizer for Handhelds 1.1

Karl von Laudermann — Sun, 01 Oct 2006 20:53:00 +0000

I recently got a new PDA, a Palm Tungsten E2, to replace my aging Handspring Visor Edge. I transferred all of my software from the old device to the new one, and in some cases upgraded to newer versions that took advantage of the higher resolution color screen. This included the SuperWaba runtime, which my Zendomizer for handhelds needs to run.

I was disappointed to discover that the Zendomizer did not work with the latest version of SuperWaba. So yesterday I finally got around to attempting to fix this. It turns out that at some point in the past three years the SuperWaba API changed in such a way that broke compatibility with the Zendomizer. I've fixed the problem, and it seems to run just fine on my PDA. So, if you have tried the Zendomizer for handhelds on your Palm or Pocket PC device and found it not working, please download version 1.1 and try it again.

Bertie Bott At The Jolly Ranch

Karl von Laudermann — Thu, 04 May 2006 22:44:00 +0000

In general, I like Jolly Rancher brand hard candies. However, next time I reach into the candy dish, I need to remember that their vomit-flavored candies are consistently mislabeled as "Apple". Perhaps I should write to the company and see if I can get them to fix the problem at the labelling plant once and for all.

Daddy Still Needs A New Subversion GUI

Karl von Laudermann — Thu, 23 Mar 2006 02:08:00 +0000

As I mentioned in my previous post, I'm looking for a GUI-based Subversion client that gives me a certain set of basic functionality necessary for managing my personal software projects. I tried a handful of programs, none of which met all of my needs. One that I didn't try was eSvn, only because it came as a .pkg installer, and I said that I would give it a try later. Well, that time is now. Also, I found a few other programs to try as well. So, let part 2 of my review of various Mac OS X Subversion GUI front-ends begin.

eSvn

Let's start with eSvn, since it's a holdover from the last review. After double-clicking the .pkg file to launch Apple's Installer program, I used the Show Files command to find out what files were going to be installed where, so that I could easily remove the program if it turned out to be yet another dud. And boy, did it. The "Read Me" that displayed in the installer window indicated that eSvn required me to have Qt/Mac 3.3 installed on my computer. I went ahead with the installation anyway, and sure enough the program wouldn't launch once it was installed. Having gone this far, I figured I might as well look into the possibility of downloading and installing Qt so that I could finally get eSvn running. The only URL that eSvn's "Read Me" document provided for Qt was for the main Trolltech page. So I visited the page and blundered around, looking for a runtime library to download.

I was completely unable to find such a thing. It quickly became clear that Qt, and likewise the web site for Qt, was geared toward developers rather than end users. Apparently developers are expected to build Qt into their own programs rather than make users install it separately as a library. So the only way to obtain Qt would be to download the actual development kit, and that costs money. There was a brief mention in the FAQ of the Qt Open Source Edition, which is free for use in open source software, but there was no link to more information about it.

So, once again I had to trash eSvn without actually getting to try it out. And this time, there's no "I'll try it sometime later". By not actually distributing Qt with their product, but rather expecting end users to install it themselves, the creators of eSvn really dropped the ball. It's just as well; from the screenshots on the eSvn web site, it is clear that eSvn fails to meet my needs, by lacking a visual diff feature. For if it had such a feature, surely this would be worth showcasing in a screenshot, whereas one of the screenshots instead shows a diff window containing the textual output of Subversion's diff command. Add to this the fact that the last stable version, 0.6.11, is from July of 2005, but the last version for which there's a Mac OS X distribution is 0.6.8 from January of 2005, and there's just not much promise there.

iSVN

Next up is iSVN version 0.9.5a2, which is a Mac-only program. Even though it's alpha software, it should be better than eSvn, since "i" is a whole four letters more than "e". iSVN is perhaps the most Mac-like program of the bunch, having both a standard Mac toolbar, and an item list pane on the left side of the main window, similar to such Apple programs as iTunes and Mail. This list pane is for local working copies; create a new item, choose a local folder that contains a Subversion working copy, and you can now manage that local copy. You can see what files have been modified or added, you can commit changes, and like svnX (covered in the previous post), it even integrates with Apple's FileMerge to provide visual diffs. And unlike svnX, there are contextual menus providing quick access to a number of tasks.

iSVN even has a feature to browse the repository, though the menu item is only enabled when you have an item selected in the working copy list. So presumably it only allows you to browse subprojects in the repository that correspond to working copies, rather than freely browse the entire repository tree. I say "presumably" because the feature doesn't work. In the browser window, where the file list should be, there is instead what looks like part of a Subversion error message.

iSVN holds a lot of promise, in part because the latest version is less than two weeks old, indicating active development. But it is unfortunately quite obviously alpha quality software. Some features don't work, some of my required features are missing, and some behaviors are quirky. So for now it is not a keeper. But it is definitely worth revisiting in a year or so to see if it has matured into what it shows the potential to be.

RapidSVN

RapidSVN 0.9.1 is a cross-platform program that uses wxWidgets. Though not as Mac-like as iSVN or svnX, its design is quite functional. It has a single main window with a tree pane on the left hand side. The root of the tree is called "Bookmarks", and can contain both repositories and working copies. Right-clicking the root item brings up a contextual menu that allows you to add either type of item, each of which itself will then be an expandable subtree. Clicking an item in the tree, which only shows folders, causes the folder's contents to be displayed in the main pane of the window. For working copies, these items show their state, such as modified or not checked in, and a contextual menu provides commands for most operations.

This program also has a lot of promise; it looks like it has the potential to provide all of the desired features I listed in the previous post. But due to some non-Mac like behaviors, as well as some bugs and/or unimplemented features in this non-final release, this potential is not yet realized. For example, it provides a diff feature, both for comparing the working copy to the repository, and for comparing versions within the repository. Invoking the former causes the program to crash, while the latter simply fails more gracefully. Thus I didn't get to see whether the diff result is visual or textual. Also, the dialog for comparing versions within the repository provides controls for selecting which versions to compare, either by revision or by date, but these controls are completely non-functional, thus only allowing you to compare HEAD with HEAD. Drag-and-drop is not supported, so for example the "move" operation within a repository requires you to type in the path to the destination. Other less critical but annoying quirks include the fact that many item names in the tree appear munged, and the fact that right-clicking an item in the main pane does not first select it. The latter behavior means that you must click to select the desired item, and then right-click it to bring up the menu, or else the selected menu command will fail to operate on the desired item.

Like iSVN, this is another one to keep an eye on.

svn-up

Finally, we come to svn-up version 0.8.0. This is a cross-platform program, written in Java. Actually, its primary purpose seems to be as a plug-in for the Idea IDE, but it is also distributed as a standalone application in the form of a .jar file.

Getting this thing to launch was no mean feat. Double-clicking the .jar file resulted in an error dialog from the OS's Java Launcher, telling me to check the Console for error messages. Doing so revealed the error:

Exception in thread "main" java.lang.NoClassDefFoundError: org/tigris/subversion/javahl/SVNClientInterface

Luckily, I remembered that when I installed Subversion, it also installed the file /usr/local/lib/svn-javahl/svn-javahl.jar. So all I had to do was run:

java -cp /usr/local/lib/svn-javahl/svn-javahl.jar -jar svnup-0.8.0.jar

...which resulted in the same error as before. So I dug into the svnup-0.8.0.jar file itself, and looked at the manifest file, and saw that it was looking for a file called svnjavahl.jar (note the lack of a "-"). So I copied the svn-javahl.jar file into the same directory as svnup-0.8.0.jar, renamed it to svnjavahl.jar, and double-clicked svnup-0.8.0.jar to launch it. Success!

You know, these reviews of products that I'm able to quickly determine I'm not going to keep are becoming tiresome to write. So, suffice it to say that svn-up is an incomplete alpha-quality program, its UI is quite awkward in several places, its repository browser has hardly any functionality, it's not very Mac-like, and it probably also hates kittens.

The Verdict

What a waste of my time. I decided to do a part 2 of my review because I wanted to give eSvn a fair shake, and I managed to find a few other programs that I had missed the last time. Turns out that eSvn was a non-starter after all, and none of the others are currently keepers. So basically I'm still sticking with SCPlugin and svnX.

I've visited the SmartSVN web site again since my previous review, and it looks very promising, based on the feature list and the screenshots. This is not surprising, since it's the only one of the programs I've looked at that is commercial, and is at a release version. But as I mentioned in my first review, I can't use it until I have a server process set up so that I can access my repository using some protocol other than file://. And I don't know what that will involve, or how soon I will get around to trying to set it up. But it looks like it might be the right way to go.

Update Available, Shmupdate Shmavailable

Karl von Laudermann — Thu, 05 Jan 2006 02:40:00 +0000

It seems these days that more and more software comes with a feature that will automatically check whether a newer version of itself is available for download, and if there is, "helpfully" inform the user. Frankly, I find this behavior annoying. When I launch a program, it's to perform a task. I don't want it to throw a dialog in my face immediately after launching, interrupting my workflow and train of thought, to suggest I take a completely different course of action from that which I was anticipating. Such a course of action amounts to maintenance of my computer, and computer maintenance is something I do on my own time, when I'm in the mood for it. If a program is buggy, or lacks a feature that I expect will appear in the next version, or is simply a program that I use regularly and like to keep up to date on, I will check from time to time to see if a new version has been released. This is true for many programs. Though for some old standbys, I may not bother to check for updates much simply because the program already does everything I need in the way I'm used to, and thus it doesn't call attention to itself. For these programs I may be using a version that is over a year old.

For those programs that do check for updates, there is usually a preference to turn this behavior off, though it is on by default when you first install it. Sometimes a program that I've been using for a long time suddenly gains this "feature" in a new version (which I've successfully managed to acquire on my own initiative, thank you very much), and of course this new behavior is enabled by default. But it irritates me the first time I see that dreaded dialog, after having used the program for years over many versions without it having bugged me before. So then I have to go digging through the preferences to find the newly added one that will restore peace to my world.

One noteworthy offender is Acquisition, a Mac-native Gnutella client. I remember that in the early days of this program, new versions were released so frequently, especially compared to how infrequently I used it, that it would inform me of a new version literally every time I launched it, even if I had already acquired the latest version the last time I had used it. But somewhere along the way it must have gained the ability to turn off update checking, because it hasn't bugged me in a while. Or maybe it always had that option, but back in those days this feature was so rare that I always upgraded immediately whenever a program told me to.

An especially egregious offender is Firefox 1.5. By default, not only does Firefox check for updated versions, but now as of 1.5, upon finding one it will automatically download the update silently in the background, and then display a dialog informing you that it has done this! I guess the Firefox team has taken the old saying "It's easier to ask forgiveness than it is to get permission" to heart.

Firefox? More like Spyware-fox!

Finally, there's the Dashboard widget Flip Clock by Widget Machine. When you invoke the Dashboard, this widget will check for a new version, and upon finding one will display a distracting red banner in its upper right corner, as shown in the picture below. This banner includes an "X" button which will (temporarily) remove the banner, and an arrow button which will download the new version.

Flip Clock whining to be upgraded.

Wait, did I say "new" version? I meant old version. For you see, I'm using version 1.2 of Flip Clock, and clicking the download button in the banner causes it to retrieve version 1.1.3 of the widget. It turns out, however, that this isn't actually an older version of the software. Version 1.1.3 is actually newer than version 1.2. This can be verified by checking the creation dates. Apparently, the creators decided that the version numbers should decrease rather than increase. Assuming that this was a mistake, I emailed them about this, but have yet to receive a response.

Flip Clock version 1.1.3 was released five months after version 1.2.

Unfortunately, Flip Clock does not provide a preference for disabling the update check. Fortunately, Dashboard widgets are distributed in source code form. Thus, I dug into the code, and was able to fairly easily find the line that checks for an updated version, and comment it out. As a result, I no longer have to worry about Flip Clock bugging me when a new (lower version) release is available, and I am thus protected from the fateful day when the version number gets so low as to regress to prerelease form.

LOL Used To Mean Something

Karl von Laudermann — Thu, 08 Dec 2005 02:45:00 +0000

Back in the old days of the internet, the acronym "LOL" meant something. It stands for "Laughed Out Loud", and was used to indicate that the person using it did, in fact, laugh out loud upon reading another person's message. If you posted a humorous message to a Usenet group, and someone responded with LOL, you had the satisfaction of picturing that person sitting in a busy computer lab reading your post, starting to laugh audibly, and suddenly receiving puzzled stares from the other people in the lab.

But those days are gone. These days, people throw LOL around at the end of their own sentences or posts, basically using it as a smiley. But unlike a smiley, it is not intended in a friendly way. It is usually meant to indicate derision or smug self-superiority. When it appears in such a context, I have trouble believing that the person did actually laugh. It's more akin to simply saying "Ha! I laugh at you!" Which, of course, isn't actual laughter.

Back in the old days, we also had ROFL, but even then I don't think it was meant to be taken as a literally true description of the person's reaction. Especially when accompanied by the suffix MAO.

Sound/Sleep Bug Fixed

Karl von Laudermann — Fri, 04 Nov 2005 03:33:00 +0000

I mentioned in my first post that my brand new G5 running Tiger has a bug that manifests itself after a few hours or days of ordinary use. The symptoms are that all user interface sounds stop playing, and the machine will not go to sleep automatically. Since then, I have received a few emails here and there from people who have encountered the same problem and wondered if I had found a solution. So, I thought I'd post this update to say that I have not encountered the bug since adding more RAM to my machine a couple of weeks ago.

The machine came with 512 MB of RAM, and I knew I would eventually want to increase this. When I finally got around to doing so, I added a full 1 GB, for a total of 1.5 GB. Why do I need so much memory? Well, I probably don't. But this machine is one of those where RAM has to be installed in pairs, and it only has 4 DIMM slots total, two of which were taken up by the pre-installed RAM. I probably don't need more than 1 GB total, so I would have just bought an additional 512 MB, but whatever I bought was going to take up the only two free slots I had. So if I want to add more RAM again in the future, I will have to replace an existing DIMM pair with a larger set anyway. I figured it's better in the long run to buy that larger set now, and not waste the money on a set that will be eventually replaced. 1.5 GB is probably more than I will ever need, so I doubt I'll ever upgrade the RAM on this machine again.

So, the question is, why did increasing the machine's RAM fix the bug? Is this bug triggered by a low memory environment, and Tiger considers 512 MB low? Would adding only 256 MB of RAM have also fixed the bug? Or is it only fixed by adding so much RAM that the OS never even needs to use a swap file? If so, then this is not necessarily an optimal solution. The whole point of virtual memory is so that you don't need to have so much RAM, and a bug that consistently manifests its symptoms when virtual memory is used is thus a rather nasty bug indeed.

Anyway, I guess the point here is that if you've been thinking about increasing your computer's RAM, and you've been bitten by this bug as well, that's probably a good enough excuse to go ahead and do the upgrade.

I Got Tiger

Karl von Laudermann — Sat, 04 Jun 2005 18:08:00 +0000

I recently purchased a copy of Mac OS 10.4 Tiger. But rather than getting the $129 stand-alone package and installing it over Panther on my 6 year old Blue & White G3, I opted for the $2000 package in which Tiger is delivered preinstalled on the hard drive of a dual 2.0 GHz Power Mac G5.

This machine is amazingly fast compared to my previous one. Since both the machine and the OS are new, I have no idea how the OS itself compares to Panther. But using the G5 for the last couple of weeks has been an absolute joy.

...Except for a few problems. There's this weird bug I've encountered in which interface sound effects stop playing. In other words, there's no longer a sound effect when an item is moved to the Trash, or when the Trash is emptied. It's not a general audio problem, because I can still play music, watch video with sound, and play games with sound effects with no problem. It's just interface sound effects. And it's not just the Finder, either. Mail doesn't play an alert when new mail is received.

The most disconcerting thing about this problem is that the only way to fix it seems to be to reboot the machine. I've been using OS X ever since 10.0, and I think that this is the first bug that I've seen that can be fixed by rebooting, but not by logging out and then logging back in.

I think that the bug might be triggered via Fast User Switching. Until I got the G5, I've been using OS X the way that I believe Apple expects most home users to use it. There was only one account that had Administrator privileges, and it was also my personal account, which I used all the time. When I set up the G5, I decided to use a different approach, which I've heard recommended by others. I created an Administrator account that would only be used when it was needed, and a personal account which does not have Administrator privileges. So while migrating software from my old machine to the new one, I was switching between both accounts frequently. I believe that this somehow causes the sound bug.

I've seen another problem as well, which so far seems to coincide with the sound problem, so I can only assume that they are two symptoms of the same underlying cause. When the interface sounds don't play, the machine also won't go to sleep. At least, not on its own; I can put it to sleep manually just fine. But I have it set to sleep automatically via the Energy Saver panel, and it won't do so when the bug is in effect. Again, both problems are fixed after a reboot.

Shadows of Doom

Karl von Laudermann — Tue, 27 Sep 2005 03:08:00 +0000

By now the game Doom 3 is old news to most PC gamers. But since my primary gaming platform is a Playstation 2, and my computer is a Mac, it wasn't until the Doom 3 Demo for Mac was released that I had a chance to try the game out. (I once played for a few minutes on a friend's X-Box, but that wasn't enough to get a well-informed opinion.) So, I played the demo for an hour or so to see what the game is like. The verdict? Doom 3 is dark. Really dark. You just won't believe how vastly, hugely, mind-bogglingly dark it is. You might think that the back of your bedroom closet during nighttime is dark, but that's just peanuts to Doom 3.

Now, I'm not talking about the atmosphere, or the theme; I'm talking about the graphics, i. e. the color palette. And that's a problem. I realize that the purpose of making the game dark, with a lot of shadows and dark corners, was to make the game creepy, and to increase the player's sense of tension and foreboding. The point is to put you in the proper state of mind so that you'll jump out of your seat when a monster suddenly pops up out of nowhere. But that's not the effect it had on me. All it did was make me frustrated and angry.

The problem is that you just can't see where you're going. Simply navigating a room is much more difficult than it should be. I should be able to just walk from one end of a room to the other and find the door that I have to go through, but this was a tedious ordeal, and I would often get lost or turned around and find myself inadvertently retracing my steps. And I'm not talking about trying to do this while running around fighting monsters. I'm talking about the beginning of the game, before any monsters show up, when I'm just supposed to be reporting to my commanding officer and getting my gear.

Here are some unretouched screenshots I took while playing (click to enlarge):

See that narrow catwalk I'm walking on? Me neither.

A typical room.

In the preferences screen, you can adjust the brightness. But even turning the brighness all the way up doesn't help, because that just makes the lights and other bright objects too bright, without brightening the dark areas at all. So you're effectively adjusting the contrast, rather than the overall screen brightness.

One item you have in your inventory is a flashlight, for use in "dark areas". At one point in the game, near the beginning when you're still learning things, the lights go out, and a message pops up on the screen telling you to use your flashlight. This is obviously done just as a tutorial, to give you an example of when you'd need the flashlight. The funny thing is, by that point I had already figured out how to use the flashlight, because I needed it long before then. Even later in the game, when there were actually monsters running around for me to shoot, I often kept my flashlight on while walking around. Then when a monster popped up, I quickly switched to my gun, shot the monster, then switched back to the flashlight. Clearly, this is sub-optimal from a survival standpoint.

And a word about the monsters. Having played the Doom board game, as well as having seen various promotional materials in print for Doom 3, I'd seen what a lot of the monsters look like. What struck me is how much originality and creativity went into the design of the monsters. It's just such a shame that in the computer game, because of the darkness, you can't actually see the monsters to appreciate this.

So, I've played enough of the demo of Doom 3 to know that I'm not interested in buying and playing the full game. But lest you think that I find nothing redeemable in the whole game, let me assure you that there is at least one bright spot (pun intended); and that is Super Turbo Turkey Puncher 3.

Get Your Rules Straight

Karl von Laudermann — Sat, 10 Sep 2005 19:10:00 +0000

I like board games. I also like game systems, i. e. sets of game components with which you can play multiple games. Although fancy, modern game systems such as Icehouse and the Piecepack are nice, old standbys such as an ordinary deck of playing cards or a set of dominoes have stood the test of time, and often allow one to enjoy playing games with people who aren't hardcore gamers.

The problem with these older game systems is that, with games having been passed down over time by word-of-mouth, and with games evolving as they spread from region to region, a single game often ends up with many subtle variations. If you ask a person to play a particular game with you, that person may say "Yes, I know how to play that game", but it turns out that the rules that you're familiar with differ slightly from the rules that the other person knows. So you have to negotiate on the finer points of the rules before you start playing. Or in the worst case, you don't negotiate on which rules to use until the differences arise during game play, by which point the two of you had already been making strategic decisions based on different rule sets.

When I learn a card game from a group of friends, I will usually take the time at some point afterwards to look up the rules in some sort of "official" reference. But there are multiple such references, and they do not always agree. For example, the rules for Gin Rummy as described at pagat.com differ slightly from those presented in Play According to Hoyle: Hoyle's Rules of Games in the area of scoring. Specifically, Hoyle specifies a Gin bonus and an undercut bonus of 25 points each, while the pagat page specifies a Gin bonus of 20 points and an undercut bonus of 10 points. The pagat page does, however, list the other option as one of several common variations.

However, I'd now like to turn your attention to dominoes. There is one dominoes game that I like in particular, in which a player scores points if, after playing a tile, the open ends of the structure all add up to a multiple of five. I have seen several names for this game, and several different variations as well. Let's take a tour, shall we?

The Game Cabinet calls this game Five-Up, but lists Muggins and All Fives as alternate names. It states that the start player is determined before the draw, and that the first double played is a "spinner", i. e. the ends can be built off of. It does not state whether the ends of the spinner are counted for scoring before they have been built off of.

The aforementioned Hoyle book calls this game Sniff, but uses the term "muggins" to refer to points scored. It states that the first player is determined by lot, independent of the draw. The first double played is a spinner, but can be played either endwise or crosswise; if played crosswise, the unsprouted sides do count for scoring.

The Domino Plaza has rules for Muggins, in which the start player is determined before the draw, and there is no spinner, thus the layout always has only two ends. This site also has rules for The All Five game, also known as All Fives or Five Up, which it states is the same as Muggins except that all doubles played are spinners.

The Macintosh shareware game Dominoes by Allgood Software has a game called Muggins, in which the start player is determined after the draw, based on whoever is holding the highest double. Also, the first double played is a spinner, but it behaves strangely. It is always played crosswise, but after its second side has sprouted, each of its ends does not count for scoring until sprouting.

Last but not least, the Puremco company's Domino Rules page has separate rules for six different such games (assuming I haven't missed any): All Fives, Five-Up, Merry-Go-Round, Muggins, Seven-Toed Pete, and Sniff. I'm not going to bother to list the differences among them and the ones listed above, but suffice it to say that they're all slight variants of the same game, and each one lists several variations of itself as well.

I'm going to assume for now that the Puremco site has the canonical versions of all the game rules, since it is the most comprehensive, and doesn't claim that any two games are exactly the same but with different names. The company also publishes a book, called Puremco's Great Book of Domino Games, which presumably contains all the same game rules as on their Domino Rules web page. However, I suspect that the content of this book is exactly the same as that of Great Book of Domino Games, considering that the title, author, and page count are the same, though the latter book's cover price is $3.00 less. I'm guessing that they bought the publishing rights to the book, and then rebranded it.

So, the next time I want to play a dominoes game with friends, in which a player scores when the ends of the structure add up to a multiple of five, which one will I suggest? I have no idea. The one I'm most used to is the one in the computer game, but the rules for counting the ends of the spinner for scoring are weird, and aren't the same as any of the other rule sets listed above. The Hoyle rules for Sniff allow you to have the same effect by playing the spinner endwise, but it's up to the player whether to do so.

Maybe I'll just go alphabetically, and choose All Fives. Using Puremco's rules, of course.