Linux on a flash drive

Linux.Ars has the lowdown on SLAX, a Linux installation for your USB flash …

Introduction

Welcome to another edition of Linux.Ars. We've been pretty busy here in the Orbiting HQ, preparing for the launch of Ubuntu Hoary this week. Our crack staff has still managed to assemble a top-notch volume of tidbits from around the Linux world.

In this issue we are taking a look at how to extend version control to automatically deploy your projects. We'll also be throwing away those extra peripherals and learn how to controlling multiple computers with a single keyboard and mouse. We're also taking a look at new ways of exploring our musical horizons. Fasten your seatbelt, young grasshopper. We're going for a ride.

Developer's corner: automating deployment with Subversion (SVN)

One of the challenges I've run across as a developer is automating deployment. As a freelance programmer I want the flexibility to work from where ever the tide takes me, be it the local WiFi-equipped Panera Bread or my basement office. A version control system is a good solution to that problem. I had used CVS before and was comfortable with it but I found something while reading Version Control with Subversionthat made up my mind: hooks.

Assumptions

Here's the scenario: I'm building a website. I have two web servers: one for development and one for production. I want my changes to immediately replicate to the development server so that once I'm satisfied that everything works I can push the changes to production, all with a minimal effort.

For the sake of this discussion, the development web is stored under /var/www, and the Subversion root is /var/lib/svn.

Hooks

Hooks are scripts that are run at various stages of the commit process. This allows you to add programmatically control, cross-reference, tweak, reject, or otherwise manipulate content that is being committed to your respository. This flexibility allows you to send change notifications via e-mail, restrict commit access by module and user or, as I'm using it, to automate the deployment of changes to a development site.

Subversion implements five types of hooks

start-commit

pre-commit

post-commit

pre-revprop-change

post-revprop-change

Making it work

The process is fairly painless. On the development server, I check out my website from Subversion. This, particularly when adding an existing project to Subversion, allows me to make sure that i have a complete working copy under version control. Next, I add a post-commit script on my Subversion server. In my case, subversion is on the same server as the development website but this can easily be adapted to work with seperate machines.

Subversion executes hooks as the user who owns the process accessing the Subversion repository. In order to allow our hook to update the development site, it needs to run with the permissions of the owner of /var/www.

There are a few different ways you can do this:

Setuid binary

Unix doesn't allow scripts to be made +s, so we can create a small C application to run svn update. Be warned that setuid binaries can be a security risk so it might not be the wisest solution for your environment.

The easiest way I've found to test that this is working is to watch the revision numbers. Commit a change to the svn repository and then verify that the revision incremented on your development site.

Summary

With this in place, any changes committed to Subversion will be reflected on your development site. You could take this a step further and automate deployment to a live site, but I wouldn't recommend it. It's best to make your changes to the development site, run through QA or unit tests or whatever kind of testing you do, and then deploy to production. You can use the same tactic of making production a checkout of your svn repository. That way updating production is as simple as running svn update.

Tools, Tips, and Tweaks

Synergy

Synergy is a cross-platform application that allows you to control multiple machines using a single keyboard and mouse.

It also synchronizes your clipboard and screen savers, effectively giving you one potentially large multi-platform desktop. Move your mouse off the edge of the screen to switch between displays.

There are other applications that work with similar results, such as x2x and x2vnc but I've found synergy is extremely easy to setup and works better than I could have hoped for.

Synergy is composed of two applications: synergys and synergyc. Synergys is the server portion that runs on the machine with the keyboard and mouse you want to use physically attached.

A simple configuration file, either /etc/synergy.conf or ~/.synergy.conf, defines your "screens" and their relation to each other.

Pretty simple so far. Frodo.local, which is a Mac Mini running OSX, needs to have its Apple key remapped in order for keyboard shortcuts to be useful using my Model M keyboard. Moradin, which is a laptop and not always connected to synergy, is set in the up position from any display. When a display is not connected to the server, your mouse just won't flip to that screen.

Connecting the client machines is easy:

$ synergyc smeagol

Performance is pretty solid. Mouse action on remote displays is pretty smooth, unless the system is under a heavy load. Mac OS X support is considered incomplete, so your experience may differ from mine. I've only used OS X as a client and I've heard from others that have had poor performance using OS X as the server. You have been warned.

The joyous last step is to automatethe synergy startup, so you never need to touch those other keyboards again.

Cool App of the Week

This week, we take a look at the music player amaroK.

amaroK

While the world of music players for linux mostly revolved around xmms and rhythmbox, these programs stemmed from their closed-source counterparts Nullsoft's WinAmpand Apple's iTunesrespectively. Recently, a new take on the subject has led to nodding heads. amaroK is a end-all solution for playing music in Linux. Written to run off the KDE libraries, amaroK delivers in the ares of feature set, speed and configurability.

Although the features are too long to list here, some of the notables that might impress are:

The interface is clean, and by default it looks like a well-thought-out KDE application. While it closely resembles JuK, another media player for KDE, most users will find the layout appealing. If not, the layout is fully scriptableusing CSS and themesare already available for download.

The speed of amaroK was impressive in tests. Adding about 8,000 songs took roughly 5 minutes, which is respectable considering it takes at least twice as long in iTunes.

amaroK also has a decent set of scriptson the wiki available for download. They range from diplaying what song you're currently playing in IRC to allowing you to change songs without leaving Firefox to downloading podcasts.

Without a doubt, the DCOP functionality present in amaroK will be a decision-maker for some of you. While new to DCOP myself, IBM has a decent tutorial herethat gives a nice overview of its capabilities. Basically the DCOP functions for amaroK allow the user to write his/her own scripts to control various aspects of the music player (i.e., skip song, randomize playlist, raise volume, etc. )

For those you wondering what AmaroK means, its inuit for wolf.

/dev/random

SuperTux is a fun Mario-like sidescroller. It is currently under heavy development, but is very playable. If this Linux.Ars is late, you know why ? Editor's note: I cracked the whip on Adam ;-).

Penguicon 3.0will be bringing Fen and Penguin together for the third year in a row in Novi, Michigan. As always, we'll have a strong Ars presence at the show, if you're in the area stop by and say hello.

Linus respondsto the withdrawalof the free version of the BitKeeper version control system.