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

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