Monthly Archive for August, 2009

Dotman – A Dotfile Config Manager

Some time ago, I started to get annoyed at the bothersome task of copying configuration files between my desktop, laptop, and remote environments.  First of all, copying the configs typically involved a lot of repetitive scp’s. The second annoyance is a little worse: some of my dotfiles need a few special settings that are localized to one environment (e.g. just to my server), but I can’t source some “local” config from the main one.

Of course, the answer was to come up with some ridiculous solution and today, I bring you:

dotman (aur package)

What on earth is it? It’s a way of managing configuration files across multiple environments.  You can upload your configs to a remote repository and then download them from each of your environments.  Furthermore, when you grab them from the remote area, you can do a diff against your existing file to keep your localized changes.

Right now, dotman only supports transfer via SFTP (through Paramiko), but it’s possible to add more protocols later.  The code is still a bit messy and needs some rewriting to properly handle exceptions, but as it stands, you can do quite a bit.  Take a look at the instructions on the above page to see how things work.

I’ve seen several different solutions to this kind of problem: some people use rsync and others use revision control systems.  I considered trying these out, but my “if you want something done right, do it yourself” mentality took hold and wouldn’t let go.  So, some may consider dotman to be totally superfluous (and I might agree), but maybe others will get some use out if it.

Frankly, I wanted better diffing capabilities.  I really wanted something like Gentoo’s powerful etc-update, but for now, vimdiff will have to do.

Examples:

comp1 $ dotman commit bashrc
-> ~/.bashrc gets uploaded to the remote repo

comp2 $ dotman grab bashrc
-> the remote bashrc gets pulled and vimdiff opens up, comparing your old config with the new one from the server (a copy of the old version gets stored to a backup directory)

Honestly, it’s that simple.

Triple Play: Matching RGV Lasers

I have just about enough portable lasers now: a bunch of green pens, a tiny blu-ray burner with a heatsink I machined myself, and my 300mW SKYlasers portable.  So, I decided to round off my collection with a set of 3 lasers (650nm red, 532nm green, and 405nm blu-ray) in identical hosts by a LPF member named Ehgemus.

To see some nice pictures (plus a somewhat sporadic build-log), take a look here:

http://jwcxz.com/projects/lasers/tripleplay/

I’m still working on the red laser–the driver I’m using isn’t behaving as expected.

Connecting to MIT’s VPN using your own client

In its infinite wisdom, MIT decided to package the configuration settings for connecting to its VPN with its own client.  Furthermore, they decided to make the package an RPM because apparently there are no distributions of Linux that use some other package manager.  After rooting around for a while, I finally found the configuration settings for connecting to their VPN (I wanted to run Matlab).  Here’s how to use vpnc (it’s extremely lightweight and intuitive) to connect.

The configuration settings for vpnc are as follows:

IPSec gateway vpn-public.mit.edu
IPSec ID MIT
IPSec secret ****
Xauth username yourkerberosname@mit.edu
Xauth password yourpassword

****  get this from the Cisco config file (from the enc_GroupPwd field, MIT certs required) and decrypt it using this utility.

Taa daa!  Now you can connect to the VPN.

4 Reasons why Every Linux User should try Arch Linux

I have probably tried around 2 dozen Linux distributions/versions-of-distributions over the past 6 years and I’ve seen many approaches to how a Linux system should be built.  Out of these distributions, one and only one stands out from the rest as the most elegant: Arch Linux.  Here are 4 reasons why you should give this amazing distro a try:

4: The Arch Way

The first thing that really hit home when I saw the Arch Linux website many years ago was the distro’s philosophy: The Arch Way.  The short version (from the wiki) is: “Keep it Simple, Stupid”.  The other short version is: provide a base system flexible enough to let the user configure their environment exactly as they like and give them the tools to do so.  Arch prides itself on constantly evaluating the most elegant approaches for doing things.  This is why, even at a first glance, the Arch base system is much cleaner and better organized than that of any other distribution.

One example of Arch’s elegance in this regard is how the distro chooses to organize configuration files.  All Linux users know the importance of /etc/–the directory that stores configuration files.  Arch chooses to have one single file for managing most of the system’s base configuration: the timezone, the hostname, which scripts to init at bootup, which extra modules to load at bootup, even static network configurations.  It’s all located in /etc/rc.conf and it’s all well-documented.

There are two main frameworks for system initialization: Sys-V and BSD-style.  You will find Sys-V init systems in most of the mainstream Linux distributions: Debian and its derivatives, openSUSE, Fedora, etc.  These distros like to use lots of directories to determine which scripts get run under certain conditions.  Therefore, you’ll often see /etc/rc0.d, rc1.d, rc2.d, etc.  Since it can be difficult to configure scripts to run at certain times manually, complex (and occasionally potentially dangerous) wrapper scripts are often provided.  Frankly, I hate the Sys-V structure.

The BSD-style init structure agrees with all of the Arch principles: it has one directory for storing init scripts (/etc/rc.d/) and provides an easy way to call them when needed (through /etc/rc.conf).  So, score 1 for Arch Linux there; thank you for not making me pull anymore hair out than I have with done with Gentoo.

3: The Package Manager

Most distributions have one.  Three examples: Debian has synaptic, Gentoo has portage, and Arch has pacman.  Let me describe a brief analogy: if package managers were in charge of one of those file cabinets, you’d see something like the following:

Your synaptic-controlled file cabinet would have a ton of stuff you’ve never used before stuffed into it by default.  Furthermore, the tape binding all the dependencies together is a complete tangle, so it’s difficult to remove all the stuff that comes in there by default.  The so-called “stable” folders (packages) are starting to smell musty and old.  Want to get a list of all the latest folders?  Well, you’ll be retrieving that list from a ton of different places, including from many third-party, not-always-up-to-date-or-working, sources.  And you better have lots of time on your hands or a really fast file cabinet because you’re going to be waiting a while for synaptic to sort through all the dependency tape.

The file cabinet controlled by portage comes with next-to-nothing by default, so you don’t need to worry about trying to remove the built-in garbage that synaptic’s cabinet has.  But, if you want to add a new folder, you’re going to have to write all the contents of the folder by yourself first because portage is source-based.  The theory is that this will make the folder more efficient, but in the long-run, you lose more time building the folder yourself than letting someone who specializes in folder-building do it for you.  But, you can install different versions of your folders “easily;” you better hope that the person responsible for maintaining the specs for any folders related to the one in question carefully took this into account when specifying all the dependencies.  portage will let you only include the portions of items in the folder that you really need, but if you forget to include something, you’ll have to rebuild all the related folders all over again.  Your file cabinet will break down from time to time as it grows messier and messier, so expect to spend some long nights putting it back together.

pacman’s file cabinet, in contrast, shimmers in gold.  It’s practically empty except for what’s absolutely necessary.  The dependency tape is all neatly aligned and doesn’t cross over itself anywhere.  Adding a folder is as simple as pacman -S somename.  The folders are always at their newest versions (usually never more than a few days old) and are well-organized.  Furthermore, there is a compromise between the number of packages (want to make as small as possible to avoid redundancy) and the splitting of features (want to adhere to the Unix philosophy of “one program: one task”) that keeps the two constantly in balance.  There is one main source for most of the folders and the user-contributed ones are all stored in the Arch User Repository (popular packages will be included in the [community] repository in the main list over time).  pacman operates with extreme speed, especially with file cabinets tuned for operations with small files (ReiserFS, for example).  You can rebuild any folder you want, if you really wanted to.  Lastly, since Arch Linux/pacman use a rolling-release system, you will never have to worry about reloading your file cabinet by downloading a new CD (or in some cases, a DVD :P ) to upgrade from Creepy Clownfish to Dirty Dodo or whatever.

Hopefully that gives you an idea of what pacman is like; if it seems like an exaggeration, it actually isn’t.  pacman has been a pleasure to work with and I’ve never had a major package management problem.  It is absolutely amazing how much better it is than all of the other package managers I’ve tried.

2: Software Philosophy

Which software should a distro install by default?  How should it choose when to update the software version?  What kind of patches should it apply independently of what the software does?  All of these questions are answered by the Arch Way.

If you boot up the installer CD and follow the fast installation process, Arch Linux installs only what you need to get a running system.  This means that there aren’t 50, mostly unnecessary, system services loading every time you boot.  Heck, Arch doesn’t even include X by default (so that you can use it as a server distribution too).  The result is that the system has virtually no bloat.  You can choose what packages you want to install.

Arch also chooses to use the latest stable versions of all software.  The consequence of this is not that your system will be horribly unstable, as Debian maintainers would like you to believe, but rather that you get all the newest functionality and no risk of absurd dependency problems that arise from having older versions of software.

Because all the newest software is used, Arch maintainers don’t need to constantly backport patches to improve security or functionality of old packages.  Furthermore, Arch doesn’t believe that it should brand the distro by default unlike some other distributions (I’m especially looking at you, Canonical); if you want to install Arch-themed desktop wallpapers, you have thousands of options, but you don’t need to.

1: Flexibility

I absolutely hate it when I can’t customize my system the way I want to.  By “customize,” I not only mean via color schemes and wallpapers but also how the core system operates.  I’ll look at a few examples:

It’s important for every user to find a window manager or desktop environment that suits him or her best.  Some users love full environments like KDE or Gnome.  Others want a flashy window manager like Compiz.  And others want very lightweight managers like PekWM, Awesome, Xmonad, etc.  Heck, some people don’t even use GUIs at all.  So why should your distribution dictate which window manager or desktop environment you use by default?  Almost all other distributions (except Gentoo) do this and I don’t like that.  Sure, you could remove the existing environment and install what you want, but the larger issue is that this philosophy is inelegant; it’s a poor way to treat a kernel that has always prided itself on being oriented toward those who want to get the most out of their computers.

Personally, I use KDE on my desktop computer and Compiz as a standalone window manager on my laptop.  I’ve switched over to console applications for many of my tasks: I use Weechat for IRC, Vim for editing, etc. so I don’t really need a full desktop environment on my laptop.  If I really wanted to, I’d switch Compiz to something less-resource intensive, but I confess that I love flashy effects.

Arch allows you to control how your system starts up and operates.  You can speed up boot time by running many init scripts in parallel.  You can choose one of many different network managers to work with your wireless card (I prefer wicd for its speed and elegance).  You can secure your system using any tools available (and because fewer programs are installed by default, you can feel a little more at ease).  When there are several tools to perform a task and those tools differ greatly, Arch usually provides all of them as options, because everyone has different needs.

So what’s the downside?  Frankly, I don’t see one, but time and time again, I hear this: Arch is too complicated for new Linux users.  I think it’s a little sad that some people like to set limits for themselves, because I truly believe that Arch Linux can be installed and properly configured by anyone who is seriously interested in learning about how to get the most out of their computer.  While the Arch Way describes the distribution’s responsibilities toward the end user, the philosophy of RTFM, Read The… erm, Fine, Manual appropriately sets forth the user’s responsibilities toward the distribution.

The Arch Wiki is both concise and informative.  It describes all of the steps a new user needs to take to install Arch Linux.  With appropriate reading of the wiki (and, if you’re totally new to the command line, some external resources) and a little time, I believe that anyone can install Arch by themselves.  Also, there is a very active community available if you get stuck.  I started with a Slackware derivative and a 2.4 series kernel (on a laptop that had buggy a ACPI subsystem that was only patched with Windows drivers), so I had to learn about command-line interfaces.  It is my hope that modern Linux users never forget that at some point or another, they really do need to learn about the CLI, too.  Why?  Because GNU/Linux specifies that the graphical interface should only be a layer on top of the more solid command-line system.  That makes graphical package managers, file managers, etc. just wrappers for their respective CLIs.  When people don’t respect that and their system breaks, it often becomes far more difficult to fix (and therefore prone to the Windows-esque philosophy of “just reformat and reinstall everything”).

If you’re a Linux user, I strongly suggest you at least give Arch a try in a VM or something.  Some people will find they don’t like having to configure everything; they just want their OS to work out of the box.  But others will see the advantage of spending a little time customizing their system; it leads to a more personalized computing experience and therefore far greater productivity in the long run.  It definitely has done so for me.
Disclaimer: this “review” seems a little biased, even rant-like.  Maybe it is, but I honestly have found a distribution that matches my needs almost perfectly.  I highly doubt any operating system will make me quite as productive and happy about my configuration for a very long time.

Happy August!

A few screenshots from the desktop:

And the laptop:

As always, older desktop screenshots are are always available here: http://jwcxz.com/pictures/desktop