What's it all about, Alfie?

So this morning I got email from easyDNS about the new system they are now rolling out, and it got me thinking about my CVS repository at home, and wanted to check and make sure that the new system would work properly and that I had the right name on the CVSweb root page. So I got to the main page, and clicked into one of the projects and got an rlog error.

Crud.

I hadn't done a lot of checking on the site since I moved it from the old machine that died, and clearly, while the server and it's repositories was fine and intact, the same could not be said for the web access of same. So I had to go digging.

First thing was that I hadn't changed the name on the front page of CVSweb - that was easy and took only a minute. The rlog problem was a little different beast. Actually, it was a hold-over from the NT world where this perl script originally started.

The code I had originally was:

    if ($tag) {
        #can't use -r<tag> as - is allowed in tagnames, but misinterpreated by rlog
        open($fh, 'rlog "' . $filenames . '" 2>nul |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }
    else {
        open($fh, 'rlog -r "' . $filenames . '" 2>nul |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }

and I overlooked the obvious problem for about 10 mins until I realized that the redirection wasn't right. It's not trying to send it to a file, it's trying to dump it. So the correct code looks like:

    if ($tag) {
        #can't use -r<tag> as - is allowed in tagnames, but misinterpreated by rlog
        open($fh, 'rlog "' . $filenames . '" 2>/dev/null |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }
    else {
        open($fh, 'rlog -r "' . $filenames . '" 2>/dev/null |')
            || &fatal("500 Internal Error", "Failed to spawn GNU rlog");
    }

The great thing about Apache is that I found this by looking in the error log. It was telling me that it couldn't create the nul file - but rather than looking for permissions because this is a read-only CGI script, I knew then it was the /dev/null problem.

So... simple to solve and now I'm back in business. This server is backed up by a 1.5TB TimeMachine volume, so I'm not going to have to worry about losing these changes the next time the system dies. Whew!

This morning I was looking at all the latest updates to software projects on the Mac - like you do, and noticed BaseTen 1.8 was released. This looks interesting in that I'm a huge PostgreSQL fan, and using it in the context of CoreData would be very interesting.

So I was reading more into this and while it looks nice, I'm not sure in it's current version it's something I'm going to spend a lot of time with. There are a few things that bother me about it in it's current version:

• Not Really CoreData - it mentions CoreData-like semantics and APIs, but it's not really a PostgreSQL adaptor for CoreData. That was what I'd have expected as it would then have leveraged all of CoreData for a different database type.
• Using the GPL but Paid for Commercial Use - this is something I didn't think I'd see in a long time - the code is GPL, but to use it commercially you have to pay? That seems to fly in the face of the GPL for if you use GPL code, you have to stay GPL code, and you can't charge for it or lock it down. Very odd.
• Dodgey Code - when I started looking at the code I noticed that for GPL code, I was going to be spending a lot of time documenting this code as it was really pretty scarce. Not really my idea of "useful" code.

Maybe in later versions it'll have a true CoreData adapter, but maybe that's not what they are going for. We'll have to see. Interesting idea, anyway.

This morning I noticed that Apple had updated Java for Snow Leopard to 1.6.0_20 - which is a nice update given that I'm starting to get more serious about Clojure, and it's use of the JVM. While I don't think it's pushing the JVM, it's always nice to see improvements there.

Nothing special about the update - it's just moving up to what Sun (Oracle) releases. OK, good enough.

This morning I noticed that Acorn 2.3.1 was out and the release notes are clear and to the point:

• Fixed a bug where setting the DPI of a JPEG image wasn't always saved correctly.
• Fixed a bug where creating a guide with the contextual menu wouldn't always put it in the right location.
• Fixed a bug where some really old Acorn documents didn't import lines correctly.
• Fixed a bug where the layers lock icon was drawing incorrectly.

I use it almost daily, so it's nice to see things getting addressed. Great package.

This week marks the real beginning of the end for my work here at The Shop. Late Friday, I got word that my current CEO gave me his blessing to get an offer from another firm - a friendly one, and the Head of IT said that he'd be working on an offer letter for me. So this week I'm expecting some kind of letter which I'll respond to immediately and then put in my two-weeks notice here and work my way towards the new place.

It's nice to see a little progress on this front after so many weeks of interviewing with the new place, and talking about potential solutions to my reasons for leaving here. It's been very stressful. But hopefully now it's really starting to clear and I can see a little light at the end of the tunnel.

Lots more going on in my life these days, but one step at a time... one at a time.

They changed the designation of the Google Chrome (dev) stream from the 5.x to the 6.x stream today. I happened to notice when I decided to check for updates and there it was. Very interesting. I expect a big change on the "release" stream as well - jumping from 4.x to 5.x which would be a very welcome development for my work at The Shop.

Once again, the guys at Panic have updated Transmit to 4.0.4 with a series of fixes and improvements. It's taken the top spot away from Cyberduck for me. It's just incredible. Amazing work.

Just got a tweet from the Adium crew that 1.4b18 is out fixing Twitter support and Facebook authorization. I don't know that I'll use either of them, but there are a ton of other fixes to this release, and they say they are getting very close to a release for 1.4. Good enough.

Well... this morning I'm tinkering with Garbage Collection (GC) options for the JVM and I've seen two that look like they may have real promise to reduce these performance-robbing GC pauses in the current install on my development box. They are:

• -XX:+UseParallelGC - this guy is supposed to be a little more adaptive than the other, but it's got a limitation in that it can't function with some more advanced options. Alternatively, this guy is meant to work with very large heaps, which we have.
• -XX:+UseParNewGC - this guy is meant to be the successor to the other, and has no such limitations with more advanced features. The issue is whether or not it's really tuned to handle the larger Heaps, and if it's fixed algorithm is good enough.

What I'm hoping is just to get rid of the GC events where one CPU is pegged to 100% for more than a minute and everything else on the server just stops. If I can keep this guy running on a more even keel, it'll really help.

I'm running with the -XX:+UseParNewGC now and we'll see how it runs today. I can't believe it'll be worse, but the real question is will it remove the big pauses? We'll have to see.

UPDATE: I tried -XX:+UseParNewGC and I ran into the exact same issue. So I'm going to try -XX:+UseParallelGC and see if it's going to be any better. If not, I'll go back to the -XX:+UseParNewGC and see if I can try something else.

UPDATE: Yeah, the -XX:+UseParallelGC wasn't as good. I'm back to -XX:+UseParNewGC and Googling to see if there's something else I can try.

UPDATE: I saw this on Oracle's (Sun's) web site: it looks interesting:

  java -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=8 \
       -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31

with decent explanations of the options. The use of two different GCs is interesting, but they make the point that they are for different regions (young and tenured). Also, the target survivor ratio is at 90% - up from the default 50% making it more efficient on the long-term storage of which this app is heavily weighted.

More tests, hopefully these will look significantly better.

[5/14] UPDATE: In the end, the defaults were just as good, and while the memory footprint was a little bigger with the defaults, there were fewer pauses and the overall throughput of the application was better. In general, I guess they tune it about as well as it can be tuned. Shucks. But hey, it's "done", then.

Today I got a tweet that Transmit 4.0.3 was released, with a significant list of fixes and additions. It's really quite impressive, and love what they've done with it.