I occasionally need to get access to my Mac remotely, but it's hiding behind a firewall. To get in through the firewall, I just need to use an SSH port forward command, like this:

ssh serverexternalip -L 1202:workstationinternalip:5900

For those of you not familiar with SSH port forwarding, this command connects to my server on its publicly accessible IP (serverexternalip), and then opens the local port 1202 and connects it to the remote host workstationinternalip on port 5900.

Port 5900 is the port Apple uses for its screen sharing application.

After these steps, I can open the Screen Sharing application and connect to localhost:1202, which transparently connects to the remote workstation through the SSH tunnel.

Obviously, this requires that the SSH session remain open as long as you're working in Screen Sharing.

There's a problem with port and non-port files conflicting if you try to install MacPorts' RubyCocoa after installing the official DMG binary release from the RubyCocoa site. You'll need to uninstall the .pkg file from RubyCocoa before running:

sudo port install rb-cocoa

I've just solved an issue with my GNU Screen setup on my new Mac for quite a while, and I thought I'd share the solution in case anyone else has this issue.

I use a shell script to initialize a customized screen session when I'm editing a Ruby on Rails application. This script launches a database console, AutoTest session, and development Mongrel instance, and organizes and titles all the screen windows.

I developed it some time ago on a MacBook Pro, and it suddenly stopped working properly on my new Mac Pro. The symptom was that all the shell-based windows worked fine, but the database console, rSpec, and AutoTest sessions all failed to boot, leaving blank screen windows.

The problem turns out to be Leopard's default screen command. It breaks the $PATH variable. The solution quoted in that post is to hard-code a shell command in .screenrc, but my solution was a little different. I just opted for installing the MacPorts version of screen instead. It's more up-to-date, and doesn't clobber the path.

sudo port install screen

Many Mac OSX applications rely on the built-in color picker. It's a great little tool, and far more full featured than the OS-centric color choosers in other operating systems. There's one small limitation, though... you can't input or export hex color values from it.... until now! The free Hex Color Picker from Waffle Software neatly adds this feature.

Waffle Software Hex Color Picker

There's no question that Microsoft Vista's User Access Control System fails in its principle goal (which is presumably to make users think twice before installing suspicious or unfamiliar software on their computers).

Why it fails isn't quite so obvious. It's not just because the message popup is annoying and a little vague, although those certainly contribute.

No, the real reason this design fails is that it prompts far too often. During program installs I ran today, I was prompted with nearly identical dialogs 5 or 6 times!! You get prompts at the start of every installer script (some applications have many parts, which results in many prompts), then you get prompts every time an application wants to perform new types of protected operations.

By the time I've installed the basic collection of software on my machine, I've clicked Continue so many times that it's a programmed response. I'm likely to hit Continue out of habit every time I see the window. It would be far more secure to present a single information dense dialog (so each one looks unique) that gave the installer free reign once approved.

It may sound absurd that making the thing less restrictive would make it more secure, but I'm confident that that's the case here. The user is the weak link in this process, but pestering and annoying tend to be poor ways to encourage a change in behavior... at least for most people.

Now, in fairness, my issue may be better raised with the installer code developers because the API likely supports multiple privileged operations to be performed after a single UAC prompt. I don't think this sufficiently answers the issue, though. On Mac OSX Leopard, I've never, ever been prompted more than once for Administrator approval during a software installation. Microsoft could learn a lot from Apple on this particular issue. Apple has done an excellent job of creating a developer community that values seamless, friendly user interactions. Microsoft seems to encourage the something entirely different.

So you've prepared a directory of files you want to transfer to someone else. Being a command-line guru, you decide to use tar. After tarring up the files and extracting them elsewhere, you find that there are mysterious additional files inside the tarball. Every single file has a "ghost twin" named identically except for a ._ (dot underscore) prefix.

For a long explanation, see this Ars Technica article. For the short answer, see below.

On Leopard

prompt> COPYFILE_DISABLE=true tar -czvf YourTarFileName.gz DirectoryToTar/

On Tiger

prompt> COPY_EXTENDED_ATTRIBUTES_DISABLE=true tar -czvf YourTarFileName.gz DirectoryToTar/

Of course, if you always want these features disabled, you could just add this to your ~/.bash_profile file.

# For Tiger
export COPY_EXTENDED_ATTRIBUTES_DISABLE=true

# For Leopard

export COPYFILE_DISABLE=true

Weird problem, simple solution. I have an external Maxtor backup disk connected to my Macbook Pro, and I cannot eject it. I get the error:

"DRIVENAME is in use and could not be ejected."

First, I try to use the lsof command to figure out what program still had open files on the drive. Unfortunately, I get no output, meaning no files are open on the drive.

Next I resorted to the Mac OSX hdiutil command. Using sudo hdiutil unmount reported that it was already unmounted.

Finally:

sudo hdiutil eject -force diskname

And the drive immediately disappeared from the Desktop. Hallelujah!