I can’t install using the package manager because Finch doesn’t exist in the default Etch repos (the price of running the stable distro). In reality, I could install it from etch-backports, but it has a lot of dependencies that I don’t want on my system (pidgin & x11 libs among others). This leaves me one option, compile it myself.

• I’ll be compiling Finch 2.3.1 (current version as of this writing). I won’t be compiling Pidgin, so I won’t need to install the development packages to support that program.
• I’m performing a default install, this will put Finch and it’s files into the /usr/local path
• I’m running all of these commands as my regular user, the root password will be required for two steps.

Install everything needed to build the Finch client

su -c 'apt-get install build-essential linux-headers-2.6-686 libxml2-dev intltool libglib2.0-dev gettext libncurses5-dev libgnutls-dev'


Download the source files and extract them (~/src is where I keep my source and build files):

mkdir -p ~/src ; cd ~/src

wget http://downloads.sourceforge.net/pidgin/pidgin-2.3.1.tar.bz2

tar xvjf pidgin-2.3.1.tar.bz2

cd pidgin-2.3.1

Run configure; Feeding it the --disable-gtkui argument tells it that I only want to build the Ncurses client (Finch)

./configure --disable-gtkui

Once the configure script completes, it’ll output Finch’s configuration information (kinda neat to read). I can review it later by reading ~/src/pidgin-2.3.1/config.log.

Now I build the binaries and install, the make command will take a while to do it’s job and output all sorts of stuff to the screen. It looks awesome if you’re doing this from your desktop with transparent terminal windows and a dope background. I like to run top in one terminal and compile in another, then I toss on some 90’s techno, run a small screen visualization and imagine myself doing something cool like hacking the Gibson.

make

su -c 'make install'

I now have finch running and ready to go. When the next version of Pidgin/Finch is released, all I need to do is go back into the directory I built in (~/src/pidgin-2.3.1) and run the command su -c 'make uninstall' to remove the program’s files. Following that, rm -rf ~/src/pidgin-2.3.1, and follow the whole process again substituting the filename/path where applicable.

isoinfo:

This is the one that saved me from wasting (a lot of) media so I’ll start with it. Since I need to create DVDs that can be read both in Windows and Linux I create my media utilizing both the MS Joliet specification and Rock Ridge standard. Basically, both of these extensions to the ISO9660 standard allow for additional file information to be stored on CD/DVD (long filenames, permissions and so on).

Initially I was attempting to create an ISO containing files with names exceeding 64 characters. Joliet technically only allows for 64 and was doing awful things to my file names (umm hello, truncating the extension?). Isoinfo (isoinfo -i <iso> -lJ) allowed me to see that the Joliet filenames were broken. Had I burned that DVD it would have appeared fine on my Linux machines (as they would be referring the RR data on the DVD) but would have been been a problem on my Windows boxes. Just that command saved me at least two discs

Handy isoinfo commands:

isoinfo -i <iso> -lJ: View info from Joliet extensions
isoinfo -i <iso> -lR: View info from RR extensions
isoinfo -i <iso> -d: View ISO’s properties

isovfy:

Isovfy’s man page states: isovfy is a utility to verify the integrity of an iso9660 image. Most of the tests in isovfy were added after bugs were discovered in early versions of genisoimage. It isn’t all that clear how useful this is anymore, but it doesn’t hurt to have this around.

Lack luster description, I personally don’t know how useful it is either but I figure that if you download an ISO, it couldn’t hurt to run this proggie on it for a quick sanity check.

isovfy <iso>

isodump:

Yeah, this one is a mystery to me. I personally couldn’t find a human use for this one at all. isodump is a crude utility to interactively display the contents of iso9660 images in order to verify directory integrity. The initial screen is a display of the first part of the root directory, and the prompt shows you the extent number and offset in the extent.

Feel free to try it on your ISO, just keep in mind that the man page is accurate, it’s crude. Personally, I get what I need from the other two utils so I’ll just forget about this one.

That’s all I have on ISOs for now, check out the wikipedia links throughout the post, if you’re a little geeky it’s interesting reading

Note: I did all of this as root

First, creating an ISO image. What I need to do is create an image from a directory of goodies that I need to back up. The directory I’m backing up contains 4.4G (or one single layer DVD) of random MP3s and I want them written to the root of the DVD when it’s finalized.

I started by reading the man page for mkisofs. That got me started, and then a quick read of http://wiki.linuxquestions.org/wiki/Mkisofs finished me off. My first few attempts just gave me ISOs containing MP3s with short filenames or short filenames in all CAPS. Not what I wanted, these are all descriptively named files and I want to retain the names. The command below worked perfectly.

mkisofs -r -J -l -d -joliet-long -allow-multidot -V Mp3_003 -o ./Mp3_003.iso _Archive/Mp3_003/*

All of those options are important, -r makes the files publicly readable (among other things), -J preserves case (upper/lower), -l allows long filenames, -d doesn’t add a period to the end of files that don’t have them, -joliet-long allows up to 103 characters (vs 64), -allow-multidot allows files to contain multiple periods and -o specifies the output file name, . Optionally, (but why wouldn’t you) -V sets the DVD’s Volume name (up to 32 characters). As is typical, there are many more options available to you, spend a little time reading the man page for more info.

Note: -joliet-long was key for me. I found that when I attempted to read files with filenames longer than 64 characters on Windows, they would be truncated and NOT in a good way. The filename would be truncated in reverse, starting with the file extension. A 65 character file with a .MP3 extension would end up with a .MP extension. Ugly. That said, the man page warns that this breaks the joliet specification and to use with caution. You’ve been warned.

After a few moments you’ll have an ISO image containing all of the files you specified. In my case, all of the MP3’s I’ve collected since I burned my last backup.

Now to write it to my media:

cdrecord -v -sao dev=/dev/dvd Mp3_003.iso

-v sets verbose mode, -sao enables session at once (no multi-disc), dev=/dev/dvd specifies the device to use and finally, the input file; Mp3_003.iso. There are A LOT of options available to you, you’ll want to spend a little time with man cdrecord.

Note: You don’t need to specify the device if you have a properly configured /etc/wodim.conf. If you’re wondering why it isn’t /etc/cdrecord.conf, the answer is that cdrecord is nothing more than a sym link to /usr/bin/wodim on Debian (and possibly other distros). You can verify this on your box with which cdrecord | file -f -.

My first write failed but it was because I have two VMware virtual machines running on this box and they were attempting to poll the CD-ROM drive for media. The fix was to disconnect the drives in the VMs and then burn.

The resulting CD should be readable in any modern OS. I have no problem accessing the files from Linux or Windows and feel confident that I have a solid solution for creating DVD archives.

Firstly, I installed the dependencies that are required for Gaim (got this tip by googling, can’t remember where)

sudo apt-get build-dep gaim

Then I installed build-essential and libglib2.0-dev (I already had these installed, just put that here for completeness)

sudo apt-get install build-essential libglib2.0-dev

I downloaded the program source from http://pidgin.im/pidgin/download/ and put it into ~/src/. After the download, I extracted everything from the archive (tar -xjvf pidgin-2.0.0.tar.bz2), changed into the ~/src/pidgin-2.0.0 directory and ran the configure script (which seemed to complete normally)

./configure

Then I ran make

make

Then I installed

sudo make install

This method about above will install Pidgin and its dependencies to /usr/local/lib and will automagically install a menu item for the application in your Gnome menu under Internet.

If you do the same, just remember that whenever there’s a new Pidgin release you’ll need to download, compile and install, your package manager has no idea what-so-ever that you’ve done this.

Check out the release notes and enjoy

Edit: fixed some silly spelling errors

I’ve just downloaded 2 VMware appliances, one includes Twiki, and the other MediaWiki (of wikipedia fame). I’m going to take some time to evaluate both (yeah I know I’m supposed to be reading about LVM, this is in addition to). I’m going to document what I learn about LVM in my Wikis and see which “feels right” to me.

I’ve already started using Twiki, I don’t find it difficult, the shorthand is easy enough to learn, but I have nothing to compare it to. Hence the download of MediaWiki. I can muck it up, see what I like, which package I prefer, and then see about installing my own wiki and migrating my work over. Should be a nice learning experience.

This is just another killer use for VMware appliances. Just start the VMs up, play and delete. No muss, no fuss. Love that!

You can download the Twiki appliance from http://twiki.org/cgi-bin/view/Codev.TWikiVMDebianStable

You can download the MediaWiki appliance from http://www.rpath.org/rbuilder/project/vehera-base/

As it turns out, building your own study guide is a fairly complex process. Which how-tos and docs are the best/most accurate? I’ve been lightly reading over what I’ve found and here’s what I’m using to attempt to teach myself how to utilize LVM.

Notes:

I will most likely be using Debian (etch) for my testing and the server I’ll be building after the fact. I find that Debian and it’s derivatives tend to be well documented and have oodles of software available “out of the box”. Even if software isn’t available, I’ve had luck compiling on Debian (probably due to good documentation). Debian has slow official release cycles and that’s perfect when your building a server based on their stable branch. I don’t want to have to worry about upgrading the machine every 6 months

Reading material:

• Managing Disk Space with LVM (linuxdevcenter.com) – quick read, pretty pictures
• Simple Intro to Working with LVM (debian-administration.org) – quick read, ugly pictures
• LVM HowTo (tldp.org) – large and in-depth
• Man pages

Reading and practice material:

• A beginner’s guide to LVM (howtoforge.com) – Not only is this inspired by the linuxdevcenter.com & debian-administration.org docs above, but it comes with a VMware appliance already set up and ready for you to hack on and ruin and start all over with. Now THAT is how you learn!
• Once I’ve mucked about with the VM image above and feel comfortable, I’ll be building a few of my own VM images and seeing what I can do with LVM myself.

Thoughts before getting started:

• Can one use a live CD to recover data from a machine with an LVM configuration?
• Can one have a multi-boot system and read/write data on another Linux install if that install is configured to use LVM?
• If one was to have a multi-boot system, would LVM be a really bad idea? (that sorta depends on the answer to the question above)
• What am I not thinking of? (always the last question I ask myself)

So now that I have something to read, I just need to start reading. Hopefully I can find some night this week to plow through the docs once or twice and then start ruining VMs – This is my first month long learning project, I reckon I’ll start the timer whenever I start actually reading.

It’s nice keeping my password manager on my main workstation. I hadn’t realized how much I disliked having to hit the other machine every time I couldn’t remember one of my passwords.

Anyway, I can’t stress enough, there is a lot of value in cross platform applications. Now I have something else to keep in mind when evaluating software

A long time ago I settled on a Windows only password manager (PM). I have hundreds of passwords and I keep them in an encrypted Password Corral database. The program & db live on my Windows box and I keep a copy on my flash drive that goes everywhere with me. I assumed that I would never use another OS and this program would last me a good long time. <– That’s where I screwed the pooch. I find myself using Linux almost exclusively now and I want a PM that will not only work on Linux, but on Windows as well (and I’m keeping my options open, I might have a MAC some day too).

I did some searching last night and found a nifty looking cross platform replacement PM named KeePass. It’s open source (I like that very much), uses strong encryption, and it’s portable. I can keep a copy of the Windows exe on my flash drive as well as a shell script that will allow me to run it on a Linux box (it seems to have all of the libraries in the tarball so it should run on any distro with a GUI).

Both programs have a similar set of features and both satisfy my needs. So I have some options here, and now I need to decide what I want to do.

Option 1: Do nothing

I’ve found that Password Corral works well enough in Wine, but I prefer using Linux native apps when I’m using Linux (who wouldn’t?). If I do nothing, I will always need to have Wine installed on any machine I want to run the app on. I must admit that this option does NOT appeal to me.

Option 2: Migrate to KeePass

KeePass has a nifty import feature, and Password Corral has a nifty export feature. Sadly, they don’t read/write common formats. That means I’m going to have to manually move everything over to KeePass. That sucks (to put it mildly). I REALLY don’t want to spend my time using copy/paste to get the data from one app to the other. This option doesn’t appeal to me either.

So, I have 2 options, both rot. Not sure what I’m going to do at this point.

If you’re looking for a portable app, something that you’re going to rely on, put some thought into it. Consider open source and whether or not the program is cross platform. You may not always be in front of a Windows machine!

I opened the 12 page doc file in OpenOffice and exported it to PDF. There wasn’t a clear way to save each page as an individual file so my output was a single PDF. I needed a fast and easy way to split the pages up for publishing. I remembered some chatter on the GNHLUG list regarding pdftk so I installed it, took a brief look at the man page and did the following:

pdftk Calender2007.pdf burst output ~/tmp/%02d-2007.pdf

Poof! Calendar split out to 12 files named 01-2007.pdf, 02-2007.pdf and so on.

This saved time and eliminated the annoyance factor completely!  The tools available for Linux blow my mind, these are programs I never would have even heard of when I was strictly Windows.  Change is GOOD.

I’ve only heard/read wonderful things about CNR, so I can’t give any details past what’s included in the press release. It should be interesting to follow the reactions of the distros mentioned and see if/how they plan on embracing CNR.

If this is something that the better known distros will latch onto, the argument that software installation on Linux “sucks” could be a thing of the past. If played well, this could do A LOT to push Desktop Linux into the foreground.

This might be a good time to download Freespire and see just how nice CNR is.