Linked by Thom Holwerda on Mon 5th May 2008 21:00 UTC
Thread beginning with comment 313041
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Call me stoopid...
by Loki_999 on Tue 6th May 2008 10:29
in reply to "RE: Call me stoopid..."
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.




Member since:
2005-07-06
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..