Why Installers are Evil
2006-05-10
About 7 years ago the OSGi Alliance forced me to switch from a Macintosh to a PC. Ok, they did not wrestle my arm but I needed access to the latest (and not so greatest) version of Java to do my work properly. With regret, I parted with my dear Macintosh and dived into the wonderful new world of PCs. Now, as a Mac owner you are bound to be a bit naïve about computing, you actually think it is not such a big deal. Well, you find out how wrong you are when you migrate to the PC.
The first time I stepped into the PC mess was when I wanted to clean up my disk. Excited about all the free downloadable goodies (and baddies) I had collected quite a set. I had installed these applications in different places on my hard disk and and decided to group them nicely in a folder. As you know, and I do know now, that is a distinctly stupid idea. It is useful, but still stupid because Windows does not want you to do that and in a fight between you and Windows, you find out why many call it “Win”.
Well, maybe that is too much credit; Windows has actually no clue that you moved the application file; the next time it needs the application it will blindly look in the old place and fail miserably with a cryptic message. After having too many of those cryptic message, I decided to reformat and reinstall Windows. I learned my lesson and after that occasion I never cleaned up anymore (My wife sometimes has a problem with this behavior, but fortunately she is significantly more benign than Windows).
So what is this rant doing in an OSGi related blog? Well, there is a lesson that we learned early in the OSGi: installers are evil. This is easy to say, but I will try to make it clear to you. Let us analyze why it became so painful to move these files around on a PC and not on a Mac. On the Mac, an application is a single file (on System X, it is actually a directory). This file is a simple database that consists of the code resources and other resources like configuration files, icons, html pages, properties, translations, etc. Anything that the program needs is stored in this single file. This file is introspective; this means that other programs can inspect the contents and react according to this content. We call these progams/utilities that react to this content extensions. Extensions are extremely useful.
Application files have a special type in the Mac, and this type is recognized by the disk operating system. Whenever you copy or move an application file the OS will track this in an application database. The OS actually looks in the application file's database and finds the information about the files it can open and other useful aspects. Ergo, you can move the applications around as much as you want; the OS just finds them when you need them. It has this genuine advantage that if you trash the application file, you really cleaned up all aspects of that application.
So why does Windows fail so miserably when you move an application to another directory? Well, Windows does not track the applications because it has installers! An installer is an ingenious piece of software that most PC users think is a necessity of nature. It is usually zipped and then compressed after which it is squeezed, requires a lot of thinking, asks you questions you have no clue how to answer or could not care less (fortunately there are defaults), shows lines that you cannot read because they are replaced too quick (which at least gives you the cozy feeling something is happening), splatters files all over your hard disk (sometimes in quite unexpected places), overwrites important DLLs, then spends minutes updating the registry, after which it asks you to read a README file that is incomprehensible until you need it because the application balks at you; unfortunately at that time you have no clue where to find it anymore. And if this all went well, you can run the application. The fact that this is all overkill is demonstrated by Eclipse that has no installer.
You would expect that for security reasons Windows would have a registry of these installed applications, and a way to forcefully uninstall an application. Well, you thought wrong. There is something of a voluntary registry that the installers can fill in if they feel like it. However, the information is not guaranteed by Windows. Worse, to uninstall an application Windows will ask the original installer to remove all the files, remove the registry changes, and generally clean up. The uninstaller sometimes fails because a file is missing or something else is wrong. At such a moment you have an orphan application that likely remains as a bit-squatter until you have to reformat your hard disk. Lots of these orphans can bring that time significantly closer.
When we designed the OSGi framework we were sure that the Windows Installer model was not where we wanted to go; the Mac model looked a lot more attractive. Fortunately, the JAR file model of Java is an even more powerful format than the Mac resource file. The ZIP file format is flexible enough to allow all kinds of application extension scenarios based on resource name and directory. However, due to the security risk attached to running applications we decided to strictly control all the aspects of the installation, update, and uninstallation; all these are primitive in the OSGi, there is no untrusted code involved. OSGi applications (bundles) can normally not move files to odd places and modify all kinds of settings. OSGi applications can declare information in their JAR files and other applications or utilities can inspect this information and act upon it. This is a clear example of Inversion of Control or IoC: “Don't call us, we'll call you!” For example, an application using Declarative Services contains an XML file with the proper setup. When the application is installed the Declarative Service implementation will find this file, the application does not have to register.
This is an incredibly robust model that prevents a lot of abuse and errors. As a simple example, assume an application fails all the time and you want to uninstall it. The fact that the application fails makes it very likely that the uninstaller will also fail. Leaving remnants in lots of places on your system. An OSGi application can always be uninstalled by the Framework. The uninstallation will notify any applications that performed some function on behalf of the uninstalled application. These other applications are in a good state and can therefore cleanup correctly, regardless of the state of the culprit.
The application model of the OSGi has learned from its predecessors and provides excellent characteristics. Most importantly: An overview what you have really installed and a guarantee that you can always throw anything away.No code can run without the Framework being aware of it.
Every time when new groups enter the OSGi Alliance we have the Installer discussion again. Every time people ask me how it can be wrong when Windows does it that way? 100 million users can't be wrong, can they? I leave that up to you to figure it out.
Peter Kriens
The first time I stepped into the PC mess was when I wanted to clean up my disk. Excited about all the free downloadable goodies (and baddies) I had collected quite a set. I had installed these applications in different places on my hard disk and and decided to group them nicely in a folder. As you know, and I do know now, that is a distinctly stupid idea. It is useful, but still stupid because Windows does not want you to do that and in a fight between you and Windows, you find out why many call it “Win”.
Well, maybe that is too much credit; Windows has actually no clue that you moved the application file; the next time it needs the application it will blindly look in the old place and fail miserably with a cryptic message. After having too many of those cryptic message, I decided to reformat and reinstall Windows. I learned my lesson and after that occasion I never cleaned up anymore (My wife sometimes has a problem with this behavior, but fortunately she is significantly more benign than Windows).
So what is this rant doing in an OSGi related blog? Well, there is a lesson that we learned early in the OSGi: installers are evil. This is easy to say, but I will try to make it clear to you. Let us analyze why it became so painful to move these files around on a PC and not on a Mac. On the Mac, an application is a single file (on System X, it is actually a directory). This file is a simple database that consists of the code resources and other resources like configuration files, icons, html pages, properties, translations, etc. Anything that the program needs is stored in this single file. This file is introspective; this means that other programs can inspect the contents and react according to this content. We call these progams/utilities that react to this content extensions. Extensions are extremely useful.
Application files have a special type in the Mac, and this type is recognized by the disk operating system. Whenever you copy or move an application file the OS will track this in an application database. The OS actually looks in the application file's database and finds the information about the files it can open and other useful aspects. Ergo, you can move the applications around as much as you want; the OS just finds them when you need them. It has this genuine advantage that if you trash the application file, you really cleaned up all aspects of that application.
So why does Windows fail so miserably when you move an application to another directory? Well, Windows does not track the applications because it has installers! An installer is an ingenious piece of software that most PC users think is a necessity of nature. It is usually zipped and then compressed after which it is squeezed, requires a lot of thinking, asks you questions you have no clue how to answer or could not care less (fortunately there are defaults), shows lines that you cannot read because they are replaced too quick (which at least gives you the cozy feeling something is happening), splatters files all over your hard disk (sometimes in quite unexpected places), overwrites important DLLs, then spends minutes updating the registry, after which it asks you to read a README file that is incomprehensible until you need it because the application balks at you; unfortunately at that time you have no clue where to find it anymore. And if this all went well, you can run the application. The fact that this is all overkill is demonstrated by Eclipse that has no installer.
You would expect that for security reasons Windows would have a registry of these installed applications, and a way to forcefully uninstall an application. Well, you thought wrong. There is something of a voluntary registry that the installers can fill in if they feel like it. However, the information is not guaranteed by Windows. Worse, to uninstall an application Windows will ask the original installer to remove all the files, remove the registry changes, and generally clean up. The uninstaller sometimes fails because a file is missing or something else is wrong. At such a moment you have an orphan application that likely remains as a bit-squatter until you have to reformat your hard disk. Lots of these orphans can bring that time significantly closer.
When we designed the OSGi framework we were sure that the Windows Installer model was not where we wanted to go; the Mac model looked a lot more attractive. Fortunately, the JAR file model of Java is an even more powerful format than the Mac resource file. The ZIP file format is flexible enough to allow all kinds of application extension scenarios based on resource name and directory. However, due to the security risk attached to running applications we decided to strictly control all the aspects of the installation, update, and uninstallation; all these are primitive in the OSGi, there is no untrusted code involved. OSGi applications (bundles) can normally not move files to odd places and modify all kinds of settings. OSGi applications can declare information in their JAR files and other applications or utilities can inspect this information and act upon it. This is a clear example of Inversion of Control or IoC: “Don't call us, we'll call you!” For example, an application using Declarative Services contains an XML file with the proper setup. When the application is installed the Declarative Service implementation will find this file, the application does not have to register.
This is an incredibly robust model that prevents a lot of abuse and errors. As a simple example, assume an application fails all the time and you want to uninstall it. The fact that the application fails makes it very likely that the uninstaller will also fail. Leaving remnants in lots of places on your system. An OSGi application can always be uninstalled by the Framework. The uninstallation will notify any applications that performed some function on behalf of the uninstalled application. These other applications are in a good state and can therefore cleanup correctly, regardless of the state of the culprit.
The application model of the OSGi has learned from its predecessors and provides excellent characteristics. Most importantly: An overview what you have really installed and a guarantee that you can always throw anything away.No code can run without the Framework being aware of it.
Every time when new groups enter the OSGi Alliance we have the Installer discussion again. Every time people ask me how it can be wrong when Windows does it that way? 100 million users can't be wrong, can they? I leave that up to you to figure it out.
Peter Kriens
Add a comment
| Previous Posts | Archives |
|---|---|