So Sun has been doing this ‘Try-and-Buy’ thing with their new T1-based Sun Fire T2000 server. Which means that you get to try for two months, a machine with up to an 8-core UltraSPARC T1, 16G of RAM and 2 73GB harddrives, for free.

A dead frog could have known I’d go out and get one.

I figured I wouldn’t max it out– I’d get the 8GB version with 8 cores. First application was denied, but the second went through amazingly quickly. I’ve heard about people having to wait weeks. It took about two days for the application to be accepted, and three more for delivery. I was definitely impressed at the speed of that.

So anyway, it came:

Pretty, isn’t it? I think it rivals Apple’s Xserve. The inside is clean as a clean thing, too. No picture of that, unfortunately, but again it rivals Apple’s Xserve.

Of course I had to try it out as soon as I had the chance. It came very well-wrapped. The unwrapping process took about 10 minutes, I think. Great care was given to even the simplest of parts. For instance, the two power cords (the thing has redundant powersupplies) came in two separate boxes, packed together in another box, shipped separately from the server itself.

Then the time came to plug it in. That’s where the trouble started: the machine doesn’t do any video-output at all. I know it’s not really necessary for a server box to have the latest and greatest in video acceleration hardware, but a most servers come with a MACH64 of some kind onboard so you can at least get up a text console without hassle. Not the Sun– it requires that you have a computer available with a serial connection. That’s all fine with me, I have such stuff anyway. But the serial connection for this uses an RJ-45 connector instead of the standard DB-9 one. And the only adapter I had for that didn’t seem to be the right one. Luckily I was able to fabricate my own:

Tip to Sun: for just that extra bit of customer satisfaction, send along this sort of adapter.

Once I had that going, setting up was a breeze. Solaris 10 came preinstalled, so all I had to do was answer some questions about the setup through the insanely slow serial connection (maybe I should have set up the network management before booting…) and it was up and running. Loudly, I might add. It makes more noise than a redundant array of vaccuum cleaners.

I’ll be running some benches on it, notably in serving anyMeta pages and doing database serving. Maybe I’ll try to get Linux going on it. It’ll also be interesting to see what the 2.5″ 10K rpm drives can do, speed-wise.

I just wanted to give this idea some exposure: a World-Wide Photobooth, because I think it is brilliant and I should have come up with it myself.

I’d like to add that I believe there are actually automator actions for uploading to flickr.com, and the watching of photos being taken can probably be done with Folder actions.

If only I had an iMac G5 to try it out with…

… when it’s broken.. Bleh.

Somehow, three of my libraries and a lot of System Frameworks got zeroed out. (Tip: when that dialog comes up warning you of your almost full hard drive, do something about it.) Usually I’d just grab an OSX install dvd, do the brilliant Archive and Install and be done in 15 minutes. But of course the thing is nowhere to be found. So I had to fix it The Hard Way.

Scp stopped working because Kerberos was hosed, but luckily ftp did still work (even though libresolv was out, too). So I tediously ftped over a few files from another box such that scp would work again (the paths to the Frameworks are very long). After that I could copy over the rest with scp (with $(pwd) and proper tabbing available) for a couple of hours. Ugh. Some of my applications are still b0rked.

You’re the kind of person who forgets a lot of crap, and you’re looking for something to set Todo items in your iCal for you, while you’re somewhere without actual access to your iCal.

Look no more.

Apple Mail allows you to set Rules on incoming mail. It has the standard action stuff of course — move to folder, mark as junk, trash-because-I-don’t-like-this-person, etc. But also one action that allows for some really interesting stuff: Run Applescript.

So I figured I could use that for some simple remote Todo-ing, via e-mail. I can send those from my phone if need be.

Now, there are a few scripts out there that will do similar things. I found, however, that they’re all closed. No sources. For an applescript. They could be doing <i>anything</i> to your system, and you wouldn’t know it. You might find your entire home directory empty after sending three todos. So here’s an open one instead. It’s fairly small so I’ll just paste it:

tell application "Mail"
	-- What must the subject start with? This gets trimmed.
	set thePrefix to "TODO: "
	-- What calendar will we add the todo to?
	set theCalendar to "Home"

	set theMessages to (messages of inbox whose read status is false)

	repeat with mail in theMessages
		if the subject of the mail begins with thePrefix then
			set theSummary to trim_line(the subject of the mail, thePrefix) of me
			set theDescription to the content of the mail

			tell application "iCal"
				make new todo at the end of todos of (every calendar whose title = theCalendar) with properties {summary:theSummary, description:theDescription}
			end tell

			-- can't delete unread messages?
			set read status of the mail to true
			delete the mail
		end if
	end repeat
end tell

-- taken from apple.com and modified
on trim_line(this_text, trim_chars)
	set x to the length of the trim_chars
	repeat while this_text begins with the trim_chars
		try
			set this_text to characters (x + 1) thru -1 of this_text as string
		on error
			-- the text contains nothing but the trim characters
			return ""
		end try
	end repeat
	return this_text
end trim_line

Don’t you love how Applescript looks? Anyway, paste in Script Editor, compile, notice it looks even better with colour and indenting, save the resulting script somewhere sane, and make a new Rule in Mail to process e-mails. The minimum I would recommend is a subject check on it beginning with ‘TODO: ‘. Add other checks as you see fit. Last, set the action to ‘Run Applescript’ and point to the script (really? yes.)

Try it out and have fun.

People have been bitching lately about how Apple’s Aperture is crap and how they should have never bought it.

Now, these people definitely have a couple of good points. For instance, Apple’s engineers apparently didn’t think that being able to set curves was a necessity. I can tell you that it is. The levels tool (while more advanced than Photoshop’s) just doesn’t cut it. Also, its noise reduction is sort of weak and the sharpening needs more detailed control.

A lot of people have also complained about how ‘Aperture has a crappy raw importer’. This is where they’re just plain wrong: Aperture doesn’t have a raw (not an acro, no caps) importer. It uses a system library called ImageIO to do all the work of making the raw file into something aperture can use. ImageIO’s engine is by no means perfect. Reportedly, Apple is working that for OSX 10.4.4. I do hope they get it up to par because it doesn’t compare to my current favorite raw converter (Capture One). In other words: yes, it can be sub-par (it seems to depend heavily on the camera), but please don’t attribute it to Aperture, because it’s a flaw in the OSX libraries.

Next complaint: the Library. Again, some valid points. Not being able to use multiple drives is going to be a pain in the ass pretty quickly for professional photographers. But another often-heard complaint about it is how it’s a ‘proprietary format’. Those people need to get a clue about how Mac OS works. Since Mac OS 9, it has supported a concept called ‘Bundles’. Essentially just a folder with a bit flipped so that the finder will show it as a file. Meant to lessen file system clutter. Bundles weren’t used much in OS9, but they’re very common in OSX. Every (non-carbon) application you can find is actually a folder. Just like the Aperture Library. Control-click on it, select ‘Show package contents’, and you can browse it like any other.

My biggest gripe about the complaints is that damn near all of them fail to see that Aperture, in it’s version 1.0, has some very good ideas that aren’t available in any other application. Stacking is brilliant. So is the loupe. Granted, some other applications have something similar for the image you’re working on, but none will let the loupe work on the thumbnail in your file browser, except aperture. Full screen mode isn’t just a slide show like most other applications. It’s entirely possible to switch to full-screen mode and do all of your edits. Versioning is a concept previously unheard of in this type of application, yet apps working with raw files can be very easily architected to have such a feature, because the non-destructive editing is always required when working with raw files. And what other raw converter will allow you to make a book of your photos and have it professionally printed, without having to learn how to use applications like Quark XPress or Adobe Indesign?

All in all, people are forgetting the most important thing about Aperture: it’s only the first version. It hasn’t been (ab)used by the general public yet. I’m entirely sure most, if not all, of the common complaints will be fixed in the next version. I’ve heard say that Apple is already working on fixing the single-volume-library thing. Unfortunately, Aperture is too slow on my Mac mini, without support for CoreImage. But I do like how it works a lot, and I see a great future for it.

MacOS X 10.4.3 promised updated raw support for digital cameras. I happen to have one that can write raw files, but wasn’t recognised by 10.4.2 and earlier. I hoped the 10.4.3 update would fix this, since Apple has announced that Aperture, their upcoming photo editor app, would support the 350D.

I was, unfortunately, disappointed.

Well, the list of supported cameras says that Aperture would support the Digital Rebel XT. It’s essentially the same camera as the 350D, but named for an american market. So in most cases, 350D == Rebel XT. Not in this case, though.

I found this webpage, explaining how to make OSX like the 350D. Apparently, OSX determines support for CR2 files by the model name of the camera that it contains. So it now supports the Digital Rebel XT, but not the 350D (or the Kiss Digital N, the Japanese name for the same camera). This means support is easily added by editing the Property List file containing the definitions.

The page shows you how to fix it by duplicating the 300D’s info in a Raw.plist file, but doing it just like that causes images to be mostly very green. An addition was made to the page that is supposed to fix it by multiplying pixel values, but I find it’s too yellow because the multiplication values were taken from the info for a Compact Camera. They are very sensor-dependent, and there is absolutely no comparison between the 350D’s sensor (or any digital SLR’s, for that matter) and a compact camera. The real fix, making the images look just like they should, is to just multiply the Red and Blue pixel values by two.

So after you paste in the XML-snipped from the webpage referenced above, change the three lines that read ‘premul’ like so:

                <key>premul0</key> <real>2.00</real>
                <key>premul1</key> <real>1.00</real>
                <key>premul2</key> <real>2.00</real>

The technical background for this is that the sensor in the 350D (and other DSLRs) contain twice as many green pixels as they do red and blue ones. Apparently the sensors in compact cameras are different.

Update: yes, this makes Aperture work with the 350D, too.
Update again: MacOS X 10.4.4 includes built-in support for the Canon 350D and KISS Digital n.

I’ve been thinking lately about how my mail server should send me notifications of new mail, instead of having my client check every X minutes. I don’t think it can be done with IMAP (and I’m positive it can’t be done with POP) but after some tinkering I found a way: AppleScript.

Back in the days of Classic MacOS, Apple was nice enough to introduce Remote Applescripting. This meant that you could execute an applescript on machine A, and it would do stuff with machine B. The problem was that this only worked with AppleTalk, so not over the internet. Then came MacOS 9, which added support for remote apple-events over TCP/IP. This allowed people to do their applescripting not only with machines on the local network, but also with machines half the world away. Great, I can use that. MacOS X added another nicety to it: it supported all this not only over IPv4, but also with the next generation of the Internet Protocol, IPv6. I happen to be IPv6-enabled, so that was of great use to me.

So what did I set up? Well. My mail server is in Amsterdam, and it runs Communigate on Linux. That means no direct applescripting because, well, it’s just not available for anything other than OSX. Luckily, about 40cm higher up in the cabinet, there’s an Xserve. The Xserve, of course, runs OSX. But not the mail server. But that’s ok, because the Xserve is still a UNIX box so I can easily get to that from the Linux box. So on the XServe, I created an applescript application that does this:

tell application "Mail" of machine
               "eppc://marco:password@despina.v6.cyberhq.nl/"
        check for new mail
end tell

It’s simple, and it works. I’d use the keychain to store the password, except that doesn’t work if you aren’t logged in graphically. (Apple: fix that!). I saved this as a runnable application.

Then on the linux box, an equally simple shell script connects to the xserve and runs the applescript:

#!/bin/bash

ssh marco@xserve.mediamatic.nl 'sudo open /Users/marco/CheckMail.app'

You want to use RSA/DSA keys so it doesn’t ask for a password to get in. You also want to add yourself to /etc/sudoers to avoid that password-prompt too. All that’s left now is to instruct the mail server to execute that shell script whenever mail arrives. I did that by setting up a rule that matches anything except a certain mailing list.

Yes, ssh also works fine over IPv6 and I could have set the shell script to ssh to my machine and locally run the applescript. I didn’t because the xserve is more available (pretty much always) and I don’t want the mail server to get stuck up on a shell script waiting to time out.

We all know the trouble: today’s stupid ISPs will only give you one IP-address so to connect more than one computer, we need to use RFC 1918 IP-addresses, also known as private IP-addresses. This is all nice and dandy when all you’re doing is accessing servers on the internet from behind your router, which will inevitably use Network Address Translation (NAT) to allow you to do so. It’s an incredible headache if you want to go the other way around: set up a service on one of your machines that people on the internet will be able to access.

Luckily, we can forward ports. You can only forward a single port once though, so take into consideration what machine you’re forwarding to. You can’t have two forwards for port 25, for instance, unless they are on different IP addresses. (On a side note, if you’re forwarding webservers, use apache’s reverse proxy feature for that to allow multiple servers based on the URL).

In Linux, I would use iptables for this. Unfortunately the machine I want to forward a port on doesn’t run linux. It runs Mac OS X server. Given my knowledge of how this is done with the same tool as setting up a firewall in linux, I set out to do the same on osx and found that ipfw (the tool that manipulates firewall rules in BSDs and OSX) knows an action called ‘forward’. Hold it, that’s not it. That does forward, like it says. But it doesn’t do NAT. Which we want, because otherwise.. Well it just won’t work properly.

Connection sharing in BSD is handled using a userland process called ‘natd’. Incidentally, natd is also capable of properly forwarding ports to other machines. Great. Now let’s find out how. There isn’t much documentation on this, but I did figure it out eventually. This is OSX-specific, I must add.

Apple stores the configuration for natd in /etc/nat/natd.conf.apple. Don’t change that though, it’s generated every time natd starts. The basis for the generated file is in /etc/natd/natd.plist. Open that up. It’s a fairly standard XML file with some settings in it. Add the following to the end of it, just before the two last closing tags:

        <key>redirect_port</key>
        <array>
                <dict>
                        <key>aliasIP</key>
                        <string>INCOMING IP</string>
                        <key>aliasPortRange</key>
                        <string>INCOMING PORT</string>
                        <key>proto</key>
                        <string>tcp</string>
                        <key>targetIP</key>
                        <string>OUTGOING IP</string>
                        <key>targetPortRange</key>
                        <string>OUTGOING PORT</string>
                </dict>
        </array>

Replace the incoming and outgoing ips and ports with whatever your network requires. Incoming is the ip address on your server, target is the ip address of the machine you’re forwarding to.

You can now restart natd, for example by stopping and starting internet sharing. If all went well, your machine now forwards the port(s) you listed. Don’t forget to allow it in your firewall!

As a last note: this was tested and verified to work on MacOS X Server 10.3. It should also work on MacOS X Server 10.4. However, the configuration files do not seem to exist on the non-server version.

It apparently threw a tantrum over how hot it got in my room and refused to work. After a while of trying to get my dear data off it (after installing osx on a firewire disk and booting that, of course), the mini wouldn’t even recognise it anymore. I then decided to let the entire thing cool off for half an hour. This made it work again to at least the point where I could make a disk image of it. I didn’t trust it anymore though, so I opted to just go out and get a new drive. So now my Mac mini is fitted with a Western Digital Scorpio 80G drive instead of the usual Toshiba 80G. It’s a little faster, too.

I’ve begun moving over to WordPress. This means the end of my homebrew Zope stuff, which was basically only there to try out Zope. It just stuck a little longer than I expected. It also means I can finally ditch the UserModeLinux virtual machine running it.

Now, I’ve archived all the old stuff of course. Most links should still work. I have no clue how I’m going to make google like all this, but who cares. It’s still the old (table-based, ack!) layout, too. Either way, find it in the archive. (Some links to files and images are broken. Should you need one of them, just poke me).

I hope this will stick for a while. I might tweak the layout a bit more but the general idea should remain the same. Or at least similar. Or maybe not.