unix

VirtualBox's native shared folders will be used by default on Windows with the type of your synced folder set to nfs, or if it's not set. This method works great in many cases, but can be fairly slow when doing work with projects with many files in a synced folder, as is often the case with Drupal sites that I work with in Drupal VM.

Another option is to switch the type to smb. This is often a plug-and-play change (vagrant reload to make the change take effect—you'll likely need to enter in your Windows username and password during the startup process. However, symlinks inside the synced folder will likely break, and so we need to make one more important change:

The synced folder configuration needs to have:

I love finding little gems like this: The Story of the PING Program.

The best ping story I've ever heard was told to me at a USENIX conference, where a network administrator with an intermittent Ethernet had linked the ping program to his vocoder program, in essence writing:

ping goodhost | sed -e 's/.*/ping/' | vocoder

He wired the vocoder's output into his office stereo and turned up the volume as loud as he could stand. The computer sat there shouting "Ping, ping, ping..." once a second, and he wandered through the building wiggling Ethernet connectors until the sound stopped. And that's how he found the intermittent failure.

I've often had trouble copying files with Mac OS X's Finder. From back in the Mac OS X Beta days (when it was based on NeXT's UI), hard drive to hard drive copies, network copies, and backups have often had strange quirks, and one of the strangest I've yet found happened yesterday when I tried copying a ~170GB Aperture library from one external USB drive to another.

I tried copying the library three times, and each time the copy would get to about 24GB, the hard drive (from which the library was being copied) would make a loud CLICK, and then it would unmount and remount, stopping the library file copy. This particular drive has never had troubles in the past, and the fact that it kept doing the CLICK-die thing at 24GB meant that there may have been a file problem or a Finder bug causing the problem.

I verified the drive using Disk Utility (could've gone deeper and used other utilities too), but only found one or two small errors (a file count one file off, or a few improper permissions). After repairing the disk, the drive still clicked off at 24GB.

For some time, I was having trouble getting the arrow keys to function correctly in my terminal sessions when logging into one of my remote Linode servers running Ubuntu 10.04. Whenever I pressed an arrow key, instead of moving the cursor or going up and down the command history, I would get a string of gibberish like [[A^[[B^[[D^[[C. Not very helpful!

So, after some searching, I found that the cause for this is an incorrect shell environment being set in the passwd file. To fix this problem, simply edit the /etc/passwd file and change the final string (after the last :) to /bin/bash (it is set to /bin/sh if you create a user via the command line/useradd):

$ sudo nano /etc/passwd

Change this:
<username>:x:1000:1000::/home/<username>/:/bin/sh

to this:
<username>:x:1000:1000::/home/<username>/:/bin/bash

...and then save the file, log out, and log back in. Problem solved!