Oct 072013



Compiling Python on one type of system to run on another type, known as “cross-compiling”, is a notoriously difficult issue, because the Python process is very complicated, and it was not designed with cross-compilation in mind.  However, a simple recipe has been devised for past versions up to Python-2.7.3:


The gist of this process is summarized in 2 steps:

  1. Compile python and Parser/pgen to run on the build-system, because they are used later in the cross-compilation process.
  2. Compile everything else and python and Parser/pgen again using the cross-compiler tool-chain.

Thanks to recent work (Issue 17086), Python’s cross-compilation process has been enhanced to use and accept an external python interpreter, which is used during the build process.  This simplifies some of the patching provided by Paul’s blog post; however, it also changes the underlying code dramatically, which may explain why there have not been any new posts documenting the updated process with new patches since Python-2.7.3.

An Updated Patch and Build Process for Python-2.7.5

Using this patch and a suitable cross-compilation tool-chain (gcc, c++, ar, ranlib, etc.), the following process can be used to build Python-2.7.5 on one Linux system to run on another Linux process:

Prepare Sources

$ export RFS=/path_to_embedded_root_file_system
$ wget http://www.python.org/ftp/python/2.7.5/Python-2.7.5.tar.bz2
$ tar -jxf Python-2.7.5.tar.bz2
$ cp <wherever_you_saved_it>/Python-2.7.5-xcompile.patch Python-2.7.5/
$ cd Python-2.7.5

Most embedded projects will have a directory on the build system, which contains all of the directories and files to be placed on the root file system of the embedded device. In this script, the full path to this directory is defined as RFS. The remaining steps retrieve the source code, unpack it, copy the above patch into place, and change into the build directory.

Step #1 – Compile Programs Used by Build System During Build

The first major step compiles 2 binaries to run on the build system: the python interpreter and Parser/pgen:

$ ./configure  # for build-system's native tool-chain
$ make python Parser/pgen
$ mv python python_for_build
$ mv Parser/pgen Parser/pgen_for_build

After building these 2 binaries, they are moved aside for later use during the full cross-compilation and installation process.

Patch Build Files and Prepare for Cross-Compilation

In preparation for the next step, all of the compiled files – except for the 2 moved aside – are deleted, the build files are re-configured using the cross-compilation toolchain, and the full Python suite is built including modules, such as ssl, zlib, and ctypes:

$ export PATH="/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin:${PATH}"
$ make distclean
$ ./configure --host=powerpc-none-linux-gnuspe --build=i586-linux-gnu --prefix=/ \
    --disable-ipv6 ac_cv_file__dev_ptmx=no ac_cv_file__dev_ptc=no                    \

I have included the full path to my current tool-chain as an example. (I have used this process for both x86 and x86_64 build systems to produce a Python installation for a Freescale PowerPC embedded Linux system.) Please notice how the path contains and corresponds to the “host” entry in the cross-compilation configuration step. I had to specify a few extra switches (disable-ipv6, ac_cv_file__dev_ptms, ac_cv_file__dev_ptc, and ac_cv_have_long_long_format) to help the configure script resolve some tests that required execution on the host. These will vary depending upon your embedded host system’s architecture.

For reference, here is the list directory listing of the above cross-compilation tool-chain:

$ ls -la /opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin
-rwxrwxrwx 1 root root  590485 Mar  5  2012 powerpc-none-linux-gnuspe-addr2line
-rwxrwxrwx 1 root root  614647 Mar  5  2012 powerpc-none-linux-gnuspe-ar
-rwxrwxrwx 1 root root  897161 Mar  5  2012 powerpc-none-linux-gnuspe-as
-rwxrwxrwx 1 root root  235382 Mar  5  2012 powerpc-none-linux-gnuspe-c++
-rwxrwxrwx 1 root root  589227 Mar  5  2012 powerpc-none-linux-gnuspe-c++filt
-rwxrwxrwx 1 root root  234277 Mar  5  2012 powerpc-none-linux-gnuspe-cpp
-rwxrwxrwx 1 root root    8503 Mar  5  2012 powerpc-none-linux-gnuspe-embedspu
-rwxrwxrwx 1 root root  235382 Mar  5  2012 powerpc-none-linux-gnuspe-g++
-rwxrwxrwx 1 root root  233126 Mar  5  2012 powerpc-none-linux-gnuspe-gcc
-rwxrwxrwx 1 root root  233126 Mar  5  2012 powerpc-none-linux-gnuspe-gcc-4.3.2
-rwxrwxrwx 1 root root   16512 Mar  5  2012 powerpc-none-linux-gnuspe-gccbug
-rwxrwxrwx 1 root root   28017 Mar  5  2012 powerpc-none-linux-gnuspe-gcov
-rwxrwxrwx 1 root root  655127 Mar  5  2012 powerpc-none-linux-gnuspe-gprof
-rwxrwxrwx 1 root root 1036372 Mar  5  2012 powerpc-none-linux-gnuspe-ld
-rwxrwxrwx 1 root root  603678 Mar  5  2012 powerpc-none-linux-gnuspe-nm
-rwxrwxrwx 1 root root  750617 Mar  5  2012 powerpc-none-linux-gnuspe-objcopy
-rwxrwxrwx 1 root root  895336 Mar  5  2012 powerpc-none-linux-gnuspe-objdump
-rwxrwxrwx 1 root root  614647 Mar  5  2012 powerpc-none-linux-gnuspe-ranlib
-rwxrwxrwx 1 root root  264063 Mar  5  2012 powerpc-none-linux-gnuspe-readelf
-rwxrwxrwx 1 root root  593901 Mar  5  2012 powerpc-none-linux-gnuspe-size
-rwxrwxrwx 1 root root  591853 Mar  5  2012 powerpc-none-linux-gnuspe-strings
-rwxrwxrwx 1 root root  750617 Mar  5  2012 powerpc-none-linux-gnuspe-strip

As you can see, each of the binaries are prefixed with “powerpc-none-linux-gnuspe-“, which corresponds directly with the “host” variable in the configuration step.  (Please ignore the fact that these binaries are world writable!  This is not good, but it is a secure build system, and this is an artifact of some unrelated build system workarounds.   Your binaries should only be writable by user.)

Step #2 – Cross-Compilation

Having re-configured the sources for cross-compilation, the next major step is to actually cross-compile the fully Python suite include modules:

$ make --jobs=8 \
    CFLAGS="-g0 -Os -s -I${RFS}/usr/include -fdata-sections -ffunction-sections" \
    LDFLAGS='-L${RFS}/usr/lib -L${RFS}/lib'

The linked patch hard-codes additional build dependencies, where the compiler and linker can find header and library dependencies, like so:

diff --git a/packages/Python-2.7.5/setup.py b/packages/Python-2.7.5/setup.py
index 716f08e..ca8b141 100644
--- a/packages/Python-2.7.5/setup.py
+++ b/packages/Python-2.7.5/setup.py

@@ -552,6 +556,11 @@ class PyBuildExt(build_ext):
         if host_platform in ['darwin', 'beos']:
             math_libs = []

+        # Insert libraries and headers from embedded root file system (RFS)
+        if 'RFS' in os.environ:
+            lib_dirs += [os.environ['RFS'] + '/usr/lib']
+            inc_dirs += [os.environ['RFS'] + '/usr/include']
         # XXX Omitted modules: gl, pure, dl, SGI-specific modules


However, they are also embedded in the above CFLAGS and LDFLAGS for good measure. 🙂 Please notice that the patch depends on the RFS serving as a flag to trigger this behavior.

Optional:  Reduce Binary Size

Optionally, additional compilation flags are also set in the above step, which help the cross-compilation strip tool reduce the binary size, like so:

powerpc-none-linux-gnuspe-strip --strip-unneeded python

This is entirely optional. Removing this step and the data-sections and function-sections compiler flags may help simplify the process, when troubleshooting.

Install into Root File System for Embedded Target

Lastly, the suite can be installed into the embedded device’s root file system, like so:

$ sudo make install DESTDIR=${RFS} PATH="${PATH}"

Often but not always, embedded root file system directories on the build system are owned by root; consequently, sudo is required to modify any files in the RFS directory. Since sudo also disregards the PATH environment variable, it must be passed explicitly via the command line.


Although patches and similar processes have been provided by others for Python-2.7.3 and below, there have been no recent updates or tutorials for 2.7.4 or 2.7.5 that I have been able to find on the internet. Most likely, this delay is because of the significant cross-compilation changes and the daunting complexity of the Python build process. The above process and linked patches enable this ongoing process for Python-2.7.5 and hopefully other future versions.  Hopefully, this patch set will eventually disappear as increasingly more cross-compilation capability is integrated into Python’s own internal build process.

Although I don’t have time to support this patch, if you have any suggestions on improving it, or if you find any bugs, please let me know in comments below.

A more elaborate build script with error checking and comments is available here for download.

Feb 222011


Sometimes, you may only be able to connect to a Microsoft SQL (MS-SQL, or MSSQL) server through its SQL port, so you cannot use RDP to access the Enterprise Manager or other graphical tools on the host.  Other times, you may simply want to leverage the power of a Linux box.  😉  Regardless of the reason, if you want to connect to a MS-SQL server from a Linux box, read on…  As in previous posts, any installation or configuration instructions pertain to Gentoo.  Please adapt as necessary. … Also, these instrcutions were tested on MS-SQL Server 2000, so some instructions may need to be adapted depending on your version of MS-SQL.


FreeTDS offers an opensource command line client, tsql.  This is comparable to using Microsoft’s OSQL command line interface, although the arguments to launch the client are different.  Although it has various options, you launch tsql, like so:

tsql -S <sql_server_name> -U <user_name> [-P <password>]

If you are comfortable with OSQL, you will have no problem using this basic SQL CLI client.


Packagers are available for Perl, PHP, Python, and several other scripting languages, which provide an extensive, programmatic interface to the remote MS-SQL server.


  1. http://members.cox.net/midian/howto/phpMSSQL.htm
  2. http://coding.derkeiler.com/Archive/Perl/perl.dbi.users/2006-09/msg00108.html
  3. http://www.easysoft.com/developer/languages/perl/sql_server_unix_tutorial.html
  4. http://www.easysoft.com/developer/interfaces/odbc/linux.html
Jun 162009


Previously I blogged about using Alsa with EchoAudio’s Mia 96-kHz / 24-bit prosumer audio card. However, I have since experienced one nagging problem: Only one application can use the sound card at a given time! It is impossible for two or more applications to share the sound card. For a second application to use the Mia, the first app must be closed before the second is opened; otherwise, the first one will maintain a lock, blocking the second.

Many newer sound cards included integrated mixers, which allow multiple applications to simultaneously produce sound. Older sound cards depended upon software to perform the mixing. ALSA includes the “dmix” plug-in, which performs this very task.

ALSA DMIX Configuration

Typically, dmix is used automatically by ALSA, whenever it detects a sound-card without built-in mixing. Unfortunately, the ALSA driver for the Mia reports the card as having mixing capability, which it does not. Therefore, we must manually direct ALSA to use the dmix plug-in by default. ALSA is generally controlled through the “asoundrc” file, which can exist at the system or user level:


Several tutorials and HOWTO’s exist to set up ASLA’s dmix plug-in; however, these proved overly complicated, as I simply use:

$ cat /home/my_user/.asoundrc
pcm.!default {
    type plug
    slave.pcm "dmix"

This directs all applications to use the dmix plug-in by default. Now I can simultaneously play sound from multiple applications and without having to open and close each application in sequence!

System ALSA Configuration

Just for reference, my system’s ALSA configuration seems to use DMIX by default; however, it has never worked for me. I am including it here, just for reference:

$ cat /etc/asound.conf
pcm.swmix {
    type dmix
    # any unique number here
    ipc_key 313
    slave {
        pcm "hw:0,0"
        # these settings may require tweaking for different sound
        # cards; this is for the Powerbook's built-in snd-powermac
        # probably not required at all for well-behaved cards...
        period_time 0
        period_size 1024
        buffer_size 8192
        # mentioning rate fixes wrong speed/pitch in native ALSA stuff
        rate 44100

# this makes OSS emulation via aoss default to using dmix, allegedly
pcm.dsp0 {
    type plug
    slave.pcm "swmix"

ctl.mixer0 {
    type hw
    card 0

# this makes native ALSA apps default to using dmix
pcm.!default {
    type plug
    slave.pcm "swmix"

Conversation with Giuliano Pochini

Giuliano Pochini is the author of the ALSA driver for the EchoAudio Mia. Recently, I posed my problem to him, as follows:

I am using your ALSA driver for the EchoAudio Mia PCI card. You have done a fantastic job! I really appreciate it.

One question: I am only able to use one application at a time to produce sound. If I want to produce sound in another application, I must close the first application, and then open the second.

Is it possible to have more than one application simultaneously produce sound through the Mia?

Should I use ALSA’s dmix plug-in, or is there a better solution?

To which, he kindly replied:

That card has 8 voices and 4 outputs. The vmixer controls how the voices are sent to the outputs. If your application uses default: or hw:x.0.0 or plughw:x.0.0 then it can use a single 1 to 8 – channels output. You have to use dmix to make alsa-lib mix the sound coming from differents apps. Otherwise you can manually configure your apps to use plughw:0.0.0, plughw:0.0.2, plughw:0.0.4 and plughw:0.0.6 and use the vmixer to route them to the ouptus as you prefer.

There is another way which requires some non trivial changes to the driver: make it automatically select the first free stereo pair when an application opens a substream. Drawbacks are that apps wouldn’t be able to open non stereo substreams anymore and that changing the volume would become problematic because you couldn’t know what channels have been assigned to each app. And, of course, there are only 4 stereo pairs available, all with the same sample rate, so dmix and resample are likely to be necessary anyway.


  1. http://alsa.opensrc.org/index.php/.asoundrc
  2. http://alsa.opensrc.org/index.php/AlsaTips#Share_a_single_card_with_multiple_applications
  3. http://alsa.opensrc.org/index.php/DmixPlugin
  4. http://alsa.opensrc.org/index.php/Hardware_mixing%2C_software_mixing
  5. http://www.alsa-project.org/main/index.php/Matrix:Vendor-Echo_Corporation
  6. http://www.alsa-project.org/main/index.php/Matrix:Module-mia
  7. http://www.webalice.it/g_pochini/ead
  8. http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
Dec 052008


Every computer you buy or assemble comes with some decent integrated sound card.  A while back (~2000), I bought a “prosumer” (entry-level professional) sound card, the Mia by EchoAudio.  It was a pain at first, because the Windows drivers for XP were just not mature.  However, after about 6 months of updating drivers every other week, I finally got a rock-solid sound card that blew the doors off any integrated sound card I have used, even up to this day (12-2008).  All the integrated cards sound so “tinny” and “weak”, compared to the rich, full sound of this card.

For some time, I have avoided moving my main workstation to Linux, in some measure, due to the lack of drivers for this sound card.  However, a few weeks ago, I noticed an entry for the EchoAudio Mia in the kernel config!  Here is how I managed to get it working on Gentoo Linux.

Default ALSA Installation

The most modern sound system on Linux at this time is ALSA.  The Gentoo wiki page for installing it is here:


One important note:  ALSA can be compiled into the kernel or compiled separately as loadable modules.  Currently, Gentoo has mostly abandoned the in-kernel approach (which uses the alsa-drivers package), and it now uses the loadable module approach.  There’s no reason to buck the system here, so we are going to use the loadable module approach.

When you activate the appropriate ALSA kernel options, make sure you include the driver for the EchoAudio Mia, or whatever Echo Audio product you may be using.  Otherwise, you can follow the above guide up to the point where you are ready to run alsaconf.

Make sure you:  Recompile the kernel.  Copy it into place.  Update grub.conf.  Reboot.  You know the drill.  🙂

Modified ALSA Installation for Mia

The Mia driver depends on alsa-utils, but it also needs other ALSA packages, which are not necessary for other integrated sound cards, like hda-intel.  Furthermore, the default make.conf flags do not include the Mia components.  To include these, and to use the latest version of ALSA ;), let us first add a few keywords and compile flags to the ALSA build configuration:

Now, we are ready to install ALSA, again, in addition to the other necessary packages:

# Use latest version of everything ALSA
$ echo -e "media-sound/alsa-tools ~amd64\nmedia-sound/alsa-utils ~amd64\nmedia-sound/alsa-firmware ~amd64\nmedia-sound/alsa-headers ~amd64\nmedia-libs/alsa-lib ~amd64" >> /etc/portage/package.keywords

# Include Mia during ebuilds
$ echo 'ALSA_CARDS="mia"' >> /etc/make.conf

# Check for weirdness:
$ emerge -pvt alsa-utils alsa-tools alsa-firmware alsa-lib alsa-headers

# Build!
$ emerge alsa-utils alsa-tools alsa-firmware alsa-lib alsa-headers

Now update the ALSA configuration using alsa-conf, and you should be good to go!

$ alsaconf

Other Tips

The best mixer to use is the echomixer, which is made for the EchoAudio products, like the Mia.

In the default configuration, most everything is muted, so you will have to slide up the appropriate sliders.  Just be careful not to overdrive the card.  Stop at “0 dB” or less.  Do not slide it up to “+6 dB”; otherwise, you get a fair amount of distortion.

Other pages that mention the “alsa-drivers” package are based upon the “IN-KERNEL” approach.  Those instructions are not compatible with these.  Be careful if you decide to “mix and match”.


  1. ALSA’s EchoAudio development status – http://www.webalice.it/g_pochini/ead
Dec 052008


Regrettably, there are some software applications that just run better on Windows, specifically, Windows XP.  Of course, Windows runs better on Linux, so I guess we can still hold to our axiom that “All things run better on Linux”. 😯 Ok, not really.  😀

In my case, I would like to run the full Office 2003 suite on Linux.  Using Wine is an option, but it can be a bit buggy.  CrossOver is a better option, but it costs money, and I am cheapskate.  Plus, it’s like “double-taxation”.  I have to pay somebody a tax, so I can pay my Microsoft tax.  That ain’t right!  Well, I am not really a Linux purist – I am just a practical cheapskate.  And, I would like to learn about OS virtualization, and apparently, so do you!  Otherwise, you would not be reading this.  😉

Installing KVM on Gentoo

KVM is just one of many possible virtualization methods, which is a way to run one OS inside of another OS.  (Imagine a “window” that is running Windows XP inside, and it “thinks” it is the entire computer.  It does not realize that it is running inside of another “computer”.)

Note:  These instruction are for:

Host:  Gentoo 2008.0
RAM:  >= 1.5GB
Kernel:  2.6.27
KVM:  v79
Guest:  Windows XP Pro

Of course, there these instructions may have to be varied slightly to accommodate your exact application.

Here are my modified instructions, based on the Gentoo Wiki:

1. Update the kernel with IN-KERNEL KVM (no need for module mayhem):

$ cd /usr/src/linux
$ make menuconfig

[*] Virtualization --->
        --- Virtualization
        <*> Kernel-based Virtual Machine (KVM) support
        <*>   KVM for Intel processors support
        < >   KVM for AMD processors support
        <*>   PCI driver for virtio devices (EXPERIMENTAL)
        <*>   Virtio balloon driver (EXPERIMENTAL)

If you want to be able to do networking, you should also enable VLAN bridging and tapping, while you are here:

Device Drivers --->
    [*] Network device support --->
            <M> Universal TUN/TAP device driver support

Networking --->
    Networking options --->
        <*> 802.1d Ethernet Bridging
        <*> 802.1Q VLAN Support

Copy new kernel into place.  Update grub.conf.  Reboot using new kernel. … You know the drill. 🙂

2. Ensure the latest version of KVM:

$ echo 'app-emulation/kvm ~amd64' >> /etc/portage/package.keywords

3. Activate useful USE flags:

$ echo 'app-emulation/kvm gnutls sdl' >> /etc/portage/package.use

4. Check emerge for weirdness and install:

$ emerge -pvt kvm usbutils bridge-utils usermode-utilities

These are the packages that would be merged, in reverse order:

Calculating dependencies... done!
[ebuild   R   ] sys-apps/usermode-utilities-20040406-r1  0 kB
[ebuild   R   ] net-misc/bridge-utils-1.4  0 kB
[ebuild   R   ] sys-apps/usbutils-0.73  USE="zlib -network-cron" 0 kB
[ebuild   R   ] app-emulation/kvm-79  USE="alsa esd gnutls modules ncurses sdl -havekernel -pulseaudio -test -vde" 0 kB

Looks ok to me.  Does it look ok to you?  Let’s go:

emerge -pvt kvm usbutils bridge-utils usermode-utilities

5. Setup access for non-root users:

For each non-root user, add them to the KVM group:

gpasswd -a <non-root-userid> kvm

Launching Guest for First Time and Installing Windows:

First, you need to create an “image” file, which will contain the entire Windows XP guest OS (think C:\ drive).  Here’s the default way:

kvm-img create winxp_raw.img 30G

This will create a RAW image format that is 30 GB in size.  This is the simplest and most portable image format.  However, it is not the coolest!

kvm-img create -f qcow2 winxp.img 30G

This does the same thing, but it uses the latest QEMU format, which enables additional features, like image overlays.

Second, if you use ALSA for your host’s sound, then you can enable it like so:

export QEMU_AUDIO_DRV=alsa

Third, install Windows XP into image.  Here’s the simplest method:

kvm -hda winxp.img -cdrom /dev/cdrom1 -boot d

This will do the same thing but it will use a local image of the install ISO (faster?), use 1GB of RAM (default is much less), use host’s local clock (helps Windows see the right time), emulate better VGA card (more colors and resolution), and allow access to 2 processors:

kvm -hda winxp.img -cdrom /winxp/ISO/WINXPSP2.ISO -m 1024 -localtime -vga std -smp 2 -boot d

Using The Virtualized Guest Windows XP

The emulated “box” will reboot once as part of the Windows XP installation process.  After it comes back up, you should be good to go!  You can now download programs, install programs, update the install, etc., just like you would with a regular Windows XP installation.  Of course, there will be some limitations, because the emulated hardware is not exactly feature-rich.

At some point, you will “shut down” the emulated Windows XP machine.  To restart it, use the a similar command – with the exception of not booting from the install disk (or ISO):

kvm -hda winxp.img -cdrom /dev/cdrom1 -m 1024 -localtime -vga std -smp 2

Accessing Host Drives

To access a local partition, first ensure that samba is installed – not running – just installed.

Then, simply add the path to the mounted partition, like so:

kvm -hda winxp.img -cdrom /dev/cdrom1 -m 1024 -localtime -vga std -smb /path/to/dir

Otherwise, you can add the share name, if you have samba already running and properly configured, like so:

kvm -hda winxp.img -cdrom /dev/cdrom1 -m 1024 -localtime -vga std -smb <share_name>

Inside the Windows guest OS, the mounted share is available at:


Also, from inside the guest OS, you can SSH, SCP, SFTP, FTP, or telnet to the host, depending on running host services, using this IP:

Other options are listed on the Arch Linux Wiki.

Using Overlays

I have found that this process is not entirely stable.  Some combinations of host hardware, host OS, emulated hardware, and guest OS, work better than others.  If I tried to emulate too much hardware, the Windows XP installation would crash, so I typically had to install using the most modest, simplest emulation.

Also, I found that this process could be slow during “boot-up” and “installation”.  Maybe disabling ACPI emulation would help?

Anyway, you can quickly make a wrong turn and wreck your “virtual machine”, basically ruining your created image, in which you spent so much time setting up and installing.  Fortunately, there are 2 techniques to help mitigate this annoyance.

One, with the emulator shut-down, simply copy the image file to another location or file name to back it up, like so:

cp -fp winxp.img winxp_orig_install.img

Then you can always copy the good install back over a broken install, like so:

cp -fp winxp_orig_install.img winxp.img

Ta-Da!  Of course, the downside of this approach is rampant disk-usage.  You need double the disk space, possibly more, depending on how many backups you make.

Another technique is using “overlays”.  You can create an “overlay” of a good image like so:

kvm-img create -b winxp.img -f qcow2 winxp_20081225.ovl

Then you can boot from the overlay, just like you would any other image, like so:

kvm -hda winxp.ovl -cdrom /dev/cdrom1 -m 1024 -localtime -vga std -smp 2

The overlay contains a “diff” of the new state and the original image, so it is much smaller, since it only contains what changed. If the overlay gets corrupted, you can simply delete the overlay, create another, and go again!

You can also stack overlays, but I think this can waste diskspace too, and it requires that you keep the whole “stack” in place.  Pull out one overlay in the stack, or just move it, and the whole thing tumbles down!  🙁

Based on a tip from Bryan Murdock’s blog for resizing image files, you can combine an overlay stack into a new, single, independent image file, like so:

# create a new image file, which will be the consolidated image
kvm-img create -f qcow2 winxp_new.img 30G

Download the latest clone-zilla LIve-CD (or DVD) ISO.


In a KVM session, boot from the downloaded ISO, and include your original overlay as HDA and your new image as HDB, like so:

kvm -cdrom clonezilla-live-1.2.1-17.iso -hda winxp.ovl -hdb winxp_new.img -m 1024 -vga std -boot d

Generally, you should accept the defaults, unless you know what you are doing, and of course, you do. 😉  The key is to choose the option for a “device-device disk/partition to disk/partition” clone, or something to that effect.  (I don’t remember the exact wording.)  Make sure you copy the complete contents, including the MBR.  Your source is HDA, and your target is HDB.  … The cloning takes a while.  After it finishes, be sure to halt, and then start up a new KVM session, using the new image file:

kvm -hda winxp_new.img -cdrom /dev/cdrom1 -m 1024 -localtime -vga std

Try hiding the original image and overlay files to see if it works.  It should!

Other Things

The default network setup is good for surfing the web, downloading stuff, and checking email.  However, if you want other devices on your LAN to “see” the guest OS as another machine, you will have to create a bridge and tap.  This gets a little more complicated.  See the references below for more details.

If the installation or something crashes, try restarting the machine – but, don’t boot from the installation disk.  Many times the install process completed “good enough” before crashing.  😮  Yeah, I know.  It smells funny to me too, but it works.  🙄  Just be sure to keep lots of backup copies of your images or overlays.


  1. http://en.gentoo-wiki.com/wiki/KVM
  2. http://kvm.qumranet.com/kvmwiki/HOWTO1
  3. https://help.ubuntu.com/community/WindowsXPUnderQemuHowTo
  4. https://help.ubuntu.com/community/KVM
  5. http://bryan-murdock.blogspot.com/2007/12/resize-qemukvm-windows-disk-image.html
  6. http://www.linuxjournal.com/video/run-your-windows-partition-without-rebooting
Nov 102008

The Problem

Occasionally, I find a text file that was written on a Windows box that contains additional garbage text.  Most often the text displayed, looks like this:

 * @(#)MyApplication.java  2.0  01 April 2005^M
 * Copyright (c) 2003-2005 Werner Randelshofer^M
 * Staldenmattweg 2, Immensee, CH-6405, Switzerland.^M
 * This software is in the public domain.^M

Or, even worse, as a single line, like this:

/*^M * @(#)MyApplication.java  2.0  01 April 2005^M *^M * Copyright (c) 2003-2005 Werner Randelshofer^M * Staldenmattweg 2, Immensee, CH-6405, Switzerland.^M * This software is in the public domain.^M */^M^M

Either way, this is annoying, if not unusable.

Brief Explanation

The primary cause of the problem is a difference of encoding ‘newline’ between the Unix and DOS (Windows) conventions.  The difference is long-standing, dating back to the days when printers were the primary ‘display’.

The Windows’ convention uses two ASCII characters, which signal ‘line-feed’ (which meant to roll the printer paper up one line) and ‘carriage-return’ (which meant to send the printer head back to the beginning of the line).  Unix selected one of those characters (‘carriage-return’) to do the same thing.

These symbols usually appear as:




Depending on the encoding, platform, and application.

The Solution Using Emacs

On most Unix platforms, commands such as unix2dos and dos2unix can be used to convert a text file from Windows to UNIX format or vice-versa.  However, sometimes a file can get so garbled that even these tools do not work.  Regardless, it is nice to know-how to fix this in Emacs.

The easiest way to fix the second case in Emacs is:

  1. Place the cursor on the first part of the strange character, the caret (^).
  2. Press C-‘ ‘ (Control + Space) to begin marking.
  3. Move to the right one character.  (You’ll notice that it jumps an extra character.  That is because ^M is really one ASCII character.)
  4. Press C-W to remove the text.
  5. Immediately, press C-Y to yank the text back.
  6. Jump to the top of the document (Esc-< or M-<).
  7. Replace all occurrences:
    1. M-x replace-string
    2. Press C-Y to paste in the text to be replaced.
    3. Press C-Q, C-J to replace with a ‘quoted’ ^J, which is the Unix newline (or, C-Q, C-M, C-Q, C-J for Windows).
    4. Press ‘Enter’ to replace all occurrences.

A little experimentation will be necessary to adapt to other cases.  You can read more here:


Oct 302008

HOWTO Connect a Linux computer to an HP PhotoSmart C7280 Printer

The HP PhotoSmart C7280 All-In-One printer contains a photo printer, scanner, and fax machine.  It can be setup as a wired Ethernet print server, wireless 802.11g print server, or a local USB printer.  It is very nice, and if you watch the NewEgg specials, you can often find one for a very good price every so often.  I have enjoyed using it from my Windows workstation; however, since I have the C7280 connected to my network through its Ethernet port (a wired print server), I would like to be able to use my Linux laptop to also print to it.

Fortunately, most HP printers are well supported in Linux.  So, I had high hopes!

As mentioned in other posts, my current favorite distribution of Linux is Gentoo, so my directions will be for Gentoo; however, you can probably adapt them to your favorite distro.


CUPS is the modern Unix/Linux printing interface.  It provides both a server and client for the common printing tasks (lpr, lpq, lpstat, etc.).  Therefore, CUPS must be installed before you can do anything else.

I added a few extra USE flags to my CUPS install, although I don’t think these are necessary in general:

$ echo 'net-print/cups dbus ppds' >> /etc/portage/package.use

Beyond that, installation is simple:

$ emerge cups

Since we are connecting to the C7280 via the network, no configuration changes are required for CUPS.  However, you will have to fire up the CUPS daemon and add it to your start-up services:

$ /etc/init.d/cupsd start
$ rc-update add cupsd default

You can find more info on configuring CUPS to work on Gentoo with other setups here:



The HP printer drivers are based on a standard HPLIP package, which is used with all modern HP printers, and a PPD file, which is specific to your printer model.  The latest HPLIP package can be installed in Gentoo, like so:

# For AMD64, Intel Core2, and newer x86 64-bit archs
$ echo 'net-print/hplip ~amd64' >>/etc/portage/package.keywords
# Install HPLIP
$ emerge hplip

The latest PPD file for the C7280 should be downloaded from the Linux Printing repository.  Currently, the C7200 model covers the C7280, and it’s PPD can be downloaded from here:


On a Gentoo box, the PPD file should be saved in a certain location, and only root should have access to it:

mv <path_to_download>/HP-PhotoSmart_C7200-hpijs.ppd /usr/share/ppd/HP/
chown root:root /usr/share/ppd/HP/HP-PhotoSmart_C7200-hpijs.ppd

With that put in place, you are now ready to configure the HPLIP program, like so:

$ hp-setup

The wizard should make everything self-explanatory, except you may have to manually search for the PPD file, if the wizard cannot find it for you.  When I used the wizard, it was able to find the printer automatically and very quickly.  However, I had to locate the PPD file for it.

If everything goes smoothly, you will be done.  All that remains is to restart cups, like so:

$ /etc/init.d/cupsd restart

If things don’t go smoothly, you may have to add the printer manually through the CUPS interface or to the printers.conf file, as I had to do.

Manually Adding the C7280 to CUPS

Unfortunately, the HPLIP setup wizard was not working correctly, and I had to manually add the printer to CUPS.  I used the web interface to CUPS, which can be accessed using a web-browser on the Linux box at:


From here, I clicked on “Add Printer”, and manually entered the necessary information.  (You should know the IP address of the C7280 printer on your network.)  Most of it was obvious, except these two bits:  The device connection type was:

AppSocket/HP JetDirect

And, the “Device URI” was:


Of course, you will have to change the above IP address to match your needs.  … If you have already configured a Windows box to use the same printer, you can get some clues for the above info in the Windows’ printer’s properties.

The CUPS wizard may request a user id and password.  Any requested userid is referring to root and root’s login password.  These are needed near the end of the CUPS wizard, so it can edit the CUPS configuration files for you.

After entering the necessary info, pointing to the downloaded PPD file, and completing the web install, I was printing my first test page in no time!

If you prefer to work on the command line, and you are comfortable with CUPS, here are the modifications to my CUPS’ files:


# Printer configuration file for CUPS v1.3.8
# Written by cupsd on 2008-10-30 17:37
<DefaultPrinter HP-PhotoSmart-C7280>
Info HP PhotoSmart C7280
Location My Office
DeviceURI socket://
State Idle
StateTime 1225405864
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy stop-printer

That’s it!

And, for good measure, you should always restart CUPS after monkeying around with its files:

$ /etc/init.d/cupsd restart


Well, it took a little longer than I first hoped, but it was not so bad.  Now, I can print, scan, and fax from HP PhotoSmart C7280 using my Gentoo Linux laptop. 🙂

Oct 212008


“Perl” can mean different things to different people, but based on this unique spelling, it can only mean one thing:

Practical Extraction and Report Language

It is Larry Wall’s scripting language, primarily developed for UNIX based operating systems.  However, ActiveState maintains a Windows port, which I use on a regular basis:


Perl was originally designed to be a superset, an amalgamation of Larry’s favorite scripting languages.  Consequently, it is an extremely rich language, because it borrows from so many.  It is also designed to enable compact code.  Consequently, it can be difficult to master and read (reverse-engineer).  However, for the patient and determined, Perl provides a treasure trove of programming power.

Common Usages

Perl is primarily used for complex text processing.  Although awk has been the traditional, simple text processor, Perl can compete well with awk.  The primary deciding factor is, as always, your personal knowledge and proficiency in each language.

Perl is also used as a programming language for many dynamic web sites.  It has been a favorite language for CGI scripts used in form processing and producing dynamic web-content.  Recently, PHP has been overtaking Perl’s popularity on this scene, and even more recently, Ruby has been overtaking both, especially when considered with the “Ruby on Rails” extension.  However, it seems like a new language appears on this front almost every day.

Although it cannot match the flexibility or speed of C or C++, Perl can be used as a complete language for very complex projects.  It provides object-oriented support.  And, it has a large developer community, providing hundreds of varied and tested third-party modules.  Exploring and utilizing these modules are key to unlocking the latent potential of Perl.  Many modules are stored and documented on CPAN:


For example, these modules allow you to edit MP3 tags, parse or write XML files, generate PNG image files, etc.  They handle many of the low-level details, which would require a large amount of time to reproduce.  Why reinvent the wheel, especially if you can download a free set with racing stripes and turbo pre-installed?

Why Perl?

Is Perl perfect?  No way!  But, it offers a tremendous amount of immediate power on multiple platforms (UNIX, Linux, Windows, etc.).  It is much easier to develop simple programs in Perl than C, C++, JAVA, or other more “powerful” languages.  Admittedly, Perl has its quirks.  But, unless you are a C.S. or C.S.E. student with copious amounts of free time and interest, it is difficult to keep up with the latest scripting language craze, which may or may not be more powerful than the language you already know.  At some point, mastery in one language becomes more powerful than mere acquaintance with several.  So, here in the real world, I have thrown my lot in with Perl, although I hope to someday learn more about Python or PHP, while I use C for “real” work.

One of Perl’s idiosynchrocies is that it tries to help you by doing several things automatically for you “behind the scenes”.  Given this fact, its diverse blending of languages, and its compact notation, Perl has an inevitable steep learning curve and a rapid “decay rate”.  You have to use Perl regularly and routinely to learn, master, and maintain a working knowledge of Perl.  Unfortunately, I don’t use Perl that regularly in my day job, so one of the categories on this web-site will contain my notes on tips and tricks in Perl.  Hopefully, my own knowledge of Perl won’t atrophy so rapidly, and I will be able to find details on accomplishing infrequent, but necessary tasks without having to search through mountains of old scripts and code.  Who knows?  Maybe you will find something helpful here too!