Music from the Command Line

In addition to programming I also love music. If I’m not listening to music I’m probably not working. While I love Pandora, my slightly off-mainstream musical tastes means that I start getting repeats pretty soon. I carry my personal library on my iPod but I don’t like listening on my iPod all day. Also, if the office is empty and my computer has speakers I like to take the headphones off and turn up the music. Last week I realized that my work machine had a 500 GB hard drive in addition to the SSD so I decided to copy my personal library on to it.

I know that there are a number of good music players for Linux but I personally wanted a very lightweight setup and didn’t need any “management” features (I have everything neatly organized into Artist and Album folders anyways). So I decided to use a little gem called MPD – the Music Player Daemon.

MPD is a daemon – it runs in the background and plays your music. It doesn’t provide an interface itself but you can connect to it using a number of clients. I love MPD becuase it’s very UNIX-y and just gets out of your way. You tell it where your music is and point it to a number of files it needs for operation (logs, a database and some state information). You then tell MPD which user to run as and a port on localhost to listen on. Here’s my config file.


music_directory                 "~/Music"
playlist_directory              "~/mpd"
db_file                         "~/mpd/mpd.db"
log_file                        "~/mpd/mpd.log"
pid_file                        "~/mpd/mpd.pid"
state_file                      "~/mpd/mpdstate"

user                            "username"
bind_to_address                 "127.0.0.1"
port                            "6600"

. As you can tell from the screenshots, it’s a lightweight but fully functional client.

This kind of setup probably isn’t cup of tea but I don’t want to convince you that it’s better than whatever current setup you have. For me this is amazing for a number of reasons. Firstly it’s quickly configurable and it stays out of my way after that. Second it’s very lightweight. Ncmcpp comes up in a second, I can quickly go through my library and add a few hours of music and set it to play. Then I can close it and not give it a second thought as I do my work. Since it’s so quick to come up, I can keep the client closed and open it if I do need to do something (like skip a track or see what’s playing). Since I have a terminal (or five) open at any time, it’s a quick process the few times I do have to do it.

Reason three is the client-daemon model. I think there are graphical clients that give you more standard functionality, but since I don’t need any of that, it isn’t forced upon me either. There is however an even lighter client called mpc (that is part of the standard MPD install) which lets you execute some actions like play, pause and skip without even opening a full client. Thus interaction is even faster.

In conclusion, if you’re looking for a simple, efficient music player that will play your music and stay out of your way then MPD is worth a try. If you’re not a command-line afficionado you might like one of the graphical clients. I’ve used Sonata myself in the past and liked it.

Advertisements

The exploding computer test

I came across an article about the exploding computer test. The gist of it is this — if you’re current computer met with some sort of catastrophic failure and was irrecoverable, how long would it take you to get up and running on a new machine? For me the test is a bit less demanding since I have multiple computers set up that could be pressed into service at a moment’s notice. But for argument’s sake let’s say that I am given a fresh new machine. Here’s what I’d do.

Install OS X or Linux

If I got a blank OS X machine things would go a bit faster. But if I got a stock Windows machine (like both my main computers were) then I’d start by putting Linux on it. If I was in a rush it would be Ubuntu which AFAIK has the fastest, simplest install. If I had a little more time I’d install Arch Linux since that’s what I’m more comfortable with, even though it has a longer initial setup time.

Install Git, Emacs and Chrome/Firefox

These are the three basic programs I need to get work done. I’m supposing that I already have some kind of terminal program since both Linux and OS X have them by default. On Ubuntu or Arch all of these are just a few commands away. They’d take a bit longer in OS X, but not really long enough to make much of a difference. With that done I can move on to retrieving all my data.

Cloning git repositories or getting stuff off Dropbox

Once I have Git getting back to a working state is mostly a matter of just cloning the repositories I need from my server. Everything I work on alone is in a Git repository and all my groupwork is in Dropbox. Getting all this back is just a few minutes work at most. If I was going to be working a lot on stuff living in Dropbox I’d install the client too. If nothing else, I would definitely get my system configuration repo and my Emacs setup repo since I consider them both absolutely essential to getting work done quickly.

Install compilers, interpreters, debuggers etc.

By this point I have my generic setup done. The last part is installing whatever project specific things I need. For example, if I need to work on my thesis I’d get GCC, GDB, Flex, Bison and Ruby. If I wanted to work on one of my JavaScript experiments, I’m all set because all I need is a browser my js2-mode for Emacs. But most of these are things I’d installed as I needed and I could get started on work again without waiting to have everything installed.

How long would it take?

The biggest variable here is the OS install time. For a Mac it’s basically zero, while for Arch it could be an hour or two. But like I said, if I was in a hurry I’d just install Ubuntu and be done with it. But even factoring in that uncertainty, it shouldn’t take more than a handful of hours. I’m hesitant to give an exact amount, but if I started right after lunch I would certainly be getting work done well before dinner time. Without having to do an OS install I could probably be up and running within the hour.

It’s been a long long time since I’ve actually had to set up a work machine from scratch. I’m a bit surprised as to how little I need to get to a work setup again. I remember when I was in high school getting back to working meant installing Windows, Office, Firefox, a Java environment called BlueJ and a bunch of other little things all of which took a good amount of time to install. I’m definitely at the stage when where my tools and workflow are very different from the average users. As the days go by I’m only becoming better and faster at getting stuff done, but that’s a matter for another blog post.

Portable Ubuntu and dual monitors

I love dual monitors. Roughly half of the labs I spend my time in have dual monitors. The others don’t and hence I try not to spend much time in those. Unfortunately one of those single monitor labs is the only computer science Linux lab that we have, so by necessity I actually do need to spend a considerable amount of time there. And whenever I’m there I miss not having a second monitor.

If you’re not someone who hasn’t used dual monitors for a while, then it can be somewhat hard to understand how much easier two monitors make your life. Two monitors provide a very natural division of information that you need on your screen. One monitor contains reference information, this is stuff that you’re always looking at, but that you’re not actively interacting with. The other monitor contains whatever things that you are actively interacting with. For me as a programmer, one monitor generally contains API references in a browser (Chrome on Windows, Firefox on everything else). The other monitor contains my editor/IDE. Unfortunately I do most of my programming in the Linux lab which are all single monitor machines or on my laptop, which I rarely hook up to an external monitor.

There are a  lot of Windows dual-monitor machines available in other labs, but the only thing I like about Windows anymore is Google Chrome. Our Windows machines aren’t locked down, so students are allowed to install software as long as it isn’t something dangerous. I was considering installing some sort of X server on some of the machines. But I generally move about machines quite a bit and so I don’t want to be installing X servers on every machine I’m on.

My next thought was carrying around a bootable Linux USB drive and running off that. I was seriously considering doing that when I came across an interesting SourceForge project via Reddit which uses virtual machine technology to let you run Ubuntu like an application right in Windows. And yes, that was the answer to my problems. Last evening I downloaded the Portable Ubuntu image to a  lab machine and gave it a test run before moving it onto my 4GB USB drive.

My experience has been mostly positive so far. The Ubuntu installation is somewhat out of date (it’s the 8.04 version of it). But that really isn’t a problem for me. In fact, as it turns out, I haven’t really been using it as a full fledged Linux distribution. For the most part I use it as an interface to my college’s powerful Linux clusters.  I have pulled my personal Git repository to it, but for the most part I think I will be working directly off my college’s machines. The greatest benefit is that I can run normal Windows apps right alongside it. This means that I can have a bunch of terminals and Emacs open while at the same time having Google Chrome and some other Windows-specific software I need. The system really comes into its own with multiple monitors. It’s useful to think of one monitor as a Linux screen and the other as a Windows screen. I’ve only been using it for a day, but I’ve already found it a natural way to work.

As a final note, I would like to put out a little disclaimer: I’ve only used this on powerful machines. The lab computers are 3GHz Core 2 Duo machines with 3.5GB of RAM. Performance is quite acceptable and whatever is happening on the linux side doesn’t seem to be affect the Windows side at all. However, on a machine that is much slower or has significantly less RAM, things might be a good deal slower. If you’re stuck using a Windows machine but would rather use Linux, this is a great way to go if you have a fast enough machine.