As another year ends and a new one begins, it does not seem so long ago that we had set up a demo of networked workstations for a financial company. The consultant shot us down in one minute. He said that if the analysts felt that their spreadsheets could be accessed by their colleagues, they won't create them!

Some years later, it took a year for me to get the first copy of Linux CD's ordered from the US. A part of the delay was that it was so low a cost that the purchase department forgot about it! Finally, we got slackware with Linux kernel 1.2x or 1.3x. Subsequently, it became easier to get various distributions when GT started distributing them from Bangalore.

The next major change was when magazines started distributing distributions and patches on CD's. Our first effort on receiving the magazines was to make sure that the CD's were readable and apply the patches.

However, the computers were slow and had a limited amount of memory. To squeeze the most out of our desktops, we would customise the kernel and remove as much as we could. Sometimes, we needed to add some drivers by using the source code. Now, I can't remember how many years it has been since I compiled a kernel.

Network speeds improved but magazines started distributing DVD's. We were updating the desktops and servers using the internet. For upgrading the distribution, we still relied on the magazines or services which would send us the DVD's.

Tools like yum and apt were not that common. We relied upon search engines like rpm.pbone.net to find pre-packaged applications for our preferred distribution. Installing them was also not always easy as handling of the dependencies had to be done manually. Individuals would make life easy for us by packaging and making available their preferred group of applications on their sites. If our preferred source was freshrpms but we needed one package for livna, it wasn't always a sure shot. If a dependency needed by both was packaged by both, it could result in one or more applications not working correctly. It seemed so straightforward and beneficial to us but, in retrospect, it is easy to understand why convincing friends and colleagues to switch was not very easy.

Now, with the widespread use of yum and apt-get and the consolidation of various repositories, version or packaging conflicts are very rare.

As the networking speeds improved, we could upgrade our home computers within days of the official releases. We could also explore beta releases as well. On the down side, the range of software in various repositories has increased, we install more packages and the updates to various packages appear to have become more frequent.

Given that our broadband wasn't broad enough, the introduction of delta packages by OpenSuse and Fedora was a great boon. In fact, I regularly started using ArchLinux as well when a user set up a delta repository for it. However, he did not need it after a while and nothing replaced it. Now, I rarely use ArchLinux. I may look at it again as there is now a delta.archlinux.fr.

I had explored OpenSuse Tumbleweed but had given up on it as it did not have delta package support in addition to a few more issues.

At college, with a much higher bandwidth, the time required to download the full package is somewhat less than the time needed to re-construct the package using delta-rpm! It is no surprise that the need for delta repositories is not that great in the network rich countries. In a couple of years, I expect that the same will be true for our home pc's as well.

The browsers may give us an indication of where we are headed.

Who knows, we may all be working with thin clients with the OS and storage all accessed from the network. As it is, very few people around me use an email client anymore. Google docs is becoming an increasingly common way to create and share documents.