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 313036
To read all comments associated with this story, please click here.
Call me stoopid...
by Loki_999 on Tue 6th May 2008 07:04 UTC
Member since:

...but my personal wish is for applications always to be fully self contained with any third party stuff they need contained within the program directory. Sure this would lead to bloat on disk size, but whats taking up more disk space on your hard drive? Those 10Gb of applications or the 100's Gb of MP3s/AVIs?

Im a big game player and i like games which have save games IN the game directory (eg: under \save or \save\profile - for multiple profiles). Saving under My Documents a la Microsofts recommedations gets me really annoyed.

And dont even get me started on saving game/configuration information in the registry. The registry is a bad idea from the start. Whats wrong with .CFG text files?

While i accept the need to consider multi-user systems and privledges im sure self-contained apps could somehow work with this.

Anyway, nice article, even if some ideas need refinement.

Reply Score: 2

RE: Call me stoopid...
by renox on Tue 6th May 2008 08:02 in reply to "Call me stoopid..."
renox Member since:

The thing is if the application is really 'fully self-contained' that this increase not only the disk usage (which we don't care I agree) but also the memory usage (which we do care about!) because a 'shared' library wouldn't be shared anymore as each application would load the version stored in his directory, the OS wouldn't know that these version are identical..

Currently the way I see to fix this is to have a 'delta' phase in the installation where all the 'shared' library contained in the application would be checked against the already installed one, if a shared library already exist in the same filesystem then it wouldn't be installed but it would be hardlinked to the existing one.
Benefit: no disk or memory bloat and the application are still self-contained.
Inconvenient: an additionnal 'delta' phase

The big downside of the 'self-containement' part is that if a shared library must be upgraded then all the application which use it must be upgraded..

Reply Parent Score: 2

RE[2]: Call me stoopid...
by Loki_999 on Tue 6th May 2008 10:29 in reply to "RE: Call me stoopid..."
Loki_999 Member since:

Had this too often with apps with shared components, eg some lib windows\system32. New application breaks old one, or old application breaks new one.

Perhaps this is sometimes caused by bad programming and/or packaging, but it does happen from time to time that two apps require exactly the same named lib that should reside in the exact same location or else it wont work, and those two versions of the lib are not compatible.

Hence my liking of self contained. And besides, sharing only bloats memory of those apps are memory resident/drivers/or simultaneously active. Not going to always be the case.

Reply Parent Score: 2