Posted by: Anonymous
on January 06, 2009 07:36 PM
DOS was single-tasking, single-user, had no inbuilt security mechanisms whatsoever, struggled to use more than 640K of RAM, had no hardware abstraction model and no standard method to implement reusable components. There was no dependency problem to solve!
Ah, those were the good old days...when every single app not only got put in its own self-contained directory. Of course, if you got a new printer and had 5 different applications that used a printer you might have to copy in 5 different "drivers" into 5 different directories, but that's OK. If you got one of those snazzy new "Vee Gee Aye" cards you needed to make sure all your apps supported it, as each accessed the hardware directly instead of through a standard interface, but that's OK too, because who needs graphics when you have such a "wonderful" command line interface and "advanced" scripting language to make those powerful "bat files"?
Heck, sounds too complex to me. I think CP/M had it solved. There was no graphics to speak of, unless you had a dazzler card or something..then you had ONE graphics app...to make pretty pictures...and that was it! No confusing directory tree either--just one nice, flat directory of files--and if you wanted to get fancy you could divide it into USER areas. You could only have what---15 of them, so you didn't need to know names...just put your WORDSTAR files in USER 0, DBASE files in USER 1 and so on, and take a sharpie and write the whole contents of the disk on the vast expanse of the 8 inch floppy dust jacket! Forget about that fancy ZCPR shell too--with all those advanced features like named directories and password protection of files you need a degree it's so complex..gimme the good ol' CCP shell any time!
Times have changed old man. All them young 'uns gotta have their Interweb, and you have to have security if you make it so all computers can talk to one another and so many people can use one computer. They all gotta have their "gooey" screens with little pictures and arrow pointers and mice. They all want "three dee" in their video games (all we had is Pong and we liked it dammit!). These newfangled computers have scads of peripherals to hook in and everyone wants dozens of applications installed, and these whippersnappers have the gall to expect ALL their toys to work with ALL their software! The nerve of them! That's why we have hardware abstraction and drivers that are reusable and *depended on* by multiple applications. With so many apps, and the expectation that they can all run at the same time within the confines of system memory, it made sense to come up with a way to share code in a standard way instead of having everything using different code (or copies of the same code) that do the same thing. Hence ANOTHER dependency after drivers--the shared library.
"Dependency hell" was CREATED out of that demand for "solutions that are simple". DOS computers just didn't do that much--they were solutions to simple problems. When the "problems" (expectations placed on PCs) grew in scope the "DOS way" became unwieldy. Nowadays ALL popular apps use graphics so they ALL need graphics drivers--thus they ALL now depend upon one standard set of shared libraries to handle graphics. Nowadays ALL computers support multiple user accounts and access control, so now they depend on a set of shared libraries and mechanisms for authentication and access control. Sure, it created the problem of "dependency hell" but can you imagine if your video card still needed separate code or "drivers" for EACH APPLICATION that used graphics on your computer? That'd be nuts!
I think this "nix" thing doesn't fix anything--It is a workaround that avoids shared components altogether (in a nonstandard way at that) instead of making shared component management work better. Sure, hard drives and RAM are cheap, but what about efficiency and application interoperability? I don't want to fill my drives with multiple copies of slightly different builds or versions of libraries--I want that space for my data thank you. The headline "Nix solves dependency hell" is catchy but it is untrue--it is merely a tool for *avoiding* the problem, at the expense of the advantages of shared components. As a stopgap to try the odd "black sheep" software it is fine, but it is not optimal as a "solution" that one could, for example, base an entire Linux-based OS distribution upon.
Also, the problem isn't really that bad anymore. Both RPM and DEB based OSes have repositories and package management tools like YUM and apt-get that track dependencies well and even manage updates with ease. If you are content with what is offered within the supported repositories you actually have a software management system notably superior to what Vista offers! And to you Debian fanboys out there--we are in the 21st century. Other package management schemes have caught up, and the devils in the details are either so minor or so technical in nature that Joe User doesn't give a damn...APT/DEB AND YUM/RPM BOTH WORK JUST FINE. Normal users are tired of such VHS/Beta battles, and with Linux we can accommodate both.
The SOLUTION isn't what NIX does, which is try to bring back elements of those DOS days. We need to refine what is out there to allow for cross-distribution compatibility in repositories and packages. LSB has made a valiant effort at trying to be a real solution but it is not a complete solution, as it focuses a bit too much on the dependencies themselves. There are means within package managers of all kinds to determine what package provides library/file 'x' and what packages depend on such a file, and executable headers could include version or build information and what not. There needs to be a distribution-neutral way to handle such "depends-upon" and "provided by" information. It might not eliminate the problem, but it would greatly reduce it, such that a Mandriva user could grab Fedora packages, or whatever.
Remember, "simple solutions" mean simple to USE. Building solutions that are truly simple for users can be tricky and require work. Otherwise, we'd be content with CP/M.