These instructions are out-of-date. See the newer post Setting Up A Ubuntu VM on 2016-10-14.
I frequently spin up VirtualBox VMs. For every reason, from quick tests to development projects. I have a file I keep on my desktop to document a few steps I run every time I install a new VM. I figured it was about time I properly document it, even if it is just for myself.
Requirements are relatively simple:
I'm not going to go into details into installing VirtualBox, nor the settings I use for individual VMs. It is specific to each project, and is influenced by the host desktop as well. A very simple linux VM to be used for development purposes can run with a surprisingly small amount of memory and disk space. My desktop runs 64-bit Ubuntu, and all my VMs are 64-bit. I haven't used any 32-bit operating system since January 2008, so in my experience a complete 64-bit setup works very well.
Make sure you've enabled hardware virtualization in your BIOS, such as VT-x or AMD-V depending on the host processor.
If you have problems running VMs, or you experience any crashes or inconsistent behaviour, I would immediately suspect the host desktop. I regularly have several VMs running for several weeks at a time without requiring reboots or restarts, and I would expect no less. If any of my VMs ever crashed, this wouldn't be a workable development setup for me, and the truth is I've been running all of my development work like this since around 2005.
The following is the long laundry list of things I do to my Ubuntu VMs to get them ready for development:
In addition to sshd which is a useful daemon to have running, this installs everything needed to get the latest VirtualBox guest additions installed correctly.
By default, some of the package repositories are disabled when first installing Ubuntu. To enable them:
I prefer to use Chrome as my browser. Installing it also automatically creates /etc/apt/sources.list.d/google-chrome.list to ensure that I continue to receive the latest updates from Google whenever they publish a new version of Chrome.
I dislike the new-style hidden scrollbars in Ubuntu. I find it difficult to find and click on them with my Wacom tablet, and it also prevents me from quickly seeing how far I am in a source file when browsing code. Thankfully, there is a simple way to bring back the old-style scrollbars.
Lots of discussion on the web about the annoying Amazon ads in Unity, and privacy concerns starting in 12.10. Like my browsing, I prefer my operating system to be ad-free. This will disable the Amazon ads.
A much better and complete method for fixing the privacy issues recently introduced, including the Amazon search ads, is to run the script from fixubuntu.com.
I dislike the Mac-style global menubar across the top of the screen. I much prefer every window keep their individual menubar which I can always see. With the global menu, it means I have to click on a window first, then go back to the top of the screen to click the menu option I want. If the menubar is kept in the window, then I can always go directly to the menu I want.
Some applications -- such as LibreOffice -- will still continue to use the global menu. But most other applications will revert back to their usual menubar with this change.
I like bash. But recently I discovered fish, which I find offers a better command-line user experience.
For the newer version of fish, see the v2 release ppa or the nightly build ppa.
Depending on your monitor size, you may want to increase or decrease the default font size. Ubuntu Tweak exposes this (and many other!) settings. Install it from the web site, or manually with the following command.
Terminal sessions by default don't keep a large amount of scrollback. This can easily be fixed.
For many years I was a big fan of Eclipse. There are several problems with Eclipse-CDT: it is a resource hog, complicated to configure correctly, and it needs Java. Installing Java in Ubuntu is frustrating, and I have little patience for confusing and conflicting instructions.
I also tried Anjuta a few years ago, and I note it continues to be developed for anyone looking for a suggestion. But for the past few years, I've been using KDevelop as my development environment for most of my projects.
This will install KDevelop, cmake, git, and subversion.
I'm probably quite slow to join this particular train, but I've recently grown to appreciate Doxygen. I'm a prolific commenter by nature, so all it took was a very small format change to my day-to-day source code comments to get them recognized by Doxygen. To get it installed correctly with all the other tools it needs:
If it is a VM where I'm going to be doing a lot of development, having the right man pages installed can definitely help:
If I need to use the Boost C++ libraries in my project:
Since this is a VM, I find I have no use for the screensaver. Instead, I rely on my host to have a screensaver configured. To prevent the screensaver in the VM: