What's it all about, Alfie?

O happy days! Yesterday at WWDC in the Safari Series of talks, Apple announced that Safari 5.0 was going to be released, and this morning it has shown up in Software Updates! Fantastic news. The big improvements are in HTML 5 support, the Nitro Engine (JavaScript), adding the Bing search as an option, and probably biggest of all are the extensions.

Now you can write extensions in a manner similar to Firefox and Chrome. In fact, the talk had Cabel from Panic showing a new extension - Coda Notes, that allows you to 'mark up' a web page, and then send it all to an email address where the reader can see what you saw, and the marks you made. Very neat looking.

Well, it's great to see Safari keeping up with the improvements in Chrome. The competition is good for both.

Looks like Google is pushing their new WebM video support out a bit early. The most recent edition of Chrome 6.0.422.0 supposedly has the WebM codec for HTML5 built in. Very interesting. It's getting to be an interesting race now. Safari is still my favorite browser - period. But Chrome is really getting up there. It's got all the goodies that I need, and speed for JavaScript that's better than all but Safari.

Amazing improvements. Great work.

In a very interesting article from the Financial Times, it seems that Google's recent brush with the Chinese hackers that compromised their systems has left them looking for the real root causes of the incident. To that end, they have decided that it's Windows that is the security threat, not the people:

New hires are now given the option of using Apple’s Mac computers or PCs running the Linux operating system. “Linux is open source and we feel good about it,” said one employee. “Microsoft we don’t feel so good about.”

Indeed, the source points to the security (or lack thereof) of Windows as the primary reason:

In addition to being a semi-formal policy, employees themselves have grown more concerned about security since the China attacks. “Particularly since the China scare, a lot of people here are using Macs for security,” said one employee.

Interesting. It says a lot about Google that they don't go the "lock down" approach to the machines - they realize that people need to be able to do things on their machines in order to get work done. So rather than try to make Windows secure, it's easier to just ban it.

Amazing.

This morning I was going to check something into one of the projects I host on my CVS repository running on my home server. I had done the transfer when the old Mac died, and thought I had it all going, but clearly I was wrong. Today I found another issue.

What I saw was that when I went into a checked-out project and did a cvs update, I got a nasty error message:

  peabody{drbob}3: cvs update
  ? src/CKPropertyChangeEvent.h
  ? src/CKPropertyChangeListener.h
  ? src/CKPropertyChangeSupport.h
  cvs update: failed to create lock directory for `/usr/local/CVSroot/CKit'
  (/usr/local/CVSroot/CKit/#cvs.lock): Permission denied
  cvs update: failed to obtain dir lock in repository `/usr/local/CVSroot/CKit'
  cvs [update aborted]: read lock failed - giving up

Clearly, I'd missed something else. Now I had to find it.

On the server, I have the CVS pserver set up as described here. The missing thing in this description is the permissions. Those are pretty simple:

  $ cd /usr/local
  $ sudo chown -R root:wheel CVSroot

so that everything in the repository is owned by root and the group wheel. Easy. I also made sure that everything is group writeable so taht if a user is in the group wheel, they can update/change the projects in the repository. Then, the username and group in the launchd plist makes sense. The problem is, my new account wasn't in the wheel group.

Because the CVS passwd file has just my username and encoded password, I'm required by cvs to have a valid account on that server. I do, but I also need to be able to read/write to the CVSroot to do any real operations on the projects in the repository. What I failed to do was to insure that my account had access to the same group.

To find out the groups you're in, simply use id:

  $ id
  uid=501(drbob) gid=20(staff) groups=20(staff),204(_developer),100(_lpoperator),
  98(_lpadmin),80(admin),61(localaccounts),12(everyone),
  401(com.apple.access_screensharing),402(com.apple.sharepoint.group.1)

and it's pretty clear that wheel isn't in that list. So let's add it:

  $ sudo dscl . append /Groups/wheel GroupMembership drbob

and now id shows us what we need to see:

  $ id
  uid=501(drbob) gid=20(staff) groups=20(staff),204(_developer),100(_lpoperator),
  98(_lpadmin),80(admin),61(localaccounts),12(everyone),0(wheel),
  401(com.apple.access_screensharing),402(com.apple.sharepoint.group.1)

Yup, right there on the end of the second line is wheel. Now I can do cvs updates without a problem. Good enough.

I noticed this morning that while I was looking at a few houses with Liza, Google Chrome (dev) was updated to 6.0.408.1. That's a good jump as far as Google goes, and it'll be interesting to see what had changed in my daily usage. It's getting better and better, and pretty soon Safari is going to have to sit up and take notice.

This was an interesting bit of news today: Google is hosting web fonts now in their Google Font Directory - very interesting. The idea is that you go to this page, find a font you want to use by seeing how it's rendered in your browser, and then you get a line of HTML to download it, and you can then use it in your CSS as a font.

Impressive.

First, the preview tool is the browser - so you can actually see what you're going to be getting. Then, just as with the Google Visualization widgets, you have a single line to "import" the font, and then you're free to use it.

Clearly, they will see who's asking for what, and in doing that they are one step closer to world domination, but what the heck... It's a very nice way to preview the font for a web page, and then be able to be sure that your client will be able to see it in the way you wanted - regardless of what machine or fonts they have.

Very neat. I'm going to have to remember this.

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.

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.