First, in VMware Player (as of 3.0) you edit the virtual machine settings -- enable Shared Folders in the Options tab, and add a host path there -- say C:\data\share_with_vm. You can add several distinct Windows paths here.

Next, you add this line to /etc/rc.local right before the "exit 0" line:

mount -t vmhgfs .host:/ /home/user/Shares

Your Linux virtual computer will see any of the Windows folders you shared at the first step as children of the ~/Shares directory. Adding this line to /etc/rc.local makes Shares available to you as soon as you start the VM.

This is how I do Linux on my work computer now, after I first tried Cygwin, then had a dual-boot setup for a while.

Anyway, so far Ubuntu's been great, but things occasionally do seize up on it. Frozen processes that refuse to obey a regular shutdown order -- you know, the click on the x button in the upper right corner -- can be killed the Unix way: with xkill. The details are here. Other solutions -- some gentler, some harsher -- are also described, but this is my favorite.

So, my recap: in the "Run Application" dialog box that opens in response to Alt+F2, or in an open terminal, type xkill. This turns the mouse into the x of death. Move it over the non-responsive window and click it. It's very satisfying.

Speaking of resurrecting old gear: if you have such designs, and you're a fellow Dell customer, consider Renwerx Tech. They may refurbish and sell parts for other brands too, but I know that their Dell section is superbly laid out. I gave Dell first dibs, seeing how they had a record of what equipment I owned, and thought they'd match my parts searches properly. I only went looking for alternatives when they blithely tried to sell me a French Canadian keyboard.

Suppose that the remote box were called myUnix. Also suppose that I had a folder there with do-files, called myDofiles and another, with data sets, called myDtafiles.

This is how I would make Stata run a do-file saved on the server:

run \\myUnix\myDofiles\myFile.do

And this is how I can load into the PC's memory a .dta file stored on the FreeBSD hard drive:

use \\myUnix\myDtafiles\myFile.dta


If one of these days I can find the time to experiment with how Stata could hook up with R and to what profit, I will do that across the two computers, for a bit of extra educational benefit. But I can't be bothered right now.

There are two encrypted key files. One is public and resides on the server. The other is private and is saved on the laptop's hard drive. On the server, from the command prompt of your user account you type

> ssh-keygen -t dsa

This will generate two DSA-encrypted key files, one called id_dsa and the other id_dsa.pub. The process is interactive. You can choose where to save them and whether you want to associate them with a passphrase (click Enter twice for the default directory /usr/home/user/.ssh and no passphrase).

OpenSSH, which I installed following the instructions in this book, has a configuration file that on a FreeBSD system goes by /etc/ssh/sshd_config. On a Linux machine it might be saved somewhere equally logical, but different. Anyway, that configuration file, by default, expects the file id_dsa.pub to be a line in the file /usr/home/user/.ssh/authorized_keys. So, the first time you set this up, just do this:

> cd /usr/home/user/.ssh
> mv id_dsa.pub authorized_keys

You may have another computer you would like to log into the server from, but don't want to use the same private key. You can repeat this ssh-keygen process and append the new id_dsa.pub file to the existing authorized_keys file like so

> cat authorized_keys id_dsa.pub > authorized_keys

The order matters. With authorized_keys first in the cat queue, all of its content will be preserved and that of id_dsa.pub will be appended to it, as it should be. If you reversed the order, id_dsa.pub would be written on top of the beginning of authorized_keys. You don't want that.

Now that you have id_dsa.pub copied into authorized_keys file, you turn to id_dsa. This file needs to be on the client computer. You definitely don't want to e-mail it. You can save it to a USB stick and take it there or you can transfer it securely with pscp.exe, but explaining the workings of that would take another post. Anyway, once you got your id_dsa saved on the Win XP client computer you're still not done.

PuTTY cannot read OpenSSH key files directly. You must download puttygen.exe and have it translate id_dsa to id_dsa.ppk. The complete instructions for doing that are here. You will notice that they were originally written for running OpenSSH on a Linux server. They worked for me.

The best way to test your setup is to go back to /etc/ssh/sshd_config, set

PasswordAuthentication no

and save over. Then, as super-user, do

#/etc/rc.d/sshd restart

and try to connect via PuTTY. If your key file is recognized and you didn't set a passphrase you will be let right in, without being prompted for any password. Your connection is both secure and convenient.