Bundles means multiple copies of shared libraries. This has 2 implication: 1. the libraries cannot share memory pages and 2. security updates are not applied across the board, meaning that security updates are cumbersome to apply.

Some shared libraries are copied, but since OS X is a predictable base system, you don't actually have to bundle most things. And the things you do bundle are likely not used by anthing else anyway. So they're non-issues. I used LInux for 10 years and I'll tell you, bundling eliminates so much hassle. Packages are fine for the base system, but user applications need to be much more flexible. Most Linux distributions are just big monolithic beasts where every damn application is tightly coupled with the next.

So it might look like a good idea to someone who doesn't know much about the subject,

Yea... not quite the same.

Only poor developers only depends on included shared libraries, and yes, the remaining libraries could be reused. You are just making excuses for a crude system.

If you think that base and included libraries are sufficient for any real work, you are not a very good developer. You will be taking much longer, with a lot more bugs, than if you used existing libraries extensively.

I'll take a system that puts user experience ahead of developmental purity, thanks. No excuses necessary.

I'm sure it depends entirely on what I'm writing. Most software out there can rely on base and include libraries. And when they can't, they can just bundle what they need at very little real cost to the user. The trick is to provide a sufficiently robust base .Something that LInux has utterly failed to do. So it is understandable that you might not think much of "base" systems.

It is OS X that puts user experience over developer (OS X developer) convenience. Automatic dependency resolving is some work, which you sidestep by bundling. Bundling costs the user, in terms of security and in terms of performance (esp. less memory). That is why they have never been popular in the Linux world. Of course, both of these are sneaky problems, which only eats at you in tiny nipples.

If you have a huge base, you will be dragging along crap for a long time, because any library you put in the base has to be supported forever unless you want to break contract on that base. And any libraries accumulate cruft, stuff that wasn't designed as well as should be, or rested on assumptions that at no longer true.

I have dozens of proprietary programs on this computer, mainly games. None seem to have a problem. The package management system doesn't get in the way, like you seem to think. It is very easy: You bundled all the shared libraries you need with you program, stuff in the some directory (./lib is popular), and add a LD_LIBRARY_PATH=./lib to the launcher. And no, this is not something the user does, it is something the developer does, just like the developer might create a deb package, or installshield package, or whatever OSX uses. See, it's all in your mind?

They've never been popular in the LInux world because Linux users have typically been willing to deal with the extra adminitrative overhead of package management and lack of proprietary software. But Linux users are not typical users and they never will be.

You don't need a "huge" base. You only needs a sufficiently robust base., which you have with OS X. You're speaking in purely theoretical terms. Open your eyes. OS X is a nice system to use and work wth.