At work I run XFCE; at home I run Ubuntu. Yesterday I noticed that the default Ubuntu color scheme for Gnome Terminal was really nice — called the “Tango” palette — and wished I could have the same at work. I already run the Tango icon theme, so it’d fit in nicely.

Turns out, the default XFCE terminal supports color schemes, too; I just had to stuff the correct color values in. I searched around a little bit, but couldn’t find anyone’s config to steal, so I copied and pasted the values in — one by one. To save you the same pain, open up ~/.config/Terminal/terminalrc, find the lines that all start with Color, and replace them with:

ColorForeground=White
ColorBackground=#323232323232
ColorPalette1=#2e2e34343636
ColorPalette2=#cccc00000000
ColorPalette3=#4e4e9a9a0606
ColorPalette4=#c4c4a0a00000
ColorPalette5=#34346565a4a4
ColorPalette6=#757550507b7b
ColorPalette7=#060698989a9a
ColorPalette8=#d3d3d7d7cfcf
ColorPalette9=#555557575353
ColorPalette10=#efef29292929
ColorPalette11=#8a8ae2e23434
ColorPalette12=#fcfce9e94f4f
ColorPalette13=#72729f9fcfcf
ColorPalette14=#adad7f7fa8a8
ColorPalette15=#3434e2e2e2e2
ColorPalette16=#eeeeeeeeecec

Save the file, and revel in your new colors!

Windows is good at a lot of things. So is Linux.

On the desktop, Linux has only been getting better. For instance, imagine my surprise when I plugged my old wireless mouse into my Ubuntu box and immediately received a warning about its battery being low. I’d been using this mouse with Windows for years, and it had never once indicated that it knew anything about the mouse’s power status. I’ve always believed Windows to be the current leader in device compatibility (companies will pay to write drivers for what people are using, and most people use Windows), so I found this to be quite humorous.

Poor old Windows, showing its age. I pointed and laughed a little.

Only problem? That same warning has been showing for the last 6 months, and the power estimate has never changed. It didn’t go to zero when the batteries finally gave out and died and it didn’t go away after replacing the batteries.

Well, what’s that they say… Even a broken clock is right two times a day. Although this is only right once a battery set.

So close.

A few weeks ago, I purchased a refurbished Sansa C2xx series MP3 player. It’s a small, 1GB “gumstick” player with a microSD slot and supports Rockbox, an alternative, open-source firmware. When running Rockbox, it’s rumored to support MicroSDHC, giving it a total capacity of (currently) ~17GB. In addition, it seemed to support both Windows and Linux pretty well, making it a good fit for someone who, like me, jumps between both.

For the most part, things work pretty well. Up until tonight I’d been running the default firmware, when I tried to install Rockbox. Here’s a collection of my experiences with the player.

• In the default firmware, the volume level is not saved when the device powers off. I use a set of earbuds that seal very well to my ears: a little volume goes a long way. Whenever I turn the player on, I have to immediately crank the volume down. I’ve heard that Rockbox will fix this.
• When resuming a previous playback position, forward/back functionality works inconsistently from how it works at all other times. If you resume partway through a song and press back, you expect it to rewind to the beginning. Instead, it skips to a random song. If you then press forward, you skip to another random song — not back to the song you were listening to.
• It’s a hybrid MTP and MSC device (in that order), picking whichever is supported by your operating system. On Windows you’re most likely stuck with MTP, while unless you specifically install MTP software on Linux, you’ll be given MSC. Unfortunately, the files you can see in MTP mode are not visible in MSC mode, and vice versa — and there’s no way to choose one mode or the other. In practice, that means there’s a big wall between your Windows and Linux music (until playing it).
• Linux apparently doesn’t play with the FAT(32) partition nicely enough to use it as a disk — I could not get the songs I copied onto the device via Linux to show up in the player’s database. In addition, just trying to use the device routinely caused file-system panics (to be honest, I didn’t even know they existed) which took down my whole box. I was also unable to get Rockbox installed via my Linux box.
• I experimented with MTP support in Rythmbox (granted, very quickly), and couldn’t see everything I’d loaded onto it (complained about a codec..?). I didn’t try adding new files.
• Given the problems I had getting files loaded from Linux into the database under the default firmware, Rockbox seems to be the way to go, as it supports browsing the actual file system for music.
• I finally installed Rockbox via an older XP install (which saw it as an MSC device), and confirmed that it did recognize a 4GB MicroSDHC card. But the default firmware always handles USB communication, so you have to copy things onto SDHC cards externally.
• None of the SD readers in my house support SDHC, again leaving me without a way to load music from Linux.

So, while I like the player overall, it hasn’t proved as Linux friendly as I’d like. Once I get an SD reader that supports SDHC, things should improve markedly.

Anyone attempting to do RAW conversion under Linux (in GIMP, specifically) is probably using DCRaw, as it appears to be the only guy in town. In which case, you owe it to yourself to check out UFRaw — it’s another GIMP plugin that’s a much better front-end for DCRaw (read: one that actually has options).

I’ve been playing around with Xubuntu on an old machine, and happened to install the latest version of Eclipse + PDT (1.0.3, IIRC?). While setting up the myriad of options I require to feel comfortable in the editor, I noticed that they’ve added the ability to strip whitespace on save. May the authors be praised!

Tonight I installed dnsmasq as a caching DNS forwarder on our home network (under a VM, no less). Additionally, I changed our primary DNS servers to those hosted by OpenDNS. To double-check that things were working, I figured I’d whip up a quick script to make a bunch of DNS requests and give an average time. First round, I faced the OpenDNS server against Cox’s own. I’d never really benchmarked the Cox DNS servers, so this was quite enlightening:

andrew@ubuntu-server-vm:~$ php ./dns_bench.php dothedrew.net 208.67.222.222
Average response time: 27.53
andrew@ubuntu-server-vm:~$ php ./dns_bench.php dothedrew.net 68.105.28.11
Average response time: 158.58

This only serves to strengthen my belief that all cable ISPs are run by pharmacists.

To satisfy morbid curiosity, here are the results against the local dnsmasq daemon:

andrew@ubuntu-server-vm:~$ php ./dns_bench.php dothedrew.net 127.0.0.1
Average response time: 0.21

That’s only about, oh, a 755x improvement. Hopefully that’ll sufficiently speed things up.

Bandwidth graph of the period during which my machine was compromised:

For the month, I’ve used about 34GB; so while my bandwidth usage was minimal overall, it was a sight higher than what I’d consider normal.

I’ve been meaning to play around with couchDB lately, and finally took the time to get it installed on my Linux VM at home running Ubuntu Server 7.10. I ran into a few problems while getting the thing to compile, so I figured I’d outline them here.

First, look at the instructions in the INSTALL file, or at the wiki. They’ll give you a good starting point — especially for all the development tools you’ll need to begin compiling things (automake, libtool, etc. — Ubuntu doesn’t install these by default). If you’re running a headless machine (like my VM) without X, however, you won’t want to install the erlang meta-package, as this will install a bunch of X related crap. And you can’t just install erlang-base, since this won’t give you everything you need, as evidenced by a failing make (trust me).

Now, before you go and search the Internet and decide that you should compile erlang from source — hardly an attractive option — keep reading. The silver bullet is that you need the erlang-nox package (that’s “no X”, not some form of nitrous oxide). The description is very vague, but it’s apparently a bunch of erlang stuff that doesn’t require X11. I also installed erlang-dev, since the description made it sound important (i.e., I’m not sure if it’s required).

Hopefully this helps somebody else.

My brother’s out visiting for Thanksgiving, and his Vista-powered (or was it ready?) notebook is having an incredibly difficult time connecting to our wireless network (for whatever reason). I was, of course, quick to place the blame on Vista — and not just because I’m being bigoted; this isn’t the first time I’ve heard someone complaining about Wifi problems under Microsoft’s “best” OS.

Anyways, I began searching Google for problems specifically related to his PC/chipset, but, in the process, stumbled across a completely scientific method of proving which operating system — Vista or XP — was better.

First, I searched for “Vista wireless problems”: 15,400,00 results.

Then I searched for “XP wireless problems”: 13,700,00 results.

Not quite as overwhelming a victory as I’d hoped for, but it’s pretty clear who the top contender is.

(As a purely academic exercise, I then typed in “Linux wireless problems”. A scant 46,200,000 results. Maybe this method isn’t really as accurate as I was hoping for. Or, more likely, people are posting lots of comments about how Linux fixed their wireless problems. Yeah.)

While we’re on the topic of the Linux command line, I figured I’d highlight a useful tool that I accidentally discovered a few days ago. I don’t remember what I was searching portage for, but I happened across Pipe Viewer, or pv. From the website:

Pipe Viewer – is a terminal-based tool for monitoring the progress of data through a pipeline. It can be inserted into any normal pipeline between two processes to give a visual indication of how quickly data is passing through, how long it has taken, how near to completion it is, and an estimate of how long it will be until completion.

And using it? You just insert pv anywhere you’re piping data between processes — it simply passes the data from stdin to stdout — and you get a nice little wget style progress bar. For instance, I could insert it in Matt’s previous example, and I’d get something like:

# pv /var/log/messages | grep bumttwagnerfor 
>  | awk '{ print $10}' | sed "s/[/ /g" 
>  | sed "s/]/ /g" | awk '{print $2}'
94.5MB 0:00:03 [34.3MB/s] [=======>            ] 41% ETA 0:00:04

The only thing I’ve noticed is that you really need to be working with a lot of data to make the information it provides useful; most of the time the piping is completed by the time you even get any output. But for situations where you’re dealing with a lot of data (like log files), it’s golden!