Category: the value of X

if it’s broken, just say so

Mac OS X-Installing Perl 5.8 on Jaguar

OS X users that have installed Fink may experience various symbol errors when executing certain Perl operations. More on this can be found in the macosx@perl.org archives.

What this means is that perl 5.8 breaks fink. Plain and simple. This claims to be the solution, but right now I would just as soon get 5.6 back. It isn’t, but read on for a solution.

How annoying. There’s nothing in the excerpt above that I parse as “fink and perl 5.8 are incompatible: choose one or the other.”

Update:

The two versions of perl — the 5.6 release that ships with OS X 10.x and the 5.8 release that’s supposed to be better — put their libperl files in different places.So I simply copied the perl executable from another machine I hadn’t “upgraded.” I’d feel better if I had the original distribution or was building from source: that’s next, I guess.

-rwxr-xr-x 1 root wheel 862676 Jul 27 20:02 /System/Library/Perl/darwin/CORE/libperl.dylib
-r-xr-xr-x 1 root admin 1118836 Sep 10 12:25 /Library/Perl/darwin/CORE/libperl.dylib

/Library is for user-installed stuff and /System/Library is for, well, system stuff, what ships with the OS. Version numbers would be useful, but this filing convention saved me this time.

think different, and keep your options open

Apple Keeps x86 Torch Lit with ‘Marklar’

Sources said more than a dozen software engineers are tasked to Marklar, and the company’s mainstream Mac OS X team is regularly asked to modify code to address bugs that crop up when compiling the OS for x86. Build numbers keep pace with those of their pre-release PowerPC counterparts; for example, Apple is internally running a complete, x86-compatible version of Jaguar, a k a Mac OS X 10.2, which shipped last week.

Wade spotted this one.

I misspake: it’s Classic, not Aqua, that’s the hog

OS X load w/o Classic

I never thought about this, since Classic is pretty unobtrusive (you never see it as an application, just as a framing environment for Classic apps). I rebooted this OS X box today, and when I logged in, I stopped the Classic environment from starting (usually I load it at login time). Now as you can see, the load average is quite low on the graph.

So an Xserve might not come with a performance penalty after all.

I thought Classic was supposed to “sleep” when it wasn’t in use.

odd: why would Zoe need Aqua/Quartz to run?

As another datapoint on OS X and Aqua resource usage, I noticed that having Zoe running consistently kept load average around 1 or slightly above. Now that I have shutdown my login session, it won’t run at all. I get these errors:

kCGErrorIllegalArgument : initCGDisplayState: cannot map display interlocks.
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorIllegalArgument : CGSNewConnection cannot get connection port
kCGErrorInvalidConnection : CGSGetEventPort: Invalid connection

I don’t know why I have connection failures. I didn’t think you could display an Aqua session over a network connection (like you can with X).

Google found this tantalizing clue:
This is what you typically get when you try to start a quartz gui
application while logged in via ssh. So your configure script starts a
gui application which it certainly is not supposed to do.

So Zoe is evidently calling on some elements of the Quartz UI and failing. This removes a potentially useful application for Zoe: I could envision Zoe running on a group mailserver, allowing a group of users to view their mail in Zoe instead of in the old linear clients. It seems silly to think you need to run the Quartz stuff on a potentially headless system, especially if it chews up 25% of your CPU.

Update: I discovered it was Classic, not Aqua, that was churning away. So leaving an Aqua session logged in, annoying and non-secure as that as that may be, won’t be a resource drain.

fink and LyX: resolved

Well, I got it installed, but in a roundabout way. I tried a couple of things at the suggestion of the maintainer, but nothing worked.

I found a page linked from the LyX site that mentioned using FinkCommander, a GUI for fink, to install LyX.

I had never tried FinkCommander and installed it today. Then I tried installing LyX again. Doing it this way raised more dependencies. A-ha!

The following package will be installed or updated:
lyx
The following 4 additional packages will be installed:
gv xaw3d xdvi xfree86-base

This time it worked, right down to the xfree86-base install.

It also needed to install the xforms libraries but that was easily handled.

My guess is the dependency data isn’t being handled correctly, but why the Commander succeeds where the cli version fails is beyond me.

The principal benefit to using a packaging system isn’t the ease with which you install binaries — tarballs are fine for that — but to keep track of dependencies and version issues so you can maintain your system.

FinkCommander looks useful and it seems to work well, better than the cli version. And one of my favorite uses of a GUI is to learn the cli syntax from it, and FC supports that.