<
B>File System encapsulation
There are few good reasons for programs to strew files all over your hard drive; since OS Xis release, however, more Mac users have to deal with programs that install in ways they cannot control. In contrast, one of the few great things about older versions of the Macintosh operating system was the practice of encapsulation.
What the hell am I whining about? Itis the Mac OS X equivalent to Windows .dll hell, something about which many Windows users have spent long hours complaining. With versions of the Mac OS prior to Mac OS X, generally, the system and programs were unitary objects unto themselves. Even with programs that comprised many support files, such programs could be contained in totality within a single directory/folder and treated as a unitary item (sans perhaps a preference file or two). Not so with OS X.
Advantages of encapsulation
A unitary object is just simpler to maintain; itis easier to move, back up and restore. In the old days, if your system got corrupted, big woop. Boot with a floppy/CD and drag over a backup of the System Folder and youire back in business. With high encapsulation, you install an application in much the same way; and if problems occur, you just drag over a backup copy–you do not have to run the install program and reinstall.
The spiritual opposites of this encapsulated heaven are found in Windows and Unix. Applications splatter shared libraries and configuration files all throughout the file system, i.e., not all in a single directory/folder specific to just that application. When something goes wrong, or you want to reinstall a clean version of the OS, most people have little recourse but to pursue a moronically tedious scorched earth policy. Format the drive. Re-install the OS. Obtain all patches and reinstall. Reinstall all applications from their CDs; obtain and apply all patches. Then, per application, tediously recreate your preferences. Anything short of this may result in aberrant behavior. Welcome to the world of OS X.
To be fair, OS X is slightly better than Windows (i.e., preferences are maintained in your user directory, which is highly encapsulated/portable as compared to spuriously varying local and global Windows registry settings), but itis still pitiful dealing with OS X. Now OS Xis Unix does complicate things because much of the power of Unix is in employing standards that have been adopted over decades, which all but demand strewn file system hierarchies like "/etc", "/dev", "/bin", etc. And these things are best left in their traditional places to ensure compatibility among Unices. So perhaps a few Unix applications have a good excuse for making a mess all throughout the file system, but Iill argue there is a solution even to this.
Mess making programs
Where some old Unix applications may have an excuse for spewing themselves into every folder across your hard drive, there seems to be little excuse for this behavior from Carbon/Cocoa application developers. Notorious examples include Adobe and Microsoft programs. When you install them, they install files into "/Library". You say whatis the big deal? Well some of the directories in "/Library" are basically system directories that may or may not be upgraded with the next revision of the operating system. What that means is when you do a fresh OS X install, you canit simply back up your old (e.g., OS X 10.2) "/Library" and then copy over the new "/Library" directory (e.g., say in OS X 10.3 when it comes out) — well you cannot do so without fear of obliterating updated functionality in the 10.3 "/Library" directory.
With the "/Library" dilemma you have to make some hard choices. You can try to integrate the "/Library" directory after upgrading OS X with a backed up version of the "/Library." That would set you on a tedious course of picking through that complicated old "/Library" file hierarchy to try and distinguish what files were strewn there by Adobe and which are system files; then you have to try reintegrating the non-system files into the new (e.g., 10.3) "/Library". If the explanation is annoying and tedious, the actual process is even worse. Of course the other solution to the "/Library" dilemma is just reinstalling all the Adobe applications, and re-apply all Adobe patches, which will install support files atop the new (e.g., 10.3) "/Library" directory. Regardless, both of these methods suck and prevent you from simply dragging and dropping file system hierarchies in place like one might have in the pre-OS X era.
If all of this were not bad enough, there is something even worse.
Some lazy programmers actually modify Unix configuration files. Messing with rc.boot files (and its ilk) is begging for trouble as it is responsible for much of the boot up of the machine. Uninstalling those applications is often a crapshoot. Not only do they litter files all over the file system that may not completely uninstall, when you do uninstall them, you may have to hand edit configuration files to get things back to the status quo ante. For the average person, this means itis probably easier to nuke the entire system and reinstall everything than risk messing with these settings. There is no easy to fathom reason for so inextricably altering the system, and perhaps that is why many Apple geniuses will quietly whisper that your system will be more stable without Norton than with it under OS X.
Perhaps the most bizarre and unforgivable party in violating encapsulation is Apple. The Mac OS 9 System Folder is a beauty to behold in its encapsulation and mobility. But with OSX, you are doomed. If you want to do a fresh install, your personal files, application files and system files are intermixed throughout the file system hierarchy. Although Apple does offer an option to install OS X and still preserve your data, this option is far from perfect. Again, if you now ask an Apple genius or any old school NeXT system administrators, they will tell you the best way to system health is via a fresh install.
This wouldnit be so bad if we merely had to reinstall the system and could simply drag over our User and Application directories and get back to work. But it doesnit work this way because some directory hierachies intermix user and system files (e.g., "/Library"). Some have even suggested using a separate drive in which to place a fresh install of OS X and then perform a CarbonCopyCloner operation of that freshly installed OS X drive over and atop your main drive with an older version of the system. If you donit understand the above procedure, donit fret about it. It doesnit work reliably either. It doesnit work for some of the same reasons, i.e., if you have applications that modified Unix configuration files, CarbonCopyCloner will rightly obliterate them with newer ones from the fresh install drive when cloning. Youire left with much the same problems and solutions.
Some solutions
So Iive bitched at length and youire asking, do you have a better solution, smarty pants? Yes I do. Some Mac advocates would like to see all of the Unix directories and system files tossed into a System Folder akin to Mac OS 9. This will not work for reasons of Unix compatibility. So my solution is more akin to the mountain moving to Mohammad. The solution is to set up a directory that will contain all non-system files. To the user this would appear to be their entire world. So on the hard drive root there would be a directory "/MyWorld" and all the Unix legacy directories would remain outside that directory, but invisible. To the user "/MyWorld" would be the root level of the computer where all things happen. This would provide at least some level of encapsulation.
Some will ask what about the Unix programs that need to be installed in set locations. For some portion of them, Apple can modify current Unix scripts to look into "/MyWorld/System/UnixCrap/script-bin-etc-whatever-mods" to see if further and/or modified behavior need take place. This way, modified Unix behavior will not be obliterated with system updates. For Unix applications where this may not work, in the majority of those cases you will be dealing with a technically sophisticated Unix user that knows what he/she is getting into.
What can be done
Complain. Admonish Apple and program developers until they put all their support files in a single directory or app wrapper. Disk drive space is cheap. We donit need shared libraries peppered all over the file system (well outside the systemis shared libraries). There is no need to see an installer program or .pkg file — as soon as I do, I groan wondering where this program is going to litter files on my system. Developers should just dump their libraries and supporting files in an application folder or wrapper, and user files should be placed somewhere in the useris directory.
Here are the good guys
Some programmers will try to blow smoke up your tailpipe by telling you certain complicated programs require such hackery. This is often bunk that glosses over programmer laziness. Programs that do incredibly complicated things well and maintain encapsulation include Virtual PC. Virtual PC actually loads a kext (a kernel extension), which is potentially a problematic activity, on application launch rather than at boot time. Less polished programmers might choose to load kexts by modifying a Unix system script. Virtual PC also contains its resources within its app wrapper and will reset its permissions upon launch if it detects they are incorrect. This makes restoring Virtual PC a breeze–you just copy its icon from your backup drive and youire set. Other good guys include GraphicConverter and OmniGroupis programs, which are installable by simple drag and drop from CD or .dmg files into the Applications directory.
When you aggregate millions of users that lose hundreds of hours of life on rebuilds (and other consequences resulting) from the lack of encapsulation every year, it results in OS X (and naughty applications) causing the equivalent loss of a couple of lives a year. In comparison, I would guestimate that Linux causes a significant number more "deaths" per year seeing as re-compiles and re-builds are almost marks of honor in that community. All of which pales in comparison to the mass murderer that is Windows (Iim ball parking around 10,000+ lives lost to wasted time). Nonetheless, even if OS X claims only two lives a year to this problem, I would argue that is two too many.
John Kheit is an attorney. Please donit hold that against him. This work does not necessarily reflect the views and/or opinions of The Mac Observer or even John for that matter. No assertions of fact are being made, but rather the reader is simply asked to consider the possibilities.