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.
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.
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.
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.
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?
Dozens, huh? And you're telling me the all just worked? Bullshit. Oh wait, I bet this is where you say something like "excluding bugs" or "I only had to do a few tweaks to make it work." Or some qualifier like that. You've never had to backport a program or fiddle with getting a package you want from one distribution to work on yours? I dealt with all of it on Linux and it SUCKED.
The problem with bundling programs on Linux is that you have to bundle far more shared libraries than you would on OS X because a developer can't expect you to have anything but the most basic libraries like libc. So it is no wonder you have such a lower opinion of bundling. Your experience with it is on Linux, a system that doesn't explicitly support bundling.
We need to know, so that we can tick off the checkbox that says "working in 32-bit". As an old sysadmin, I presume you are familiar with the fact that going from 64-bit to 32-bit can break stuff, just like the other way?
On Linux, yes, but I never had a problem on OS X. That's what I'm trying to tell you.
A harmless bug might suddenly not be so harmless when you change the word-length, you know? Had we used Macs, we would have to do the exact same thing. My point was that unless you actually query the system in some way, it's hard to tell. Seems very seamless to me.
You just went over how you have to use schroot to setup a full 32bit environment and you're going to sit there and tell me that it is seamless? You're being dishonest. When I am developing for OS X, I don't have to maintain two different test enviornments. If I want to test 32bit on OS X, I output 32bit executable. If I want to test 64bit, I output 64bit. In most cases, there's no real need to even make a 64 bit version. I can, if I have reason to (like I actually might need 4+ GB of RAM), but for the most part I can ship a 32bit OS X application and nobody will really notice the difference.
Do you seriously not get just how seamless 32/64bit is on OSX? I guess you wouldn't because it sounds lke you've never actually used OS X.
That would be because you do not know much about how shared libraries work. It is not only disk space that you waste, it is also memory. Oh yeah, sure, it is cheap also
Ok, now you're just being insulting. I know EXACTLY how shared libraries work. NOthing I have said indicates otherwise.
What hoops? You install a program, and the system resolves the dependencies and install what is needed. There are no hoops to jump.
And it works fine, until you want to do something outside the confines of your package management system. On OS X, I can have both. I can use MacPorts for more traditional, open source only, Linux style applications and I can use bundling for everything else. Though I would never expect the average user to use something LIke MacPorts. Even if put a pretty graphical interface on it. Bundling is far superior for end users and it works much better when it is embraced rather than leaving it to developers to implement in their own ways.
Look, it seems you had a bad experience as a linux sysadmin. That is too bad, but you need to get over it if you ever hope to be a decent developer.
As a sysadmin I had a great experience. For servers, Linux is great and I still use it. Package management is great servers. For users... for desktops... not so much. You have to be able to recognize when one size does not fit all. Stop treating desktop systems like they are servers.