Attempting To Try Out Mindquarry

I’ve been interested in Mindquarry for a while now, so when they finally released a version you could download I headed straight over and grabbed a copy. Sadly, the copy I grabbed, advertised as for OS X, is actually a generic package for which there are no installation instructions. The instructions that are provided for installing Mindquarry all talk about executing ./bin/mindquarry – which would be good if there were a ./bin in the generic package.

Not to be deterred, I set up a Linux installation (Debian testing) in a VM and grabbed the Linux bundle. It has a ./bin directory and executing ./bin/mindquarry says it’s starting mindquarry which is good. I can’t find an open port anywhere on the system to actually use the system but I can start it up and shut it down again successfully. The logs by the way are empty.

So attempt number 3, probably should read the entire installation guide and follow every step. Install and configure apache, subversion, mod_perl, mod_dav etc. I swear I followed every instruction to the letter. Now I still don’t know where the heck Mindquarry is running but when I go to http://localhost/ (or using the DNS name or any other way I can think of to get to the server) instead of the Apache 2 “It Works” page, I get a 403 Forbidden. The logs of course are still empty, except for Apache’s endless drone in the logs showing that it is in fact forbidden for me to access my own web server.

There’s probably a very simple explanation for all this, but without anything actually printing to the logs I’ve got no chance of finding it. I really want this software to work, it sounds really cool, it sounds like something that could really help out a new team that’s about to start, but this is ridiculous! Can we please, please do just a few simple things that should avoid these kinds of problems:

1. Include the installation requirements, specifically tailored for the particular package, in the package itself. The Windows package should only contain Windows installation instructions, the Linux one only Linux instructions etc.
2. Include even a brief note on where the heck the server is going to be running when I start it. A getting started guide would be better, but I’ll settle for a simple port number.
3. Write something to the logs. If there’s a permissions problem and you can’t write to the logs, write to the console when the server starts up. The logs should tell me whether or not the server started successfully at the bare minimum. If it does start it should tell me what ports it’s listening on or what URLs it thinks I should use.

I saw somewhere (I think it was the installation guide) that there will eventually be prebuilt packages for various systems – I guess I’ll just have to wait for those.