Kyle recently suggested that ISVs who would like to sell Linux software should, instead of opting for an InstallShield-like product, use the standard package systems (RPM and/or DEB) and the distribution-specific package distribution systems (APT, yum, Red Carpet/Open Carpet, etc.) in order to distribute their software.
While it’s a very good idea to have the vendor provide packages of their stuff (and many do, e.g. Opera Software, Intel, Real Networks, etc.), it’s not quite as workable to utilise the channels for software distribution, since those channels are very much geared toward non-commercial distribution (i.e. free distribution).
Also, Windows’ situation isn’t all that bad. The last few versions of InstallShield have essentially piggybacked on the powerful Windows Installer (MSI) system, and have essentially become tools to migrate legacy installation scripts to it, as have the likes of Wise, InstallAnywhere and the like.
MSI is Microsoft’s package tool whose functionality can be compared to a large extent to that of RPM and deb. In its newest incarnation (version 3.0), apart from dependency tracking, it has about everything its Linux counterparts do, and more. For instance, it’s completely scriptable — while building a MSI package using any of numerous toolkits (either free of charge or not), you can provide arbitrary control over configuration of the package, and like debconf, there is a framework provided to ask the user questions to install features a certain way or configure the package to behave in a certain manner.
Additionally, the Windows Installer service builds a rollback script as it goes along so that if a package installation must be terminated for some reason, it can be rolled back completely, restoring the system to its previous state.
Another very powerful capability it has is to be able to incorporate merge modules into the MSI package. This is how dependencies are handled in the Windows Installer world. The dependency items are placed in Windows Installer components that are merged into the MSI and distributed along with it. At install time, the merge modules check if they’re already installed and if so, they query the Windows Installer to find out what versions of the files are installed. They can then install any newer available versions if need be; these decisions are also fully scriptable. In this manner, a toplevel package will incorporate all the software it depends upon.
msiexec, an installation tool installed along with the Windows Installer service, can take command-line parameters to provide varying levels of status information and prompts to the user, making it easy to do unattended installations, scripted installations and transparent installations as needed. The installation user interface is highly customisable as per the publisher’s need.
The upcoming version (3.0) also has a means to enumerate, apply or remove patches to an installed product as needed. This can allow the Windows Installer to handle quick updates to installed software.
Its biggest flaw is, of course, that there’s no way to specify products this product depends on — it’s assumed that if the products are needed, the scripts provided by the packager will check for them and provide an error, or that merge modules for those products will have been incorporated. Windows Installer by itself will not do dependency checking. (It’s arguable that providing merge modules makes things easier for the end user, who doesn’t need to deal with installing prerequisite items, especially since there is no central dependency-resolving means provided to fetch and install such items.)
As far as commercial package distribution on Linux is concerned, I’m convinced that the current means (place all packages in a central indexed repository and have clients pull them out of this repository) is workable only if all available commercial packages have been paid for, which is almost certainly never the case. In such a situation, we’d need these distribution channels to incorporate means to differentiate freely-available software (available in the repository) from software that must be downloaded from a secure channel (perhaps from the publisher itself) after having undergone a transaction to obtain the privileges to obtain the software, and also to provide this secure channel and a way to securely obtain the single-use key or token that the user software would use to decrypt the software being downloaded from the publisher’s server.
This sort of thing would likely require co-operation between the distribution software developers (open-source guys) and a party that would co-ordinate the commercial distribution channel and the transactions (someone like, say, Ximian).
Both the public distribution/index server and the client would have to gain capabilities, and a private/publisher’s distribution server would have to be written that could tell the index server about its available products, that would provide hooks for a transaction server to receive decryption keys for authorized clients, and that would be able to stream encrypted binaries to such authorized clients.
The distribution/index server would need to be able to tell the client to tell the user what to do in order to become eligible to decrypt the binaries (e.g. visit a certain web site on the transaction server to purchase the product or provide a license key to demonstrate eligibility, etc), and also what server to obtain said binaries from.
The transaction server would need to be able to process the commercial transaction, to be able to contact the publisher’s distribution server to tell it to start a secure session, to obtain the decryption key and to securely pass it along to the client.
The client would need to be able to notify the user that the software is encumbered and to tell the user what to do in order to become authorised, and once the authorisation is complete, in order to contact the transaction server to obtain the decryption key. At this point, the client would contact the publisher’s distribution server citing the session the transaction server started on its behalf, pull down the encrypted binary, decrypt it using the key, and install the software as usual.
Certain publishers would need some form of DRM to be available. The trouble here is that being open source, the client software could not be trusted by the publisher’s server, so this mechanism would not provide a means to install DRM-protected software.
At this point, finally, we would have a capable and powerful universal software distribution system.
I’ve seen some speculation that Ximian might add such commercial software distribution capability to Red Carpet. When this happens, I’d like to see Red Carpet become standardised across Linux distributions (even if this means that on Debian, debs must go away and the debconf framework must be ported to work with the RPM platform, which is certainly capable of utilising such a framework).
I have no doubt that tools like the traditional InstallShield of old are obsolete and on their way out. Even Macrovision themselves believe this, with the advent of the Windows Installer package manager. I wouldn’t mind seeing InstallShield and the like provide tools to make it easy to build RPMs and debs and provide wrappers around them for automatic configuration and the like, though, just as they do for Windows Installer today. This would make software installation easier for the end user and help Linux shed a bit more of its “rough” image.
Ultimately, I’d like one of the software deployment/distribution systems to become commercial publisher-friendly and become capable of handling the distribution of encumbered software while keeping the publisher happy and unifying installation procedures for commercial and non-commercial software.
Where have I been these past few weeks? Busy. First, my parents arrived and stayed with me for much of last week and the week before that. Additionally, work pressures have diverted time away from other activities. Finally, last week, I attended Microsoft’s Tech.Ed India 2004 conference, courtesy of work. It was more of a .NET CLR/CLI 2.0, Visual Studio “Whidbey” 2005 and SQL Server “Yukon” 2005 propaganda session than anything else, but I did win a cheap watch, a cheap T-shirt, a cheaper keychain and their dirty laundry a set of CDs and DVDs carrying Microsoft’s beta software.
As far as the upcoming releases of Yukon and Whidbey are concerned, they’re a major step up from their previous versions. Yukon has had a bunch of performance and programmability changes. It’ll host a .NET CLR to run stored procedures and user-defined functions written using the .NET Framework. It also has improved OLAP capabilities, as well as some new much-needed aggregate and other functions to make things like implementing paging through rows easier and better-performing. Whidbey has better data visualisation now, as well as an upcoming set of tools known as Visual Studio Team System that essentially will include modelling and code generation capability (though nowhere near rivalling Rational’s current products in that field; however, this is tightly integrated with the .NET platform), bug tracking and task management features.
.NET 2.0 and the associated languages have far too many changes for me to outline here. It’s just become somewhat more interesting a platform.
I’m thinking of expanding my computer’s RAM to 768 MB from its current 256 MB. Unfortunately, finding a good deal on memory here is a bit hard. I’ll try looking around sometime next week.
