Pankaj Kumar's Weblog

It was an educational experience to play with my latest purchase, a Compaq EVO N1015V. The machine worked fine with its pre-installed Windows XP Professional. However, I have no intention of getting hooked to yet another MS upgrade.

My troubles started when I decided to install RedHat Linux 8.0 on this. Initial few steps went fine but then the CD drive stopped responding. This happened a couple of times. A seach on the web came up with this writeup explianing troubles in installing linux on evo N1015v. I, for one, am not a real Linux guru and hence, decided to limit my experimentation to only latest available RedHat Linux, RH Linix 9.0. Downloaded RH Linux 9.0, burnt the CD and put in in the CD-drive. No luck. I got the same behavior -- the CD drive would become unresponsive after initial few steps.

This happened around 6 weeks ago. Today, as I write this entry, I came across this brief guide by Robert Toole that describes step-by-step process to install RH Linux 9.0 on a evo N1015v. Good to know that I am not the only one facing this problem. However, execution of these steps is certainly beyond my time budget for installing a bare-bones OS. May be some day later I will try these steps.

Yesterday night I decided to turn my laptop into a Windows 2000 machine. But even this turned out to be challenging. Initial install will allow the display to be only 16 color and the screen resolution to be 480 by 640 and with no sound capability. A search on the Web turned up this page with all the info. I needed about the Windows 2000 drivers. The rest turned out to be a fairly smooth operation.
Well, all this may not be much for a pro, but as greehorn, I found the experience educational.

BTW, I have nothing against evo N1015v itself. It is a fine piece of hardware and a very good value for money, at least for me -- I paid only $629.0 for a refurbished piece (discounted for HP employees) plus another 31.50 for Shipping and Handling and 54.51 on taxes. Even with all this, the total is just around $716. And I got 1.4MHz AMD Athlon processor, 30GB of hard disk, 256 MB of RAM, CD drive, 14 inches TFT, inbuilt 10/100 NIC, 56 Kbps modem and Windows XP Professional. Can't really complain.

Lately, there has been signficant chatter about ability of certain companies to operate massively distributed systems built with low-priced h/w and s/w and how this gives them competitive advantage against those who rely on high end computing systems. Traditionally, for most IT shops, the system management cost has been a major determinant when it came to deciding for a small no. of high-end systems versus a large no. of low-end systems, mostly resulting into a decision in favor of a small no. of high-end systems. However, as the linked story points out, companies like Google, Akamai, eBay, Amazon and Yahoo! are bucking the trend by developing their own management infrastructure.

Given that these companies may not want to market their management infrastructure for obvious reasons (a no. of readers didn find the reasons to be so obvious, so I will list them here: (a) they are not in the business of system management; (b) most of them would have used GPLed code which would make it difficult to sell packaged products; (c) they would want to keep their expertise as competitive advantage) and traditional management vendors may be too busy serving their existing markets, it appears to me that the field is rife for a fresh batch of startups that would promise off-the-shelf management s/w for such massively distributed systems built using low-cost machines.

With lots of trial and error and some googling, I finally managed to get CygWin/X running on my Windows box work with my Fedora Core2 Linux system. The steps are actually quite simple:

1. start the X in multiwindow mode from cygwin's bash prompt:

$ X -multiwindow &

This would run the X server in the background, showing an X icon in the Windows system tray (also known as notification area). The root X window is hidden.

2. launch xterm on the local machine:

$ xterm -display localhost:0 &

This opens an x window on the local machine.

3. From this X window, ssh into the remote Linux system:

$ ssh -X -l <user> <linux-host>

Now, any program with GUI run from this window on the remote system will open a window on the local machine. Simple, isn't it!

So, why did it take me signficant amount of trial and error and googling?

Perhpas I was misled by the ease with which CygWin/X works with an HPUX system:

$X -query <hpux-host>

This doesn't work for Linux. The explanation I found is that the above command requires xdm daemon to be running on the target host, which is disabled by default on most Linux systems (for security reasons). Apparently, the steps to enable and run xdm are not very straightforward and I gave up after a couple of false starts.

Other route I tried was to run X server on the local machine, then ssh into the remote Linux machine from a Windows command window, set the DISPLAY env. variable and then run an X program from the ssh session. This used to show the following error on the remote Linux machine:

Xlib: connection to "<local-host>:0.0" refused by server
Xlib: No protocol specified

xterm Xt error: Can't open display: <local-host>:0

And the following message on the local machine:

AUDIT: Wed Sep 22 23:52:18 2004: 2040 X: client 1 rejected from IP 192.168.1.103

These messages had me baffled for quite a while! But now that I know how to make things work, even these error messages make sense.

I had been toying with the idea of attaching a NAS device to my home network for quite some time, but the steep price of over USD 300.00 has been a dampener. At these prices, they start competing with my other wish, and my enthusiasm usually goes down (Though the prices have been on downward spiral lately, and it has become possible to acquire a decent box for less than $200)

I was getting the following error while installing rubygems-0.8.11 on my Fedora Core 4 Linux box.

rubygems/custom_require.rb:21:in `require__': no such file

A google search indicated that I was not the only one facing this problem. Though I couldn't find a fix following the various search results.

Suspecting the problem to be with the particular version of rubygems, I tried an earlier version, rubygems-0.8.10. But no luck. Even this install produced the same error.

I resolved the problem by uninstalling the rpm ("yum remove ruby"), getting the ruby-1.8.3 source tarball and installing it the old fashioned way. ie;

ruby-1.8.3> ./configure

ruby-1.8.3> make

ruby-1.8.3> make test

ruby-1.8.3> sudo make install

Few days ago I figured out a simple, inexpensive and elegant solution to my backup needs and am thinking this may be of interest to others as well. Though keep in mind that this solution is somewhat specific to my setup and your mileage may vary.

I use a compaq nc4000 laptop running Windows XP as the main system and have a number of other machines running either WIndows or Linux. The main Windows XP system also includes Cygwin, a collection of GNU tools such as ssh, svn, cvs, tar, wget etc. Use of ssh keys allows ssh sessions to the Linux system without the need to enter a password. All my data files, including Outlook PST files, are under a single directory in C drive.

Copying a directory tree from Windows XP system to a Linux host machine is fairly straight-forward with rsync (available within Cygwin):

rsync -avz <datadir> <user>@<host>:backup

Turning this simple command into a daily backup is fairly straight forward: create a command file backup.cmd with following text (or adapt to your setup):

c:
cd \
rsync -avz <datadir> <user>@<host>:backup >> backup.log

That is all you need to do. Just look at c:\backup.log once in a while to make sure that the new or modified files are indeed being transfered.

No backup process is complete without the restore capability. So, here is the restore equivalent:

rsync -avz  <user>@<host>:backup/<datadir> .

Humor me with this simple task -- arrange the following list of strings in lexigraphically ascending order:

a.b
aab
aaa

Keep in mind that the ASCII value of '.' is 46, which is less than 97, the ASCII value of 'a'. Note down your arranged list. Now, create a text file list.txt with the above strings in separate lines and sort them on a Linux system using the sort utility with the following command:

$ sort list.txt

Did you get what you were expecting? I didn't. Here is what I was expecting and what I got under three different Linux systems (Fedora Core, Mandrake and Ubuntu):

Expected           sort output
=======           ========
a.b                   aaa
aaa                   aab
aab                   a.b

What is going on here? Looks like sort is simply ignoring the '.' character. It shouldn't, at least not as per the sort man page. There is this option '-d' to ignore all characters except letters, digits and blanks, and hence '.', but this is not a default option.

Just to confirm that I didn't make a mistake in my manual sort to arrive at the expected list, I sorted the strings within PHP command line shell:

php > $a = array("a.b", "aab", "aaa");
php > sort($a);
php > print_r($a);
Array
(
    [0] => a.b
    [1] => aaa
    [2] => aab
)

This output is same as what I expected. So, no mistake on my part!

And this led me to the question: is GNU Sort broken? or did I miss something. After shifting through sort man pages at different machines, noticed this warning on a Fedora Core 6 box:

*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.

So, this is what I was missing! Btw, this is not something obvious that I just didn't pay attention to. Rechecking the online man page, something that I tend to use more often than the man output on a 20x80 terminal screen, confirmed that the warning wasn't there. Also, none of the machines I had tried, all installed for US locale, had LC_ALL set to C by default. And keep in mind that I came across the above discrepancy in sort output only after my program finding the difference of two sorted files failed on certain specific input values. Like most normal folks, I suspected my program first and it took a while to suspect the sort output as the culprit.

Sorry for the provocative title -- I found out about LC_ALL environment variable only while writing this blog post and double checking my facts (one of the few advantages of writing things down) and didn't feel like changing the title. After all, how many of us will think of setting LC_ALL=C before issuing sort! In that sense, Gnu sort IS broken.