Ubuntu's multisearch surprise

Ubuntu's multisearch surprise

FF, OO.o, etc work on Windows because they bundle every dependency directly into the app download. They each maintain private copies of libpng, libjpeg, gtk, etc etc etc.

These libraries cannot be shared in memory and use extra disk space. Who cares these days, right? However, the separate libraries mean that the app vendor must issue a security update if any of the libraries they use in the app suffer from a security hole. Each vendor must update its app(s) separately, since they have private copies of the affected libraries. The poor user has to find out about these updates - or is deluged with hard-to-verify-as-authentic update dialogs from a bunch of different apps.

App auto updates are dangerous when the user has no way to verify that (say) the OO.o update dialog really is from OO.o, not a web page trying to trick them into downloading malware. I've already seen fake Adobe Updater dialogs, so this is far from a theoretical problem. To you or I it might seem fairly obvious how to check, but most users just haven't the foggiest, and tend to either reject all updates (leaving their machine with gaping security holes) or accept them all (opening them to malware risks).

FF works around this by not giving the user a choice. That's fine so long as the updates are trivial, you're absolutely certain they'll never break anything, and the user has the access permissions to actually install the updates. The latter, however, is often an issue in FF installs, and tends to leave users confused.

An OS-provided central secure update channel would help mitigate these issues. Think "Microsoft Update" but with 3rd party providers allowed to subscribe their apps. This would put MS in the implied position of being expected to vet all those updates, though, and they're never going to allow it. WHQL drivers already give them quite enough trouble.

As if the security issues weren't unpleasant enough, there's also the fun of "DLL hell" or "shared library hell" caused by ABI-incompatible libraries with the same soname being loaded into the one executable. This would seem trivial to avoid by bundling all your own libraries, and these days _mostly_ is, but you still run into unpleasant issues with LoadLibrary/dlopen(), user PATH / LD_LIBRARY_PATH settings, etc.

Essentially: Yes, the Windows app distribution model works, but it (IMO) suffers from a collection of annoying flaws just like the Linux distro model. They're just different annyoying flaws.