[marssaxman]

I am surprised to see you compare the OS X and Windows experiences. They seem completely dissimilar to me.

With Windows, it seems like every little thing needs some complex installer procedure that splats files all over the system. Every program needs dozens of DLLs, and the only way to get rid of it is to run an uninstaller that hopefully remembers everything it created, and even more hopefully doesn't break anything else on your machine.

With Mac OS X, there's generally no installation process at all. You download the app, and you put it where you want it to go, and then you run it, and that's it. Nothing goes anywhere and you don't need any special process to manage it.

The experience I've had on Ubuntu is sort of midway between these. There's a complex installation process, and everything has to deal with it, and shit gets plastered all over your machine and there's no way you can keep track of it all, but at least things generally mostly work most of the time.

But really: why manage complexity when you can do away with it?

[vacri]

and you don't need any special process to manage it.

You're speaking of apt/packaging like it's a bad thing, when it's awesome. Want to download a new OSX or Win app? Open your browser, hunt it down, in the case of Win, figure out if you can trust the site, download it, open the downloaded item and do the install dance, and then have it stay sessile on your system, never updated... unless it has its own phone-home system - and now you have more crap on your system.

Want to install a package with package management? It takes literally seconds plus download time. Package management systems are all about doing away with managing complexity.

[schmonz]

If you think OS X's approach has done away with it, you're wrong. Maybe you've found it a worthwhile tradeoff, but flattening each application's dependency tree is still a tradeoff: you get truly independent applications, but you pay for it in duplication, the costs of which are well enumerated in binarycrusader's post. Maybe you mostly don't encounter those costs. Maybe you even believe most people mostly don't encounter those costs. But they do exist.

[JoshTriplett]

Exactly. The "self-contained" approach means I can't just upgrade a library once and have everything using it Just Work with the features enabled (or bugs fixed) by the new version.

[marssaxman]

It's not going to just work all the time. There are so many possible libraries and possible versions of those libraries and their sub-libraries that it is possible, even likely, that nobody in the world has ever tested that precise combination of components before. You don't know whether it's going to work until you try it, and when it doesn't work, it's up to you to figure out what went wrong and fix it. This seems like a monumental waste of time. I would rather use a complete, monolithic application built and tested by the app developer, leave it the way it came, and upgrade it when the app developer has a new, complete, built, and tested version I can use.

[JoshTriplett]

Personally, I'd prefer a library version tested by a huge number of people running a given distribution than one tested only by the developer of a single package.

[brigade]

And the opposite approach means I only need to update glibc once and flash audio is broken.