Upgrading to Fedora 15 beta - the problems encountered

As usual, I wanted to upgrade the existing Fedora distribution using yum and not install it from scratch. I was wondering how smooth the transition to Gnome3 would be. I decided to experiment on Lenovo S10-3, especially as I was curious to see how Gnome 3 looks in comparison to the Ubuntu Unity on a Netbook.

The first step was to download fedora-release-15-0.7.noarch.rpm and manually install it. I needed to install fedora-release-rawhide-15-0.7.noarch.rpm as well.

As expected, some packages created conflicts. These seemed to be related to meego desktop. So, I removed them as that could be tried later.

Surprisingly, I had conflicts with backgrounds which I could not resolve. To narrow down the issues, I decided to disable the updates-testing repository and see if there was a change.

Now, I could go through with the upgrade but after I had forcibly removed gnome-themes. This did not seem to be a concern as there were conflicts in file names with another similar package.

The next surprise was that there were delta rpm packages. However, they would not work. Sadly, I did not read this documentation and had not seen this link regarding the changes in the xz compression. I let yum download the full packages.

The system was up and running. The KDE environment did not look any different. The Gnome3 environment was, of course, disconcerting. However, my first concerns were more immediate.

The first shock was that network manager did not find any devices.

A little search revealed that Fedora does not ship with the open source driver for Broadcom wifi devices as it is still a part of staging directory in the 2.6.38 kernel. And the wl driver was also not available for this kernel from the freshrpms repository. I will need to build a custom kernel.

That did not explain why the wired ethernet card was not found. I could get the network to work by explicitly running
# ifconfig eth0
#dhcpclient eth0

But why was network manager having a problem?

This led to the discovery of two other issues - /var/log/messages contained no new messages. And the NetworkManager system service was not running. I could manually start it and it would then find the eth0 device.

I tried the LiveCD and the messages file contains new entries. The logger works as expected.

Network manager works with the wired ethernet card without having to manually start the NetworkManager service. The difference is that the device is named em1 and not eth0.

So, somehow some of the configuration settings are not the expected ones because I upgraded from Fedora 14 to 15 beta.

Next step will be to understand how the new systemd is working and what could have caused the unexpected behavior when booting into Fedora 15.

Indian Railways online booking experiences - Complexity of Scaling

I saw a presentation about the infrastructure of Facebook a couple of days ago and found it fascinating. A few lessons really stood out:

• Use of mysql as just a reliable storage & not a relational database
• High ratio of RAM to database size for the performance to be acceptable.
• Extensive use of cache and programmatic generation of indexing.
• A view shown to a user has to be consistent but not current.

This presentation came to my mind as I tried to make a train reservation for my nephew during the day time. I normally do not try to make a booking during the day as I find that the failure rate for me has been very high. Yesterday, between noon and 6PM, I must have failed over 6 times. On two occasions, the payment from my bank was done but no booking done.

I no longer worry about the payments because experience has shown me that the money is refunded within a week.

Finally, after I had successfully booked a ticket at 7:30 PM and emailed the ticket to my nephew, I was wondering about whether any of the lessons of Facebook applied. The data needs of the railways are not that large. There are no arbitrary relationships that need to be formed dynamically, e.g. collation of the data of 'friends'.

I have no knowledge of how the railway reservation system actually works. But since it seems to take a fair amount of time for the system to display the availability status of the train/class, it would appear that the availability information is not cached.

As a user, it hardly matters whether the system says 100+ seats are available or 131 seats. In most cases, a somewhat stale information would be perfectly acceptable. Furthermore, the fact that one seat is available is no assurance that it will be when I make the payment.

It is hard to understand why the site would get so slow and timeout. I would be curious to understand the architecture of the railway reservation system, why can't it add servers as it is not a major expense these days. I wonder how much useful work the system actually does under stress, and the resulting 'losses'.

With my bad experience re-confirmed, I am likely to stick to booking at night only. That is still preferable to going to a physical counter and standing in line. So, in spite of the performance issues, irctc.co.in remains one of the most useful sites in India.

On Computerizing the Government

I had admired and liked V P Singh.

We had been involved in a project when he was the finance minister. At least I never met him but the people we interacted with definitely wanted to stop tax evasion. It was obvious that the country's infrastructure and rules made it hard.

I recall an effort to create a simpler, one page form. The officer spent a lot of time and came up with a mess. It was, then, that I realized that how hard it is for people to realize that a code is enough. All information associated the code can be displayed on the system or in the reports effortlessly. A person or an organization once known to the computer application does not need to provide anything more than the code again. However, they must provide the code!

There were times when we had extract the code from the raw information because the government forms did not ask for the code!

Success of the project was minimal. Failure was more likely to be because of logistics and the horrible telecom infrastructure and not because of commitment. Manual processes could not be eliminated in short term.

The objectives of the project were achieved. Tax compliance improved thanks to lower tax rates :)

Getting faster updates of Fedora in India

I was finding updates of Fedora pretty slow for some months now. Finally, I realised that the local mirror in India, at IIT-K, was probably limiting the bandwidth.

Earlier, I had changed the text file, mirrorlist.txt, using the mirrors in US and Canada from the default list of one Indian mirror and rest from China, USSR, Japan etc.

Manually changing the metalink.xml did not seem to work.

It turned out to be easy. I had to modify the mirrorlist option in the fedora-updates.repo file and add the country option.

mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch&country=us,ca

The updates now are much faster though it seems silly that to get a fast response I have to use mirrors in US rather than in India!

Tumbleweed and Other Repositories on OpenSUSE

From the OpenSUSE forum posts, it was apparent that I was not the only one confused by which repositories to use and the implication of using multiple repositories.

OpenSUSE does not allow an update from a repository if the package ownership changes. This is a mixed blessing. It appears to be useful if one is using packman repository in addition to the OpenSUSE's OSS, nonOSS and contrib repositories and some packages overlap. However, it also meant that I could not update the additional packages added to Tumbleweed repository. (I may be able to overcome that problem using the instructions in http://en.opensuse.org/SDB:Vendor_change_update.)

I needed to use the following command again.
$ sudo zypper dup --from Tumbleweed

So far, I have not come across delta rpm packages in Tumbleweed repository. I am hoping, once the packages are updated within Tumbleweed, delta rpms will also be available.

I expect that after some time, the 11.4 specific repositories will become redundant.

Currently, it would be easier to stick to Arch Linux! But there would also be less to learn :)