OLPC Experimentation

Two weeks of trying out OLPC development environments in my spare time is finally starting to have some visible results.

I did not enjoy exploring OLPC software in an emulator and wanted to install it on a partition of a (slow) spare pc. It has a via C3 chip. The instructions are here: http://seth.anil.googlepages.com/olpconapc

Programming Lessons on Western Railway - Multiple threads and performance

Western Railway in Mumbai has 4 tracks - slow Up, slow Down, fast Up and fast Down. In order to provide a fast service to passengers in various areas, Western railway has some trains which are slow between Borivli and Andheri and fast between Andheri and Churchgate. There are trains which start or terminate at Andheri and are slow between Andheri and Bandra.
Conditions of passengers at intermediate stations can be very difficult; so, Western Railway has special trains which, e.g. start at Goregaon and are slow up to Andheri and fast after that.
A programmer will see an obvious design concern. These threads will need to be synchronized. Will there be a problem? Every day and night, I experienced the problem. The train would halt and we wait. The design problem was even more severe. To switch between slow and fast tracks, the train had to cross a track with traffic in the opposite direction. More the traffic as at peak hours, worse the synchronization delays.
My brain had nothing else to do during the seemingly endless delays except dream of a different design. If the mind was occupied, the claustrophobia of being surrounded by a mass of humanity seemed less.
My ideal solution - in another post.

Daydreaming - I wish I were a Superman

I read in the morning paper that a SUV didn't stop for a cop and carried him a couple of kilometers. The cop is seriously injured. On the inside page, the story is that a cop is suspended for asking for a bribe for a traffic violation.
As I am crossing the road, a lunatic runs through the red light. I scramble across the road but how I wish I were Superman. I would have stood still and enjoyed the look on the driver's face as his car would have been crushed like a piece of paper after the collision.
Well, even if we can't do anything about it, at least we can daydream:)

Lesson in Programming on Western Railway - Capacity problems, look beyond compression

A general manager of Western Railway made the effort to quickly increase the capacity. He introduced train coaches which had very few seats and, hence, a much larger standing capacity. It seemed reasonable that many more people could fit into each coach. The coach looked like a typical metro or subway train coach with seats on the sides and standing room in the middle. Except that these coaches were much wider and standing in them in crowded conditions was a torturous experience.
The congestion on the platform did not get any less. I avoided such a train, preferring to wait. The GM carried out a survey in which people said that they would accept such coaches if they were air conditioned.
The coaches were not airconditioned, rather they were withdrawn. I am pretty sure people, especially children, could have suffocated in such coaches. It would no longer have been lossless compression.

Lesson in Programming on Western Railway - Don't add a feature till needed

I had to go to a formal meeting and dressed in a tie. The train in Borivli was crowded as usual but getting down at Bandra was worse than I expected.
The rush of people trying to get in made exiting a very difficult exercise. I got down but my tie got entangled. Fortunately, only my shirt and tie were twisted out of shape.
It was, but, a valuable lesson. After that, the tie was always in my pocket and not on my neck till I was out of the local train.
The habit became so strong that I try not to program even a line till it is needed.

Lesson in Programming on Western Railway - Exception Handling

Even after over 30 years, some of the memories of traveling in Western Railway of Bombay suburban are very vivid. Some of these experiences have made me conscious of a number of critical programming concepts.
For example, exception handling is a must. If you can't handle a problem, pass it to someone else who can.
I was returning home and crowd was the usual size. We try to rush in and, hopefully, into the compartment so that we are not hanging from the door.
I try to get in from the left side of a pole in the center of the door. I suddenly find that a fellow passenger is trying to get in from the right side of the pole. Nothing wrong with it except that his arm is going around my neck. Neither can get on board and the harder he tries, the worse my condition.
To this day I cannot figure out how such a configuration occurred; but many problems in a multi-threaded application do not make any sense either. For a few seconds, I was sure that this was the absurd end to my life. However, other passengers realizing the deadlock, made the other passenger release his grip and I could board the train and then so could he.
I did not get an apology. Did not expect it either. I was just grateful for the release.

Overcoming a powerfailure in the middle of an upgrade

Upgrading a distribution invariably introduces new challenges. In this case, it resulted from taking an absurd risk of upgrading during the summer in the midst of power failures. Our area in Chandigarh does not get many cuts, but still...

After upgrading about half the packages, the power failure occurred. UPS batteries did not last long enough. I restarted the upgrade and, to my relief, found that the machine still booted and allowed me to upgrade the distribution. It upgraded only the packages which had not already been done.

The unpleasant discovery came after the upgrade was successfully done and I decided to apply the available updates. There were problems of conflicts in files because many of the FC6 packages were still installed.

The net helped in understanding that this was a consequence of yum crashing in the middle of a transaction. However, manually fixing about 600 packages was a pain. So, I enjoyed myself and wrote a python script to clean up the mess.

The script follows, in case anyone else ever needs it.

#!/usr/bin/python
# Power failure during FC7 upgrade results in duplicate entries in rpmdb
# This program will create a file 'deleteList.txt'
# containing duplicate rpm's which may be deleted using
# rpm -e `cat deleteList.txt`
# Depending upon the number of packages to be deleted, it can take time.
# Anil Seth, Jun 2007.

import rpm
NEW_DISTRIBUTION='Red Hat (FC-7)'
REL_SUFFIX='fc7'
ARCHS=['x86_64','i386','i686']

def chk_dups(pkgs,arch):
""" find the duplicates for a given architecture
by looking at the distribution (4th element in list - index 3)
or by checking the suffix of release(2nd element in list).
In case the above strategy does not find a new package,
select the one with the highest version(1st element in list)
Returns 2 lists - new packages and remaining packages.
We expect, but do not require, one item in each list.
Returns None if there are no duplicates.
"""

dup_pkgs = filter(lambda x: x[2] == arch, pkgs)
if len(dup_pkgs) > 1:
newPkg = filter(lambda x: x[3] == NEW_DISTRIBUTION or REL_SUFFIX in x[1], dup_pkgs)
restPkg = filter(lambda x: not(x[3] == NEW_DISTRIBUTION or REL_SUFFIX in x[1]), dup_pkgs)
if len(newPkg)==0:
max_version = max([x[0] for x in dup_pkgs])
newPkg = filter(lambda x: x[0] == max_version, dup_pkgs)
restPkg = filter(lambda x: x[0]!= max_version,dup_pkgs)
return newPkg,restPkg
else:
return None


def delete_duplicates(ts,dups):
""" convert the items in dups list into package names suitable for erasing
It is written in a file
We could use ts.addErase(rpmname), ts.check(), ts.order() & ts.run() to
delete the packages through the program. Hence, ts is being passed as a parameter.
dups is a pair of lists of which the second is one for deletion
"""
f=open('deleteList.txt','w')
for name in dups:
for rpm in dups[name][1]:
rpmname = name[0] + '-' + rpm[0] + '-' + rpm[1] + '.' + rpm[2]
f.write(rpmname + '\n')
f.close()
print '''Now as root, run
rpm -e `cat deleteList.txt` '''

def main():
""" Iterate over the rpm data base, creating a dictionary
with name as the key with the value being a list of attr which is a list package attributes
Duplicates need to be checked for each architecture separately.
Hence, we create a dictionary with (name,arch) pair as the key.
The values are the two lists returned by chk_dups.
We returned the list of new packages in case
we wanted to verify the installation of these packages. Not being done.
"""
ts = rpm.TransactionSet()
mi=ts.dbMatch()
packages = {}
for hdr in mi:
name = hdr['name']
attr=[hdr['version'],hdr['release'],hdr['arch'],hdr['distribution']]
if name in packages:
packages[name].append(attr)
else:
packages[name]= [attr]

duplicates = {}
for name in packages:
for arch in ARCHS:
dups = chk_dups(packages[name],arch)
if dups:
duplicates[(name,arch)] = dups
delete_duplicates(ts,duplicates)
main()