What's it all about, Alfie?

I just got a little pop-up saying that NetNewsWire had an update for me - to v3.1.7b4. Seems there was a problem at startup, and someone wanted to be able to execute Javascript for the given page from Obj-C. Nothing major, but nice to update in any case.

But after the update I noticed this same problem I've had for a while - every now and then, when refreshing the list of articles, the parser gets "stuck" on PHPmac.com and the "out of" number of RSS feeds climbs rapidly without bound. I typically just cancel the activity, and I'm OK. But I decided to check, and sure enough, the site is there, but I'm not allowed to see anything. I think this is what's causing the problem.

So... if I get time tomorrow I should send in a little bug to the developer and let him know what I've found. I'm not the only one, I'm sure, and it's probably a much larger issue of proper error handling.

[8/20 3:44am] UPDATE: I sent in the bug report. We'll see if they contact me, or an update appears to correct this in the next release.

The MacVim Team has cut Snapshot 34 that includes the ability to turn on/off the ATSUI renderer for the app. The ATSUI renderer is the Apple Type Services for Unicode Imaging system - basically, the (old) Apple way for rendering Unicode. It's supposed to be significantly faster for rendering text but in the past it's had the limitation that the mouse events simply weren't supported in the MacVim code. What's happened is they added a superclass that had all the standard mouse support and then sub-classed the standard renderer and the ATSUI renderer. I'm hoping that it's faster, but it's awfully fast already.

I'll be working with this guy for a while and trying to find any problems but it'll be nice if it's faster and not picking up any bugs.

UPDATE: interesting note: I read about ATSUI and it seems it's rather old (Mac OS 8.5) and has been replaced by Core Text in 10.5 (and beyond). So... while it seems we're one step up in MacVim, it seems it's come right at the time when it's really a generation behind. Shucks. We'll see what happens in the future with SubEthaEdit and BBEdit - see if they pick up on this.

My daughter is a huge fan of movie-making and her next foray is into the realm of green screen (or blue screen) movies. She's talking about getting a loft bed to make room in her bedroom to put up the screen. That's a clear vision, I have to say.

So I did a little digging and I have to say that there seems to be a lot of plugins for the older versions of iMovie - you take two clips, one that's the background, the other is the screened clip, and then layer the second on the first. It's a nice way of doing things, but as I've also found out, Final Cut Express ($199) does all this and a whole lot more. So that may explain why I haven't seen any plugins that have kept up with the latest iMovie.

Of these, she seems to be most interested in eZedia's eZeScreen plug-in for iMovie 6 (or later). It's a Universal Binary, and says it'll work with anything after iMovie 6, so we'll have to see what happens when we get the demo and try it out.

I've also seen Norrkross Movie, which is sort of an iMovie replacement, and it's not bad looking for $59. It's got all the things she's looking for, and is probably the place to start as it's a nice entry point for what she's doing. If she keeps up with this, Final Cut is a reasonable alternative, but it's after she's kept with it.

After I got the WebDAV server working on my OS X 10.4 machine, the next thing was to get SSL working with a self-signed certificate so that I could do secure WebDAV to the box. I've done this on Leopard (10.5) and so doing it on 10.4 was not too bad, but there were a few wrinkles.

First, follow the directions for creating the certificate files in this Mac OS X Hints hint. Don't mess with the httpf.conf file as we're going to do something a little more 10.5-like there. But make the cert, and the private key and the request and then sign it all.

Then in the /etc/httpd/users/ directory use the following file for ssl.conf - theirs is missing a few things.

  #
  # This is the SSL config goodies
  #
  LoadModule ssl_module         libexec/httpd/libssl.so
  AddModule mod_ssl.c

  <IfModule mod_ssl.c>
    Listen 80
    Listen 443
    # Some MIME-types for downloading Certificates and CRLs
    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl .crl

    # inintial Directives for SSL

    # enable SSLv3 but not SSLv2
    SSLProtocol all -SSLv2
    SSLPassPhraseDialog builtin
    SSLSessionCache dbm:/var/run/ssl_scache
    SSLSessionCacheTimeout 300
    SSLMutex file:/var/run/ssl_mutex
    SSLRandomSeed startup builtin
    SSLLog /var/log/httpd/ssl_engine_log            
    SSLLogLevel info

    <VirtualHost _default_:443>
      SSLEngine on
      DocumentRoot "/Library/WebServer/Documents"
      ServerName MACHINE
      ServerAdmin you@yourplace.com
      ErrorLog /var/log/httpd/error_log
      TransferLog /var/log/httpd/access_log

      SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
      SSLCertificateFile /Users/YOURNAME/Documents/certs/frosty/newcert.pem
      SSLCertificateKeyFile /Users/YOURNAME/Documents/certs/MACHINE/webserver.nopass.key
      SSLCACertificateFile /Users/YOURNAME/Documents/certs/demoCA/cacert.pem
      SSLCARevocationPath /Users/YOURNAME/Documents/certs/demoCA/crl

      <FilesMatch "\.(cgi|shtml|phtml|php)$">
        SSLOptions +StdEnvVars
      </FilesMatch>
      <Directory "/Library/WebServer/CGI-Executables">
        SSLOptions +StdEnvVars
      </Directory>

      # correction for browsers that don't always handle SSL connections well
      SetEnvIf User-Agent ".*MSIE.*" \
        nokeepalive ssl-unclean-shutdown \
        downgrade-1.0 force-response-1.0
    </VirtualHost>
  </IfModule>

Where YOURNAME is the login you put the certificates under, and MACHINE is the name of the machine directory that you put the specific certs in. It's pretty close to what he had, but there are a few differences and it's important differences.

With this, I have https: and WebDAV over SSL for the box. Nothing horribly hard about this, but it's nice to have it all working now. Just took a little time.

With all the interest in using WebDAV as a network storage protocol for things like dotMac and applications like Skitch, I wondered if it would be possible to get WebDAV working on my older Mac server sitting in my office at home. I have heard it's easy if you have 10.5 (Leopard) but I'm not really ready for that, and it was more for the interest of getting it going on the server and not for any real pressing need. If I had a pressing need, then I'd have it going on Leopard, as it's got everything ready to go. This was going to be interesting.

What I found was that there was a lot of people looking into this in the pre-10.5 days, and it wasn't really all that successful in the general sense. Several folks reported they got something working, but they had to disable all the security measures (like encrypted passwords) and that was simply unacceptable to me.

But I got it close working. The WebDAV service was running in the stock Apache from Apple, and I could get it to authenticate with security, and I even saw the files in the root of the WebDAV service. The problem was that I could not do anything with them. I ended up with complete WebDAV functionality.

I could not read them, or update them, or save files... it was like only a limited subset of the functionality I needed was in the WebDAV client that shipped with 10.4.x. And to that I guess I'm not terribly surprised. It would have been really nice, but I'm not surprised that in order to have this really work I'm going to have to be working with Apache2 and the WebDAV module there. [Really, it turned out to be a configuration problem that I really needed to look at the Apache logs to figure out. There was also a configuration problem on the client I was using (Cyberduck) and I needed to figure out the server before I could figure out the client. But I got both.]

But on the off-chance it's possible to get this finished, here's what I did. First, you need to edit the /etc/httpd/httpd.conf and where you see the lines:

  ...
  #LoadModule digest_module          libexec/httpd/mod_digest.so
  ...
  #LoadModule dav_module             libexec/httpd/libdav.so
  ...
  #AddModule mod_digest.c
  ...
  #AddModule mod_dav.c
  ...

edit them to remove the comments so that they become:

  ...
  LoadModule digest_module          libexec/httpd/mod_digest.so
  ...
  LoadModule dav_module             libexec/httpd/libdav.so
  ...
  AddModule mod_digest.c
  ...
  AddModule mod_dav.c
  ...

then, after the block of config that looks like this:

  <IfModule mod_dir.c>
      DirectoryIndex index.html index.htm index.php
  </IfModule>

add in the configuration for the WebDAV server component:

  #
  # This is for WebDAV
  #
  <IfModule mod_dav.c>
      DAVLockDB /Library/WebServer/WebDAV/Dav_lock
      Alias /webdav /usr/local/davroot
      DavMinTimeout 600
      <Directory /usr/local/davroot>
          Dav On
          AllowOverride None
          Options FollowSymLinks Indexes
          AuthType Digest
          AuthDigestFile /Library/WebServer/WebDAV.passwd
          AuthName "frosty"
          <LimitExcept GET HEAD OPTIONS>
              require user drbob
          </LimitExcept>
          <Limit GET HEAD OPTIONS>
              require valid-user
          </Limit>
      </Directory>
  </IfModule>

This ends the editing of the /etc/httpd/httpd.conf file, so you can save it. What will become important later is the location of the directories and files, and the AuthName as that will be used in the password creation command, below.

At this point, it's time to make the location of the 'root' of the WebDAV server. I've chose to hang it off /usr/local, but you can put it anywhere:

  cd /usr/local
  sudo mkdir davroot
  sudo chown -R www:www davroot

and we also need to make a place for the lock file:

  cd /Library/WebServer
  sudo mkdir WebDAV
  sudo touch WebDAV/Dav_lock
  sudo chown -R www:www WebDAV

We're getting close. The next thing to do is to create the password file for the user(s) mentioned in the configuration, above. The AuthName is used here, as is the user drbob as it appears above. To make the password file:

  sudo htdigest -c WebDAV.passwd frosty drbob

Finally, we're ready to restart Apache:

  sudo apachectl graceful

At this time, on Mac OS X 10.4.x (Tiger), the user will be able to login securely to the URL http://machine/webdav/, and they will be able to see the contents of /usr/local/davroot but they will not be able to save things there, nor will they [and] be able to see, modify, or [and] use anything that they see. It's almost like the initial protocol is supported, but the more advanced stuff the clients have updated, but the server has not. [Everything works as advertised.]

Like I said... if it gets serious, I'll put this on my Leopard box and be done with it. But there's nothing pushing me right now, and I may come back to this and try to see what I need to do to fix it. Hard to tell. But that's what I've done.

UPDATE: Holy Cow! I decided to look at the Apache error and access logs and I figured out the problem. The Alias line above needed to not have the trailing slashes and they needed to match. I removed it from the first argument and restarted and all of a sudden, things started working! I'm amazed. Transmit works, Safari works, the Finder works... everything seems to work just fine. I need to set up SSL on frosty, but that should be pretty easy and when that's done I'll have a secure channel to my home WebDAV! How cool is that?!

Cyberduck still tries to assume it's using Basic authentication, and I can see that, it's not trying Digest, but the WebDAV server understands that and deals with it nicely. It's amazing. Wow.

This morning I was checking on a few remote sites and decided to pull up Cyberduck to see how it was doing with the relative speed of access to my home network. When it launches, Cyberduck uses the Sparkle framework to check for updates, and there was a new version released - 3.0.2. Of course, I got it.

Now I have paid for Transmit, and I'll still use it from time to time, but I have to say that I like the minimalistic GUI layout of Cyberduck more. No unnecessary border, no wasted screen real-estate - that's what I like. But with 3.0.2 they've added a default Bookmarks view. All of a sudden, it's not as clean as it used to be.

There's a menu item to toggle the bookmarks on and off - that's nice, but you can't really get rid of the bar right below the toolbar. You used to be able to just have the toolbar and the list of files - very nice and clean. You drag things out and that downloads them, you drop them in and it uploads them. What could be simpler?

I've looked around the program and I can't find a way to remove the second toolbar. Maybe they'll get requests to make it optional - maybe even from me. If they can remove it I'll be a lot happier. I just want a simple interface... nothing fancy or anything I don't need.

After reading several posts in the Cyberduck forums, it's clear that I'm not the only one that thinks this is not a step in the right direction. So I'll bide my time. I'm guessing that there's going to be a compromise here about how the bookmarks are handled. For now, If I get rid of the toolbar, I have only the one I can't get rid of, and that's a reasonable number for me to deal with. Still... too bad.

I like to stay up with the Camino project as well as Firefox, but I'm not yet convinced that the Camino Team is building a better browser than Safari or Firefox. I still use Safari for 90% of my work, but when that fails, I pull up Firefox that's always running and pull up the page. It's been a really workable solution for me so far.

But I have to admire the Camino team... they're still at it. So I check each new release to see if there's a better browser there. Getting better, but it's still not Firefox.

One of the things that has historically been a problem with NeXTSTEP/OPENSTEP and now Mac OS X development projects and source control is the fact that on all the operating systems, the bundle concept exists and complicates CVS considerably. The bundle is nothing more than a directory that's treated as a single entity. The app, the nib, the rtfd... all these are really directories on the filesystem and yet the OS thinks of them as single, indivisible entities. So when CVS goes to make a CVS directory in one of these bundles, and then the tool (such as InterfaceBuilder) saves a change, it overwrites the entire directory - destroying the CVS directory within the bundle.

With the recent editions of Xcode (from the old ProjectBuilder) the source code control has been built-in. However, I've been very gun-shy to use it for fear of not getting anything done because of these issues. So it was a very anxious time for me today when I tried to get my first Xcode 3.1 project put into my home repository.

Since the repository was already created, and running on Mac OS X 10.4 (Tiger), I thought if it were going to work at all it should work in this environment. So I did a little Googling on this and found a page that walks through this for Subversion, but not CVS. I figured that if I backed everything up, I'd be set. So I dove in.

Configuring Xcode for Your Repository

The first thing to do is to have a repository, since I had one, and it was already running on a pserver I'd set up ages ago, it seemed like I should be set to go. What confused me for a little bit was the fact that Xcode was going to allow me to configure the root of the repository and therefore view all the projects I've placed in that repository. Very nice. In order to get there, however, you need to tell Xcode how to connect to your repository.

Select SCM -> Configure SCM Repositories and then click the '+' button at the bottom of the list to add a new repository. Once you give it a name and a type, you'll get an appropriate dialog box where you can enter all the data for the repository Xcode will need. As a nice little bonus, as you fill in the components, Xcode builds up the CVSROOT (for those that are familiar with this, it's a real lifeline) and so you can see each component going into the CVSROOT as you enter it into the dialog. When it's all filled out, Xcode will automatically verify the connectivity (another amazing piece of work) and then you can click "OK" to save everything.

At this point you have the repository configured with Xcode. Now you can look at it by selecting SCM -> Repositories and then the one you just added will be on the left and it's contents in the finder-like view on the right. You can look at everything you've already put into your repository (for those of us that used existing repositories, this is really a place to give a wonderful sigh of relief.)

Import Your Project

Once you have a project ready to import, simply select where you want the root of your new project to sit, and click on the Import icon in the Repositories window. Xcode will then ask you what to import - navigate to the root of the project directory and give it a nice comment. Xcode will indicate in the bottom pane of the Repositories window what's happening and in a few minutes, you're all imported.

Check-Out Your Project

As with all other CVS imports, save the old project file by renaming it, or tar-ing it up and saving it off someplace, and then from the Repositories window select the project you just imported and click on the Check Out button. Xcode will ask you where to put this, and you can navigate to the directory you want it to be placed. Click 'OK' and Xcode will do the checkout. As a wonderful feature, it's going to ask you to open the project in Xcode when it's done. Say 'Yes', as we need to do one last thing before we're done.

Enable SCM on Your Project

Now you need to navigate in the 'Groups and Files' list to the name of the project (typically the first thing in the list) and then click on Info to pull up the main project info window. Navigate to the 'General' panel and then at the bottom choose the repository from the SCM list and you'll notice the GUI shifts a bit to place the CVS status next to each file. At this point, you're ready to go. The SCM menu is now greatly expanded and using SCM in Xcode is very simple.

You can do diffs... additions... moves... all the things you'd normally do, and with CVS, Xcode is smart enough not to blow away the directories of the bundles and so things get versioned properly. It was easy... but very nerve racking for my first time since the old days. In the future, I'll tell people to do it earlier. Much earlier.

Because the chat infrastructure team seems to be unable to get their issues resolved about the MindAlign bots, and because I can't really honestly say that the bots I need are business critical, I've started looking for IRC servers that I can start up on my own, point all my servers at, and then simply have my own IRC system. The load is trivial, and with this, I'd be able to get things done, but there's always the risk of being tagged as a rogue chatter.

Given that it's been two weeks, and there's no accommodations being made for important but not critical bots, I'm thinking that even if I get nailed (and that's not a guarantee by any means) that my excuse is exactly that - two weeks, no communication, and no alternatives. Sounds good to me, anyway.

So I've been looking at the IRC servers, and it seems like IRCD-Hybrid is a decent tool, and the history of it leads me to believe that it's really different only in the very 'far out' IRC issues - things I'm not liable to hit ever. I just need a basic communication hub, and for that, this should do just fine.

I'll get it, build it and see if I can get it going on a box of mine. If I can, then good enough and I'll try running it there for a while. I'll convert a few processes over and then see how that flies for a few days. If all looks OK, I'll convert over simply to await the day that the MindAlign guys get things worked out.

UPDATE: so I got the code and configured it by reading every single line. And boy, oh boy... you have to read every single line as there's a line in the config file that will crash the server intentionally if left in the config file. So, read and configure.

The big change was that the default IRCD-hybrid 7.2.3 does not allow for NICK names to start with an underscore (_). Since all the bots for MindAlign have to start with that, I needed to get into the code and fix it. The relavent code snippit was originally:

  int
  valid_username(const char *username)
  {
    int dots      = 0;
    const char *p = username;
 
    assert(p != NULL);
 
    if ('~' == *p)
      ++p;
 
    /* reject usernames that don't start with an alphanum
     * i.e. reject jokers who have '-@somehost' or '.@somehost'
     * or "-hi-@somehost", "h-----@somehost" would still be accepted.
     */
    if (!IsAlNum(*p))
      return 0;
 
    while (*++p)
    { 

and needed to be changed to:

  int
  valid_username(const char *username)
  {
    int dots      = 0;
    const char *p = username;
 
    assert(p != NULL);
 
    if ('~' == *p)
      ++p;
 
    /* reject usernames that don't start with an alphanum
     * i.e. reject jokers who have '-@somehost' or '.@somehost'
     * or "-hi-@somehost", "h-----@somehost" would still be accepted.
     */
    if (!(IsAlNum(*p) || ('_' == *p)))
      return 0;
 
    while (*++p)
    { 

After this change, a simple recompile, and the bots were working great. This would be a nice change to the codebase to put this in the config file, but I can see that this is probably pretty stable, and so they might not want to mess with it.

In any case, I'm set now with my own IRC server for my apps. If they come after me, I have a solid defense - it's for the best for the business.

This morning I was putting in a few changes to a project I was working on and one of the nice features of CVS over Subversion really hit me - CVS allows you to check-in part of your workarea by specifying the files you wish checked in. This is really the core of Subversion - that the entire workarea is a single check-in unit, but what happens if you're in the middle of changes for something and you need to checkin some changes to another totally unrelated part of the code.

Subversion would have to branch or checkout a new workarea, add in only those things that you can checkin at this time, check them in, and then go back to the original workarea and update that to merge in the changes.

That doesn't sound too bad, but it's nice to have several changes in CVS and check in just those that you know are safe for the repository, and then keep working on the others. I know it's part of the "problem" with CVS, but I see it as a genuine feature. I use it all the time.

In fact, the number of times that I checkin everything in CVS is so few as to be considered "rare" - less than 5% of the time. The vast majority of checkins are checking in a few files with a directed comment in the logs, and then repeating as necessary.

So while I like the Subversion feature of keeping a pristine copy of the workarea in the workarea, it's got an offsetting feature in the targeted checkin. At least for me.

[8/5/08] UPDATE: I was talking to a friend today and he mentioned that you could checkin individual files. But I looked at the PDF again that comes from the Subversion project and it doesn't mentioned this at all. I'm stunned that they didn't mentioned this in the docs from the project. It's one thing that really was turning me away from Subversion. Now I can relax and move back towards it as necessary. Wild.