The problem with photocasting

Lots of hay has been made this week over the Mac only nature of photocasting. Apple is being bashed from all sides for using photocasting as a marketing ploy for Safari. It seems, however, that a few relevant facts may be left out. Here's what I've been able to determine.

In addition to working with the Safari and iPhoto duo, photocasting also works well with Thunderbird on Windows and on both platforms Bloglines has no problem reading the feed and showing it.

Apple is checking for an RSS capable browser and if you don't have one you'll see a message suggesting Safari works well. What are they supposed to suggest instead? A competitor's product? Safari has some of the best river of news style RSS display of any browser on the market. Sure you can do the same thing with NetNewsWire but it eats CPU cycles and spits them out to get warmed up.

What is being overlooked is an interesting new setup. If you come to visit a feed with a non-feed reader why should I not set my web server to show you the content you will be able to see? Browser detection has been in use for years to accommodate mobile users with their WAP browsers. Why not do the same with web feeds on the desktop. Something to take a look at once the Drupal 4.7 release hits the streets.

Slowdowns using IRM on Safari

For the past few months we've been working with Information Resource Manager at work. It seems to be one of the best open source/freeware database managers for tracking assets and help desk functions for small teams. The lingering annoyance had been slow performance. The more I experimented it turned out the slow performance was only when using Safari/OS X. A quick trip to the /Applications/Utilites/Java/J2SE 5.0/ folder and opening up the Java Preferences allowed me to change the Java settings from 1.4.2 to J2SE 5.0 and all is well.

The latest release of IRM (Yesterday) adds some great functionality for moving printers and other non-computer assets into their own categories.

Mail Act-On a boon to getting organized

Without a doubt one of the greatest changes in the last decade has been the migration of e-mail from the realm of a small portion of the population to the pervasive force it is in our life today. Users of Apple's Mail application have a great tool available to help turn the mass flood of email into a manageable stream of information. Mail Act-On is a plugin that makes it possible to do any number of things to an email box with the press of a key (well two keys really).

In addition to the obvious things like highlighting email and doing things when email arrives in the inbox, Mail Act-On makes it easy to perform rule actions at a later time. I generally find two pairs of rules are quite useful. One pair files email in the archive - depending on which account it was sent to, and the other files them in an action folder, again depending upon which account they are in. This makes it easy to have a single inbox and to whip through the email while deciding whether something is to be replied to immediately and then archived, simply archived, or put into an action file for later follow-up.

Mail Act-On is a great tool for having an email box that is empty at the end of the day and being more productive while doing it.

Moving mailman from one server to another

Yesterday brought the much anticipated (dreaded) task of moving mailman from one server to another. The move was necessary to retire a FreeBSD server and consolidate services on a Mac OS X 10.4 Server box. There are good documents on the web about setting up mailman on OS X 10.4 Client but not as many on the setup of a standard mailman install on the server platform.

The first question that may jump out at folks is why? Mac OS X 10.4 Server comes with Mailman already installed. Why not use it? The installation included in OS X is highly customized in order to work with Apple's server administration tools. Also in my case I was moving a Mailman 2.1.6 installation on FreeBSD and the OS X Server version is still 2.1.5 (though it has been nearly six months since the release of the security patches in 2.16). Looking at the documentation there is little suggestion changes would have prevented the newer files from working but as a Nevadan I prefer the house's odds to those of the gambler.

Software Update problem not with DirecWay

After setting up a new iMac G5 recently there were a plethora of software updates to be downloaded. The problem is that after the first time where the update window showed two pages of available updates it subsequently refused to show any at all.

Thinking that the problem might have to do withDirecWay as the DirecWay XML-RPC does.

However, the fault seems to be with OS X instead. If there is a cache file in the following directory remove it and all should be well:



Subscribe to OS X