4 ms·
The versioned share library is interesting. But another concern to "non-installation" method is that some "lazy" programmers failed to keep the library they use
by liuliu 18y ago
The versioned share library is interesting. But another concern to "non-installation" method is that some "lazy" programmers failed to keep the library they use update. When there are security issues around the library, usually, the developer of the library will quickly come up with a hot-fix. But Other applications which use the library under their own local folder still expose the potential security backdoor to third party.
- KirinDave 18y agoThe .framework actually can handle this. The xml registry can list versions and version aliases. Maybe you're implying that .app files tend to keep local .framework files inside their bundle. I'm not sure how common this practice is, but one thing that's true about OS X apps is that they're almost uniformly equipped with something like Sparkle (http://sparkle.andymatuschak.org/ http://sparkle.andymatuschak.org/). Most of my apps self update without me even trying. I think that part of 0-install is self-updating.
- wmf 18y agoMaybe you're implying that .app files tend to keep local .framework files inside their bundle. I'm not sure how common this practice is... If your app requires a library that is not included in OS X, you have to ship a copy of that library inside your app bundle. (Or you can use an installer .pkg, but that defeats the point of no-install.) Self-update helps, but the app developer has to actually build the update. There's a tradeoff here between the simplicity and reliability of OS X app bundles and the other benefits of Linux package managers where an app can just express a dependency on a library and that library will be kept up to date globally.