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 313054
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: some ideas for refining
by Thom_Holwerda on Tue 6th May 2008 10:24 UTC in reply to "some ideas for refining"
Thom_Holwerda
Member since:
2005-06-29

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:
2006-01-29

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