Applications: A Survey

See Time For a Change for the first in this series, or view the index to see all the entries dealing with Arch Linux. In this post, I'll list some of the applications that make this machine a home.

When I switched from Windows to Linux, I found myself looking for applications to do things that I took for granted before. Eventually, I settled on my favorite programs for each of these tasks, but in so doing I learned to make some compromises, try new ways of doing things, and found unexpected features. That, in a nutshell, is what this whole Arch experiment is all about. So let's start with a list of activities that need software support, and the apps I use for each of them on Ubuntu today.

• Word Processing, Spreadsheets, etc: On Ubuntu 10.10, that's all covered by Open Office; on Arch and on newer distro versions, it's Libre Office.
• Web Browsing: Ubuntu ships with Firefox, but I've been playing around with Chrome lately, and I think I like it a smidge better. One thing that always seems to cause problems is Flash, so I'll watch out for that. The open-source variant of Chrome is Chromium, so that's what I'll use.
• Secure Password Storage: This is one I don't compromise on. Back in Windows, I used Password Safe, which was originally developed by Counterpane Software, but has since been moved into the open source community. When I went to Linux, I used Wine to let me keep using it. They have a Linux native beta now, which I hope to use on Arch.
• Personal Finance: I use a java-based program on Linux called Moneydance. It isn't Quicken by any stretch, but it runs natively and gets the job done.
• Options Trading: I have that account with ThinkOrSwim I've mentioned a few times, and they have their own trading platform. It's also java-based, so I don't expect any problems.
• Minecraft: a great way to lose an hour, or a weekend. Also java-based.
• Photo editing: the Linux standard for photo editing is The Gimp. It has nearly as many features as Adobe's Photoshop, and it's free and open source. (psst, it also runs on Windows)
• Speaking of Adobe, a PDF reader: simple... there is a reader built into KDE called Okular.
• Cloud Storage: I use Dropbox to carry a bunch of cruft around with me.
• E-Mail: I use Thunderbird in Ubuntu right now, but it's really annoying me with its constant update nags and insistence on using Firefox to launch links. I'd also like better integration with contacts and calendars, instead of having to use a browser for that.
• Twitter/Facebook Stream-following: Ubuntu defaults to Gwibber for that stuff, and it annoys me in many ways, but I haven't found a good replacement.
• Notes / Personal Organizer: I have a free Evernote account, which I use on my Android phone. But Evernote doesn't make a Linux desktop app, so I use an open-source clone that integrates with the Evernote servers called NixNote (formerly Nevernote).
• Instant Messaging: I ditched the ad-laden, bloated default IM clients a long time ago. Right now I use Pidgin to chat on Yahoo and MSN (or whatever they're calling it these days). There is also a facebook chat plugin, although it doesn't seem to be working lately. Facebook keeps changing its chat protocol, so that's not a big surprise.
• VOIP: I use Skype to chat with the poker buddies on Friday nights, and hopefully I won't have to go back to booting a Windows machine for that.
• Programming Environment: At the office, and here at home, I use Netbeans. It has a pretty friendly interface and fairly good code completion and auto-formatting, even if it is pitifully slow when opening a new project the first time.
• Hex Editor: we nerds occasionally need something a little more precise than a text editor. For that, I use a nice little editor called Bless that I found in the Ubuntu repository one day.
• Audio Editing: I'm too lazy to go find something better or easier to use than Audacity.
• Music Player: I use a player called Clementine that I had to work pretty hard to get working in Ubuntu. I really like it, so I'm willing to work fairly hard to get it working in Arch, too. Unless KDE has a better one pre-installed, of course.
• Video Editing: the first time I went skiing with the camera, I went looking for a video editor and eventually settled on OpenShot.
• Automated Backups: I have been using Bacula for years. It primarily runs on the file server, so it has very little exposure to the Arch conversion. I just need to get the client running so my machine will get backed up.
• Windows stuff: sometimes I have to run Windows programs. I hate doing it, but that's life. For that, I use Wine... just like every other Linux user in the world.

That's a pretty long list! Rather than diving right in, this is probably a good place to stop.


Next: The Easy Ones

Or check out the Index

X Windows and KDE

See Time For a Change for the first in this series, or view the index to see all the entries dealing with Arch Linux. In this post, I will go from the command-line to a KDE desktop. We're getting somewhere this time!

An awesome Linux machine isn't very awesome if all you get is a root login and a command-line prompt. There are a number of desktop managers out there for Linux, but the two most popular are Gnome and KDE. For this machine, I chose KDE. There are several command-line examples throughout this post, and by a common convention I will prefix the ones that should be done as root with "#", and the ones that should be done as an unprivileged user with "$".

In Arch, most things are installed with the package management utility: pacman. Other distributions have different but similar utilities: Fedora uses yum, and Debian uses apt. They all do pretty much the same things, and they all have documentation that does its best to convince the reader that each utility is different and somehow better than the others. Whatever. They are just tools to do a job, as far as I'm concerned. Before I get started installing KDE, I need to generally update my system:

# pacman -Syu

Immediately after a new installation, this will probably update pacman itself and then dump back to a command prompt, so it's a good idea to run the command twice.

Next, I need to install X Windows before I install KDE. Linux is laid out in a hierarchical way: there is the underlying kernel, which runs the operating system and does hardware, resource, and process management, but it doesn't have any graphical capabilities. On top of that -- if installed -- is X Windows, which is capable of interfacing with the graphical hardware subsystem and providing a high(er) level framework to applications looking to provide a GUI interface to their users but not wanting to reinvent the wheel, the way DOS games had to back in the day. Finally on top of that is the desktop manager, which puts a pretty face onto X Windows, coordinates a user session, and manages access to the various utilities and menus an average user needs to do his job. Technically, X Windows can be run without a desktop manager like KDE, but no sane person would want to.

As an example of insanity, here's how to launch the X Windows calculator, and what it looks like:

$ X &
$ export DISPLAY=0:0
$ xcalc &

And here is the equivalent in KDE:

Launching KCalc

KCalc itself

Bear in mind that if you want to see more than one application at a time in X Windows, you have to specify the size and coordinates of the windows at launch time. Yeah, I'll stick with a desktop manager.

So... onward to X and KDE installation!

# pacman -S xorg

This takes a while. When it's done:

# pacman -S kde

This takes even longer. When that finishes, though, X Windows and KDE are installed. But they need some configuration before they can be used. First of all, I had to add "hal" and "dbus" to the DAEMONS section of /etc/rc.conf - no idea why, just following instructions. In order to get a dvorak layout at the login prompt (very important when you can't see what password you're typing), I also had to add the following highlighted line to the appropriate section of /etc/X11/xorg.conf.d/10-evdev.conf:

Section "InputClass"
     Identifier "evdev keyboard catchall"
     MatchIsKeyboard "on"
     MatchDevicePath "/dev/input/event*"
     Driver "evdev"
     Option "XkbLayout" "dvorak"
EndSection

Next, if I want to use KDE I have to create a non-privileged user, because by default root isn't allowed to log into KDE directly. I also need to set a password, create a home directory to store the new user's configuration and personal files, and make sure this user can elevate his privileges to root in case I need to use it to manage the system from within KDE. So I executed the following commands in sequence:


# useradd mark -d /home/mark
# passwd mark
 (enter a password)
# mkdir /home/mark
# chown mark:mark /home/mark
# groupadd sudo
# usermod -aG sudo mark

Since I had never set up sudo, which lets an authorized user elevate his privileges to super-user, I also had to execute visudo and comment out the line that says that anyone in the "sudo" user group is allowed to use the sudo command. In this way, I have given unlimited power to the mark user, but no one else.

All that is left now is to make the machine boot directly into KDE instead of to a console login. To accomplish this, I edited the /etc/inittab file. First, there is a section near the bottom that has several example lines for starting various desktop managers. Luckily, there is a KDE one: "x:5:respawn:/usr/bin/kdm -nodaemon". All I needed to do was comment out the "xdm" one that leads to the bare X Windows environment, and uncomment the line above dealing with KDE. Next, there is a line near the top that reads "id:3:initdefault:". Changing this to "id:5:initdefault:" causes the default runlevel to be 5.

OK, what the heck is a runlevel?

In a nutshell, runlevels categorize the various services that should be started or stopped based on what task the operating system is carrying out. This is an old concept harkening back to the Unix System V days, but it is still a simple and powerful way to manage a system. The various runlevels in Arch are:

• Level 0: Halt, aka Shutdown. If you switch to level 0, your machine will power off.
• Level 1: Single user mode. If you are familiar with Windows Safe Mode, this is like that but more so.
• Level 2: Not used these days.
• Level 3: Multi user mode, console login. This was the default level after a bare Arch installation.
• Level 4: Not used these days.
• Level 5: Multi user mode, X Windows. This is our target level.
• Level 6: Reboot. If you switch to level 6, your machine will reboot.

So by switching my default runlevel from 3 to 5, I make the machine boot straight into KDE. Simple!

And here it is!

Next: Application Install
Or check out the Index

The Arch Installer

See Time For a Change for the first in this series, or view the index to see all entries dealing with Arch Linux. In this post, I will detail the steps I took to get Arch installed on my virtual system.

The "Live" Environment
When you first boot off of the Arch Live CD ISO, you get dropped into a command prompt, as root, with a little message on the screen that reads:

To begin installation, run /arch/setup
You can find documentation at /usr/share/aif/docs/official_installation_guide_en

i18n: Use the 'km' utility to change your keyboard layout and console font.

If you encounter issues and want to report them or seek help, run /arch/report-issues

If you are looking to install Arch on something more exotic, such as your kerosene-powered cheese grater, please consult http://wiki.archlinux.org.

Thankfully, I don't have a kerosene-powered cheese grater. Recall that I have switched myself over to a Dvorak keyboard layout, and I have replaced my old QWERTY-labeled keyboard with an awesome blank-keyed Das Keyboard. So of course the first thing I did was to run km and select a Dvorak layout. Ah, much better.

Steps 1-3
Then I ran /arch/setup, and was greeted with this screen (click for a full-size view):

One might be tempted to jump around, but the installer won't allow that; so I started with the first step. The "select source" task gave me some cryptic warnings about making sure to use the right repositories, lest I hasten The Singularity. Not knowing what was the right or wrong choice, I just chose what was pre-selected by default. We haven't been enslaved by our computers yet, so I guess it wasn't a terrible choice. Back I came to the main menu, with "2 Set editor" helpfully pre-highlighted for me. Choosing this gave me a choice of "vi" or "nano". I'm a vi man, so that one was easy.

The next one was "set clock". I ended up having to run this installer several times for reasons unrelated to the clock, and eventually I came to the conclusion that getting too wrapped up in setting the clock from here, at least in a VirtualBox Guest, was a sucker's game. So, in my ideal install, I skipped this step.

Step 4
"4 Prepare hard drive(s)" may not look ominous to the uninitiated, but I knew from years of experience that this is where the partitioning would happen, and stuff would get tougher. As I explained last time, I have two storage devices in my main desktop computer: a 100GB SSD for fast booting and operating system use, and a 2TB hard drive for main storage. I don't want to devote a multi-gig chunk of my precious SSD to testing an Arch installation, and performance isn't the point of this test. The point is to have two hard drives, one large, one small, and to make sure I know where I want what, and that all my partitions and whatnot work out right. So both of my "drives" are actually contained in files on the 2TB drive. I proceeded with some trepidation to the Prepare Hard Drive sub-menu:

I put Arch on the laptop for a couple of days for fun a few weeks ago, and when I selected the first entry: "Auto-Prepare", everything worked out great. But that choice isn't appropriate for a multi-drive setup like my test machine. So that means I have to manually partition and configure the filesystems and mountpoints. This is never fun.

My simulated 8GB SSD mapped to /dev/sda, and my simulated 100GB hard drive mapped to /dev/sdb under the Arch system. By looking at the layout chosen by the auto-prepare option on a single hard drive installation, I determined that Arch likes to have a separate /boot partition. So I created the following partitions and mapped them to various filesystems and mountpoints:

• /dev/sda1, bootable, 580MB, type="Linux", mounted at /boot, ext2 filesystem. This partition gave me the most problems. I wasn't sure what the right type was, because there were a few options that seemed reasonable, and I wasn't sure what filesystem to put on it. If I chose any combination other than the ones listed here, everything would seem fine until the very last step (8 Install bootloader), and then GRUB would refuse to install.
• /dev/sda2, remaining 7.5GB, type="Linux", mounted at /, ext4 filesystem. This is the main filesystem root, where all the operating system stuff goes, so that should be on the SSD for maximum performance.
• /dev/sdb1, 96GB, type="Linux", mounted at /caviar, ext4 filesystem. This is the main storage partition, which in real life would be 1.88TB. Using softlinks, I can map whatever I want into this drive as I use the system in the future. In case you're curious, it's called "caviar" because it is a Western Digital Caviar hard drive.
• /dev/sdb2, 4GB, type="Linux swap / Solaris", swap. The swap partition on Linux is just like C:\Pagefile.sys on a Windows machine: it's where memory gets written to disk if you start running out, or if you put your machine into hibernate. I located this on the slow hard drive instead of the SSD because I don't expect to use it very often. I can avoid using it by installing more memory, and many people choose to have no virtual memory at all. I prefer to have it available for exceptional circumstances, but I don't want to devote precious SSD space to it. And on a real SSD, there is no real speed gain from putting your machine into hibernate instead of just shutting it down. My desktop machine currently boots into Ubuntu, ready to be used, in about 6 seconds.

Bear in mind that the choices above were finally determined to be the right ones after many annoying attempts. After each, the Arch Installer would format my hard drives, create the filesystems, and set up the mountpoints. I usually didn't know something had gone wrong for about an hour.

Step 5-6

Next are a couple of simple steps. Selecting the packages was easy, since I had no idea what most of them were, and I knew I could install them later if I realized I needed them. However, a couple of extra non-default packages turned out to be a good idea:

• pacman-mirrorlist - the Arch package management application is called "pacman", and it downloads software packages during install or upgrade from a repository mirror specified in the /etc/pacman-mirrorlist file. If you don't install this off the installation CD, I don't know how you're supposed to use pacman post-installation.
• sudo - the ability for a normal but authorized user (like the "mark" user) to elevate his privileges to be indistinguishable from "root" without having to type in the root password is very valuable. It's more secure, and it's more convenient. I found I needed it immediately after installing Arch, so it was a no-brainer to put a tick next to this package during the installation process.

Step 6 - Install Packages is the easiest of all. It tells you to be patient, you hit Enter, and you watch it install stuff without having to do anything yourself.

Step 7

In the next step, I needed to create the initial system configuration files. Much of this can be skipped, but it's a good idea to cruise through each file and see if anything jumps out needing changing.

Arch has a simple System V-style configuration model, where most of the main configuration options are stored in the /etc/rc.conf file. I made a few changes:

• I changed the TIMEZONE line to read "America/Chicago", which makes my system clock work out right.
• Under the NETWORKING section, I changed "Interface=" to read "Interface=eth0", which is my one-and-only ethernet card on the machine. By not setting anything else here, I let it use DHCP to get its networking details. In the real world, I can start this way, but I'll want to change it to a static private IP so that other machines on the McHouse Enterprise Network can find it. 
• I set the machine name to "arch64test" here, and also in /etc/hosts.
• I did not have to change my keyboard layout, because the installer automatically propagated my choice of "dvorak" into the rc.conf. But if I hadn't bothered before, I could have set it system-wide here.

There are several other configuration files that are available for adjustment at this stage, but rc.conf is the main one of importance. I added "arch64test" to the /etc/hosts file so it would match the rc.conf, and I also set a root password in this step, so I don't forget to do it later.

Step 8

Installing the bootloader (GRUB) is an infuriating step. The installer fails cryptically if it doesn't like something about the partitions chosen way back in Step 4, and your only choice is to effectively start over. Also, the Arch Installer makes a big deal about forcing you to look at the /etc/grub.conf, even though the contents never need changing. The first time I landed here I felt this sense of responsibility, like I had to verify every line in the file for correctness - tough when I didn't even understand every line! After going through this step five or six times, I became pretty comfortable with just instantly exiting out of the file when it popped up on the screen.

Success!

Eventually everything went well, and I kept my fingers crossed during the GRUB installation, and the installer exited successfully. That let me remove the install CD and reboot into my brand new Arch installation, which looks like this:

Now what? It's not exactly the multimedia experience we have all come to expect from our PCs these days. That's the thing about Arch, though: it is exactly what you make it. It doesn't try to guess what you want your desktop to look like - it gives you the power and the responsibility to do it yourself.

Next: X Windows and KDE
Or check out the Index

VirtualBox

See Time For a Change for the first in this series, or view the index to see all the posts dealing with Arch Linux.

VirtualBox is well-documented on its website and on Wikipedia, and I see no reason to rehash that information. However, I want to discuss how I use it when testing a new desktop installation like Arch. It really works perfectly for my needs and I hope that now that Oracle owns it they won't screw it up like everything else they've touched (I'm looking at you, Java). Other similar products exist, including VMWare, KVM, and xen. After reading about them and trying them, I found VirtualBox the most intuitive, so that's what I use.

It begins with deciding what hardware the virtual machine will have. I like to approximate my real desktop machine as much as possible, so that I can encounter as many problems as I can before I wipe my hard drive. My desktop machine has a 4-core i7 processor, 6GB of memory, a 100GB SSD for operating system and fast-access files, and a 2TB hard-drive for main storage. The graphics card is nothing notable, since I don't really use this machine much for gaming, but for completeness it's an nVidia, and I am running the proprietary drivers for it. I'm running 64-bit Linux, as any reasonable person would with 6GB of memory. And I have a little stone skull sitting on the keyboard.

Obviously, since the virtual machine (known as a "guest") is running within my main machine (known as the "host"), it has to be smaller in every way, but it should have a similar footprint. So the guest is a dual-core processor, running in 64-bit mode, with 2GB of memory, an 8GB hard drive that I treat like the SSD, and a 100GB hard drive that I treat like the main storage drive. VirtualBox also gives me as many CD/DVD drives as I want, and I have one in there. Sound, network, graphics are all stock, supported by VirtualBox. Except for nVidia-specific driver issues, I have all the hardware likely to give me trouble in a real installation. Sadly, no skull on that keyboard. Now I need some software.

Next I download the Arch installation media, also known as the ISO. If you aren't familiar with an ISO, it is basically a CD in a file. I can burn it straight onto a disc or USB memory stick and have exactly what I would get if I ordered the hard media. But since I'm using VirtualBox, I can also mount it directly, without having to put it on anything physical. All I have to do is select the ISO file for insertion into the virtual CD/DVD drive, and to the guest machine it looks like a new disc was just loaded into the tray. By adjusting the boot order in the VirtualBox management application, I can have my guest machine - which I very creatively called "Arch64Test" - boot straight from that ISO file as if it were physical media. That starts the Arch Live environment, from which I can install onto the hard drive. When I'm done with the ISO, I click a little icon in the status bar of the guest's window, and select "Eject Disc". Simple!

That's about it for the VirtualBox details, but there is one other feature that is really key for this type of activity: snapshots. I can take a snapshot of a guest machine any time I want (as long as it isn't running), and VirtualBox gives me a checkpoint. I can have as many of these checkpoints as I want, and they end up like a set of stills depicting the guest machine at various stages of its life. If at any time I want to roll back to a particular snapshot, I can do so from within the management application. I can't do this lightly, though, because rolling back to a previous snapshot throws away all changes to the machine since that snapshot. But if I'm having trouble getting something installed correctly, being able to roll back to just before I started screwing up the machine is really important.

Next: The Arch Installer
Or check out the Index

Why Arch Linux?

See Time For a Change for the first in this series, or view the index to see all entries dealing with Arch Linux.

Unlike Ubuntu, Arch uses a rolling release cycle. This means that new updates for included parts of the distribution (called "packages") come out whenever they are ready to come out. Instead of periodically inducing a forklift update, necessitating backups, testing, and stress, individual packages are given minor updates all the time. This means that new cool stuff is available sooner, and if any bugfixes or enhancements come out after a release, there is no need to wait. In practice, interim updates to Ubuntu and other fixed-cycle distros fix bugs pretty quickly, but applications included in the distribution are never updated with new functionality. Arch gives the user the power to decide when he wants to upgrade. As long as I run the update scripts regularly, my system is just as up-to-date as I want.

The downside to a rolling release cycle, of course, is that the distro maintainers don't have a fixed code-base to test against, making sure that everything works together smoothly. This increases the probability that the user will have to do more work to make things integrate the way he wants them to. But in practice, many of the open-source applications for Linux are run at so many version levels, thanks to the various distributions that package them at different snapshots of their ongoing developments, that they have evolved to inter-operate very well without relying on a specific version of this or that. Dependencies are usually described in terms of an inequality expression, like "glibc >= 2.3", meaning that the developer has tested against v2.3 of the glibc library, and knows of no changes to it after that time that breaks his application. So the ">=" expresses his expectation that any version of glibc at or above 2.3 should be fine. The other side of that coin is that packages in active development always make sure they work with the latest stable version of libraries like glibc. If a breaking change occurs to glibc, the developer of the application that relies on it will scramble along, updating his application to work with the new library. In the process, he may find he has to make it impossible for his app to work with prior versions of glibc, updating his dependency to "glibc >= 2.5".

Ubuntu is based on Debian, another Linux distro. Debian is famous for being very conservative about rolling out new code, which makes it very stable. Stability is great, but this conservatism means that two rounds of delays and testing need to happen before big changes come to the desktops of Ubuntu users: first Debian has to sign off on it, and then Ubuntu goes through its own round of customizing, integrating, and testing. Finally in April or October, the new stuff hits the wires for users to get as part of their Ubuntu systems. In theory, I can go get the latest-greatest directly from the teams building it: if I want KDE, I can go download it from kde.org. The problem with doing this is that Ubuntu manages its version of that software in its repositories, and now I have installed my own version. By working around the system in this way, I take on not only the installation, integration, and updating tasks, but also all the strange inter-dependency problems potentially introduced between my new version of KDE and my old versions of all my other applications. This is a slippery slope, and soon I find myself doing three kinds of version management on vast parts of my system: the Ubuntu (easy) way, my own home-grown (scripted) way, and the nasty and manual toggling back and forth on an individual package basis.

Arch, on the other hand, is not based on anything except Linux kernel source. When a new version of something big like KDE comes out, the Arch team builds it against the latest source tree, does some dependency checking to determine if related packages are affected, and packages the KDE-only release for deployment. Instead of a delay of close to 6 months, like Ubuntu, this regression testing and packaging is typically done in only a day or two. Recently, KDE had a fairly major revision bump from 4.6 to 4.7. The KDE project announced the new version on July 27. Arch had the package ready to be automatically updated on users' systems on July 30.

In addition to the officially supported packages like KDE, Arch has the Arch User Repository (AUR). This repository is maintained by the user base itself, and is the place to find the less-common applications that have not been officially added to the distribution. If something isn't in the AUR, anyone with the experience and community-mindedness can add it themselves, making it easier for the next guy to install the software.  In Ubuntu, individual software maintainers can create their own repositories, called PPAs. These can be added to the Ubuntu Update Manager to automatically keep the software up-to-date. This works well, but PPA support is pretty spotty across various maintainers; often the web address of the PPA - where the Update Manager should go to check for updates to install - changes, causing arcane error messages in the Update Manager that must be decoded and dealt with. The PPA system does a good job of hiding the details of Open Source Software from the user, but that also makes it very difficult for him to fix his own problems when the maintainer is too busy to fix them for him. Arch avoids this issue by putting the responsibility squarely on the user's shoulders. This would make management of all these "3rd-party" applications nearly impossible for most, but not for a developer - and in practice, by the time I suffer enough pain to go deal with an issue myself, someone has probably already packaged the solution up for me and updated the AUR.

In general, Arch has a do-it-yourself flavor not found in most of the other distributions. This DIY spirit hearkens back to the early days of Linux, where if you wanted to run the operating system, you were compiling kernel source for hours first. Arch isn't nearly this effort-intensive, of course, since there is no reason for thousands of users to cover the same ground and deal with the same frustrations over and over. It strikes a balance between doing the common work so the user doesn't have to, and leaving the personal decisions (and the maintenance consequences) to each individual. Like all continuums, different people have different opinions about whether the right balance has been struck. That's OK, that's why we have so many distros to choose from!

Arch Linux isn't all sunshine and flowers, though. The installer is a lot less helpful than Ubuntu, and when you get done you find yourself at a console login: no desktop manager has been installed, not even X-Windows. If you don't know you need to keep the system up-to-date, or you don't know how, it doesn't get updated. If an update breaks your system, you're on your own to fix it. The growing user community is very helpful and the Arch Wiki is fantastic, but many of the basic things that users take for granted on Ubuntu (like wireless support) are the subjects of long, technical Wiki entries and vast arrays of piteous requests for help on community support forums. Each of these preceding words are a separate link, if you're feeling curious, and these are just the first page of results from Google! There are Linux distros (Mint) I would recommend in good conscience to a first-time user coming from Windows or Mac. Arch is not one of those distros. This is a big step up for me in terms of taking responsibility for the ongoing maintenance of my desktop machine, and I don't take it lightly.

The best way I know to make sure something is going to work and support all my critical computing tasks (including Minecraft) is to install it in a Virtual Machine, documenting my challenges and their solutions as I go. It's like a dress rehearsal.

Next: Virtual Box
Or check out the Index

Time For a Change

This is the first post in a lengthy series describing my move to Arch Linux. To see all the posts, check out the index.

I have been running Linux pretty much exclusively at home for a couple of years now, and most people would consider that the end of the story. But for people who work and play with Linux on a daily basis, the next obvious question is: which distribution? So far, it has been Ubuntu, but I'm working on switching to a much more advanced and up-to-date distro: Arch. It has already been an adventure, and the adventure continues. But first some background on my choice, and why I want to switch, and why switching isn't as simple as just downloading a new ISO and loading it up.

At work, I mostly program on a real-time Linux distro called RedHawk, which is based on Red Hat Enterprise Linux, known affectionately by most in the Linux community as RHEL. RedHawk had its beginnings in the aerospace and defense industry, where real-time kernels were first deemed critical. It and other real-time distributions has a rapidly growing user base in the finance industry, now that latency is measured in microseconds and nanoseconds instead of milliseconds. Unlike most Linux distributions, RedHawk isn't free - in fact, it's pretty damn expensive, and since it is geared for the defense industry, it isn't kept all that up-to-date. It's a nearly perfect platform for writing latency-sensitive enterprise trading software, but it really sucks for a home machine on which I want to do lots of other - and more fun - things. Plus, it's tough to find a community of users giving help to each other, since it is mostly populated by the hyper-paranoid (finance is as paranoid as the defense industry, but isn't as good at it).

I decided to make the switch from Windows to Linux at home when we decided to move our trading system from Windows to Linux. I figured if I was going to become professionally proficient, it would be a good idea to immerse myself. Plus, I had been thinking I wanted to make the switch "sometime" anyway, and this was a good push in the right direction. I had used Linux as a server at home and was fairly comfortable with most things, but the move to it as my primary desktop was a scary one. So I chose Ubuntu.

Ubuntu is the most popular distribution out there, and is geared toward the novice. Nearly everything can be done with the GUI instead of having to memorize arcane Unix commands. It has a nice friendly installation utility that does a great job of figuring out all your hardware and installing the right drivers for it, just like Windows. It automatically keeps your system up-to-date with an Update Manager, and it provides a nice Software Center facility for searching for software and installing it, usually with the click of a button. But best of all, it has a huge user community consisting of a large number of lost newbs, just like I was, and a moderate number of helpful experts, who answer all their questions. Whenever I had a problem, I was able to find others who had the same problem and had already gotten answers to their questions. This was a big help to a stranger in a strange land.

Ubuntu releases a new version of itself every 6 months, in April and October. The April release is always a new major version number, with ".04" on the end, and the October release bumps that to ".10". Each release has a corny moniker consisting of an adjective and a creature, both starting with the same first letter, which increments with each release. My first installation of Ubuntu was 9.04, Jaunty Jackalope, and today I am running 10.10, Maverick Meerkat. The upcoming release, due in a month or so, is 11.10, Oneiric Ocelot (no, I am not making this up). Most users of Ubuntu simply refer to the various versions by their adjectives: Jaunty, Karmic, Lucid, Maverick, Natty, and now Oneiric.

I dislike the semi-annual release schedule that Ubuntu follows. Because it comes so frequently, it seems like everyone is always looking forward to what is coming in the next release. This causes older releases to rapidly become implicitly unsupported, since the instant response to a question like, "how do I get this new version of XYZApp to run on Maverick?" is usually, "just upgrade to Natty!" This becomes a problem to an old stick-in-the-mud programmer like me who has the heretical viewpoint that his computer is a means to an end, instead of an end in itself. I don't want to constantly be servicing the beast, feeding logs into its all-consuming version furnace, when I would rather be doing more important things like playing Minecraft.

Most people just let Ubuntu upgrade itself to the next version every 6 months, but I find this terrifying.  Maybe it's my Windows heritage, but every time my operating system says, "great new version available with lots of awesome features! Wanna upgrade?" All I hear is, "we've barely finished testing this, and none of your applications are going to work right, and you won't be able to find anything! Wanna roll the dice?" My computer is a garden, not a waste dump, and as such, I'm very careful what I plant in it. My normal procedure for a new version of an operating system is to wait for a few months to see if any major issues crop up, then try it in a Virtual Machine and get all my apps installed and configured to make sure they still work. Then I back up my hard drive, wipe it to clean out any cruft, and then install clean, reinstalling and reconfiguring each of my applications. I usually take that opportunity for hardware upgrades, too. Needless to say, this is not a procedure I want to be going through every 6 months!

Lately, the desktop Linux world has been going through some upheaval. Gnome, the desktop manager I use, has come out with a major overhaul that is ruffling a lot of feathers: Linus Torvalds called the new version "an unholy mess." KDE, the other major desktop manager, has been swinging and missing for years, ever since they started on KDE 4. But just a few months ago they came out with version 4.6 that fixed nearly all of the problems. KDE has a reputation for being a desktop manager that really caters to programmers with its powerful scripting, widgets, and customization capabilities. I tried to use it while it was broken, and now I'm ready to give it another try. Ubuntu, meanwhile, has switched to a new default desktop manager called Unity that looks like it's designed for netbook users, which I tried for a while on the laptop and decided I couldn't stand.

I want an up-to-date system. I want to be able to run Gnome 3.1 and KDE 4.7 as soon as they come out, without waiting for Ubuntu to get around to releasing it. When bugs get found and fixed, I want the changes immediately instead of having to go through another forklift upgrade 6 months later just to fix some bugs. I want to run the desktop manager of my choosing without having to work around my distro. I am no longer a Linux newb who needs his hand held: I'm ready to take responsibility for a greater part of my system, scripting my own upgrades and figuring out my own problems.

Next: Why I Chose Arch
Or check out the Index

Happy 1982

In the Year-a-Month project, it's 1982. My original list has only four albums on it this month, but I did a little swapping and editing. And Amazon, for unknown reasons, seems to think that shipping me CDs is less expensive than downloading me some data. So I could only listen to samples of Judas Priest and Accept; the full albums will have to wait for Super Saver Shipping to arrive.

Ted Nugent: Nugent - There are a few songs by Ted Nugent that have rocked so hard that they have made me react positively to him whenever I heard him announced on the radio. But I'm coming to realize that those songs are the exceptions rather than the rule. This album's uninspired name (don't confuse it with the 1975 debut album, Ted Nugent) is indicative of the music within. Ted seems to be phoning it in on this one, so I'm skipping it entirely.

Judas Priest: Screaming for Vengeance - from what I've read, this album marked the high point in Judas Priest's U.S. popularity. The album went double-platinum here, the only Priest album to reach that distinction. It seems to be a fan favorite, too: out of 165 reviews on Amazon, 127 of them are a full 5-stars. Review titles are things like: "Best Ever!", "Metal Gods", and "Back when metal was still metal".  I can't wait to hear it...

Iron Maiden: The Number of the Beast - Bruce Dickinson has arrived!  His iconic British Heavy Metal voice takes center stage on the very first track. Nevertheless, Bruce drops in pretty neatly to replace Paul Di'Anno, and overall, the band sound hasn't really changed that much since the first two albums. I'm listening to The Number of the Beast as I write this blog entry, and I keep having to take breaks for head-banging.

Accept: Restless and Wild - The opening track of this album, "Fast as a Shark", is considered among the first speed metal songs.  It just barely beat out the grand masters, Metallica, who released Kill 'Em All a year later, beginning the biggest heavy metal dynasty of all time.  You won't see Metallica next month, though, because all their albums already inhabit my shelves.  In any case, I'm looking forward to hearing this early speed metal example along with the rest of the album when it arrives.

Motörhead: Motörhead - Wait a minute, this album is from 1977, not 1982! What gives? Somehow, Motörhead managed to get forgotten when I was putting together my band list. Since my Amazon order for Screaming for Vengeance and Restless & Wild didn't qualify for Super Saver Shipping, I figured now would be a good time to start rectifying that oversight. This album isn't available for MP3 download at all, so I'm buying it without any preview. The anticipation is killing me.