Some of the improvements I have noticed:

• Snow Leopard is noticeably faster! I had thought it might just be fan-boy talk, but this operating system is in fact noticably faster at launching applications and the like. It is especially nice to no longer see the beachball every few minutes in the Finder. In fact, I don’t think I have seen that dreaded rainbow beachball int he Finder since upgrading!
• Cisco VPN is built in! Like the iPod Touch, Cisco VPN networking is now built-in, so all I had to do was configure it as one of my network interfaces. Thank you Apple! If you previously had it installed, you can uninstall Cisco’s crappy little VPN client using the command:sudo /usr/local/bin/vpn_uninstall
• QuickLook works in the Open/Save Dialog Boxes: Just as in the Finder, you can now hit the spacebar with a file selected in an Open/Save dialog box and you get a previous of the file’s contents. Sweet. QuickLook was probably the most useful feature I use everyday in Leopard, so I am glad to see it available in Open/Save dialog boxes as well.
• I can see Hidden Files in the Open/Save Dialog Boxes: Credit this to MacOS X Hints, but in the Open-Save Dialog box, if I hit ‘Command-Shift-.’ (that’s a period), you can see the hidden files in a given directory. If you use your mac in a region where commas are normally used to as a decimal separate, you have to use the comma from the numerical keypad instead of the period. Very useful for people who edit .tcshrc or .bashrc files regularly.

Some of the annoyances I have been ironing out during the last week:

• X11 now knows more about user environment: I use tsch as my shell environment. Apparently X11 on Snow Leopard loads the ~/.tcshrc file to set the system enviroment! I had a bug in the file that prevented X11 from launching. I was able to figure out it was local to my account by creating a test user account and launching X11 without a hitch. I was able to find the bad library path and fix it in the ~/.tcshrc and now my X11 works fine.
• Battery Issues with Snow Leopard: I had issues with the battery under Snow Leopard. The battery life that was being reported was half what it had been before the upgrade. This seemed very odd to me, but the system profiler app insisted that after 183 charge cycles I had only 1949 mAh of power. So to ‘recalibrate’ I started up the computer after it went to sleep due to ‘low power’. It ran for another hour, reporting 0% battery the entire time. It then did a hard shutdown. I left it off and unplugged overnight, I then charged it full. It still reported only 1949 mAh total charge. I called Apple’s tech support which elevated the report to engineering. Then, after ’safe booting’ the machine (see notes below), and booting back into my normal setup, I discovered the battery level was being reported as 4300 mAh, as it should be. Now, as of this morning, the problem is back again and System Profiler insists the battery has only 2870 mAh of maximum charge and it requires service. Not sure what the problem was, but a lot of people have been having similar problems with this particular battery and snow leopard.
  [Followup (added Oct. 23, 2009): Apple replaced the battery and the problem went away.  It is possible that the number of people reporting the problem is just indicative of a small percentage of users whose bad batteries were not obvious to them before Snow Leopard.]
  
• Ethernet Issues with Snow Leopard: I had major issues with the ethernet connection dropping after a few minutes. Actually, it isn’t a full lost connection, I can still see computers on my subnet, and Skype seems to work, but a large percentage of websites fail to load and mail doesn’t work for off-campus mail servers. Quite a few other people were reporting similar problems on the Apple Discussion boards, but most of them resolved the problem by doing one of the following:
  1. Sometimes corrupt settings persist from a previous setup. Removing all the files in /Library/Preferences/SystemConfiguration/ and rebooting will purge all the system settings related to networking. You will also lose settings related to other things, such as Energy Saver settings, but it can help when you can’t isolate the issue. I tried this, it didn’t work in my case
  2. The other solution many people hit on was to create a new “Location” in the Network control panel. If you have a corrupt preference setting in your Location, creating a new one lets you start from scratch. Again, this didn’t work for me.

  After going through all this, I talked to an Apple product specialist and they hit on the idea to try bringing up the computer in ‘Safe Mode‘ by rebooting ahdn holding the shift key during the boot. Safe mode turns off the launching of all non-system deamons and agents as well as turning off the launching of all the programs you might launch at login via your Accounts preference pane “Login Items”. Lo and behold, after doing this, my ethernet connection appears to have been stable! What I did was

  1. I removed Adobe VersionCue CS3 from my launch items in the Accounts preference pane. Adobe noted it was incompatible with Snow Leopard anyway.
  2. I disabled the following launch items by moving them to my Desktop and then rebooting
     

     /Library/LaunchDaemons/com.adobe.versioncueCS3.plist
     /Library/LaunchAgents/at.obdev.LittleSnitchNetworkMonitor.plist
     /Library/LaunchAgents/at.obdev.LittleSnitchUIAgent.plist

  Having now brought the computer back up through a normal boot, the ethernet connection has remained stable. The fact that my battery issue seems to have been resolved almost simultaneously makes me think these apps were responsible. [Followup (added Oct. 23, 2009): I narrowed down the problem to an apparent incompatibility between Snow Leopard and the version of BIND my campus is using as a DNS server.  And it may be specific to my machine.  Not sure.  Switching to using OpenDNS as my DNS resolver made the issue go away for me.  My server, a Mac Pro, which I have upgraded to Snow Leopard, has exhibited no such weirdness.]

• MacPorts Rebuild: I traditionally rebuild my MacPorts installation from scratch with a new OS installation. There were no major issues, but I took the opportunity to upgrade to the latest MacPorts and to try to rebuild with only the bare minimum of ports that I was using.
• Many Mail Plugins Fail: Most mail plugins use ‘unapproved’ APIs and most of the Mail Plugins I used failed for Snow Leopard’s Mail.app. Furthermore, it looks like Apple has changed things so now every minor revision in the OS will require Mail plugin writers to explicitly approve the plugin for that version of Mail.app. This means in the future every minor revision in Snow Leopard will likely shut down Mail plugins until they get updated.
• Force 32-bit compilation for IRAF in Snow Leopard: Doug Mink has discovered that compiling IRAF packages in Snow Leopard presented errors until he forced 32-bit compilation (I am assuming he was on a 64-bit machine). I am quoting his suggestions (sent to me via email) below:It turns out that Snow Leopard defaults to 64-bits and you need to add the -m32 flag to hlib$fc.csh and hlib$mkpkg.inc just like you have to for 64-bit Linux:

  In fc.csh (Juan’s Note: in Scisoft OSX, this is /Applications/scisoft/all/Packages/iraf/iraf/unix/hlib/fc.csh) after this:
  

  # Scan the argument list and concatenate all arguments.
  set args = ""
  while ("$1" != "")
  set args = "$args $1"
  shift
  end

  
  add this:
  

  if ($MACH == "macintel") then
  print ("MACINTEL: -m32 flag set")
  set args = "$args -m32"
  endif

  
  and in mkpkg.inc (Juan’s Note: In Scisoft OSX, this is /Applications/scisoft/all/Packages/iraf/iraf/unix/hlib/mkpkg.inc for each IRAF package you want to recompile) :
  

  $else $ifeq (MACH, macintel) then
  $set    XFLAGS          = "-c -w -m32"  # default XC compile flags
  $set    XVFLAGS         = "-c -w"       # VOPS XC compile flags
  $set    LFLAGS          = "-Nz -m32"    # default XC link flags

That is my Snow Leopard report for now. More from the trenches and after I upgrade SciSoft OSX.

Two years ago, I wrote a blog entry with hints for setting up X11 for the astronomer. The problem is that while the hints in that writeup are still valid, they don’t work if you are using Xquartz because the preferences are stored in a different location for XQuartz versus the built-in X11. As such, I am reproducing those X11 hints here, but with the edits necessary for use with XQuartz.

Once you have installed XQuartz, the X11.app should automatically launch when a program that needs X11 is executed (If you are an old hand at X11, you probably discovered since moving to Leopard that you should NOT set the DISPLAY variable to :0 to display an Xwindow on your primary display, just leave DISPLAY undefined.):

1. There are many hidden preferences in XQuartz just like in many Mac Applications. You can see a list of the hidden (and not hidden) preferences using the command line tool defaults. To see the available XQuartz preferences, type:defaults read org.X.x11NOTE: If you are still using Apple’s built-in X11 implementation (or if you are using MacOS 10.4), just replace ‘org.x.X11’ with ‘com.apple.x11’ in all the following hints.
2. In addition to “reading” the preferences, you can write to them. From the command line you can type:
   • defaults write org.X.x11 no_quit_alert true
     This allows X11 to quit without an alert box. Useful if you find it irritating like I do that X11 will prevent me from logging out or the computer from restarting due to that dialog box. However, this does mean you can accidentally quit X11.app pretty easily if you hit cmd-Q at the wrong time.
   • defaults write org.X.x11 wm_ffm true
     Allows which X11 window is selected to follow the mouse, which is the way X11 behaves under most *nix systems by default.
   • defaults write org.X.x11 wm_click_through -bool true
     This activates click_thorough events in the Quartz window manager, which allows clicks to pinned windows, another behavior common to *nix X11 installations.
3. You can control which window manager is launched (if you prefer something other than the quartz-wm used by default). If you don’t have a ~/.xinitrc file, copy the default one:
   

   cp /private/etc/X11/xinit/xinitrc ~/.xinitc

   
   and then manipulate it with any text editor.
4. BIG LAPTOP USER HINT: Because XQuartz on the Macintosh uses authentication to prevent connections from unauthorized sources to the X11 client, something interesting happens when you change IP address, you will discover you can’t use X11.app from the MacOS X Terminal until you quite and relaunch X11.app. This happens to me all the time on my laptop when I travel and the IP address changes. I recommend either using the Xterm as your terminal or just get used to restarting X11 if you have problems connecting to the terminal.
5. You can run X11 remotely on your Mac, if you can ssh into your Mac, then just use
   

   ssh -Y youraccount@yourcomputer.com

   
   , the -Y flag should allow you to run X11 remotely as long as X11.app is running on your machine before the connection is made. If your ssh on the remote machine doesn’t support X11 connections and you have admin access, you can edit the file /etc/sshd_config on the remote machine and make sure X11 Forwarding is turned on by looking for the following lines and making sure they are uncommented and that all “no”’s are set to “yes”:
   

   X11Forwarding yes
   X11DisplayOffset 10
   X11UseLocalhost yes

And that is it for the hints for now.

Well, I’m way late to the game on this, but our long national nightmare is over – Xquartz for Leopard support full screen!

The Xquartz folks latest edition of Xquartz (version 2.3.2.1) includes full-screen support. Now, personally, I like the way X11 integrates with Aqua, but for those who prefer to use only one windowing system at a time, you can now do it on MacOS X Leopard. You can download it here.

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

error when fonts are used in PHP routines (fuller notes on this problem here although with my “hacked” fix, which is no longer needed). This problem as originally reported under Trouble Ticket #15909 on MacPorts.

Careful with that Apache2 upgrade, Eugene: I also discovered I have to be careful when updating apache2 under MacPorts in that it actually wiped out some of the configuration files stored in /opt/local/apache2/conf/, specifically it overwrote my modified versions of the /opt/local/apache2/conf/extra/httpd-dav.conf file and /opt/local/apache2/conf/extra/http-userdir.conf files. So now I am keeping copies of everything in /opt/local/apache2/conf backed up so I can roll back my changes after an upgrade of apache2 in MacPorts.

1. Fixed a parsing bug that prevented the loading of any Clear Sky Chart for sites containing parentheses or periods in their names. It was this bug that was interfering with the loading of our observatory’s Clear Sky Clock.
2. Since the Clear Sky Chart is quite large and many people will use the widget on laptops with small screens, I added a “Half-size mode“. All you do is click on the “Toggle Size” link on the widget. This shrinks the charge and saves screen real estate.
3. With Attilla Danko’s permission, I added a Built-in Legend (copied from his site) for interpreting the Clear Sky Chart to the widget. Just click on the charge and the legend appears. Click again and it goes away.
4. I also added a link to the Clear Sky Charge site page, so if I wanted more detailed information, I can get it there.

I hope a few Mac-owning astronomers in the U.S. and Canada find this widget useful.

• Aqua 10.4 Tiger (Universal)
• Aqua 10.5 Leopard (Universal)
• X11 10.4 Tiger (Universal)
• X11 10.5 Leopard (Universal)
• X11 10.5 Leopard (Universal) with Firewall

To quote the release notes on the SAOImage DS9 website, the changes in the newly released version 5.3 are

Regions: Regions now support a centroid function. The centroid function can be manually invoked or regions can automatically snap to a centroid when moved or edited. Regions now have a DASH line property.

Colorbar: Now supports a vertical colorbar layout option, via the View Menu. Users can configure the font type and size of the colorbar, via the View Menu.

GUI: Now supports a vertical button bar, when in vertical layout mode.

Aqua MacOSX 10.5 firewall: The MacOSX Aqua 10.5 Leopard port of DS9 can be used with the MacOSX 10.5 firewall enabled.

X11 MacOSX 10.5: There are now two versions available for X11 MacOSX 10.5 Leopard. The non-firewall version is recommended for all unless you wish to enable the 10.5 firewall. [Juan's Note: While not stating this, they mean specifically the application-specific version of the MacOS firewall. See my notes on this problem here.] In that case, please use the firewall enabled version. Please note: this version consist of 2 files, ds9 and ds9.zip. It is very important that ds9.zip be placed in the same directory as the ds9 binary at all times.

Contours: Contours now have a DASH line option.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine except that newer releases of Scisoft OS X place the binaries in /Applications/scisoft/i386/bin/ instead of /scisoft/i386/bin/ and if you are installing the X11 binary that is compatible with the firewall, you have to install both the ds9 and ds9.zip file in the bin/ directory of Scisoft OSX.

As I reported on my blog here, here, and here, I have been having problems with my PHP programs on my web server that use fonts crashing with errors of the form:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

The problem turns out to not lie in PHP, but in Apple’s pre-installed FreeType which is compiled with “old font” support. This old font support is apparently old Carbon code instead of Cocoa (if I understand correctly, which I may not) and thus requires a forking of the process… which triggers this fault.

If you use MacPorts version of Apache and PHP (as I am now doing), you can fix this problem by editing the Portfile for freetype to disable old font support, recompiling it, and restarting your apache server. So following the hints in the MacPorts Bug Report #15909 I did the following:

Edit the Portfile located at /opt/local/var/macports/sources/rsync.macports.org/release/ports/print/freetype/Portfile changing line 50 to

#    --with-old-mac-fonts 
--with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no --with-quickdraw-carbon=no 

Now recompile freetype in MacPorts. To do this you have to force the uninstallation of freetype (which will cause much gnashing of teeth by MacPorts since freetype is required for several other ports.

sudo port -f uninstall freetype

Then recompile and reinstall freetype:

sudo port install freetype

And finally, give the apache server used by MacPorts a fresh restart to get it going with the new freetype libraries loaded.

sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper restart

Doing this fixed all my freetype issues and I was able to use my FinderChart program again. The only disadvantage is that if freetype is updated from version 2.3.7 in MacPorts (and no no-old-font variant appears), I will have to re-apply this hack.

There are a few changes in this version and all packages have been updated to the latest available versions. Starting with this version, Scisoft is installed in /Applications/scisoft (it previously was installed in /scisoft). Make sure that you remove any old /scisoft installation and properly update your startup files to source the Setup.csh or Setup.bash from their new locations.

In the README file you are told

Once the collection is successfully installed csh and tcsh users should invoke the command:

source /Applications/scisoft/all/bin/Setup.csh

to gain access to all the software and configure their environment correctly.

Users of the “bash” shell should instead use:

. /Applications/scisoft/all/bin/Setup.bash

Personally, to avoid problems in tcsh with a script breaking or with modifying my PATH multiple times by repeated execution of the Setup.csh script, I use the following line in my .tcshrc to first check for the existence of the Setup.csh script and SCISOFT environmental variables before executing it.

if (! $?SCISOFT) then
test -r /Applications/scisoft/all/bin/Setup.csh && source /Applications/scisoft/all/bin/Setup.csh
endif

Permission Problems Persist
This version addresses all the issues I noticed with Scisoft OSX 2008.5.1 except for one annoying one, the reassignment of ownership of the enclosing directory on installation. If you installed the old version of Scisoft OSX, it would reassign ownership of the root (/) directory to the second user on the system (in my case, since their is none, it showed the user as “502″). I beta-tested various versions of Scisoft OSX but Nor was not able to stamp out this particular problem. I believe Nor has come to the conclusion after extensive testing that this is a problem with Apple’s software for constructing installer packages. By moving the Scisoft OSX installation to /Applications/scisoft, it is the /Applications directory that gets its ownership changed instead of the root directory, which is less damaging. However, I would strongly suggest checking the ownership of the /Applications directory afterward and if isn’t owned by an administrative user, set it as such using:

sudo chown username:admin /Applications

(where “username” is the primary administrative users username, in most cases, your username) to perform the repair.

A Quick-Fix for any Legacy Scisoft-related scripts
If you had a few scripts that relied on Scisoft OSX being located in /scisoft and you don’t want to edit them all is you can make /scisoft point to /Applications/scisoft. This can be accomplished by first moving the old version of Scisoft OSX before installing 2008.8.1 via the command line:

sudo mv /scisoft /scisoft_old

and then once you have installed the new Scisoft OSX in 2008.8.1, create a symbolic link from the old location to the new by typing (again from the command line)

sudo ln -s /Applications/scisoft /scisoft

This will allow any scripts that refer to items in /scisoft to continue to work for the most part.

What’s New?
An investigation of the /Application/scisoft/i386/Packages directory as well as the NEWS file reveals the following changes to this version of SciSoft OSX over the 2008.5.1 version.

• DS9 updated from 5.1 to 5.3beta
  
• FV updated from 5.1 to 5.2.1
• ATLAS updated to version 3.8.2
• MIDAS updated to 08FEBpl1.1
• cdsclient was updated to version 2.87
• OpenMotif updated to 2.1.32_compat
• cfitsio library updaed from 3.090 to 3.090 (the current version is 3.100)
• pango library updated from version 1.20.2 to 1.21.3
• pixman library updated from 0.10.0 to 0.11.2
  
• expat library updated from 2.0.0 to 2.0.1
  
• fontconfig library updated from 2.3.2 to 2.6.0
• freetype library updated from 2.2.1 to 2.3.6
• gettext library updated from 0.14.5 to 0.17
• gtk+ updated from 2.12.9 to 2.12.10
• libpng library updated from 1.2.10 to 1.2.29
• netCDF library version 3.6.2 added
• pkg-config updated from 0.20 to 0.23
• TclTk package updated from 8.4.13 to 8.4.19
• wcstools library updated from 3.6.4 to 3.7.3 (current version is 3.7.5)
• IRAF package rvsao updated t version 2.5.7 to 2.6.4
• Python was updated to 2.5.2 and the following Python libraries were updated:
  
• • ScientificPython updated to 2.6.1

Minor Glitches
The only other minor glitch I noticed was that /Applications/scisoft/i386/bin doesn’t appear to have a ds9 binary installed. You can fix this by installing the X11 version of ds9 there or by linking to the Aqua version of ds9 that was installed using the command line

ln -s "/Applications/scisoft/i386/Applications/SAOImage DS9.app/Contents/MacOS/ds9" /Applications/scisoft/i386/bin/ds9

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

Finally, there’s a big problem with FreeType. As I discovered, anytime FreeType fonts are used by GD, they apparently make a Carbon API call of some sort. Problem is, Apache2 uses fork() without a corresponding exec() and, upon calling PHP/GD/FreeType, the Carbon call in FreeType causes Apache2 to crash. It shows up in the error_log as

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.
Mon Nov 26 12:38:11 2007 notice child pid 304 exit signal Trace/BPT trap (5)

and in the system.log as

Nov 26 13:12:00 shr-g5 ReportCrash664: Formulating crash report for process httpd659
Nov 26 13:12:02 shr-g5 ReportCrash664: Saved crashreport to /Library/Logs/CrashReporter/httpd_2007-11-26-131145_shr-g5.crash using uid: 0 gid: 0, euid: 0 egid: 0

I didn’t discover the cause–I can’t take credit for this one.

[I]nstall FreeType 2 without the Mac-specific extensions. These extensions make it possible for FT2 to access fonts stored in a font suitcase, something which is unnecessary if you use plain “.ttf” fonts from other sources. Here’s how I did that: Get FT2 and expand the tarball: (in Sources–my version of /SourceCache):

curl -O http://download.savannah.gnu.org/releases/freetype/freetype-2.3.5.tar.gz
cd ..
tar xvfp Sources/freetype-2.3.5.tar.gz

Configure FT2 and make it:

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp" CCFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" CXXFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -g -Os -pipe" LDFLAGS="-arch ppc -arch ppc64 -arch i386 -arch x86_64 -bind_at_load" ./configure --with-fsspec=no --with-fsref=no --with-quickdraw-toolbox=no --with-quickdraw-carbon=no
make
sudo make install

Libraries end up in /usr/local/lib.

I had tried to alleviate the solution previously by compiling a version of PHP myself that would be compatible with Apple’s built-in Apache 2 web server. This turned out to be difficult because Apple’s Apache 2 web server is a “universal” binary, meaning it contains four seperate binaries (for 32-bit PowerPC, 64-bit PowerPC, 32-bit Intel, and 64-bit Intel processors). As such I needed to compile a “universal” PHP binary and since I wanted MySQL support, I needed a “universal” MySQL binary. This turned out to be too much for this astronomer, so I gave up on making a new PHP that was compatible with Apple’s built-in web server.

So I bit the bullet and after reviewing the options, I decided to install Apache 2 and PHP under MacPorts. If you have read the other posts on this site, you know I really like MacPorts as the quick and dirty way to get many things running on the Mac. However, despite this, I don’t like installing MacPorts for items Apple provides, instead generally preferring to use Apple’s “pre-installed” versions. Furthermore, there have been a lot of complaints on the MacPorts mailing lists about various issues compiling PHP5. So I wasn’t as quick to jump onto the MacPorts bandwagon for PHP as I am for other problems. However, since I am familiar with MacPorts, I decided this was the best approach for getting my online Finder Charts to work again.

The process proved reasonably painless, especially since I was able to review this blog post, where he lays out pretty much what to do. However, since I wanted to achieve maximum compatibility with Apple’s built-in web server and PHP setup, in case I wanted to switch back, I ended up doing things a little bit differently, so I am outlining my steps here.

1. I started by installing the MacPorts version of Apache 2 using the command sudo port install apache2
2. Next, I had to create the Apache 2 configuration files and edit them. I started by copying the sample configuration file

   sudo cp /opt/local/apache2/conf/httpd.conf.sample /opt/local/apache2/conf/httpd.conf

   and then editing /opt/local/apache2/conf/httpd.conf with my favorite text editor to change the configuration to match the that of the built-in Apache 2 server a closely as possible. My matching the configuration of Apple’s built-in server, I can switch back to it with relative ease if I choose to do so later. So I made the following changes to /opt/local/apache2/conf/httpd.conf:
3. 1. I changed DocumentRoot to "/Library/WebServer/Documents" as is the case with Apple’s built-in server.
   2. To allow index.php files to be used as directory indexes, I changed

      DirectoryIndex index.html

      to

      DirectoryIndex index.html index.php

      (I don’t know why this isn’t necessary with Apple’s built-in server, but it was necessary here).
   3. I changed to and in that directory block of code, I added “MultiViews” to the Options line.
   4. I changed to in order to prevent the listing of .DS_Store files in directory listings by the web server.
   5. Before the ErrorLog block of code in this file, I added the following lines copied from Apple’s default Apache 2 configuration:

      #
      # Apple specific filesystem protection.
      #
      
      Order allow,deny
      Deny from all
      Satisfy All
      
      Order allow,deny
      Deny from all
      Satisfy All

   6. I changed ErrorLog to "/private/var/log/apache2/error_log"
   7. I changed CustomLog to "/private/var/log/apache2/access_log common"
   8. To match Apple’s Apache 2 server configuration, I changed ScriptAliasMatch to

      ^/cgi-bin/((?!(?i:webobjects)).*$) "/Library/WebServer/CGI-Executables/$1"

   9. I changed back to
   10. I added the following Handles to the “To use CGI Scripts” block of code:

       AddHandler imap-file .map
       AddHandler cgi-script .cgi
       AddHandler cgi-script .pl

   11. I uncommended the following lines near the end of the file:

   12. [OPTIONAL] Because I use the WebDAV server on my server, I also uncommented
   13. Finally, I added the following lines to the end of the file in order to allow loading of the PHP5 configuration

4. Next, I editted /opt/local/apache2/conf/extra/httpd-userdir.conf and added the following to the end of the file

   #
   # Users might not be in /Users/*/Sites, so use user-specific config files.
   #
   Include /private/etc/apache2/users/*.conf

5. [OPTIONAL] Since I use the built-in WebDAV server, I made a backup of the WebDAV configuration, then copied the Default MacOS X one, because I have spent a lot of time tweaking it previously and I didn’t want to have to reinvent the wheel. 

   sudo cp /opt/local/apache2/conf/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf.orig
   sudo cp /etc/apache2/extra/httpd-dav.conf /opt/local/apache2/conf/extra/httpd-dav.conf

6. I had to install PHP5 with MacPorts. Since I wanted to add support for Apache 2 and MySQL, I entered the command: sudo port install php5 +apache2 +mysql5 +pear which has the side effect of installing MacPorts version of MySQL as well. Assuming everything goes well, after a few minutes (this takes longer than the apache2 install earlier), the installation will end. At this point we can configure the Apache 2 mod_php module by typing: 

   cd /opt/local/apache2/modules/opt/local/apache2/bin/apxs -a -e -n "php5" libphp5.so

7. [OPTIONAL] Next, I had to create the PHP5 configuration file and edit it. I started by copying the sample configuration file sudo cp /opt/local/etc/php.ini-dist /opt/local/etc/php.ini and then editing /opt/local/etc/php.ini to make it match /etc/php.ini (which Apple’s built-in PHP uses). All the changes I made were optional and related to the specifics of my setup. The only interesting one was that I wanted to continue to use the MySQL.com binary distribution of MySQL server, so I set the following variables in /opt/local/etc/php.ini: 
   1. mysql.default_port from “” to 3306
   2. mysql.default_socket from “” to /private/tmp/mysql.sock
   3. mysqli.default_socket from “” to /private/tmp/mysql.sock
8. I deactivated Apple’s built-in web server by turning off Web Sharing in the Sharing.prefPane.
9. Finally, I launched the new webserver (and set it up for launching on boot-up in the future) by typing

   sudo launchctl load -w /Library/LaunchDaemons/org.macports.apache2.plist

   If this breaks anything, I can reverse the process by typing

   sudo launchctl unload -w /Library/LaunchDaemons/org.macports.apache2.plist

10. [OPTIONAL] I like the ability to turn on and off the Apache webserver from the command line using apachectl. I can “emulate” this in /bin/tcsh (my prefered shell) by adding the following command to the ~/.tcshrc file:

    alias apache2ctl 'sudo /opt/local/etc/LaunchDaemons/org.macports.apache2/apache2.wrapper'

    After which I can bring down the server by typing apache2ctl stop and restart it by typing apache2ctl start.

While I’m sure Apple did this for security reasons, since upgrading the Leopard, I have had a problem with scripts that use the JpGraph plotting PHP library crashing. After looking in /var/logl/apache2/error_log, I see the following eror message:

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

PHP on Mac OS X. Apple’s PHP version which is bundled with Mac OS X does not work with PDFlib DSOs. To use PHP with PDFlib on Mac OS X you need third-party PHP packages such as MAMP, XAMP[P] for Mac, or Marc Liyanage’s version from www.entropy.ch. Mac OS X 10.5 (Leopard) adds new complications. As described in developer.apple.com/releasenotes/CoreFoundation/CoreFoundation.html it is no longer possible to use CoreFoundation functions after a call to fork( ) without exec( ). However, CoreFoundation functions are required for PDFlib’s host font feature, and the critical sequence above is used in the combination of Apache and PHP. This may trigger the following error message in the Apache log (and can even crash the Apache process):

The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec().
Break on _THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug.

In order to avoid this problem you can run PHP as a CGI on Apache, or disable the host font feature in PDFlib[.]

Sure enough, JpGraph is using host fonts. Damn.

Unfortunately, the Marc Liyanage’s version of PHP5 for Leopard from www.entropy.ch is still in beta and the last update of MAMP was quite a long time ago. And while XAMPP for MacOS X looks promising (at least it has been updated recently), I would really like to keep on using the MySQL server I already have running. So for now, I try installing Apache 2 and PHP using MacPorts.

[See my subsequent posts about getting the MacPorts version of Apache 2 and PHP going and the subsequent continuation of the problem after a reboot.  There is more information about this issue there.]

Unfortunately, it looks to to be as twitchy as running your own Darwin Calendar Server. I’ve been using CalDAV on my own personal server for a few months and I have to admit it has been a bit twitchy, but getting better as time rolls on. I tried to synchronize this afternoon to Google Calendar and got the following error:

The server responded with
"HTTP/1.1 500 Internal Server Error"
to operation CalDAVWriteEntityQueueableOperation.

Followup (July 30): I noticed all of the errors occurring during the import were for old classes last semester. So I forced my way through them by clicking “Revert to Server” for every one of the errors. There were probably 20 of them. Once done, I compared my calendar on my computer and Google’s Calendar, they were identical. So for now, it looks like GCal’s CalDAV server may serve my needs after all. I could have avoided all this by directly importing my ics file into Google through their web interface.

Followup (August 27): So I got an iPod Touch and discovered that CalDAV calendars are loaded on the iPod Touch as “Read-only”. If Apple really wants to back CalDAV as a standard, you would think they would support it more fully on their own products. For now, I found that BusySync works quite nicely for syncing my iCal calendars with gCal in such a way that the calendars are hosted on my Mac and the iPod Touch then can treat the calendars are read-write. This, along with the lack of native ToDo list synchronization on the iPods are about the stupidest bits of inconsistency I have seen in using the iPod Touch. Luckily the ToDo list being missing from the iPod Touch doesn’t affect me as much as I am using OmniFocus, which works very well on the Mac and iPod Touch and allows synching between both.

As such, for now, since I prefer the X-windows version of SAOImage DS9, I am leaving the the Firewall off for now, I’m not too concerned.

• Upgraded the freetype library to version 2.3.6, which fixes “A bunch of potential security problems have been found [and fixed in this release”
• Upgraded to pixman library to version 0.11.4.
• Xquartz fixes from xorg-server-1.3.0-apple21, the key fix being support for monitor hotplugging, although several security fixes also occurred.

Again, if you upgrade MacOS (say to version 10.5.4, which is supposed to be released soon in order to support iPhone G3 and MobileMe), you will likely need to reinstall Xquartz (unless Apple has upgraded their X11 installation to match Xquartz).

Yesterday, Firefox 3 was released. I have been using the betas for the last month and have been happy with its improved speed and functionality. Its part of the reason I am back to about a 50/50 split in Safari vs. Firefox use. Today, the other show fell in the form of this posting on MacOS X Hints:

There is now a Firefox extension named firefox-mac-pdf, available for Firefox 3 under OS 10.5 that utilizes the built-in PDF support in OS X to display PDFs in-browser. In my testing, it appears to work very well. It doesn’t have the nifty fading bezel that the Safari PDF viewer does, but it supports all the same keyboard shortcuts and you get the standard Mac OS PDF contextual menu when you control-click on a displayed PDF.

Its interface is not quite as easy to use as Schubert’s plugin, but it works. I now have inline PDF viewing in Firefox and things are better in the world again.

Saving PDFs: The one issue I noticed is there was no seemingly obvious way to save the PDF once you were viewing it. Nothing in the contextual menu allowing “Save as…” for example. Turns out it was easier to save the PDF than I imagined. In the “Issues” page for firefox-max-pdf I found this exchange which included the solution:

Currently there are two ways of saving the PDF:

1. File->Save Page As menu
2. The apple-s (command-s) keyboard shortcut

[HOLD OFF ON THIS UPDATE! I have discovered that at least on one of my systems, this version of ds9 is refusing to run properly. It launched once, but when I attempted to check the “About SAOImage DS9”, it triggered the following error:

 “An internal error has been detected local header mismatch couldn't open “zvfsmntpt/doc/sun.gif”: no such file.

(this occurred in both Aqua and X11 versions). Furthermore, all future attempts to launch ds9 (again, either Aqua or X11) fail with the following error:

Error in startup script: couldn't read file “./zvfsmntpt/src/ds9.tcl”: no such file or directory  

Even removing the preferences file at ~/.ds9.prf didn’t help.]

Apparently, my problems with SAOImage DS9 in Leopard are a known issue. If you configure the built-in Firewall to “Set access for specific services and applications” so that you can approve “holes” in your firewall on an Application by Application basis, your first launch of SAOImage DS9 will irreparably damage the application!  Unfortunately, Apple implements the application firewall in part by modifying the Application package of the Application you are running by digitally signing it if it was not digitally signed by the developer (adding a file called CodeResources to the Application package). According the Apple’s documentation on this:

If you run an unsigned application not in the Application Firewall list, you will be presented with a dialog with options to Allow or Deny connections for the application. If you choose Allow, Mac OS X 10.5 will sign the application and automatically add it to the Application Firewall list. If you choose Deny, Mac OS X 10.5 will sign the application, automatically add it to the Application Firewall list and deny the connection.

So basically,Apple doesn’t warn you in the dialog box that comes up that it has whatever decision you make, it will modify the application by digitally signing it and it doesn’t give you a way to avoid this. This is, in my opinion, is an incredibly boneheaded move on Apple’s programmer’s part. They readily admit that

  Some applications check their own integrity when they are run without using code signing.

They suggest the application firewall will try to automatically detect these and avoid modifying them, but they should give you, the user, the option instead of making the decision via some internal algorithm.  MacOS X shouldn’t assume its OK to change an application. In the case of SAOImage DS9, they are irreparably damaging the application without leaving you a way to avoid the damage once you trigger the application firewall. Shame on you Apple. The only way to fix it is to reinstall the application!

So when I figured this out (a tip of the hat to this post on IRAF.net). I reinstalled the SAOImage DS9 executables (both Aqua and X11 versions) and before launching them, I set the Firewall (via the Security Pane of the System Preferences) to “Allow all incoming connections” (this is the default mode, so it is as secure as MacOS Tiger was). Everything now appears to work just fine.

Personally, I believe an application that fails its checksum should present a message indicating that is the problem instead of just crapping out, but in this case, the fault lies mostly with Apple. Apple is damaging applications by making this critical decision in the background, without user intervention!

The Xquartz folks have updated Xquartz to version 2.2.0.1. Xquartz is an effort to provide a better X11 server for Leopard than Apple provides, being proactive in providing fixes Apple will likely include later. The release notes are long and cover a bunch of updates to various items, including:

• Added informational output when falling through to failsafe startup in X11.app
• Unsetenv(DISPLAY) when falling through to failsafe startup in X11.app
• Exposé now works as expected
• X11 works better with spaces

I suspect the discussion of ‘failsafe’ startups is to provide a more informational failure than what was happening before for people like myself who transitioned from previous MacOS X installations and had been manually forcing the DISPLAY variable to point to :0.0, which is somewhat standard in the Unix world.

I’d recommend grabbing this Xquartz update and applying it if you use Leopard and astronomical software. Its a double-click install. Apple does watch this project (one of the developers is Apple’s X11 developer), and as noted on the Xquartz site:

Apple included some of the work done in this project in their 10.5.2 update and will likely include further changes in possible future updates of 10.5.x. It is suggested that you install the latest XQuartz release after updating to 10.5.2 (and any future 10.5.x or security updates).

In other words, while some of these fixes will likely end up in the official MacOS released by Apple, if you want them now, use Xquartz. Furthermore, since Xquartz does over-write Apple’s default X11 install, this means that if Apple upgrades X11 in a future patch, you could end up with a broken install if you used Xquartz. Personally, I haven’t had a problem, but I suggest you keep the Xquartz package around, and re-install it after any future MacOS X updates.

sudo port -d selfupdate
sudo port -d sync
sudo port install osxutils