I evaluated the MDaemon v9.7.2 mailserver, and I must say that it's quite complex to get it to run... my way.
It's quite common to separate the program and the data. So, I tried to put the data on a different disk. This isn't done by using the GUI, but you need to edit the
Mdaemon.ini file in the
App directory (not every directory can be changed by the GUI). After changing the defaults, the MultiPOP feature didn't work. It seems there's another config file for remote mail stuff. This file (
schedule.dat) needs to reference the same location as the
Mdaemon.ini file. Why is that? Why use two config files for one program? And why use a different extension (.dat versus .ini)? Beats me.
For a mailserver that pretends to be a fair, and relatively
simple alternative to the over-powered and over-featured Microsoft Exchange mailserver you need a '
rocket science engineers degree' to get it to work properly.
The release of the beta
PGP v9.7 a couple of weeks ago, made me kinda curious if I had to pay for the new update. I bought v9.0 officially, and every update 'swallowed' my old license info. And what happend today, when I installed the newly released full version of
PGP 9.7 Desktop... It swallowed my old license.
B.t.w. the original purchase was for the Windows version of PGP, but the license also works on the OSX version of the software (it always did). So it's not necessary to buy a new license when you switch platforms.
There is a downside though; It's not possible to download a full version for the license holders. You need to download the
30-day trail version. And you'll only get it when using a valid e-mail address.
In the old days they had some restriction on how many times (and in what time frame) you used an e-mail address.
Major bummer: the sign and encrypt buttons are no longer available in the Apple mail.app. So you need to use the builtin PGP proxy. So basically, there is no way of manipulating single messages (other than using the clipboard). There is no need for me to sign every mail I send, nor is there the necessity of encrypting every mail I send to a certain person.
Having a day off from work meant that I had some time to clean-up my server from everything crap. This also meant trying to upgrade Coldfusion MX 7 to
Coldfusion 8. The new version supports some nice
new features, with which I wanted to experiment.
Since none of my production websites run on Coldfusion (currently PHP), I could safely uninstall and install the new developer version. When I pressed 'remove' I had this flash from the past. When I tried to install version 7 I had humongous problems with the installer (services didn't register correctly with IIS, etc.). But this could be just a coincidence...
Installing Coldfusion itself was straight-forward. The fun began when the installer wanted to launch the admin-panel to finalize the installation. No responds from the webserver. Even my blog was not working ("
System cannot find the file specified"). Seemed that there were references to the old Coldfusion parser in the IIS.. After removing those instances, I had my blog back up-and-running.
Next was to finalize the Coldfusion 8 installation. I had to manually add the Coldfusion parameters to IIS (allowed Web Services, document types, ... the works) After screwing around for nearly two hours, I could finish the installation.
Just to make sure that it wasn't me, I installed it also in a virtual machine. And off course it worked flawlessly. Guess I need to reinstall my server in the next couple of weeks. Who knows what else is f*cking up the system.
Oh, another thing; I used to use RDS for development of the websites, so I tried to configure it again.... Well you might guess it... Not working. After yet another hour searching I found that RDS uses a '
virtual file' called '
ide.cfm'. This file is located in
/CFIDE/main/. The actual location (
main/) doesn't exist, so IIS returns a 404 error.
It seems that you need to uncheck '
Verify if file exists' in IIS for the .cfm extension for RDS to work. Or do as I did; create the directory '
main' and create an empty file called
ide.cfm in that directory.
Well, this was an afternoon well spent.... NOT.
Next mission is to upgrade MySQL to version 5. So expect some serious downtime.
UPDATE: MySQL has also been upgraded to v5.something. It went surprisingly easy.
Since the upgrade to OSX Leopard, I've not been able to use PGP, since it simple won't work. Yesterday I received an e-mail that the
public beta of PGP 9.7 has been released (for Windows and OSX). This one does work on Leopard (until December this year though), so I guess that I need to BUY myself yet another version of PGP.
I found one 'bug' in the meantime; I seem to be missing the encrypt and sign buttons in the OSX Mail app. Or I might be missing something? I don't want to use the PGP service which signs or encrypts everything. I want to sign and/or encrypt when I want to, and not when an app tells me to.
It seems that Gmail is going to
enable IMAP support for their free mail service.
The gmail application for mobile devices is nice, but it IMAP is nicer to have.
It seems that the IMAP option isn't available on my account (yet). Guess I have to wait a little longer.
A while ago I cataloged my photo's in
iView Media Pro (now property of
Microsoft). It took me hours to do this, and it still needed some finetuning.
Somewhere along the line, I decided to switch to
Adobe Lightroom for some weird reason. The actual importing of the photo's was quite easy, but somehow I wasn't able to import the metadata I had attached to the photo's. So this meant that I had to do this all over again. This time it took me hours without a couple of minutes. I did it a bit faster because of the more intuitive interface. Man, tagging sucks. I must remind myself to do this everytime I add new images.
Next time when I have an epiphany about changing image catalog/management tools I might want to read this as a discouragement.
B.t.w. the reason for changing from iView to Adobe was the better collaboration between the OSX and Windows versions. Somehow iView lacked this, even though it was available on both platforms. iView used absolute path to the images in the catalogs. As far as I can see, Adobe uses relative paths if you exchange catalogs. Anyway I exported, and imported several catalogs between the platforms and so far everything worked.
BorderMaker is a tool for creating borders, watermarks etc on digital images. The nice part is that it comes in a Windows version (written in Java) and a cross-platform version (JAR file). It's a pretty versatile tool and it's for free :).
The cross-platform version works on Apple OSX, but has the limitation that the EXIF information gets lost. On Windows the supplied
jhead.exe program works without any problems. On OSX, the .exe file (obviously) won't work. Thankfully, there is a
OSX compiled version available. The program (jhead) itself works like a charm, but won't work from the BorderMaker interface (under OSX).
./jhead -te "${src_file}" "${dest_file}"
The parameters ${src_file} and ${dest_file} generate errors. When the command is executed from the command line, everything works (with the variables substituted with the real filenames).
Currently I use a workaround on OSX by executing jhead after I have created the 'bordered' images wit the command
explained on the jhead website;
jhead -te "originals\&i" *.jpg
Back in the old days, when I was struggling on the Windows platform, I used Nikon Camera Control with my nikon D100. Great tool for experimenting. Downside was that the D100 had a USB 1.0 interface, so it took forever to download the images.
During the transition to the Mac I found the OSX version, but it was only available for the PowerPC platform.... until recently. Version 1.3.x is Intel compatible, so now I can unleash the tool on my MacBook Pro.
Note: v1.0 installs on an Intel Mac, but it DOESN'T run. You need to upgrade it before you run it.
Too bad though that the D200 doesn't have a
LiveView kinda feature.
Oke, the first annoyance about the Nokia E61 is a fact. Well, actually it's about the Nokia PC Suite with which you can connect the phone to your (Windows) PC.
Somehow my Nokia E61i wouldn't connect using bluetooth with the Nokia Software. It could connect to the PC itself, but the Nokia software didn't want to 'see' the phone.
So I tried to remove the pairing between de two devices (which seemed to work). After that I tried to pair the two devices again... That's were the trouble started.
The software did see the phone via bluetooth, but it gave an error when I wanted to connect. The error said 'Cannot Authorize Phone'. Connecting via the USB cable worked fine.
I tried rebooting the PC and the phone several times, but the error persisted. Finally I removed the software from the PC and reinstalled it. Same error occured :mad: .
This was the point when I seriously thought about going back to a Windows Mobile device. There was one more thing I might try, and that was going through the registry of the PC and remove EVERY reference to Nokia. I first uninstalled the software and afterwards I removed everything Nokia-related in the registry.
After a reboot I reinstalled the Nokia PC Suite software, and everything worked fine.
This proves that Nokia software is as buggy as Microsoft software.
How hard is it for a piece of software/developer to remove all references to the software when you remove it? (rhetorical question)
