Speed up MacPorts compiles

If you’re not already using MacPorts, you should be. I’ve got some introductory posts coming that will explain why and how. For now, suffice it to say that MacPorts opens the vast universe of open source to Mac users. It isn’t new, but I think it has matured and stabilized such that even non-developers can start tapping the vast universe of free Mac-compatible software. While you’re waiting, now would be a good time to download the latest Xcode 3.x release. Note that if you use your “unlimited” mobile data plan for this, I am not responsible for your $3,500 phone bill.

Today, I’ve got a simple but effective tip for dramatically reducing MacPorts build time. By default, no matter how many processors or cores you’ve got in your Mac, MacPorts compiles one file at a time. It’s time you put your extra core (or cores) to a better use than keeping those Flash ads running smoothly in your minimized Safari windows.

Easy

Assuming you’ve installed MacPorts in /opt/local, edit the file

/opt/local/etc/macports/macports.conf

and locate the parameter “buildmakejobs”. Change the 1 to a 2 and save, then kick off a build (e.g. “port install something“). On a dual-core uniprocessor Mac, there’s no point pushing it any higher because two build threads will max out your CPU. Limiting RAM-hungry and I/O demanding apps (Safari, Word, Mail, Spotlight searches) increases likelihood of success.

Expert

If you’ve got a Mac Pro or (non-production) Xserve with plenty of RAM, buildmakejobs can conceivably go as high as the number of cores, but you might hit a memory ceiling or a disk bottleneck before you get there. You may want to set a couple of cores aside for foreground apps.

Activity Monitor will show you how far you can push it. If it’s too much of a pig, just Control+C the port command, dial back the buildmakejobs setting, and reissue the port command to resume the interrupted build.

Unfortunately, the buildmakejobs setting doesn’t make fetches (source downloads) and compiles run simultaneously. Stupid-fast broadband is a good investment, but some repositories are just slow. Your fans will announce the transitions between fetches and builds.

A special note for notebooks

If you have a MacBook Pro, plug your machine in before building and for pity’s sake, don’t set it or the charging brick on your lap, a bed or a sofa cushion during a build. The hardware gets hot, and the fan will scream. Unless you’re a gamer, you may never have pushed your notebook as hard as a lengthy multi-threaded compile will do. In particular, your first few builds will be horrendous as MacPorts builds commonly-used libraries.

This trick is worth trying on any multi-core Mac, even a Mac mini or MacBook. My hunch is that you’ll want at least 4 GB of RAM, but you might get by with less if you shut down other apps.

If you’re up for an adventure, MacPorts is also compatible with distcc for distributing builds across multiple Macs. I haven’t used that facility in years, but this looks like a good cause. I’ll report back.

Posted in Command line fun, MacPorts, Software development, Tips | Leave a comment

MacBook Pro trackpad goes all Ouija, gets cured

About a month ago, the trackpad on my MacBook Pro (5,3) became possessed. Even when I was nowhere near the machine, the cursor would zip around the screen erratically, registering left and right click events in random spots as if some hyper-caffeinated  toddler had hacked into Screen Sharing. None of the usual sanity-restoring tricks worked. I agonized over this and even bought an external trackpad until I found the genuine and low-cost solution: Clean the trackpad.

The MacBook Pro’s trackpad is glass. Unlike the glossy display glass, which makes the merest fingerprint or water spot scream “clean me!”, the trackpad glass’s slippery texture hides the presence of oils, minerals and other contaminants that interfere with multi-touch. With the display glass, it suffices to polish away fingerprints now and then with a soft cloth. But I learned that with the trackpad, what you can’t see can hurt you. Just rubbing it with a cloth didn’t help.

What finally did the trick was a spritz of eyeglass cleaner, a.k.a. camera lens cleaning solution. This stuff is designed to clean thoroughly without eating away at delicate optical coatings. It’s best to spray the cloth, not the surface, and a little goes a long way. Don’t drench it, and don’t use one of those sopping wet individually-wrapped cleansing naps or swabs. If any moisture gets under the trackpad or the keyboard, your trackpad could stop responding to tactile clicks, and your keyboard backlight might short out. Heed the voice of experience. These are costly repairs.

It turns out that eyeglass cleaner is the best and safest way to clean any tech surface. It restores Apple Aluminum to showroom luster, lifts oils and germs from keycaps and banishes that embarrassing veneer of obsolescence from your iPhone 3G S. And it smells great.

Posted in Hardware, Tips | Leave a comment

Screen sharing hyperlink, command line shortcut

Apple has thoughtfully wired up a URI handler for the Screen Sharing client bundled with Leopard. Put this in a (local!) hyperlink:

vnc://[user[:password]]@systemname.local[:port]

If you omit the credentials or supply only the user name, you’ll be prompted to enter them. URI magic works from the command line, too. Type this in Terminal:

open vnc://[user[:password]]@systemname.local[:port]

The system name (“systemname.local”) can be any fully qualified domain name, a Bonjour name, an IP address or anything that resolves with ping.

Posted in Command line fun, Xserve and OS X Server | Tagged , , , , , | Leave a comment

Intel v11 compilers: Don’t use -fast w/Nehalem

Mac software frequently uses the -fast compiler flag as an abbreviation for a common set of optimizations. Version 11 of Intel’s Pro C++ and Fortran compilers for OS X interpret -fast to imply -xHost, which means “optimize for the computer I’m using to run the compiler.”

I didn’t realize this until I compiled the SPECcpu2006 suite on a Nehalem Xserve. When I ran the compiled code on a pre-Nehalem Xserve (2,1), it bombed with this message:

Fatal Error: This program was not built to run on the processor in your system.

The allowed processors are: Intel(R) processors with SSE4.2 and POPCNT instructions support.

I’ve never had a microarchitecture fork bite me like this before. I wonder if the code that failed actually made use of any SSE4.2 or POPCNT instructions.

That’s no complaint; the error message is clear enough. I’ll recompile with explicit optimizations instead of -fast. If you get this error and can’t recompile the failing app, there’s nothing you can do.

Posted in Software development | Tagged , , , , | Leave a comment

POSSIBLE BREAK-IN ATTEMPT!

My 8-core Xeon Xserve seemed particularly noisy yesterday. The lights up front showed constant low-level CPU activity. That’s always suspicious. Cracking open Activity Monitor, I noted that launchd was chewing up 6-7 percent CPU. I went digging around my logs, and eventually came across a slew of these in secure.log:

May 28 14:04:24 maxx sshd[35110]: reverse mapping checking getaddrinfo for ip-88-188.neuviz.net.id [203.128.88.188] failed – POSSIBLE BREAK-IN ATTEMPT!
May 28 14:04:24 maxx sshd[35110]: Invalid user username from 203.128.88.188

That’s a verbatim cut from my log. Someone tried to log into my server as “username.” Next were “user,” “admin” and “test,” and then the dictionary words kicked in.

I don’t  see much need to protect the IP address of the PITA running a dictionary attack against my Xserve, whether that IP is bot-ed or not.

This is a log message that most admins would ignore. It’s notice that a break-in, if that’s what it was, was thwarted. But I’m a carbon minimalist. This jack-off is running up my electric bill by keeping my CPUs from sleeping. I wanted to cut him off before he stole my cycles and log space.

I already have sshd configured to accept logins from only one user, but this genius kept pounding on my server, filling up my log while I watched.

Instinct pulled me toward a new firewall rule, but I wondered: Are launchd’s TCP services run in a wrapper like they were in the old days? If so, then /etc/hosts.allow and /etc/hosts.deny (type “man 5 hosts_access” in Terminal) will filter connection attempts. I decided that there’s no harm in trying, so I poured the following into my server’s /etc/hosts.deny file:

ALL:  203.128.88.188

It worked immediately. The log went quiet, my CPU utilization fell below 1 percent and my Xserve fans spun back down to a whisper.

Posted in Xserve and OS X Server | Tagged , , , , | Leave a comment