Further X-periments on Qemu

After installing Qemu and ghci, I needed to run "gobby" to access some mutually edited files. But that needed X. So I could not avoid X altogether. Here is what I did to install X.

First start up Qemu using

$ qemu debinst.qcow

where debinst.qcow is the qemu hard disk which we installed in the previous blog. Log in as root. Now we are ready to do the actual installation.

Do the customary

# apt-get update
# apt-get upgrade

as root. Though it is not strictly necessary as the following will upgrade whatever it needs automatically.

Now we start the main installation. First we need X.

# apt-get install xorg

This will take some time as it will retrieve something around 40MB of data and then install it. Next one needs a window manager to use the X. I wanted something light and hence went for xfce. I might have used fvwm or something like that. But I used fvwm and blackbox and icewm for quite sometime and wanted to try something new. So I did

# apt-get install xfce4

This will download around 25 MB of data. The installing of fonts might take some time. Now after it is done, comes the scary part of testing it. So keep your fingers crossed and switch over to the full-screen mode by

pressing Ctrl-Alt-f

while the qemu window is in focus. This will grab the whole screen for qemu. Now run

# startxfce4

That should start xfce. I had done a few more installations. I needed the X for gobby. So I had installed gobby. I needed a web browser. w3m was already installed, but I wanted something more graphical. I tried links2. That seems to be reasonable. It can at least handle gmail and the webmail of my institute.

Some experiments with Qemu

For the last two days I have been playing around with Qemu a bit. The system administrator had installed qemu in my office desktop. As an experiment I tried to install a minimal debian system on it. I downloaded the debian net-installation CD image just because it was the smallest and good for experimenting. With qemu installed and with the iso image of the CD on the hard disk I started the installation step by step.

First the virtual computer should have some virtual hard disk space. Qemu provides a tool to do that. I used the command

$ qemu-img create -f qcow debinst.qcow 5000000

Yes the "create" command creates the hard disk. The switch "-f" specifies the format. I used the native qcow format for the disk as I read that it is the best and it takes less amount of space on your "actual harddisk". So a 5GB virtual harddisk after installating debian took a little less than 1GB of actual harddisk space.

Note I saved my cdrom image (debian.iso) one level below the directory where I am presently in. So for the installation I ran the command

$ qemu -hda debinst.qcow -cdrom ../debian.iso -boot d

So it says qemu to take debinst.qcow as the harddisk for the virtual computer and ../debian.iso as the content of the CD in the cdrom drive. -boot d tells it to boot from the cdrom.

The debian installer kicked in and the installation was smooth. For my experiment I used the guided partitioning with just two partitions; one for the root and one for home. I did not install any extra packages other than the standard ones initially. I actually don't need a graphical interface, so I did not bother to install any desktop environment either. My installation only has the console interface and I am happy with it.

Later on I had installed build-essential just for my programming interests.

Then I wanted to use this installation from my slow dial-up connection from home. (You must be wondering why... Well I don't know... My answer would be just for fun!!!) The problem was it was too slow to forward X over ssh and use qemu. Specially since I am only using the console it does not make sense to forward X, I found out that qemu has the -nographic option. But somehow it was doing nothing if I tried to run

$ qemu -nographic debinst.qcow

Later on I found that

$ qemu -nographic -curses debinst.qcow

did exactly what I wanted. Now I can run qemu from the linux console without having to use X at all.

Linux and Alcohol

It was a surprise to me to find so many linux commands having names of alcoholic drinks. I list the three I discovered. Let me know if there is something else!

• Wine : This is actually a well known application used to run windows applications in Linux.
• Brandy : This turns out to be a basic interpreter.
• Beer: This is a security package as far as I understood. Well beer and security??!!!

I have a feeling that the list is incomplete, but I could not find any other either.

Hash Tables

Couple of days back, I got into a discussion about hash tables with one of my friends. Initially we were confused about what good it is over an array. Before explaining the confusion, I'll describe an example. (You know I strongly believe what my sixth standard teacher told me once: "Eg makes it easy.")

Suppose we want to store a table containing roll numbers and names of students:
(1, Pundarikakshya Purakayastha)
(2, Prasenjit Sarvadhikari)
(... well I think it is better to shorten the names ...)
(3, Arun)
(4, Varun)
(5, Darth Vader)

Okay we can continue with this. Well we can store this data in an array containing five elements and store the ith entry in a[i-1]. That would be good enough. We were confused what is the point of defining something like a hash table. Well we realised the point is we don't construct hash tables for such data. To give a real example, hash tables are used to handle data like path names of Linux executables indexed by the command names, like (just as an example)
(ls, /bin/ls)
(rm, /bin/rm)
(shutdown, /sbin/shutdown)
(vi, /usr/bin/vi)
(acroread, /usr/local/bin/acroread)
... and so on

Suppose there are 1355 commands and if we put the whole data in a 2 x 1355 array, it might be a time consuming job to find the path for a command you want. First you have to find the position of the command in the array and then check the corresponding path. If the command lies towards the end of the array, it will take some time to find it out.

So the way a hash table solves the problem is that it uses a hash function to convert the command name into a number and then store the path in a one dimensional array at the corresponding place. Like if, for example, for a suitable hash function, "ls" converts to 6, the computer sets a[5] = "/bin/ls". And so on. So when the computer has to retrieve the path for ls, it calculates the value of the hash function at "ls" and gets 6 as it's value and then gets the path at a[5] to be "/bin/ls". That works much faster than searching an array for "ls".

Now, as usual, life is not all that fair and it's very hard to construct hash functions which are "good" in the sense that they do not give the same number for two different commands and at the same time the numbers it produces are not too huge compared to the total number of commands. Well if one is interested how one solves those problems, one can read the article on Hash Tables in Wikipedia or some advanced book on algorithms.