"Need?" Maybe. "Dire?" No. Both Macs (and to a much lesser degree, Windows) were both designed to allow applications to be atomized into easier to install "dr

"Need?" Maybe. "Dire?" No. Both Macs (and to a much lesser degree, Windows) were both designed to allow applications to be atomized into easier to install "drag-and-drop" installs. The problem is from those development houses who get too ambitious or too paranoid to allow users to keep their installs in just one folder. (Either they are being too worried about library versions, which is really a red herring, since in the real world, apps can only maintain reliability if they keep they're own copies of the libraries separate from other apps. Or they're too afraid of software piracy to allow apps to be too easily moved.) The classic Mac architecture did things right by having a simple key/value lightweight DB built-in, to allow apps to have all it's components in one file. (Actually two "forks", but that's ancient history.) Even under OS X, the OS provides the "bundle" folder concept to keep an app's state in folder, save for a prefs file. I've worked with package managers like Fink, and they strike me as solving a problem that should not have existed in the first place: Unix's insistence on breaking apps into little teeny tiny pieces strewn over half a dozen directories. It's sad that Windows succumbed to this by the time of Win 3.1, and OS X is heading in this direction too. I miss the time where I both knew what files were on my system, and that the organization was simple enough to do things "manually" without too much technical knowledge. We didn't have to have the current byzantine system of thousands of files in an install; it's not progress, but technological laziness and paranoia to keep the underlying technology complicated enough to cow most end users.