rant

Earlier this week I bought a printer for the new project I'm working on. A big, bad-ass OKI 9800 A3 color printer for the price of a small car -- not my money -- the client's money ;-).

Since we're a Mac-only shop here, I made sure it's got postscript3 and ethernet, so that connectivity wouldn't be a problem. Well, it was. Of course. Long story short: if we used the offical, OKI supplied PPD, the printer wouldn't print. It only could be coaxed into printing when using the generic postscript PPD -- which of course knew nothing about the A3 paper size or any of the other nifty features.

After spending three days(!) with the OKI hotline (spent mainly with re-stating our problem and configuration to various operators) I finally hit gold. In the form of a friendly, competent and female(!) operator (Hallo, Frau Walther!) who didn't just resort to OKI's ticket database but (gasp!) to her memory. She actually remembered a similar case a while back, told me to hold, came back 30 seconds later and ever since we're able to print here!

Turns out, that OKI has been delivering a faulty PPD - ever since march 2005! In the end it's just a single % character that's missing. I have to ask myself: WTF did they not update that file? Anyway, I'm posting this so that any other fellow OKI users can find this (because until now googling for the error Missing filter "application/vnd.cups-postscript 0 fierycupsfilter" didn't deliver any results. Hopefully, this will have changed).

Below you can find a diff of the the PPD or, for your convenience, you can download a patched version right here from tomster.org.

@@ -2947,5 +2947,5 @@

 *% PPD Last Modified 2005.03.10
 *% OS 10.2 PPD DB version 4/10/03 JDF
-*cupsFilter: "application/vnd.cups-postscript 0 fierycupsfilter"
+*% cupsFilter: "application/vnd.cups-postscript 0 fierycupsfilter"
 *% End of PPD file

Today I needed to make a fetchmail process automatically start on a Mac OS X Server instance.

Now, ever since Version 10.4 this is the domain of launchd. But compared to what I'm used to in FreeBSD, Apple's own introduction to launchd seemed rather daunting.

My reasong was something along the lines of "If I can't use something as straightforward as rc I might as well get out the big guns and use daemontools" (which already e.g. takes care of my IMAP Server and, of course, my name servers.)

Well, to make a long story short, once I got over the fact, that I need to write XML to configure startup items everything else went rather smoothly. In the end, to have fetchmail launched automatically at startup I needed the following markup in /Library/LaunchDaemons/fetchmail.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
    <key>GroupName</key>
    <string>staff</string>
    <key>KeepAlive</key>
    <true/>
    <key>Label</key>
    <string>fetchmail</string>
    <key>Program</key>
    <string>/usr/bin/fetchmail</string>
    <key>ProgramArguments</key>
    <array>
        <string>--fetchmailrc=/Users/diradmin/.fetchmailrc</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>Umask</key>
    <integer>7</integer>
    <key>UserName</key>
    <string>diradmin</string>
    <key>WorkingDirectory</key>
    <string>/Users/diradmin/</string>
</dict>
</plist>

(Since the fetchmail process won't be launched via a logged in user, I needed to point it explicitly to the config file I developed for it using the ProgramArguments key.)

Next, I needed to make sure that the abovementioned file had the right ownership and permissions:

sudo chown root:wheel /Library/LaunchDaemons/fetchmail.plist
sudo chmod 644 /Library/LaunchDaemons/fetchmail.plist

Unlike with rc or daemontools, however, just because I now had a perfectly fine config file sitting in its proper place didn't mean anything would happen next time the machine booted. No, I still needed to explicitly tell launchd to use this item using its companion launchctl command:

sudo launchctl load fetchmail.plist

To test the item I then proceeded to manually start it:

sudo launchctl start fetchmail

Note, that this time I didn't state fetchmail.plist as above but rather fetchmail, which refers to the Label key in the XML.

And sure enough, fetchmail was now up and running and was doing its thing. Since I had set KeepAlive to <true/> I could kill it and not even a second later, it was back up and running (with a new PID, of course). Nice. Just like daemontools.

While I'm glad that this all went rather smoothly for me I must say that I much prefer rc and daemontools, though. launchd seems over-engineered. I find that snippet above positively ugly. Even for XML. I mean, come on, what's this supposed to be: <key>RunAtLoad</key><true/>?

But to be fair, Apple specifically designed launchd to handle more than just start up items but to replace "init, rc, the init.d and rc.d scripts, SystemStarter (Mac OS X), inetd and xinetd, atd, crond and watchdogd", to quote its Wikipedia entry.

Anyway, from now on I'm probably just going to use the snippet above as boilerplate and get over with it ;-)

Oh, and Tim? Sorry about the XML bashing. I got nothing against XML per se. In fact I wouldn't know what to do without it. I just don't think it's a good choice for configuration files that are created and read by humans. (And perhaps, neither do you.) Even Zope is moving away from ZCML ;-)

I feel a bit like an journalist digging up stuff from the trenches and presenting it to a wider audience for evaluation (i.e. posting about portal_view_customizations) but there has been another topic lingering in the background and coming up now and again on several mailing lists. There is a sentiment (and lament) to it, similar to the TTW issue.

I noticed it first, when I released the first beta version of Quills 1.6") ca. one month ago. Being a "Plone 3.0 only" release, I had worked on it using a custom buildout configuration which was just fine and dandy... for me.

When releasing the beta I initially hadn't even included a tarball, instead (thinking I was making it easier for potential beta testers) I simply referred to aforementioned buildout and included even a handy one-liner that would get you going.

The sentiment I was following (unconsciously at the time) seems to be prevalent among other developers, namely that buildout is easy to use, even for end users. "I mean, c'mon, it's only one line of copy-and-paste... how hard can it be?!"

Well, that's certainly true, if viewed in isolation. But the truth is, as usual, far more complex. I received several questions (and even complaints) both on and off-list afterwards. Just as with the TTW story, there was this notion of "This used to be easier! Why are you developers forcing this complicated new stuff upon us? Sure, it may be easier for you, but what about us?" (I'm grossly paraphrasing here, mainly because I think these complaints are indeed very valid.) The issues that came up fell mainly into two categories: either buildout itself gave rise to trouble (Windows related or python related) or people wanted to test Quills in their existing setup and were left puzzled as how to achieve that.

Well, one reason is, that things have indeed become more complicated with Zope 3. Let's not mince words here:

What (error prone, hard-to-debug, rot-in-hell-evil) magic Zope 3 takes away from Zope 2 it has to make up with additional paperwork.

Namespace-packages, .zcml, .cfg, the whole "multicomponadapterfaces" shebang. While most of this is only of concern to developers (who mostly are eager to make that trade-off - believe me, once you got used to the 'new style' you don't ever want to go back) some of this (currently) also has repercussions for end-users and integrators. Packaging (finally coming back to the title of this post) being one of them.

Let's (continue to) take Quills as an example. This used to be just a bunch of ordinary 'capital-"P"-Products' that you downloaded as a bundle and popped into your Products folder - presto! Now it's made up of several components (5 products and 4 packages). From a developers point of view that is a good thing, as each component does less and is easier to debug and maintain. For an integrator its (again) just extra sit-ups: "What needs to be copied where? Do I need to copy the whole quills.core directory or just quills.core/quills/core?" etc. pp.

Personally, I've always found the "unpack it and stick it into Products" approach rather inelegant but most people have accepted this as the de facto method of distribution and installation of Plone add-ons. This tolerance might start to wear thin, though, now that it's basically coming to "unpack it and stick certain bits into Products and others into lib/python/ (wherever that is on your system, good luck with finding it...) and stick something called zcml-slugs into etc/site-packages".

Like with the TTW issue I'm just playing the messenger here, though. I just want to work on Plone features and cool Plone products that users out there (hopefully) will find useful... if they can be bothered to get them installed, that is...

It's not as if the designers of Zope 3's component architecture hadn't come up with a design solution to this mess, though. Their answer is: use eggs. That way end users and integrators just need to download a few zip files (and stick them into some 'magic' folders... sound familiar?).

The problem is, Plone won't be entirely eggified for quite some time, as I understand it. 'Old-Style' Products can't be eggified, either and not all Products can simply be converted into packages, etc. etc.

As I mentioned, tolerance is starting to wear thin, adoption of Plone 3 is being slowed down. Somebody needs to make sure that the new Zope 3 way of doing things is followed all the way through to the end user. Currently it's stuck somewhere at the developer's feet. This needs to change.

So, I'm afraid this might turn into some sort of 'signature ending' of mine, but I'm ending this post, too with... "Any takers?" ;-)

Man, I'm frustrated... while getting a client's project ready for deployment I noticed that performance on the production server was dismal and went about debugging when I realized that the CPU-hog wasn't the new project but... the Zope instance serving tomster.org...!

Its ZODB had grown to over 2.2Gb in size (eventhough the site doesn't contain more than ca. 300Mb actual data) and every click on it sent the CPU usage up to 100%. I decided to export the content and set up a new instance to alleviate the performance problem.

No dice! The attempt to export the plone instance to a .zexp causes the zope process to crash after ca. a minute. So does the attempt to compact the database. And... in the attempt to export each top-level folders of the site on its own so did the attempt to export my blog.

At the moment I don't have any time or energy to pursue the matter any further, as the aforementioned client project clearly takes prority.

At least now with the new instance the performance seems to be back to normal again...

Dammit! Half-assed generosity can be worse than no generosity… I guess over the past years many a closed-source software company has realized that they are faced with increasing competition from the open source market or simply want to gain karma points by handing out freebies. These usually come as dumbed-down versions of their flagship product. I think that’s totally legitimate and am grateful for that generosity. For instance, I’m a long year happy user of the lite version of XMLMind XMLEditor and NetNewsWire Lite - both excellent products that give me so much functionality in their lite versions that I don’t see any need to upgrade to the ‘pro’ version.

Enter Poseidon, a neato Java-based UML Editor and indispensable tool for anyone working with ArchGenXML. They too offer a lite version (dubbed ‘Community Edition’). But instead of just offering that version for download you need to register and apply for a ‘Community Licence’. That’s not too bad in itself, but get this - that free licence expires and needs to be renewed periodically… online, of course - duh!

Which this is why I’m sitting on a train and writing this stupid rant instead of debugging UML, because, of course, the license on my powerbook has expired and I’ve got no way to use Poseidon on this machine until I’m back online again.

So, to all Software companies out there: if you want to gain positive mind share with your freebies — offer them “no strings attached”, everything else will just backfire in the long run, trust me. Thanks for listening, I think my stop is next…