Linked by Thom Holwerda on Mon 5th May 2008 21:00 UTC
OSNews, Generic OSes Ever since I started using computers, I've been baffled by the relative clumsiness of installing applications. Whether we are talking the really old days (launching the Rambo game off a tape), the '90s (running Keen or using installers in Windows 95), or the modern days (still those installers, but now also package management and self-contained applications); it's all relatively cumbersome, and they all have their downsides. I decided to put my money where my mouth is, and come up with my idealistic, utopian method of installing, running, updating, and uninstalling applications.
Thread beginning with comment 313028
To read all comments associated with this story, please click here.
some ideas for refining
by s-peter on Tue 6th May 2008 04:22 UTC
Member since:

I enjoyed reading the article very much and it seems like a good base for building a new packaging scheme. However, there are still some areas that need further work. Some assumptions of the proposed system were also not clear.

The first one is the operating system, is this meant for Windows, OS X (OS XI?), Linux, some other OS, or an entirely new system? For "legacy" systems, the biggest issue of all seems to be providing a migration path from existing software deployment methods to the new method.

The handling of shared libraries, and the necessity of separating user settings from user homes have been mentioned by others. Also, the write-up talks about a single host, but in practice, program and user directories are often shared among several hosts. It is not obvious that the system would work well in such scenarios. More detailed consideration may be needed about what is shared among which hosts and users. Depending on the OS environment, support for multiple architectures may need to be considered as well.

One of the biggest issues is the storing of settings. Supporting multiple versions of a program in parallel, sharing the same set of settings, is a pain in the ass for software vendors. I think that a lot of conflicts would arise from trying to run different versions of Word, Photoshop, or even GNOME2 with the same set of settings.
So if different versions have to share the same set of settings, many software will likely refuse to install without having prior versions removed first. In such case, if you have other software packages that depend on this kind of a package, you're again stuck with dependency hell.

Furthermore, as mentioned in the article, sometimes the user or administrator does not trust a new version of a program. So even when the software supports shared settings, the user may not want to allow it to modify the settings used for the "trusted" version.

One solution may be to store settings for different versions separately, but have the installer generate the new settings automatically based on those for previous version.

Finally, the proposed system also does not seem to support installing programs without system privileges, which is normally possible for most Linux / OSX software and an increasing share of Windows software.

Good luck for working on this new system, and looking forward to hearing about the progress.

Reply Score: 2

RE: some ideas for refining
by Thom_Holwerda on Tue 6th May 2008 10:24 in reply to "some ideas for refining"
Thom_Holwerda Member since:

is this meant for Windows, OS X (OS XI?), Linux, some other OS, or an entirely new system?

It's not meant for any specific system, but you can see my involvement in Haiku and my love for BeOS shining through.

Supporting multiple versions of a program in parallel, sharing the same set of settings

Except, they don't. The whole idea is that the the directory /Settings/User 1/Garden Designer could contain multiple settings files for multiple versions - just as I explained in the article. They would be differentiated by their internal version numbers. The file manager could show them as follows:

/Settings/User 1/Garden Designer/settings.xml:438
/Settings/User 1/Garden Designer/settings.xml:439

The same goes for the programs:

/Programs/Garden Designer.bundle:438
/Programs/Garden Designer.bundle:439

The idea is that the system is clever enough to only display the internal version number when there are actually multiple versions installed. Since installing multiple versions is most likely an expert endeavour only, normal users will never encounter such internal version numbers attached to their program bundle files.

Finally, the proposed system also does not seem to support installing programs without system privileges, which is normally possible for most Linux / OSX software and an increasing share of Windows software.

Installing Linux packages without system privileges? Some exotic Zero Install systems may be, but other, more conventional package systems all require system access (as far as I know).

Anyway, executable code should never be able to be installed without a system password, if you ask me. I'm quite strict in that, I know. Executable code is the basis for A LOT of attacks, so it simply shouldn't be something just any user can dump on the system.

Edited 2008-05-06 10:31 UTC

Reply Parent Score: 1

RE[2]: some ideas for refining
by s-peter on Tue 6th May 2008 14:24 in reply to "RE: some ideas for refining"
s-peter Member since:

Thanks for the clarifications. And sorry, I obviously somehow missed the paragraph about multiple setting files.

I still have some things to add...

Multiple versions

I don't agree with having multiple versions being an unusual case that "normal users will never encounter". In fact, I think that the ability to have multiple versions of the same software side-by-side might be one of the most sought-after features in program management.

Not being able to have multiple versions side-by-side is what keeps a huge number of users at businesses and many at home stick with older, often outdated software. Many people won't upgrade unless they are absolutely certain that they can do the same things with the new version as they used to do with the previous. And with most existing systems not allowing to use multiple versions side-by-side, there is usually no way to make sure.

So I'm confident that users will install multiple versions when the program management system allows it. This is even more needed for systems with multiple users. In such case, the migration of all users may take longer, and so the time frame when multiple versions are installed side-by-side becomes longer. Note that company and school systems with large numbers of "normal" users fall into this category, where multiple versions would be available for extended periods of time.

Actually, in the utopistic program management system where multiple versions can exist side-by-side without conflicts, there should be no need for the user to explicitly uninstall previous versions. Old versions out of use could be removed automatically in a time-machine-like fashion. (In practice you should consider removing them sooner for security reasons.)

Installing with user privileges

Several other comments have mentioned this as well, so this also seems to be a sought-after feature. (This may also be related to the reasons above, e.g. some user wanting to use Firefox 3 on the company/school etc. system where Firefox 2 or maybe 1.5 is installed system-wide.)

I have to mention that when I said "installing" I was referring to software deployment in general, not one specific deployment framework. For example, I can download an archive ("bundle") of Eclipse for Windows, Linux or Mac OS X. For each OS, I can extract it in my home folder ("install") and run it from there. This does not require administrator privileges ("system password"). (For Linux, installing other applications in home folders may require tweaking with paths, but for most programs it is possible.)

Note that from that user's point of view, after it has been installed, such an application can be used in the same way as a system-wide one, the only difference is that it is not available for other users.

With a clean framework as the one described in the article, it should not be difficult to add support for enabling this kind of installation for all bundles. (As suggested by others, they could be put under "/User/User 1/Programs" instead of "/Programs", for example.) Doing so would reduce the amount of user actions required for such installation, allow automatized upgrading of all software a user has installed, etc. It does not make the system more vulnerable, compared to when the user has to do all these steps manually. Finally, it would also reduce sysadmin load as users who weren't able to install by themselves would not need to ask the admin anymore.

Reply Parent Score: 1