[harshreality]

Updates are not invisible by default because the organizations behind the distros can't provide the same level of assurance that Microsoft or Apple can that update X won't break something.

Average users should have no say in keeping their apps from getting auto upgraded. Linux distros have to track upstream app releases because if they don't there will be breakage eventually. Some app will require a feature added in lib X version Y, and they're still on Y-2. If the packages aren't upgraded, users will complain when they can't install newer packages.

[angersock]

So, you've brought up another important point in the Linux/packagemanager ecosystem:

"Some app will require a feature added in lib X version Y, and they're still on Y-2."

Windows has had this solved for something like a decade. Sure, there's the much lampooned "dll hell", but honestly, Linux's solution was "lol lets upgrade things and break user apps".

There is zero excuse for apps in Linux to have library dependency issues. A package, when downloaded, should have its depended-upon libs and so's tagged. When some other application is updated and pulls in new version of the libs, the first app shouldn't ever see the update. Wouldn't that be nice?

Similarly, having a stable ABI to program against for system calls would be helpful. Users complain when their old apps break, and this is unavoidable under the current Linux development model (see http://primates.ximian.com/~miguel/texts/linux-developers.ht... for a good article on this problem).

[georgemcbay]

Windows has even solved virtually all of "dll hell" via SxS.

Linux distros would do well to implement something similar. Disk space and RAM are cheap, having a few different versions of the same DLLs is no big deal. I don't remember the last time I had a .dll problem in Windows post Vista, whereas I still run into .so issues nearly constantly in Linux distros.

[nitrogen]

Linux has versioned libraries, but distros often ship only the latest versions. Libraries usually have filenames like "liblibrary.so.x.y.z", and an application will link to "liblibrary.so.x.y" or "liblibrary.so.x". Library maintainers also get lazy with making sure that the library stays compatible within major versions, or don't update the .so version properly.

[Drbble]

Perfect username. The problem is that Linux ecosystem doesn't have enough QA backing the amount of new and changing code. The is partly caused by inflated egos of the competing distro teams.

Ingo is wrong about freedom. Freedom is the cause if Linux's problem: dev teams are too free to make compatibility breaking changes and too many alternatives in core desktop infrastructure, so QA can't keep up.

[flomo]

No, there are definitely underlying economic motives beyond ideological "freedom". The only way to make money in the Linux Distro world is to sell 'stability' ala RHEL.

That practically requires that the free teaser product be 'unstable' (and therefore undesirable for paying customers). And the easiest way to do that is a top-to-bottom bleeding-edge system rebuild with each new release.

So it's not just a matter of "not enough QA", because there are very real scalability problems with re-QAing everything every six months to ensure that some random library or compiler flag change didn't break something.

Look at Debian for example - they very much get the idea of "freedom", but they also understand software deployment lifecycles and produce a long-term stable version. (One could argue with their management decisions, but the basic idea is correct.)