I don't see how this makes it any more convenient on the users than downloading it from upstream makes it.
I compare this to things like installing nginx on ubuntu which comes with files in the places I expect (/etc instead of the configure script default of /usr/local/conf) etc. Packages are actually very convenient for 90% of what I user on my computer.
Ruby and Clojure stuff are the only thing I download and install myself.
See http://www.pathname.com/fhs/pub/fhs-2.3.html#OPTADDONAPPLICA...
That's, more or less, what /opt is supposed to be. QT and KDE used to be "integrated" that way, until distros finally got around to put them into /usr. So, there really is a standardize mechanisms with those uncommunicative packages in the FHS. (Note that the Unix family as a whole does not standardize filesystem layout, even though Solaris also has /opt and uses it for exotic packages such as GNU gcc).
And why do you do this? Because the Debian/Ubuntu packages for these things are old and broken, primarily because they are insistent on breaking up the packages and scattering the files all over the FHS they worship. They despise RubyGems because it installs packages in a self-contained way and lets you install multiple versions of everything without mangling the names. It puts them out of a job.
A way that conflicts with the software management Linux distros use. You can't issue a command and have your system updated and, at the same time, your Ruby environment updated. Introducing some new gem can crash system software written in Ruby and make it impossible for the system management tools to rely on the same interpreter you do.
If you want to install your gems, something like Python's virtualenv is recommended. I don't know if Ruby has one. If I relied on Ruby, I would make sure it had, even if it meant writing C.
I curse the guys at CSW all the time (eg up and changing config directories from /opt/csw/etc to /etc/opt/csw[1]) but they have probably saved me quite a bit of work testing and building packages.
[1]For the record, I think /etc/opt/csw is better, just not better enough to be worth all the hassle of changing.
Binaries tested against what? Obviously the testsuite that upstream uses, but every program will have dynamic dependencies into the distro. In that case wouldn't the upstream maintainers have to test every version or every distro to make sure it works for you? That seems time intensive (not infeasible, but it would become chaotic very quickly when we multiply the number of distros by the number of apps people want).
I'd also presume that the upstream maintainers include their testsuite with their source, so nothing should prevent the downstream distro maintainers from running the testsuite before shipping (I have always assumed they do, I hope I'm not wrong).
If you're willing to take some abuse you can release server software only on RHEL/SLES and desktop apps only on Ubuntu and tell everyone else to fend for themselves.
The crappy webapp you work on, which is described as "like $x but better" probably shouldn't be in existence at all, because we already have $x.
Again, just using Firefox as an example. The same applies to most end user apps, stuff like Java and Flash, etc.
With shared libraries, only one library needs updating. With each package proving it's entire ecosystem, every package on your system needs such updates.
I trust application developers usually to do better tests than distributors. And certainly distributors don't even care about 3rd party packages. I would prefer a system where application developers are responsible for which libraries link against their applications. And a complete different mechanism for security. For example a list of libraries+versions with known security-problems against which shared libs can be tested on start.
And I'm sure there are other solutions, for example searching my system for all versions of a certain library and asking me which to replace (and maybe keep me informed about not-updated versions). Preferably while keeping the old version around for a while to make it easy for me to switch back for the applications which do break now.
It's not like having a single version of a library is the only way security can be handled - it's just the current way of doing things. And one can discuss what is preferably - a secure system which occasionally breaks working applications or insecure applications which at least do work.
edit: Btw., this might even be in the interest of free software. Ever had a problem with a certain library which won't be patched in the official sources for whatever reason? Right now - basically you're fucked. Because even if you patch it yourself, the chances you will get distributors to add a second nearly identical library with 1-2 simply patches is basically zero. So although you have those free libraries with source, it doesn't really matter because you can't change those sources yourself if you still want to be in official distributions. A real free system would be one where changing sources is made easy.
IME, application vendors only test on a few common systems, not across the board. Try running something which isn't common (say a 64bit Linux distribution three years ago), on even with newer hardware. My Linux experience has been with third party packages breaking, not anything shipped by the vendor.
That just sounds like promoting a culture of waste to me. "Do we need to care about resources?" "Nah, disk and RAM are cheap, and our users won't mind paying for more of it."
What happened to elegance, efficiency, and modular, maintainable design? Just because you have a shiny box with 8GB of RAM and a terabyte of space, it doesn't mean everyone does, or everyone should have to.
The difference in disk space or ram taken by apps on an average OSX desktop, and average Windows desktop, and an average Linux desktop seems to be negligible.
I'm not sure you can meaningfully make this comparison since the platforms (at least at the GUI level) are quite different. A better test would be to take a "standard" Linux system, and then create a "bundled" system that has each app in its own directory with all its dependencies bundled with it (perhaps leaving out some of the fundamental ones like libc). A little bit of common reasoning would suggest that memory and disk usage would be affected greatly.
Each app having it's own copy of the libraries it needs is actually MORE maintainable.
It's not uncommon for a newer version of a library to introduce a change which breaks something in your app. One example from my work: we tried building with a newer version of Qt and all our text was suddenly getting rendered upside-down due to changes in how Qt uses OpenGL. If we had been using the system copy of Qt, it would have been our customers seeing this problem instead of our dev team.
There are other advantages too, but to my mind this alone is enough reason to bundle libraries with your app.
I'm a bit surprised that the Qt guys would make an incompatible change during a stable series. Is it possible you were relying on undocumented behavior that was subject to change?
your doing it wrong
What's wrong is the cycle of freezing all the packages for a 'release' and then 'supporting' them in the future by trying to extract 'bugfix' patches from newer versions instead of just shipping the goddamn upstream software.
The answer is rolling releases and a proper slots system — look at Gentoo or Arch.
My point is that on OSX or Windows, installing an application from "upstream", like getting the latest Firefox from Mozilla.org for example, is something even relatively non-technical users can do by themselves. On a Linux desktop, it's a "here there be dragons" operation.
Not to mention that on Windows or OSX, a developer of a relatively small, obscure application (like say, HN favorite Bingo Card Creator) has a standard, relatively easy way to package their application up for installation by end users.
On a Linux desktop that's really damn difficult for both the developer and the end user.
in my experience there is nothing better then having a repo/ppa or even a well built .deb / .rpm, i wish for it every other day for my mac/win boxes.