I'm not sure if what I propose here is necessary or safe, but I'm willing to experiment. I already use SpiderOak to synchronize my /home folder across these two machines. Now I'm going to make sure that they have the exact same software installed. They started out that way, as pristine machines off the same Ubuntu 10.04 installation DVD. They had no trouble staying similar enough for a while. When I installed Vim and KeePassX on one, I made sure to immediately install both on the other. Later still I did the same with SpiderOak, R and then with a few other things. All along, I figured that there had to be a better way, and I might even get around to googling it sometime.

That time came today, after I got the vim-latex plugin and a full install of TeX Live on Machine A. Google turned up these instructions. They're pretty good until they go into Windows-related details that you may not care about.

So, here's what I think might work:

You take Machine A. Check for updates as usual, and install them. Then close the Update Manager, and open Synaptic. Select all the installed packages, mark them for re-installation, and then instead of hitting "Apply" go into the "File" menu and click on "Generate a download script". The download script is is just a list of wget -c commands applied to each .deb package that corresponds to everything that you have installed on Machine A. Call it something descriptive, like machine_a_packages, and copy it to Machine B inside a folder of its own. Call that folder something descriptive too, like new_downloads. Then run the download script with sh.

Now, on Machine B you have just populated a folder with all the .deb packages you need. Open Synaptic on Machine B, and in the File menu click on "Add downloaded packages" and navigate to "new_downloads" in the dialog box/Nautilus window that opens. Hit Open, and watch the magic: Synaptic will go through all the packages, pick out only those that aren't already installed on Machine B, and announce that it will install them, unless you object. That's it. Now delete the folder "new_downloads", because it's big and you don't need it anymore, I don't think.

After this, another SpiderOak run should copy any new or changed dot files from Machine A to Machine B, and that should do it. If there is a better way, I'm curious. If I wrecked anything, I'll know soon enough.

I now use two laptop computers -- my own and the one I got from work. I have been wondering for a while if there was an easy way to deploy the same home environment across different physical machines given that you would need it for some reasons, but not for others. For example, if I want to write code or surf the web with synchronized Chrome instances, I want a uniform environment so I can easily pick up on one computer where I left off on the other. But it's also reasonable for a computer that I use mostly for work to have different settings from one that I use mostly for play: for example, my work computer needs hard drive encryption and remote IT assistance tools, while my home computer does not need MS Office, because for my own letter writing and bookkeeping I am happy with OpenOffice.org.

My proposed solution:

One obvious way to have a uniform home environment across computers with such different requirements is to put it inside a virtual machine. The VM's from different computers keep their common settings in a Dropbox folder, which is updated quietly every time you go online. Here's how that folder could be used to have the same Vim environment across multiple computers, all the time:

My two VM's are Ubuntu 10.04, created in VMware Player 3.1.2 from an x86 ISO disk I burned. Each has a Dropbox folder. In it, there's a vim folder, and in it there's the vimrc.local file that I want to apply on both machines. Now in each VM's /etc/vim/vimrc file I change this:

" Source a global configuration file if available
if filereadable("/etc/vim/vimrc.local")
  source /etc/vim/vimrc.local
endif

to this:

if filereadable("/home/username/Dropbox/vim/vimrc.local")
  source /home/username/Dropbox/vim/vimrc.local
endif

For this to work, your username must be the same on the two Ubuntu VM's. If by chance it's not, one easy way to fix the problem is to enable a root account on one of them, as described here, log in as root, then in a terminal window do this:

usermod -l newname -m -d /home/newname oldname

This has the effect that both your login name and your home folder will change from oldname to newname, as explained here.

I wish there was a more elegant way, but I couldn't get /etc/vim/vimrc to source to $HOME, so this user name constraint seems to be binding. A slicker way to go would be if the whole /etc folder could be housed in Dropbox, and your applications knew to look for their runtime configurations there.

How would you solve this problem?

On the recommendation of my friend Bálint Érdi, I signed on with Dropbox, and I figured one good use of it would be to keep my vimrc files in sync across three virtual Linux computers I'm having to use.

So, I went looking for the originals -- the Vim configuration files on the Linux Mint 8 VM that I am using now. Except I didn't go straight to the VM. I took a detour through Chrome, and typed this in the address box: "where is .vimrc". That got me here, which is a comment thread that happened six years ago.

Of course, the answer is trivial: # locate vimrc. That's UNIX love right there. If you want to find a file, just locate it. If you're the almighty root (#), the computer will fetch it without a fuss. But the more fascinating bit is a little further below, posted by the user Wolfbone:

.foorc = runtime configuration file for programme "foo" located in user's home directory.

/etc/foorc (if it exists) = global (all users) runtime configuration file for programme "foo", overridden by .foorc, if it exists.

Suggesting to someone who cannot find an 'rc' file that '#locate vimrc' is a useful command is not very helpful.

I had no idea that vimrc was called that in order to respect this [r]untime [c]onfiguration naming convention. I also had no idea that the ~/.foorc files are there to override /etc/foorc files. Sounds like an architecture thing. I am guessing that the common use is that your IT guy will put configuration files in /etc/foorc, and if you like those, fine. If you don't, just make up your own .foorc files and stick them in the home folder. Neat, but it gets even better.

If you run this # locate vimrc command, it'll turn up /etc/vimrc.local. If you then cat vimrc you can see that it defers to vimrc.local if it exists. So, there are two available layers of configuration overrides: first is /etc/vimrc.local, then ~/.vimrc, which reigns supreme. What's the use of that? And how is this implemented in FreeBSD? My initial guess was that the FreeBSD convention is that rc is a file extension, as in mail.rc. But then in the /etc folder I also saw things like rc.firewall. And in /usr/local/etc I saw things called ddclient.conf. What's different between files that start with rc., or end with .rc, or end with .conf?

So many questions, so little time. Still, this is better than my experience with Windows, where things either just work (thank you, Windows 7) or they're so arcane that, if I ever attempt them, it's always on guts alone. I have no theory whatsoever of what might go wrong.

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.

There was one small hiccup: one of the recent updates to rdesktop must have overwritten the /usr/share/rdesktop/keymaps/common file, because all of a sudden I could not use the Caps Lock key on the remote desktop. That's OK. I googled it as usual, and I found help here. Also as usual, those lively Ubuntu forums will send you all sorts of places before you hit something useful. You're happy when you find it, then the next moment you appreciate paid customer support. Then the moment after that you think OK, but it didn't take that long, and it didn't cost a dime. There's room for all of us, it seems. I wish Microsoft the best of luck. I wish Canonical the same.

Next up: fix the "Connect to Server..." item on the Places menu in Gnome. I can't SSH into the home server from there anymore. I can do so from a terminal window, and I can still auto-mount my home folder on the server via NFS, as documented earlier here and here. Auto-mounted NFS shares are best anyway, because that way my stuff on the server is available on the client automatically at start-up.

I spend most of my work day connected to a Windows Server 2003 machine sitting in a colocation facility in Atlanta. I write and run Stata code on it, use the MS Office products, a bit of Gmail -- the usual stuff. As it turns out, the Ubuntu half of my computer has a much slower connection to this thing than its Win XP Pro sister does. It's so bad it's heart-breaking. I like Ubuntu, but I can't type very well with a two to three second lag. This should not have happened. Before I turned my main machine (a Dell Latitude D630) into a dual-boot system I had puttered around with a Dell Latitude D400 running Hardy LTS. I was pretty happy. I certainly don't remember the VPN connection on that computer being this slow.

Google didn't help much. There is some consensus that tsclient with RDPv5 is slower than mstsc.exe (the program behind the Remote Desktop Connection on Windows XP), but it doesn't sound like the difference is as painful as I'm feeling it. I have not found any working guidance to maybe fire up rdesktop without tsclient, which I was hoping might speed things up a bit, under the hypothesis that fewer apps in the chain are better than more. So I am not sure if the standard-issue Ubuntu solution -- tsclient+rdesktop -- has suffered some performance decrease between Hardy and Jaunty, or getting a remote desktop in a bigger full screen is going to be that much slower. I have no other ideas.

Has anybody seen this before? One thing that might still save this migration project is that the server in Atlanta is on its last leg, to be replaced soon by a far better system, running 64-bit Windows Server 2008. That should come with a Remote Desktop server with RDP version 7 according to Wikipedia. Maybe that will speed things up a bit on my end too -- if not right away, maybe another month or two into Karmic.

Suppose you don't want to do that. Suppose you just want to get the code all in the same directory structure on your local machine, and only the code, not the associated html files that make it render in a browser. In that situation, you can do this:

wget -r -np -nH -R "*.html*" http://www.sobell.com/UB2/code/

Recursive downloads with wget are discouraged because they hit the web server hard with a fast succession of requests. But I think the example above is a case of polite wget use: it only downloads what the original host of the code intended to make available for downloading. The -r part means "recursive". The -np part means "but not upwards". The -nH part means "and do not visit any hosts referenced here". Finally, the -R "*.html*" part means "and I don't want any file with .html in it".

As it turns out, wget can do a lot of things, so its man page is rather long. I googled around for a more concise reference, and I found this. Enjoy.

You also need to download the Oracle Instant Client. Download all three rpm files -- basiclite, devel and sqlplus -- not just the first. You do need all three. Finally, the ./configure [...] line in debian/rules took some fiddling. I read this post by Arun Mallikarjunan and, emboldened, I tried a few variations of my own. This is what worked:

./configure --prefix=/usr --with-oracle=/usr/lib/oracle/11.2/client
--with-instantclient --without-rpath --disable-new-check --without-kde
--with-oracle-includes=/usr/include/oracle/11.2/client
--with-oracle-libraries=/usr/lib/oracle/11.2/client/lib --enable-libsuffix=

The above is all on one long line. Incidentally, Arun commented here that in addition to the prerequisites Brad listed, you need a few others. Brad disagreed here. He is right that the extra packages on Arun's list not are required. But if you install them, you also get MySQL and ODBC support enabled, so I did. One time last year I had to odbc load some data from a MySQL database into Stata (I found help for that here) and I figured the need might come up again. Finally, I cleaned up after myself with help from here.

Over the weekend I decided it was time to raise the stakes, so I turned my main machine into a dual-boot system with Windows XP Pro and Ubuntu 9.04 Jaunty Jackalope. Now I am in the process of deciding whether the Ubuntu half might cut it alone as a work computer. I got Skype working on it and I got a PPTP VPN connection to my team's Windows server in Atlanta. Those are both essential. I also put gVim on it. As of version 7.0 it comes with Jeff Pitblado's Stata syntax file installed. That will be nice. The ability to use my BlackBerry as a tethered modem would be good too.

So, we'll see. There's not a lot of real pressure to switch. I buy my computers refurbished, from the Dell outlet. I always end up picking a system configured for business use, with one of the better Windows versions pre-installed and no crapware. This has worked out well for me. My little Ubuntu excursion has been driven by curiosity at first, and then I just liked what I saw.

OK, so that's the setup for this post, which is also about SciTE. I have been using this editor on my Ubuntu machine for writing C++ code for three separate courses now, most recently one on data structures (final exam was two days ago; here's to hope). So I thought I'd use it for Python as well. It works as well as ever, especially after a visit here. Google had sent me. I was looking for a way to clear the output screen (turns out clear.before.execute=1, in the user properties file, will do it).

I'm falling hard for SciTE. And I'm doing in Python in one evening things that took me weeks in C++ to figure out, which is nice, though not entirely fair. Had I not had that experience, I'm sure I wouldn't find it so trivial. Still, I am impressed.