Upgrading

I’m a little late with this post because of an issue with my computer. An upgrade resulted in me not being able to send and receive emails. While this is partially fixed I still have work to do.

I’ve been in the business for decades so I’m acutely aware of how things can go wrong in an upgrade. Sensible systems administrators take backups, plan out the upgrade in as much detail as they can and probably spend more time getting ready than in actually performing the upgrade.

This pays huge dividends, but still, not infrequently, things can go wrong. The wrongness can be major, with a totally destroyed system, or minor, as in niggling irritations like something behaving slightly differently after the upgrade.

Computer firms and software suppliers often make huge efforts to make an upgrade work easily and cleanly, and many have put in place systems to make it easier to upgrade their software or back it out if something goes awry.

There are various levels of upgrade – a small part of a program may need to be upgraded, or the whole program may need to be upgraded, or indeed the whole operating system, Windows or what have you, may need to be upgraded.

In the early days of computer systems upgrading would mean downloading some source code or source code changes called “patches”, making changes to the existing source code, compiling it and then installing it into a particular location on the computer.

The technical terms don’t matter too much. I just want to convey how complex and manual the process was. That is fertile ground for errors to creep in. You download a bunch of code, trusting that it will work and fix some problems, some of which you may not even be aware of, and then transfer them to the existing source code.

You may mistype something, or mistakenly overwrite something in the existing source, feed the new code into the compiler, and out pops a new program, which you then transfer into the correct location and cross your fingers and test.

Incidentally a compiler is also a program and as such it has bugs which need to be fixed. What if you update or patch the compiler and it breaks? You can’t remove patch and re-compile as you just broke the compiler!

The solution is to reinstall the original compiler that came from the supplier, and potentially patch that to the point before you broke it. Or, if you a sensible system administrator, you restore the original compiler from the backup that you took before the upgrade. Either solution is tedious and frustrating.

Operating systems are the biggest upgrades that can be done. They are also the most dangerous because they are big and complex, which multiplies the chances of hitting problems or ending up with a system that doesn’t work.

Operating systems upgrades used to come as a magnetic tape or two, and a small book or manual of instructions. IBM for instance used to supply several books of instructions, hints, cross references, dependency lists and so on for each major upgrade. The necessary books for looking after IBM mainframes amounted to a library and that was what it was called.

IBM and others quickly realised that something needed to be done to help the system administrators to install, maintain and operate their big computer systems. Otherwise people would end up with unusable systems, and IBM would have to spend time and money helping them fix them up.

So the concept of a package was conceived and from very early in computing history, everything was supplied to the customer as a package from the actual operating system down to the programs that ran the printers.

A package was a cluster of programs that provided some feature or facility on the computer. Packages requisites and dependencies on other program – it would be no use installing a package that needs stuff printed, like an accounting package, if there was no printing package already installed.

Computer manufacturers also moved away from providing source code to customers. They supplied, for example, a printer driver or a compiler in binary, ready to run, form, so that the program binary could be simply dropped in place and it would run right away.

I’m simplifying a little, as there were other program chunks that, while they weren’t compilable source code, could not be run as supplied and which had to be intimately connected to other program chunks to produce a runnable program.

Nowadays the average user, professional or home, of the Windows operating system has never seen source code. All updates through Windows Update, and programs like browsers, games, utilities and other programs, are binary distributions, binary packages that the operating system installs for you. The Windows operating system doesn’t even provide a compiler.

This whole distribution system for programs and updates requires very rigid interfaces between the bits of the operating system itself and other programs which are not part of the operating system, and this is, when you know what is going on in the background, truly amazing.

Indeed, a Brazilian Windows systems operator can confidently install a program on his computer, which communicates with him in Portuguese, and so can a Windows systems operator in Finland or even Japan. All can expect that the program will work almost perfectly on all these diverse systems.

It’s slightly more blurry in the Unix/Linux world. There the operator or maintainer is given an option – use packages similar to those used with Windows or use source code. Many Unix/Linux users these days will never have knowingly compiled source code packages, though sometimes the package maintenance system may compile code for them. However this is rare.

Some Unix/Linux users however like to compile some things for themselves, so that they can get the very latest versions of things, and some even compile their whole systems from the ground up though this is rare.

So when you complain about your Windows system installing updates when you shut it down, reflect that things could be worse – you could have needed to compile them yourself.