Urania

I host a reasonably large astronomical database on my office Mac (http://www.cabanela.com/MAPS_Database/), so I pay attention to migration issues with the web server component of the Mac OS. I suspected there would be some because Apple was switching to Apache2. I have in recent years been a fan of the “MAMP” setup (MacOSX, Apache, MySQL, PHP) and have used Apple’s preinstalled Apache, the binary MySQL installs, and a custom compiled version of PHP. This typically required banging on the configuration files for the Apache server a bit.

As I discovered, my web pages wouldn’t even load on the laptop under Apache2. The first step was finding the Apache2 configuration file at /etc/apache2/httpd.conf and editing it to re-allow PHP execution (uncomment the

#LoadModule php5_module libexec/apache2/libphp5.so

line). I still continued to get a permission error, I finally discovered that the MacOS X upgrade process didn’t move user website directory configuration files to the new location on the drive. I moved the individual user files from /private/etc/httpd/users/ to/private/etc/apache2/users/ and bang, I could view most of my personal webpages on my laptop again. But anything using URL re-writing still failed (including WordPress blogs). I had to change the AllowOverride configuration entry in my users’ configuration files to include Options, then everything worked again. I’ll still need to custom compile a version of PHP that supports GD2 and a couple other libraries I use, but this has been less painful than I naively expected.

So this weekend I decided to take advantage of the long weekend and between bites of turkey with the family, I decided to upgrade my laptop to Leopard (MacOS 10.5). I had been reading about the various issues with Leopard before the upgrade, so among the things I did in anticipation of Leopard was

• I uninstalled Unsanity’s Application Enhancer.
• I removed X11.app from my automatic launch items in the Accounts Preferences Pane Login Items. X11 is extensively refreshed under MacOS 10.5, so you don’t want to autolaunch X11.app any more.
• I upgraded Cisco’s VPN software to the latest version distributed by my campus (you want Cisco VPN Client 4.9.01 (0090)).
• I did a quick search of the various applications I run and looked for “Leopard” upgrades via MacUpdate.
• Finally, I researched the incompatibility of Adobe Acrobat with MacOS X 10.5. I discovered that while the AdobePDF printer driver broken under the new OS, you can use Apple’s built in PDF capability (specifically “Save as PDF-X”) capability to create the PDF, which can then import and edit just fine in Acrobat.

Having done all that, I decided to bite the bullet and install the upgrade. First thing I did was back up the entire internal drive to an external drive (which I had formatted with Disk Utility to make sure it was capable of booting an Intel Mac) using Carbon Copy Cloner. Once the drive was cloned, I ignored the overhyped warnings from MacFixIt.com (who I won’t link to, because they were bought out, they definitely sold out as a source of accurate help) and instead followed the Apple recommended procedure of just doing an upgrade to my previous Tiger installation. I figured if worst came to worse, I would recover from the backup drive (in my mind, the backup is the critical step, not how you choose to upgrade). So approximately 80 minutes later my laptop finished its upgrade and rebooted. Some notes on my initial issues with the new OS.

• The new dock doesn’t bug me as much as some (John Siracusa does the best analysis of the problems with the new Dock in his extensive ArsTechnica review of Leopard), but maybe its because I thought the old dock was broken enough as a launcher that I use QuickSilver instead (which works fine under Leopard).
• Leopard finally handles virtual memory use nicely, removing old files in the /var/vm directory once the memory has been released.
• I don’t like the translucent menubar, but there exist various free applications to get rid of those and the changed dock.
• The new OS nuked all my installed printers. Not a huge deal, but I have to re-install all my printers again. I kind of understand why this might of happened, but it was a pain.
• I had to use Disk Utility to Repair Permissions before my Widgets behaved properly, but now, they actually seem to run better than before (less delay in accessing them).
• I patched IDL to version 6.4.1, seems to work now.
• I knew from Ben Bayer’s (Apple’s X11 guy) postings on the matter that
  

  Biggest architectural change in Leopard for X11: Switched from XFree86 codebase (based on, IIRC, X11R6.8) to X.org codebase (X11R7.2)

  Biggest user-visible change: launchd support for X11. The only situation where you should need to manually start X11.app is if you are only running remote X11 applications.

  The way that this is accomplished is by some slight-of-hand with the $DISPLAY variable — if you look, it should be something like “/tmp/ launch-vbXRyu/:0″. If an X client connects to this, it will actually connect to launchd, which will start Xquartz if needed and pass the client’s socket to the server.

  All of that should be invisible to you; the X client library (libX11.dylib) was modified to support this, and all X11 applications link against this library. “DISPLAY=:0″ would still work if X11.app is already running, but it will not trigger X11 to launch.

  So in other words, we are not supposed to set the shell environmental variable DISPLAY to “:0″. Well, I removed all the times I set it from .tcshrc, .bashrc, .login, etc and it still remained stubbornly set until I remembered trying to get Carbon Emacs working a few months back required my setting environmental variables to my entire session using the ~/.MacOSX/environment.plist file. I opened it, removed the DISPLAY variable from the list of those set for the entire session, and viola. Almost everything worked as advertised except:

• SAOImage DS9 refused to launch because of the non-standard DISPLAY variable. I initially hacked around this by launching an xgterm (from IRAF) and setting the DISPLAY variable in it to “:0″ then launching ds9 within that xgterm session. I did this all in one line via: 

  xgterm -geometry 80x45+40+30 -sb -e 'setenv DISPLAY :0; ds9 -fifo ~/iraf/dev/imt1 -geometry 800x800+600+30 &'

  where I was connecting to my IRAF pipes (thus the ‘fifo’ command line entry). However, I emailed the SAOImage DS9 folks on Thanksgiving and they replied same day to tell me about the new ds9 darwin 5.1beta. That fixed the launch issues with ds9. Apparently getting the Aqua version updated is a bit trickier, so its not done yet.
• I had to uninstall the MacPorts version of xephem, but installing it manually from the source worked just fine.
• I installed the unofficial updates to X11 from Xdarwin (see MacSingularity for some notes). The biggest issues this fixes are (1) the focusing problem of X11 windows behind Aqua windows not always being “focusable” and a (b) bug in X11 that caused several programs using the Gimp Toolkit (aka gtk) to crash. NOTE: These updates have been superceeded by those on the MacForce XQuartz updates site.

All in all, I like the new upgrade, the most useful feature for me being the QuickLook interface and the just generally better networking behavior. I also think there has been a lot of thought put into nips and tucks (such as where the Firewall controls are now, in the “security” prefpane instead of “sharing”). More reports from the field as my usage of IRAF and ds9 under Leopard continues.

No… the new Scisoft OSX isn’t out quite yet, but I got the following note from Nor Pirzkal responding to my post regarding the various broken symbolic links in SciSoft OSX 2007.11.1.

Just to let you know that I just implemented your changes in 2007.11.2b. Thanks again.

So it looks like these bugs will be fixed when Scisoft OSX 2007.11.2b is released soon. I have to hand it to them, Nor is pretty quick to respond to these bugs, given he has a full time job which doesn’t involve maintaining SciSoft OSX!

Comet 17P/Holmes (Wikipedia) is normally a pretty innocuous short period comet that is invisible except to users of large telescopes. However, around 23 October 2007, it brightened up by a factor of about 1 million in 24 hours, becoming a clearly visible naked eye comet in Perseus (assuming you have dark skies).

Last night, I went out to the Feder Observatory, our campus observatory, to learn how to use the new telescope control system and CCD camera. This new system is a replacement for our old system which became a mouse’s final resting place (details here). This new system is on our old reliable 16″ Dave Weinrich (our planetarium and observatory guru), Jack (a student), and I decided to target Comet 17P/Holmes. Now mind you, there are still collimation issues with this telescope and we haven’t quite worked out the focus vs. temperature function, but this came out pretty good for a first shot of the comet.

Wow, Nor Pirzkal and Francesco Pierfederici have kept quite busy making small updates to Scisoft OSX for Intel. They released another new version today (available for download here). Here’s the entire description of the changes in this version of Scisoft OSX from the release notes:

This version updated Python to version 2.5.1 and correct some minor issue with the bash version of the irafuser.bash script when running under OSX 10.5 Leopard. Missing GCC runtime fortran libraries are also now included. This version was test under OSX 10.5 and seems to run fine. Note that 10.5 does deal with X11 applications slightly differently. Once the Setup.bash script has been source[d], you should add the following line to your .bash_profile: export DISPLAY=127.0.0.1:0.0 This will enable all Scisoft X11 applications to start from Terminal.app

I am not running Leopard (and probably will not switch until the winter break, when I have time to deal with all the X11 issues it creates), so I can’t confirm the ability to run under Leopard, but its great to know they are keeping SciSoft OS X up to date. Issues with this Release of Scisoft OSX

• I did notice this new version of Scisoft OSX doesn’t appear to link its IRAF install with the rvsao IRAF package (used for radial velocity computations). Doesn’t matter to me to much since I compiled the newer version and linked to it, but it is funny they include the rvsao package at /scisoft/all/packages/iraf/extern/rvsao but don’t link to it in the $hlib/extern.pkg file, which I do believe they did in the older versions.
• I may not have noticed this earlier, but in the libraries directory /scisoft/i386/lib, some of the symbolic links are broken. Specifically:
  • All the items in this directory linking to the OpenMotif library items are not linked, it appears /scisoft/i386/Packages/OpenMotif-2.3.0/lib doesn’t exist. However, /scisoft/i386/Packages/OpenMotif-2.3.0/lib.org does. So I symbolically linked lib to lib.org via:

    cd /scisoft/i386/Packages/OpenMotif-2.3.0/
    ln -s lib.org/ lib

    And now all the links to the OpenMotif libraries within /scisoft/i386/lib work.
  • The CFITSIO library is mis-linked to an older version which no longer is installed. So I needed to:

    cd /scisoft/i386/lib/
    rm libcfitsio.a
    ln -s ../Packages/cfitsio-3.040/lib/libcfitsio.a libcfitsio.a

    and the CFITSIO library was properly linked again.
  • libpng.so was apparently not compiled within /scisoft/i386/Packages/libpng-1.2.10/lib, so there is no quick fix for that broken link.
  • I removed a link to python2.4 in /scisoft/i386/lib and replaced it with a link to python 2.5:

    cd /scisoft/i386/lib/
    rm python2.4
    ln -s ../Packages/pygtk-2.8.6/lib/python2.5/ python2.5

• All the CFITSIO headers in /scisoft/i386/include/ are linking to an older version (3.006) instead of the current installed version (3.040). Fixed via:
• There are symbolic links in the /scisoft/i386/bin directory to a variety of executables from the sm plotting package which doesn’t appear to have been installed as part of the Scisoft OSX distribution.
• Not really a bug, but the version of SAOImage DS9 is version 4.1.3 and not the current version 5.0.0. Of course, given the long history of dangerous version X.0.0 software, this maybe safer that way.