The Rationale of Linux.

After my amateurish attempts at trying to get a "enjoyable" Linux installation working, I have begun to question the reasons for trying to do so.
As a single PC owner, it makes little sense to try to tackle the issue of shoe horning Linux with the hardware. The problems with driver installation, and Wine installation (for gaming, since games are an important use any PC will be put to) are simply too challenging for most people. The plethora of live distros seem to be a solution, since a user has the option to go about trying out different live distros to see if the drivers are all proper and the Wine installation is error free. But even then the downloaded content remains incompatible amongst distros so a lot of downloading is needed. For those not on a broadband connection, this eclecticism is not an option. In my case, PCLinux offered the best compatibility with hardware, and also the right amount of "administrative freedom", but I have not been able to install a single application without the application manager crashing with a "rpm database not available" error. In those distros where I could get Wine installed, the GUIs to most of the routine tasks were missing.
The cheapest Windows option that can address these issues will cost me about Rs. 4000 (Windows XP Home OEM). The added benefit of doing Windows is also that any custom hardware can also be used without much heartache, like plugging in a webcam.

But, seen from the perspective of a person who is incharge of many systems that are to be used in an official (aka no fun during working hours) environment, Linux is a god send. Here, since the driver issues need to be addressed, it helps if all the systems are homogeneous. Testing out a few live distros hopefully will offer the most compatible option, and that just needs to be replicated on all systems. The cost saving is substantial, since at Rs. 4000 per PC, in a place that has 10 PCs, the cost savings just multiply. The added benefit is the inablitity to load up the PC with irrelevant programs. Since it is common to find many office PCs loaded with games and other software which can bog down the system, Linux's inability to handle such programs is a boon. Manhours spent in unproductive entertainment via games are reduced, which is also a saving in disguise.

Transmission

FC8 opened the Transmission gates for me. Transmission is an extremely lightweight torrent client that is quite deep. Compared to the overhead of Azureus and the clunkiness of Ktorrent, Transmission is a featherweight torrent handler. It has most of the required options available with a host of statistics on display. Very intuitive to use as well.

After yuck, Transmission is a face saver for FC. I dare say some of the torrents that seem to get stuck in Azureus found a fresh lease of life in T. Though this could be all the positive energy talking.

Update:
Tansmission has a nasty habit of amnesia. On restarting the app, it forgets the download locations of the torrents not saved to the default download location. This is rather strange.

Application Management in FC8 - yuck

They say that application management in FC is handled by yum - type it in the console to launch the routine.
But, I launched it the GUI way. For newbies, the routine is a bit puzzling. Handling a simple uninstallation routine for example cannot go on without having net access. Only after a net access is not found is the option to select repositories offered.

Since I was looking for Wine, and this package was not offered even in the DVD (which is a shame) I had enabled the two online repositories already selected - fedora and fedora updates. The routine started accessing the online repositories, which I presumed was for getting the program lists. But half an hour of "retrieving software information" and over 150 MB of downloaded content later, the program was still downloading stuff. I lost my patience and killed the application.
Ofcourse I could not launch it again since a message that some other routine is already accessing it came up preventing it use.
A restart later, I launched the app. Again without a net connection I was able to get to the repository list. Here I disabled all options, including the installation media. Now I could get the application list that I was familiar with after seeing it in other distros. Then I enabled just one online repository. This time the downloading was brief, and a few MBs and seconds later, I could search for the Wine package. Unlike a few other application managers I have met, this one does not mention download sizes at all. There is no way one can find size information of existing programs, so how much space will be freed on uninstalling it also cannot be found.

I managed to install wine, which proceeded, thankfully, uneventfully.

Update :
The experience with yuck repeated itself, so I am sure that it is not a one off incident. On installing FC8 on a second PC, and running the application manager, here too the initial attempt seems to take too long "retreiving/reading application list". On cancelling the attempt, and restarting it, things were much faster. Wine installed well here too.

SIOCSIFFLAGS

Ofcourse it is not supposed to make sense, if it did it would not be a linux distro that we would be dealing with! If you can accomodate Dolphin, synaptic, atun then why not SIOCSIFFLAGS.

It is an error, that crops up when trying to boot FC8 on the Geforce 7025 motherboard. And since it is immediately preceeded by "eth0" I can safely conclude that it is the Realtek Gigabit LAN that is causing it. Unlike the other distros that managed to boot up well enough, FC8 stumbled even there.

The reason I returned to FC8 was because I got the DVD, without having to download it. Since Wine is a must have, and PC linux is having problems with it, I was hoping that FC8 with its popularity would offer fewer challenges. Things are not looking sunny after this.

The solution could lie in disabling the ETH interface from being started at boot time. To prevent this changes needed to be made in the /etc/sysconfig/network-scripts/ifgcfg-eth0 file.

Compiling the Kernel

It is one of the rites of passage. I have no clue why I bothered, but it was something that I wanted to do. Theoretically, having a custom compiled kernel ensures maximal compatibility with the hardware, this step is also necessitated if any new hardware is being used whose drivers are not supported innately by the kernel.
So I downloaded the latest kernel from the kernel.org site. First I ended with a 9 MB bz2 compressed file, and I was taken aback by the size. I was expecting a larger file to be the center of a revolutionary movement. After getting the instruction on compiling the kernel from different sources I got down to doing it.
Before compiling, one needs the tools which are mostly not available in the Live CD distro in most cases. The tools needed are gcc and make. For some reason, probably during my earlier attempt to get the driver for the Realtek Gigabit LAn, I already had the files installed, which was revealed by looking at the application management window.
The first command to put in is make menuconfig. This is supposed to offer the user a list of parameters that can be altered before the compiling can begin. In my case this returned an error that the directions were missing. Further looking around revealed the presence of two types of souce files, the entire source and the patch source. A patch source merely contains the differences between the two kernels and hence is of a smaller size. The actual latest kernel weighed in at over 50 MB.
With the package extracted, on running the make menuconfig command the expected menu popped up. In it there were many options that could be enabled or disabled. Since I was using AMD Athlon and nVidia chipset, I disabled all entries that related to Intel CPUs and other chipset manufacturers. I played around with other options as well - irrelevant stuff like bluetooth and wireless support was also disabled.
The next step involved using the make modules command. And as I feared here I was presented with an error, which I did not bother investigating.

Clobbering Kubuntu

For some unknown reason I am unable to visit any blogspot.com address since a few days. Only today did I remember that I could post through blogger.com without having to visit blogspot.com.

In the meantime I downloaded Kubuntu 8.04 with the KDE4 windows manager. Besides a large dose of visual candy, Kubuntu remains incorrigible.
There still is no way to access any graphical interface to install-uninstall programs, change the desktop resolution, mount-unmount partitions selectively. I wonder what is the reasoning behind this continued aloofness.

KDE4 looks quite pleasing in the all black mode, and rounded edges. The problem is that on a 256 MB machine this is not a practical option. While using the Live CD, the slick GUI consumed so much resources that all the swapping that was necessitated as a result left the user waiting for things to happen. I wish every distro also offered the equivalent of the simple tool in Windows, where a single setting to set the installation for Performance would impact all GUI aspects.

While not adding anything to improve a user's experience, Kubuntu did change the startmenu. This addition is similar to the Opensuse 10.3 start menu with the menus opening up in the same menu. I found this feature user hostile then too. This ofcourse could be changed in OPensuse, and hopefully Kubuntu allows it too. I did not see a Firefox icon, with Konqueror being the sole browser. The File manager, Dolphin which I liked a lot in Kubuntu 7.04 is still here. The all important button that I missed was "Open as root". It is probably hidden elsewhere.

I did not spend as much time as I would have liked to. The sluggishness was getting on my nerves.

Eventhough it was the latest distro, hopefully having the latest kernel and all, it did not get the graphics settings right, and I was left with a 800X 600 desktop on the geforce 7025 motherboard. This was disappointing, indeed.

In conclusion, a CD has been wasted. This experience has prompted me to get a CD RW. I will not be installing it on a hard disk.

Who touched my fstab?

Confirming the whimsical nature of Linux, today morning I was unable to boot the system. Since it is not possible to scroll back through the error messages, I had to reboot a few times and use the scroll lock button to figure out what the problem was.
Apparently, the entry for / in fstab was missing! Without the root partition I was getting a long list of permission denied errors.
Thinking this may because of some data corruption, since it is difficult to imagine a particular line missing from a file overnight, I tried booting into the Opensuse installation that was also on the same drive. In Opensuse I got a "su" error, meaning that I was unable to login as root and use any of the tools limited to su, like fsck or accessing the disk partitioner to figure out how the partitions were labelled. As already mentioned in one of my posts, hda and sda are used depending on the distro used. Opensuse used sda while PC linux used hda to refer to the master primary hard disk. With OPensuse also acting dilinquent, I relied on a live cd to boot up.

I first did a fsck on the partition, and it did find some errors. Thinking this would solve the problem, I rebooted after the check. But the same errors were showing up. I also observed that even though the root partition was missing, the other partitions were being checked and tagged as clean.
Another live CD boot, and I investigated the fstab file in the relevant partition, and shockingly the entries for the root and swap partitions were missing. I am not sure how this happened. The last time I edited the fstab was probably two days back when I had mounted a few partitions and allowed the fstab to be updated. During that process, the root parition was not selected, since it was already mounted and did not need a mount point. Same with the case with the swap partition. I doubt if this could have overwritten the root and swap partition information in the fstab.

This remains a mystery. But, it confirms the claim that Linux is endowed with human qualities like eccentricity and impulsiveness.

PC Linux Migration problems

The shift from the Geforce 6100 motherboard to the Geforce 7025 motherboard had been hard on FC and PC linux. The other distros atleast managed to bring up the console. In PC Linux's case the failure was especially hard hitting since I had been using it regularly.
The problem was that the system would crash soon after the the boot option was selected. Using the safe boot mode and frame buffer mode did not improve matters. My belief that Linux manages hardware changes much better than Windows was belied after that experience. But what made matters even more annoying was that even the Live CD would not proceed too far. Stopping with an unprecedented "Unable to Mount Live CD" error. Considering that the same Live CD worked fine on the other motherboard, and that other Live Cds worked fine on this motherboard on the same DVD drive, the CD-motherboard interaction was suspect.
A google brought up the explanation and the solution. Apparently, PC Linux has problems in dealing with SATA drives and adding "linux all-generic-ide" to the existing boot parameters solves the problem. Eventhough the DVD drive and Hard disk that I was using were NOT SATA, I edited the boot menu and voila the earlier problems vanished.

X still had issues with the 7025 onboard graphics. For this I used the Xorg -configure command, which promptly left the system unresponsive. I tried editing the original xorg.conf file and reduced the colour depth, but that did not help. Since the driver and monitor were accurately identified, there was nothing else to edit. Then I loaded the live Cd and went through the contents of it's xorg.conf file, since the live Cd managed to load X with diminished resolution. On browsing the contents of the file, I found that the device was not identified as nvidia, rather as vesa. I simple copied this section from the live xorg file and pasted it on the original xorg file. The next reboot brought up the GUI.

I could change the resolution to the max of the monitor from within the OS. Since the nv drivers were not being used, there was a reduction in the visual aspects of the GUI, most notably the lack of Anti alaising which ensures smoother fonts and curves. But, that is a small price.

I had hoped that the change of luck would carry on to the Realtek driver as well, but this was not to be.

Update:

Well, well, well.
I have had a change of heart with regard to the apathy of component manufacturers towards linux. The Realtek LAn driver ordeal fresh in mind, I braced my self for another session of make, make install etc to get the display drivers for the geforce 7025. Without the correct drivers the fonts were all pricky and scrolling was a slideshow.
A google search revealed the presence of a nvidia self extracting, self installing package (http://www.nvidia.in/object/linux_display_amd64_100.14.11_in.html). I'll repeat the nature of the package, because it is probably a first in Linux - SELF EXTRACTING, SELF INSTALLING. The package with a .run extension weighed in at 15 MB. To run it the sh command is all that is needed.

Post download, I tried the sh command, but since I was using X, I was asked to run the package after exiting X. After exiting X, and logging in as root, I ran the command. The experience was too good to be true, except it was. The files were extracted and promptly the installation began. Somewhere midway during the installation, the routine came up with an error that a compatible precompiled kernel module was not found (probably referring to the PC Linux kernel which may not have been on the top of the developer's mind). IT offered an option to download the same from the Net which I permitted. A few seconds later, it returned with empty hands. Now get this : after the message that no compatible modules were found, it says "NO PROBLEM I SHALL CREATE ONE!!!!!!!!!!!". And so it proceeds to compile and create a kernel module. Then it tells me that the Xorg libraries were not found, and its paths are being guessed, and if the guesses were inaccurate another utility needs to be downloaded to rectify it. With that message, it goes ahead and tells me that the installation is complete.
startX and lo and behold.

The nvidia experience is not just an eye opener, it is a techtonic shift, it is a vision of paradise from the midst of pain and suffering, it is beyond words.

I shall not waste any more words riling Realtek and their asinine handling of drivers. In their support, though, compared to the might of Nvidia, they are paupers and probably incapable of allocating adequate funds to match the sheer elegance of nVidia's driver routine.

Driver Driven

Finding the solution to the Realtek driver issue became important, because I also discovered that the USB ports were not functional, which could also be related to the absence of proper drivers.

Googling for Realtek 8169 directly, I discovered that there were many who had faced the same problem - of the system inaccurately installing the wrong driver. The chipset was the 8168, but Linux used the 8169 driver automatically. Besides the readme instructions, I found anothe set of steps here http://www.linuxquestions.org/questions/showthread.php?p=3029998#post3029998. Following these also proved futile.

While in Opensuse, I managed to successfully complete the steps, in Mandriva 2008 I was stopped midway with a "invalid module format" error on using the insmod command.

Temporarily, I have given up the pursuit, and have resigned to opt the easier way out, that of using the discrete lan card. The USB will also have to wait.

What makes this entire ordeal unacceptable is that Belenix, an Opensolaris distro, seems to have no problems in this front (but it fails in other aspects). The reason : this issue is based right in the core, the Linux Kernel itself.

Make a tar#$%* Part 2

Installing drivers being central to the whole Linux experience, I took another jab at trying to figure out what the reams of text blurted out by the "make clean modules" command meant.

The first search on google revealed that to utilise make, one needs the kernel source code. To check if the kernel source is installed use the "rpm -q kernel-sources" command. I bet this can also be used for any application. The source was not included in the Opensuse installation I was on, and probably is not available in any live CD, for a reason that I found soon after.

I tried using the application manager to check for the availability of the source. Shock : the source is about 250 MB!

By the way, drivers are usually created specifically for each kernel version, and though the driver source size is comparatively insignificant (a few KBs), the command to find the kernel version is "uname -a". The application manager listed the source for the correct version. This need not always be the case, as I found out during my google forays.

250 MB is a strong motivation to look for other possibilities, but finding none, I prepared to download the source.A pleasant surprise awaited me, when I discovered that the actual download size was less than 50 MB. The 250 MB referred to the decompressed size, probably.

Post download and auto configuration, I reran the make clean modules command. This went past smoothly. The next command make install also did not throw up any problems. The depmod -a
and insmod ./src/r8168.ko commands also did not have any hiccups.

The readme file also provided some diagnostic commands to check if the driver had been installed, and these seemed to indicate that it was indeed the case.

I tried using the GUI to see if any changes had happened. Indeed the driver had changed from 8169 to 8168 which is the correct number of the chip.

But since the proof of the pudding is in the eating, I tried accessing the Net. Alas, this was not possible. Before going through all this, even with the automatically installed 8169 driver I was facing the same problem. A restart also did not help. So the attempt on the whole was not a success.

The sole consolation I could extract was that I had experienced my first compile and install session, and except for the initial hiccups, it went smoothly.

Now while the information to install a driver is readily available, how to accomplish uninstallation is not.

Linux losing cool

A recurring "feature" of Linux is the unpredictability associated with it. Every reboot presents a new, usually unwelcome, challenge. Presently I am unable to launch any KDE application because I get an error that the DCOP could not be contacted. This system worked fine till yesterday, today DCOP is AWOL. Without DCOP I cannot launch any KDE window - no menus, no file manager. The solution is a reboot. But, I am not sure doing so will not bring up another problem.

While many lacunae in every distro can be attributed to the improper selection of preinstalled packages, the kind of problems like DCOP is more intrinsic. Expecting a user to spend a large part of the working hours trying to get the system workable is wishful thinking.

Make a tar @#$*

Installing Drivers can be a major headache for newbies and GUI enthusiasts. In my case, since the achilles heel of most distros seemed to be improper drivers for the LAN card, I headed to the Realtek site. The drivers were there, but in the most unfreindly format - source code.
Source code needs to be compiled before it can be installed. And while this ensure maximum compatibility with the hardware, it also means relying on the console throughout the process.

I tried this in Mandriva and Opensuse, and in both cases stumbled in the second step of the installation process mentioned in the readme file that accompanies the driver.

The tar command can be used to open th gz/bz2 compressed packages. Or it is just much easier to use the usual GUI option to extract the archive. The result is the same.
After extraction, the source needs to be compiled, and the steps to do this is present in the readme that is available after extracting the archive.
"make clean modules" is the first command to be used, according to the readme. This promptly returns an error - make command not found. The make command will be available after installing the make package. So I loaded the application manager and did that. With make available, I reentered the command. This time the error related to the absence of a gcc file. Another visit to the application manager and the gcc packages was installed. Retrying the command not produces numerous errors, all relating to missing files.
gcc is just one of the many C language package available. There are other options titled gcc 3, gcc 4 etc which refer to the version of the package. With no advice on which version was needed, I did not venture to install any further package.

The solution or rather shunt, involved using a discrete lan card with a chip whose driver was already in the distro. So I extracted the Lan card from an older system, and was quickly online.

I needs to be mentioned that none of the distros indicate that lack of driver is the problem. All of them, during the configuration stage continue as normal, but accessing the net is impossible. Opensuse during the installation also identifies correctly the chip - realtek pcie gigabit - but still when trying to go online I get "no connection" errors. This is strange.
While an older LAN card solved the net access problem the fact that Realtek did not offer a precompiled or binary version of the driver is worth considering. This is undoubtedly one of the negative effects of the multiple distros, offering a single source file beats having to offer over a dozen binary versions since each distro has projected its own package manager. This approach is suicidal, for the Linux movemen, of course.

Probably the motherboard manufacturer has the relevant drivers on the site, which is where I should have gone first.

Disk Drake

There is only one partition tool that combines versatility with ease of use - Diskdrake, the partition tool seen in PC Linux. It can handle the most partition types, it allows the user to control the fstab entries, it allows easy mounting/unmounting of paritions. The only area where it lacks is that it doesn't make the distinction between primary and logiical drives.
Qtparted and Gparted which are the other partition tools seen more commonly in Linux distros pale in comparison. Unfortunately, these are the tools one is more likely to comeacross. While Gparted is comparatively better, it allows mounting and distinguished between logical and primary, it can only handle few partition types. Qtparted which is at the bottom of the pile also has the nasty habit of renumbering partitions, which can render an installation unbootable unless the boot menu is edited. Avoidable.

Self Saboteur, Belenix

The art of shooting oneself in the temple is something that Belenix teaches the world. It is simply unimaginable how a distro creator can be so oblivious of the lack of the essentials.
There are many obstacles that need to be overcome before someone keen to install Belenix can begin that actual process of the installation. Persistence and Determination, the two friends that one will need to taste success in life are critical for success with Belenix.
1. Belenix does not make it clear that it is possible to install the live CD onto the hard disk.A user has to go online to discover "hdinstaller".
2. Belenix does not offer a disk partition tool that can create a partition of a format which is needed for the installation! This is so stupid that it needs to be repeated, emphatically. BELENIX DOES NOT OFFER A DISK PARTITION TOOL THAT CAN CREATE A PARTITION OF A FORMAT WHICH IS NEEDED FOR THE INSTALLATION. The Gnome partition tool which is bundled with the distro cannot handle Solaris or Solaris2 types.
3. Ofcourse, hdinstaller does have a command line disk partitioner - fdisk. But using it would be similar to doing a rope walk, blindfolded. It will not allow a user to create a partition based on the size of the partition. A user is expected to figure out the percentage of the disk space to be allocated instead, or alternatively, the cylinder numbers are to be provided. A persistent user will go to those lengths to see Belenix installed, only to be rebuffed by a terse "the partition space is inadequate" message by hdinstaller.Can't it be considered idiotic to give that message after all the changes have been committed? What prevents Belenix from telling the user to create a 5GB partition before hauling him over the coals? Users without that much free space on the disk can avoid all the hassles. Ofcourse, the fact that a primary partition only will do is also not mentioned upfront.

4. If the user has gotten so far, and created a 5 GB Solaris2 partition, another obstacle comes in the way of a message "The window is too small for the application. Resize screen and restart application". Also hdinstaller only offers a Hobson's choice, no going back, its either quit or OK all the way.

In their defence, it can be said that a user takes on the hdinstaller challenge voluntarily, since Belenix only promised to be a live distro of Opensolaris. And if the user wanted Opensolaris, that is a different story (hopefully not as nightmarish).

I am writing this as Belenix is being installed in the background.

Update:
The Cup of Woes overfloweth

The ludicrousness of Belenix scales newer heights, post installation. It doesn't even manage to get the GRUB installation right. It seems it is using some ancient notation, and while the boot path is shown as "/platform/multiple kernel/unix"; the error message states that "Opensolaris no longer uses Multiboot option". But, this comes up later.
The default options do not work, the first error referred to an incorrect path. On viewing the boot line options, I find that the hard disk is numbered hd1. Modifying this to hd0 causes the booting to stop with the previous "Multiboot" problem. So I remove the multi word, and the boot process manages to creek to the next error - "kernel needs to be loaded before the modules".

Since this would require checking the path to the kernel, I had no option to use a live CD to boot. Using Belenix live CD itself failed, crashing midway - I am guessing this has something to do with the hard disk installation. It is not the first time though where I have observed that the fate of the Live CD is influenced by the state of a hard disk installation. I had to resort to Knoppix to boot. Navigating to the partition, I found that the boot path was incorrect, the unix image was in the boot/platform/... directory. So I tried editing the menu.lst file from within Knoppix, but this was not permitted, even when using the root account.

Returning back to the hard disk boot, I tried editing the menu to accomodate for the boot option, this time the error was that "absolute path" was needed. So I preceeded the kernel path with the hard disk notation hda0. Finally, the boot progressed past the earlier errors and came to a halt with a "Stack error".

Well the solution it would seem is a reinstall. But, since the Belenix live CD will not boot with the hard disk installation, all hopes of a repair reinstall faded away. I used the Knoppix CD to delete the partition, and was able to reboot with the Belenix live CD and type this.

I am disappointed, mildly put.

Since this whole exercise was necessitated since all the rest of the distros did not have the relevant drivers for the Realtek Gigabit LAn, I downloaded the relevant drivers from the Realtek site. Imagine my surpise when I tried to extract the .tz and .bz2 archives. The XFCE windows manager does not pack in a archive tool! Not that it would have helped much, since I did not have a Cd burner as well, and plugging in the flash drive received a cold shoulder. Funny thing is when logged into the KDE interface, one of the entries under the Utilities menu is Xarchiver, this is in addition to KDE's Ark tool.

New Motherboard Problems

The new motherboard has managed to evade all attempts to successfully install a completely working copy of Linux. Some distros like PC Linux and FC 8 could not even mount the live CD. PCLinux stopped with an explicit message that the Live CD could not be mounted. FC8 gave a different error that seemed to point that it did not take the onboard IDE controller as a friend. Some ATA... error.
Other distros that I tried - Mandriva, Centos, Sabayon, Opensuse - all failed to tackle the net connection. The onboard Realtek gigabit network card proved too much. But, in all other aspects they were successful.

Salvation came in the name of Belenix. The only hiccup was in the X configuration, since this took time and a lot of trial and error and restarts. What aggravated the situation was that I could not login from the console to try editing the conf file manually. The username password combination remained elusive - root, user, password etc were tried out.

Eventually the combination that worked involves using the Vesa drive and not the Nvidia driver, and reducing the colour depth to 16 bit. The network problem was addressed beautifully, and here I am typing this. The resolution remains at 800 x 600, for which the only solution is a manual edit of the xorg.conf file since Belenix does not offer the proper graphical tools to tweak X.

The default combo is user and belenix.

Segmentation Fault

This means that either the RAM or the program code is corrupt. If the RAM is to blame, a restart fixes this, but it can reappear. If it is the code then a pattern can be deciphered, helping pin point the program to blame.

A series of unfortunate events

The seeds were sown yesterday when the system would not power off after a shutdown command. The system remained unresponsive after displaying the "sending term signal". After waiting for the usual time, I did a manual shutdown with the restart and power down buttons.

Today morning the series began. The system would not boot to the desktop but stopped with a series of permission denied messages. The use of the "Scroll Lock" button, something that I had never felt the use for for over a decade, allowed me to make out the messages as they quickly scrolled. A few files were identified.

Thinking this could be a result of the improper shutdown, I concluded running the fsck command on that partition would help. Since the system even couldn't boot to the command prompt, running it from the same system was not possible. Ofcourse, at the point I noted that an explicit boot option to boot to the console was missing.

Booting with the PCLinux live CD, I ran the fsck command. Way too many inodes were found out of order. After the sweep, I tried booting from the hard disk. No luck.

Had this been Windows, the next logical step would be a repair install. This is the first area where I felt Linux is a major let down. For one it makes life difficult by having too frequent disk errors (this could also be because one of my RAM modules is not error free, though this fact does not seem to affect normal working). Secondly, a repair reinstall is not available in most distros. I have seen this in, probably, just Sabayon- though even there it is accompanied by a message that it takes a lot of time but works.

PCLinux does not offer a repair option, so thinking a reinstall on the partition without formatting would work just as well, I proceeded with the install. At the partition selection step, I selected the older partition as "/" mount point but disabled the format option. Imagine my shock when the next step still gave a warning that all content on the drive will be erased! I quickly backed out. Then I copied all files under the home folder from the older partition to a safer place and returned to the reinstall step. During the backing up process I made a useful discovery, that the downloaded packages of Synaptic are stored under /var/. I had searched for *wine*.*. To return, the format option was disabled, yet the warning came on, but it did not format the drive! The installation proceeded and after the boot loader was installed, I shutdown the system.

The corrupt RAM was weighing on my mind, and I blamed it for the Azureus phenomenon ( Azureus would complete download of a torrent, check it, find peices missing, download these peices, recheck again, still peices would be missing, and the cycle continued a few more times, before the check was satisfactorily completed. Many times the extra MBs downloaded would be just a small fraction of the total file size, but occassionally, somewhere like 50-75 MB would be downloaded after the entire file had been completed. The corrupt RAM could be causing the hash failures, I conjectured.). The solution would be to add the drive to another system where the RAM was error free. Since the earlier experience of Linux taking hardware changes in it's stride, I was confident that there would be no hiccups. Linux surprised again.

But, I was so convinced that it was a lingering problem with the previous corrupt installation that I did not immediately switch to the older configuration. On the new system, I discovered that not only would not the freshly reinstalled system not work, nor would any Live CD as well. Belenix, PCLinux, Freespire, all failed to properly boot, crashing before the desktop showed up. Kubuntu managed to deliver the desktop, though. Another fsck followed. Eventually, better sense prevailed and I restored the older association, and the reinstallation booted normally. In hindsight, it seems that the reason none of the live CDs booted properly could have been because the motherboard, being quite recent - based on the geforce 7050 onboard graphics chipset - the proper drivers may be missing. A VI of one of the non GUI loaded installations xorg.conf file showed that the contents under the device section were correct - nvidia.

After the reinstallation experience, I discovered that the network would not work in the reinstalled system. All attempts to reconfigure, delete and create a network connection failed, leaving me with no net access. To make things worse, Synaptic too began playing truant. I had hoped that the reinstallation would've made some changes so that this time Wine installation would proceed more smoothly. Dashed. Synaptic would show up on the taskbar and then close. So the Wine experiment could not be done.
Since I had backed up all files, I copied them back into the earlier locations. I had recreated the same user and root accounts with no password in both during the reinstallation. Azureus would not load, till I deleted the older .azureus folder under the account's home folder.

Overall this took almost the entire working day. And at the end of it I was still without a net connection. Which leads me to the point where a complete reinstall is needed.

The experience has been informative. I found out where the synaptic download folder is. I disovered that there are limits to which Linux can accomodate new hardware, which brings be to the need to learn how to install drivers during installation. I revisited Kubuntu, and reexperienced the marvel that is Dolphin - the file manager, also found that it is the one distro which mentioned Wine in the most logical way - as an option in the Control panel offering to run Windows applications (Wine is NOT preinstalled though). I recollected that Opensuse is not a Live CD.

Apt-get

Apt-get is Synaptic without the GUI.
If Synaptic begins to act funny, you can rely on apt-get to get the job done. In my case I had to use apt-get because synaptic would not launch. I can see the busy icon, and then nothing appears. Luckily, apt-get is a bit more logically deviced unlike many other commands in Linux.

I was completely flattered by the concise and well laid out command options. Usually typing in a command will output it's help file by default. In the few commands I have had the misfortune of having to use, this runs in to many pages. Not apt-get. The screenshot below shows the beauty of apt-get.

Since I had been trying out installing and uninstalling Wine till it somehow got motivated to sync properly so that I could use it, I was interested in removing the Wine package.
Entering apt-get got the options. Seeing that "remove" is the required option to uninstall a package, I simple entered apt-get remove wine. A few seconds of analysis later, apt-get prompted for confirmation and after the affirmative response, proceeded to remove Wine.

What striked me was the speed of processing. In synaptic invariably, even if no new packages are to be installed, it would spend a few seconds "downloading packages" then it would proceed to remove the selected packages. And usually this step if followed by a reloading of the package list which takes a few seconds more seconds. apt-get does away with both the preceeding and succeding steps and sticks to the brasstacks. It probably takes half the time as a result.
The drawback is that unlike Synaptic which automatically tracks down dependent packages and lists them too, apt-get did not do so. So a re read of the help document revealed that another parameter needed to be given for removing dependencies as well.
The correct command to remove dependencies as well was "apt-get remove wine -D".

It would be hard to understand apt-get at work without having an opportunity to see Syanptic first. The visual feedback of the package listing, the dependency calculating etc makes Synaptic many times better. But, for those seeking a quick end to a application management problem, and know exactly the package to be done away with will find apt-get more useful. It also helps when Synaptic is too gloomy to come out to play.

Since the problem I was facing was that Wine would cause X to restart without warning, which was why I was uninstalling and reinstalling the Wine package, after the latest restart, I logged into the user account, almost absent mindedly. And to my surprise Synaptic works find in that account, not Wine though.

Checking Windows partitions

fsck works for Linux partitions. Try running it on a FAT partition and you get a fsck.vfat not found error. A google search revealed that the tool may have been renamed to dosfsck in some distros. Well in PC Linux atleast this is true.
To avoid having to run the dosfsck command separately, a "symbolic link" can be created linking fsck.vfat to dosfsck by running this command : ln -s /sbin/dosfsck /sbin/fsck.vfat

Snapping Synaptic

Repeated attempts to uninstall unwanted applications by using Synaptic end with the error - rpm databse not found. Unlike most Windows applications with an "uninstall" or "unwise" program that can be run to uninstall applications, I am not able to find a similar executable for programs installed in the Linux system. Programs mostly end up under the /usr/bin folder.

In general, application misfires are not a rare event in Linux. It is expected that every boot brings something new to the equation. It is not surprising to have a system that worked fine during the last session to exhibit inexplicable anomalies at the next boot. Most of these anomalies disappear on a restart, though.
I would like to believe that these problems arise out of the absence of tight integration between different components that constitute a disto. It is rare for all applications in a distro to have the same creator. Since all distros are a bundle of different apps, it is expected that the interfacing between all these apps across different environments would not have passed rigorous quality tests.

Fixing X

Shifted the hard disk from the system with the Via chipset motherboard to another system having the nvidia chipset (Geforce 6100 onboard graphics). As previously experienced in PC Linux, the new hardware was properly detected and relevant drivers loaded. All hardware except the graphics. So I was left with the command prompt. The shortest way to getting back the GUI involves reediting the device details in the xorg.conf file. To get these details XFdrake needs to be run. Running XFdrake will show the name of the driver being used. Note down this name, and replace the existing one in xorg.conf. Then do a startx at the command prompt and you are all set. This works only in those distros with XFdrake. Xorg -configure is another command which can also be used, but in my case this left the system unresponsive requiring a restart and the associated fsck due to the improper shutdown.

Stepwise :
1. run XFdrake.
2. Identify driver name usually in quotes
3. Run vi /etc/X11/xorg.conf
4. Dig down to the devices paragraph, where among other things, the driver is mentioned. This is usuall "nv" or "Savage4" etc.
5. Replace existing value with the one displayed by XFdrake.
6. Save :w and quit :q! vi
7. run startx.

While in PC Linux I had to do this, Mandriva even managed to reconfigure X all by itself. All I had to do was twiddle my thumbs.

Installing DirectX in Wine

A google search threw up this page :
http://wine-review.blogspot.com/2008/03/directx-90c-march-2008-redistributable.html

An older version relating to the installation of DX 9c is here :
http://wine-review.blogspot.com/2007/11/directx-90c-on-linux-with-wine.html

I tried the latter, and installation was glitchfree. I could run DXdiag and the direct draw tests were a bit sluggish, which could be attributed to the 256 MB shared RAM and the onboard S3 graphics. But, probably, the hardware would not have posed a problem had the tests been done in Windows. Since the emulation process takes CPU power, some headroom is needed to match the speed.

The dll files mentioned can be downloaded from here : http://www.dll-files.com/

Testing with real games will require a beefier system.

Mandriva driving mad

It doesn't allow you to login as root. It doesn't offer an option to browse through the drive as super user. So how can one access files under the root partition or in those drives mounted by the root?
Doing an su in the command prompt does not reflect in the file manager.

Update:
A quick query at Linuxquestions and I have a solution thanks to a guru. The solution:
Create a link on the desktop to the Konqueror application, which is the default file manager. The Konqueror executable is in the /usr/bin directory. Only the working folder needs to be filled in the properties. Then under the Advanced options enable "Run as another user" and enter the root username. The next time any locked file needs to be accessed, launch the file manager with this link, and insert the password and voila.
In the same link properties mentioned above, under the command box entering "kdesu konqueror" will also suffice.

The moot point is : if it is so easy to offer a superuser file manager, why not incorporate it in the distro in the first place?

Update 2
A follow up post at linuxquestions offered a more user friendly option. INstall openasroot-kmenu. This will give the Open as Root option that makes using PC Linux so much easier. Since this application is in the Application manager's package list, this is another reason follow the earlier tip to look through the application list as a first step to working with a distro. If the program doesn't turn up in the first search,, this is because the relevant repository is not enabled. Enable the Contrib repository and retry. In Opensuse, this is a 19 KB package, and installed without problems.

Serendipity

After trying out many distros, I had come to like PCLinux. It had most of what I wanted in a OS without being tied down by paranoid security protocols. The inability to get Wine installed was a major blow. Since installation had failed on one system, and on the other system the installation proceeded in the same lines, I had given up hope of being able to live with just one distro, needing a second distro like Mandriva for the wine utility and the ability to run windows games.
But, a reinstallation of Wine seems to work, even though I do still get a lot of errors. Since I had enabled saving the packages locally, for the reinstallation there was no more downloading. The application manager went through the motions of the installation, and abruptly stopped with errors. BUT, fortunately, the Wine name made an appearance in the programs menu, AND more importantly, launching it worked without glitch.
I still have been unable to replicate the reinstallation success on the other system. No matter how many times I tried to remove and reinstall Wine, it always crashed on launch. Online, there are no sources of information to shed light on this situation.
The conclusion I have arrived at is that a lot of serendipity is associated with program installation, especially when dealing with new program installation. I am of the view that the Wine installation would not have been a problem, had the installation DVD of PCLinux been used, since in that case the packages would have been installed along with the OS. There are obvious advantages of using a CD, since one would rarely need most of the apps on the DVD. So if both are as easily available, the latter is a wiser choice.

To enjoy a distro

The first step to enjoy a distro is to look at the list of applications available in the application manager. After having gone through the list myself, I have found many applications that need to be removed and added to make the installation run more effectively.
Ofcourse, making changes to the list and having them applied successfully are two entirely different issues. Nonetheless, browsing through the list, an updated list that contains all the packages available in the different repositories especially, should be one of the first things to do before settling down with the distro.

(updated 6.4.08) A side effect of this exercise is that the cryptic nomenclature of applications becomes less annoying. GKrellm makes sense.

Wine in OPensuse

After having tried installing Wine in PClinux (failure), and Mandriva 2008 (success), I tried doing the same in Opensuse.
Of the three, the installation was the briefest in Opensuse. Just over 8 MB was downloaded. Post download, the entire integration took less than 5 mins. BUT, Wine was no where to be seen. It did not mark its presence on the desktop or the menu. To find out where the program files had ended up, I had to relaunch the application management routine. There the path /usr/bin/wine was revealed. I double clicked on a shell script, winecfg.sh. It ran successfully, so the installation was not botched up. But since there seems to be no easy way to run a windows application (right clicking on an exe did not produce the Run in Wine option), it is hard not to consider this a failure.

The work around is to use the Open with option while right clicking on the exe file. Then browse to /usr/bin/wine and select the "always use this application " option. The next time an exe is clicked, Wine will do the necessary.

Distro choice

Here I have listed a few criteria that need to be considered before selecting a distro. Probably I shall create a chart to compare the distros across these features.

1. Ease of switch as Root. PCLinux offers a context menu option that reads "Edit as Root", in Mandriva 08, I can't login as root from the normal login screen, there is not Root terminal, there is no root mode file manager, and the context menu seen in PCL is missing.
2. Password lengths
3. Mounting/Accessing other partitions graphically.
4. Command line editors - nano beats vi
5. Openoffice
6. Wine
7. Repository management - adding and removing offline or online repos.
8. Acess to control panels
9. Autologin any user.
10.

X Factor

Linux owes its popularity to X. You cannot spell Linux without X. The masses that adopted Linux did so because X offered the freedom to bypass the complexities of the command line.
It would logically follow that X IS Linux, without X, Linux is just Unix.
My experience with X and how it is treated by different distros seem to indicate that the importance of X is underestimated by many distros. In this particular case it is Sabayon.
Migrating a hard disk with PC Linux installed from a geforce onboard graphics motherboard to a savage graphics onboard motherboard was quite simple. X had problems, but XFDrake worked which showed that the drivers are all there, since the test with the new settings was a success. Ultimately, I just copied the relevant portions from the live CD's xorg.conf file to that of the installation. And it worked smoothly.
Sabayon makes life difficult. For one there is no XFdrake. Searching online I found about the Xorg -configure command, but this stops with an error. Finally, copying the relevant parts from one Linux distro to the Sabayon one also failed with an error that xinetd has errors.
I have said this before as well, but the message is too important to ignore. There needs to be some standardisation among distros with regard to critical OS functions. Display is one of them. My experience with many distro leads me to believe that it is more appropriate to consider each of them as a distict OS rather than the same OS in different flavours. If this reality were digested, the distro navigation becomes easier. Linux needs to be pushed to the background, and each distro needs to be accepted as a distinct OS, like Windows, MAC etc.

Sabayon vi sabotage

While I have stated, repeatedly, that vi offers the only hope when the dark ages of the command prompt are confronted, Sabayon proved me wrong.
The heartless Sabayon takes away even the little ray of hope that vi is. So if dumped at the command prompt, when using Sabayon, you need "nano". I chanced upon nano accidentally, I tried out pico, vim, emac, emacs and was considering the arrogance of Sabayon in their inability to add even a basic editor.
nano happenned by fluke, being from the same naming retarted family as pico. But, the naming irrelevance aside, it offers greater ease of use than vi, much greater. For one there is a list of commands that can be used, which is a god send. The rest is easy. I need to check if nano is available in other distros as well.

Another instance of Sabayon playing truant is the absence of the XFdrake command. I recall that I had used this command to gain some hope when I was dumped at the console after a system switch. In Sabayon this command does not exist

GRUB errors, contd

The problems in resizing with Qtparted began showing up in different ways. This time I end up with just a grub command prompt. No more Error 18 message.
In the mean time I tried a few modifications to the jinxed OpenSuse installation. I used the sabayon live Cd to re-resize the NTFS partition, then I reduced the size of the extended partition which was covering the rest of the drive to make space for another primary drive to hold the swap and boot ext2 partitions. Here too the Sabayon installation proceeded smoothly, but after a reboot I do not get any errors, just the Grub command prompt.

I tried using the drive on another system. This time I got the boot menu, which surprised me a lot. I was just begining to think that the previous mobo was to blame and not GRUB or Linux, when the booting process stopped with an error that the root drive was not valid. The boot progress could be seen from the display, and one word seemed interesting - mtab. Rhymes with fstab. A google search showed that mtab is automatically created and hence editing it is not worthwhile. Editing fstab seemed like the logical next step.

Opening up fstab, I was introduced to yet another system of naming drives. This one goes one step beyond the one seen so far in making life for the ordinary user difficult. While the naming scheme involving sdx or hdx which could label a disk based on its location in the channel was idiotic, this one was downright incomprehensible. When a partition on the drive is labelled "/dev/disk/by-uuid/f7a69855-d98a-448b-9347-0688aa548dc3" it is impossible to tell which partition is being referred to. Atleast "hda5" made some sense.
Seems distros like Opensuse and Sabayon revel in aggravating a user, since I have seen a similar notation in OPensuse menu as well. I wonder if UUID is the same for a hard disk irrespective of the motherboard it is plugged into, or is it a random figure.
The fstab entry is reflected in the menu.lst file in GRUB as well. In Sabayon's Boot folder, I discovered another thing - that menu.lst is a short cut to grub.conf file. Is this only in Sabayon's case?

Replacing the UUID gibberish with the more sensible hdax notation seemed to improve matters, a lot. With the modified menu.lst, Sabayon booted right into the command prompt. As previously experienced, the shift in systems only caused a hiccup in X. fstab still contains the UUID notation, but it didn't cause a problem during boot.

Proxomitron

With Wine installed, I could use many of the best apps that were out of bounds because an equivalent was not available in Linux.
Proxomitron was one of them. While Privoxy is rated highly among ad blocking proxy servers for Linux, it does not offer the ease of use and configuration that Proxomitron does.
All that was needed to run Proxomitron, was to right click on the executable and use the Run with Wine option. Since it did not have an installation routine, I had apprehensions on how it would run under Wine. But, they were unfounded.

Why I whine vi

Mastering Vi, the very irritating text editor which is the only hope to edit a file when the system does not boot and drops you in a maintenance console, is the only way to avoid taking the circuitous route of loading a live Cd to edit the same file in GUI mode.
The frequency with which you will get dumped in the maintenance console increases exponentially depending on the number of entries in the fstab file. You will need vi in those cases to delete all but those lines relating to the boot partition and the swap partition.
A google search revealed the most elusive commands in vi - :w and :q, to save and quit respectively. During my fiddling with vi I had figured out how to insert and delete content but the saving and exiting were hard to pin. The ":" was the eel in this case.
There is a lot of history behind Vi, but the controls are unforgivably irritating. I am not sure if this is the only text editor to be used in maintenance mode. Even if it isn't, isn't it time someone made it less stressful.

GRUB limitations

I am not sure if this is a shortcoming of just the boot loader or something more intrinsic to linux.
The partition nomenclature used in Linux has a serious limitation when it comes to migrating hard disks. A hard disk is named differently based on the channel which it is connected to. To elucidate : a hard disk connection to the primary IDe channel, as master is hda. Strangely, if the same hard disk is made slave (even if there is no master in the same channel), it gets labelled hdb. Similarly, there is a sdx series to denote SATA drives, though I am sure I have come across this naming even when PATA drives are used.
This is not just a source of confusion, it also makes migrating hard disks difficult. A drive that is hdc in one system, has to be installed as master in the secondary IDE channel of another system if it has to be booted. Since the GRUB menu entries use hda, hdb etc notation the menu entries are rendered unbootable if the drive is loaded on some other channel.

In comparison, Windows uses a more user friendly nomneclature. Atleast a bootable hard disk will work in any system irrespective of its channel status.

QtParted skills

Qtparted, the partition tool that comes with Knoppix had rubbed me the wrong way previously, by renaming the partitions and thus causing the system to become unbootable.
I had another opportunity to use Qtparted. This time I wanted to resize an NTFS partition to make way for a Linux distro. Before using Qtparted, I had defragmented the partition in XP. (which brings me to the question does Linux have such a tool?)
Then I booted with Knoppix, opened Qtparted, set a new size for the partition, and applied the changes. It must have taken less that 5 minutes for the job to complete. I was taken aback by the speed with which the partition had been resized, that I was quite sure that the data had been erased. But, that was not the case, I could see the files in the resized partition, as well as boot into the XP installation which that partition contained. The 1 hour defrag process in XP may have some say in Qtparted's quick response. Interestingly, it was an NTFS partition, a file system which cannot be written to in Linux (in my knowledge).

So, far so good.
But then the Linux installation started acting up, or rather the GRUB in it did. While the Opensuse installation went smoothly, after restart, GRUB would stop with an Error 18, before offering the boot menu. Thinking the Grub menu would need some tweaking, I tried booting with Knoppix. This time Knoppix did not boot, but stopped midway with some hard disk or partition error. Then I tried using the FC 8 live CD, and the Gparted partition tool in it showed that the resizing operation had left a 5 MB space free between the partitions. Could this be the cause of the error? I checked Grub's the menu.lst entries and found them to be valid. So probabably Qrparted's crude resizing had something to do with it.
The 5 MB space was the result of the unused space on the cylinder. Usually, when partitions are created, the sizes are rounded off to include the entire cylinder. So it is quite common to find paritions that are a few MBs off from the user's desired size. In QTparted, the partitioning does not do so, leaving the rest of the cylinder free. Since a new partition will start with a new cylinder, the free space remains free.
A Google search revealed that the Error 18 is a result of improper disk geometry reported by the BIOS to the OS. So the partition table was incorrectly written thanks to Qtparted. Some other sites also report that an EXT3 partition could also be to blame, since I had used EXT3 for the partition this needs to be checked.
The Qtparted problems also prevented rewriting the bootloader, which I tried to do with the Sabayon Live Cd. SAbayon offers installation option including a full install or upgrade or bootloader installation. Doing the latter produced another error. So I tried creating a new partition by deleting the earlier one, but this too ended in some hard disk error. After the aborted bootloader modification with Sabayon, Knoppix booted without problems. When I tried to use Qtparted to undo the damage, it would not cooperate. The options to delete or resize the partitions were greyed out. Even when the partitions were not mounted.

Update :
Plugging the hard disk onto another system seemed to solve the Error 18 problem, and the boot menu and all installations in it worked fine. This was strange. Then it struck me that the BIOS settings could be the cause for the change in behaviour. So I reinstalled the hard disk in the original system and changed the BIOS parameters for that hard disk to Auto, from the previous Manual (which can shave a few seconds off the booting time). Voila, the error 18 vanished.

Wine and Opera

Opera 7.54 is my default browser. While all Opera browsers are the best of the lot, 7.54 has a special trick up its sleeve - the ability to reduce the tab size to a few pixels wide. This feature is absent in all later Opera versions, besides all other browsers.
Installing Wine allowed Opera 7.54 to be run, since this version is not available on Linux. Wine unfortunately makes it difficult to change the default font, resulting in unpleasantness as seen in the screenshot below.

The only way to overcome this is to either install a Windows theme - not just any theme, but a theme that also includes a font file (ttf), or install a font. Installing a theme is easier, since Wine offers an interface to do so. Notably, while many site offer themes, not all of them contain a font, so a lot of trial and error can be expected. Installing a font is more direct, yet Wine does not allow any interface to do so. The easiest way out is to copy font files from the Linux installation's fonts folder to the Wine installation's font folder. Since Linux also contains ttf files, there is little incompatibility encountered. The Linux fonts are stored in the /usr/share/fonts/TTF/ folder, and the Wine fonts are in /home//.wine/drive_c/windows/fonts. .wine is a hidden folder.
The much better results are next

Mandrake 2008

The shift to a new system gave me an opportunity to retry the failed Mandrake 2008 installation. This time the graphics drivers were cooperative.
Man 8 offers almost similar features as PC Linux, probably the latter is based on the former. The one sore point was that Man 8 insisted on a 6 letter password for the root, and would not allow the root to login from the GUI. Besides this, it is PC Linux in a different colour scheme.
One experiment that I wanted to tryout on the Man 8 installation was installing Wine. Since the installation on PC Linux had failed, I was hoping that Man's popularity would make a difference. It did.
The application management routine in Man 08 is quite good, allowing easy adding and removing repositories offline and online. Since Wine did not show up in the initial search, I added an online repository, and proceeded to install Wine.
After the first download and installation, about 50 MB was downloaded, the menu entries of Wine made their appearance, but launching it did not result in anything. On revisiting the applications selected for installation, I found that lib wine package, which were the libraries on which the Wine executable depended upon, were not installed. Though I do recall that on selecting Wine a few dependent packages tagged along, probably this particular one was not one of them. So the second time, I selected the lib package and a few other apps were tagged on as a result, and then proceeded to download and install these as well. In all the total download size came to about 90 MB, compared to the 300 MB which I had to download while installing wine in PCL.
Post installation, since the glibc package had been updated, a restart was needed. After restart, Wine was running as expected. After installation, a new context menu entry makes an appearance everytime an exe file is selected - Run with Wine. Selecting this will launch Wine, and in it the particular application, without any further action from the user. The screenshot is of Irfanview running in a Wine window.