Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Posted Aug 8, 2009 15:33 UTC (Sat) by MattPerry (guest, #46341)In reply to: Ubuntu's multisearch surprise by ikm
Parent article: Ubuntu's multisearch surprise
> that what you get there is essentially a precompiled binary. Untar it and
> run it.
Right, so why is Ubuntu shipping that binary rather than leaving it up to the user to get it for themselves?
Posted Aug 8, 2009 17:25 UTC (Sat)
by ikm (guest, #493)
[Link]
Posted Aug 10, 2009 0:35 UTC (Mon)
by ringerc (subscriber, #3071)
[Link] (1 responses)
If there's a security hole in libpng, on a distro-shipped app all you need to do is update one package. If you're using vendor-supplied packages you need to find out which of your apps are affected and manually update them.
Why not share a common libpng, you ask? Well, in the case of libpng that's not unreasonable, but not all libraries have strong API/ABI compatibility guarantees. One app may need version 1.1 and another needs version 1.2.
OK, so parallel install the libraries. Sounds ok, right? Well, it does until you realize that the 1.1 and 1.2 libraries are _both_ linked into one process via a 3rd-hand library dependency, and everything falls in a heap. To work around this you need strict symbol versioning, and even then it's far from reliable.
I see two ways to tackle app distribution. One way is for the app to be completely self-contained, including all dependencies not part of the OS its self. This results in bloated installs (lots of duplicate libraries and data), security problems, app compatiblity problems ("DLL Hell"), memory bloat (DLLs/shared libs can't be shared in memory between different apps) and all sorts of other issues. If some rules are very strictly followed it can work, as Microsoft Windows proves. Ever packaged an app for Windows, though? It's not fun. Coding for the platform is also more complex: you must, for example, never assume that other DLLs are using the same C runtime as you, so you can't free() memory they've malloc()'d or vice versa, you can't pass a FILE* between DLLs, etc etc.
The other way is to ensure that the OS has a way to provide all dependencies in a central way, so apps don't carry them at all. To make this work practically the OS has to be responsible for app packaging and installation too, as it's hard to guarantee perfect compatibility of all libraries across distros especially given the problems with multi-versioning. This means that the app user is somewhat dependent on the OS to provide updated versions, but allows the OS vendor to ensure app compatibility and stability, eliminate shared library conflicts, etc.
I don't think either approach is "right" ... and personally, I wouldn't mind seeing improved distro compatibility in package formats, package names, etc so a package could be produced that'd reliably install on multiple distros. Sometimes, though, the package simply _couldn't_ be installed due to library versioning conflicts, so you'd still have to maintain a couple of versions or start bundling your libraries.
It's not a simple problem, and all the current solutions kind of suck.
Posted Aug 10, 2009 6:29 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Aug 10, 2009 10:02 UTC (Mon)
by dunlapg (guest, #57764)
[Link]
Re the "middleman", I definitely feel like the "middleman" is a feature. Look at all the crap that Windows users end up installing because there is no middleman! Because there's no one vetting the software and making sure that it's up to snuff, each individual piece of software wants to at least install its own update-checker and its own useless piece of junk in your status bar, if not its own spyware. With Ubuntu, they can have a reasonable policy across the board for that stuff, and as a result, my Ubuntu desktop is always more clean and usable than my Windows desktop. Even with the current "spyware" issue, I trust Ubuntu a whole lot more than I trust all those random "application providers" that might want to install who-knows-what on my system.
As someone else has already pointed out, Google and Mozilla both know everything that Canonical would know anyway. And after taking some business classes, I can sympathize with wanting to understand what your users are doing so that you can serve them better. (Asking is of limited use, because only certain kinds of people answer, and even when they answer, it may not be representative.)
My main concern is that new versions of Ubuntu not end up like a new Dell box, packed full of junk that I have to un-install before it's remotely useable. That's one of the things that I *really* appreciate about Linux distros: not having to deal with random junk.
Posted Aug 21, 2009 21:25 UTC (Fri)
by sigra (guest, #57156)
[Link]
...using wget I assume?
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
you build your own copy, because FF relies on some patches that were
rejected by upstream. And FF ships NSS because, um, they were shipping NSS
many years before any Linux distros were using it for anything else at all
(and a good few still don't: its only real advantage is certification
stuff, and if you don't care about certifications GnuTLS has a far less
ugly interface and OpenSSL is faster).
Ubuntu's multisearch surprise
Ubuntu's multisearch surprise
to the user to get it for themselves?