Urania

When I first started this blog, I was using Apple’s built-in X11, but then with the transition to MacOS 10.5, there were some serious issues with Apple’s X11 implementation having to do with the transition from X11R6 to X.org. One of Apple’s programmers started putting out bleeding-edge updates to Apple’s X11 called XQuartz that fixed a lot of the programs and I have kept using it ever since.

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.

I just noticed that the XQuartz folks released X11 2.3.3, but when I attempted to install it, it said I needed Mac OS 10.5.7 installed, which hasn’t been released yet. I have confirmed this on the release notes page. The full release notes seem to describe to major changes, updated support for OpenGL and some bug fixes regarding Caps Lock and mouse tracking.

Interestingly, the XQuartz wiki notes that

[MacOS] 10.5.7 updates the X11 server to match what shipped with 2.3.2. Most of the userland, however, only saw security updates. The version reported by X11 in 10.5.7 is 2.1.6 to distinguish it from the 2.3.x series which contains a much newer userland.

I have the feeling that the update to MacOS 10.5.7 will be released very soon now.

[UPDATE: In fact, it took almost two weeks, but MacOS 10.5.7 was released on Tuesday, May 12, 2009.]

There are some older school astronomers on Macs who cut their teeth on Linux and as such really prefer the full-screen X-Windows display for running astronomical data reductions. This way of running X11 has been unavailable since MaxOS 10.5 (which switched from X11 code bases). Well, to quote Macros Huerta’s MacSingularity Blog:

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.

Today I noticeed two interesting software updates for Mac-based professional astronomers.

The first one I noticed was the updating of Xquartz to version 2.3.0. Xquartz is the updated version of X11 for the Mac OS (even ahead of Apple’s own installed versions) that I prefer to use, largely because bug-fixes get rolled in here before they appear in Mac OS. This version requires Mac OS 10.5.4 and has a couple of caveats attached to it for programmers, notably:

The software supporting the deprecated imake build system is not provided in this package. If you need imake and xmkmf, please install the X11 package that came with your Leopard DVD before installing this version. Alternatively, you can compile these packages on your own or get them from a third party such as Fink or MacPorts. The darwin configuration files used by the imake build system are outdated and not supported. Developers using this build system are advised to migrate to autoconf.

[Added July 24, 2008: Apparently, this version of Xquartz changed the X11.app Icon so it now X11 looks like this

when it is on the Dock. Interesting, but it threw me for a second. The only documentation I found of this change is in a Ticket filed with XQuartz's bug reporting system. Still, I think this is a good idea, as it gives a visual cue that you are using XQuartz as opposed to the default X11 installation.]

Along with a bunch of library changes, the key update appears to be having the Xserver updated to the 1.4 branch of Xorg. There is also “support for adding new $DISPLAY sockets after the server is running” (which I think means using the DISPLAY variable will not break things) and “/usr/X11/bin/Xquartz is just a stub that will ‘do the right thing’,” whatever that means. I have upgraded to it and as a reminder, if you upgrade MacOS after installing Xquartz, you will need to reinstall Xquartz to get it back.

The other interesting software release for Mac-based astronomers I noticed today was SAOImage DS9 which has released version 5.3beta, which appears to be, based on the statement on their homepage that “MacOSX 10.5 users with firewall enabled, please use version 5.3 beta”, geared toward addressing the issue I noticed this April with version 5.2 where launching SAOimage DS9 with a certain firewall setting on the Mac could result in the the application becoming irreparably damaged at launch.

I was trying to upgrade wine within MacPorts when I realized I had forgotten to upgrade Xquartz after my upgrade to MacOS 10.5.3 on my Mac Pro. So I checked, Xquartz has been upgraded to version 2.2.3. Since version 2.2.1 (which I talked about in my blog here).

• 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).

The Xquartz project is a useful one for Leopard users of astronomical applications because of the dependence of most astronomical applications on X11. A few days ago (what can I say, its finals and I am swamped with exam writing and grading) they released version 2.2.1. It contains all the tweaks that made it into the previous version and also includes

• All packages updated to versions intended to ship as part of X11R7.4 (as of 2008.04.21).
• Fixed multiple crash-causing bugs in the server.
• Fixed cmd-tab to properly move all windows forward when entering X11.app.
• Cleaned up multi-monitor support (still not completely bulletproof) [I have 2 monitors, so this is a big one for me].

As I have noted before, Apple includes some of the work done in this project in OSX updates, so 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).

Immediately after installing SAOImage DS9 5.2, I had a major failure of the application and initially I just thought it was some sort of build bug. This is what I posted at that time:

[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!

[See my more recent post warning about MacOS X Firewall settings and how they can destroy the SAOImage DS9 executable during its first launch! This problem is avoidable by tweaking the Firewall settings, but once you have launched SAOImage DS9 with the bad settings, the application is damaged can can't be relaunched again. A reinstallation is the only solution, so it is a good idea to avoid this problem.]

The folks in Cambridge have kept busy. They have released SAOImage DS9 version 5.2. The versions for MacOS X include the following:

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

The rather extensive changes are detailed in the release notes here, but the notable ones to me include:

• ANALYSIS: for MacOSX tiger, wrap cmds with shell and PATH.
• GUI: change default directory for standard dialog to $HOME.
• ANALYSIS: add /sw/bin to default path for MacOSX. While unstated in the release notes, this is clearly an attempt to support Fink, which places its installation in the /sw directory.
• GUI: ds9 will now start in the users home directory for MacOSX Aqua users when invoked from a double click and the default dialog box is Motif or Windows.
• MACOSX: fixed a problem with printing non standard colors.
• MACOSX: restore postscript printing.
• REGIONS: apply WCS to fits regions if present.
• GUI: add support for user configured button bar.
• CATALOGS: add support for simbad.
• IMEXAMINE: added support for key stroke events.
• Although unstated in their release notes, they are now apparently providing universal binaries instead of PPC and Intel binaries for MacOS X.

I have previously posted notes for integrating upgrades of DS9 into the Scisoft OS X installation and they still work just fine.

[This originally linked to version 2.2.0, but there was a security related bug in version 2.2.0, so this release has appeared to replace it.]

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.

I have taken part of my day to get my main web server upgraded to MacOS X 10.5 (aka Leopard). I spent quite a bit of time waiting, removing programs I knew were incompatible, and so on. Still, this upgrade was not without a few bumps:

• Check Hardware Compatibility: My Sonnet Tempo SATA X4P card (which I use to provide an external SATA [eSATA] interface for my RAID of data drives) was incompatible with Leopard and would cause the installer to hang. I finally discovered a firmware upgrade was available that fixed this. This was a stupid rookie mistake. Rule of Thumb: Always check the non-Apple hardware for updates before making a major OS X upgrade.
• Watch out for /home: I had been using a symbolic link from /home to /Users because in my old Unix days, I hardcoded a lot of my software to look for my home directory in /home. Leopard expects /home to be available as mount point for the automount service, so getting with the modern era and not relying on /home to point to /User is required if you adopt Leopard.
• Rebuild Web Server Configuration: One problem I was prepared for is that the web server was updated to Apache2. This in itself was not bad, but the configuration files for Apache (version 1) were stored in /etc/httpd and the new configuration files for Apache2 are in /etc/apache2 and they were NOT migrated. I don’t fault Apple for not migrating the files, but I kicked this around on my laptop quite a bit in order to tweak the configuration files back to something I liked. One thing I immediately did was that this MacOS comes with PHP 5.2.4 preinstalled, but not enabled in Apache2. I enabled it by editting the /etc/apache2/httpd.conf file (which you might have to create) and uncommenting the line with # LoadModule php5_module (by removing the ‘#’ symbol from the beginning of the line). Once that was done, I restarted the Apache2 server and all my PHP code (including this blog) was running again.
• Tweak MySQL for Leopard: The PHP 5.2.4 included with MacOS X is compiled with support for MySQL. This is nice in that you can just download the MySQL package installer and quickly get a LAMP server running. However, it was set up with the MacOS X Server version of MySQL in mind, which means it expects the socket to be in a different location than the vanilla MySQL. This can be solved by either tweaking the MySQL configuration (as outlined in the MySQL section of the blog post at http://remysharp.com/2007/10/27/lamp-in-leopard-osx-105-php5-and-apache-22/ ) or by tweaking the PHP configuration by editing the /etc/php.ini file (if it doesn’t exist, first copy /etc/php.ini.default to /etc/php.ini) and search for the line containing mysqli.default_socket = to read
  

  mysqli.default_socket = /private/tmp/mysql.sock
  

  This solution seemed more straight forward, so I did this.
• Reinstall MacPorts: Since I am aficionado of MacPorts, I reinstalled it and rebuilt all the ports. Some of the issues I had before with MacPorts on Leopard on my MacBook Pro cropped up again on my PowerMac G5, notably
• • gv still needs to be patched as I noted here.
  • sqlite3 still does know about its dependence on nawk.
  • xterm doesn’t install unless you update your X11 installation using the latest version of Xquartz (currently at version 2.1.4).
• Update to latest version of Xquartz: Since I don’t like X11 headaches, I updated to the latest version of Xquartz (currently at version 2.1.4).

So the adventure continues. Back to research, I have invested about 5 hours of my spring break into this upgrade, that is enough for now.

The folks behind SAOImage DS9 have now released version 5.1. The big change I’ve noticed since the last version is that version 5.1 works without issues under Leopard’s new X11 implementation. Of course, the disadvantage is you now must download a version compatible with your OS version as well as your CPU.

• If you want the Aqua (MacOS X native version, download the appropriate one of the following files. If you want to use the Aqua-native version from IRAF, you will need to access the command-line binary within the SAOImage DS9.app application bundle as “SAOImage\ DS9.app/Contents/MacOS/ds9“.
  • MacOSX 10.4 Tiger Aqua Interface, Universal (PPC and Intel)
  • MacOSX 10.5 Leopard Aqua Interface, Universal (PPC and Intel)
• If you want the X11-based command line driven version
  • Darwin PPC 10.4 Tiger version
  • Darwin Intel 10.4 Tiger version
  • Darwin PPC 10.5 Leopard version
  • Darwin Intel 10.5 Leopard version

More detailed release notes are available here. See my previous post on SAOImage DS9 5.0 to see how it is possible to upgrade the binaries included with SciSoft OSX.

The latest XQuartz release (2.1.1) finally fixes one of the major annoyances I was having with X11 under Leopard. Because the X11.app program under Leopard is really an xterm launcher, starting X11 always started an xterm window. This has now been fixed. All you need to do is install the new XQuartz package (WARNING: Because this changes the launch daemon settings, you will need to restart the computer afterwards) and then once you have rebooted, type the following command into the terminal:

defaults write org.x.X11 app_to_run /usr/bin/true

And you have xterm-free X11 again. Furthermore, this updates xterm as well, so even though I don’t want xterm to launch automatically with X11, I am happy to have it updated.