|
This article is part 12 of an ongoing series of articles on this site comparing Apple Mac OS X 10.4 "Tiger" to Red Hat Linux Fedora Core 4 (FC4). (The previous article is here.) The point of this comparison is not to say that one OS or the other is "better" but rather to point out the differences and indicate where an artist who previously used Mac OS X 10.4 would find Linux to be easier, harder, or the same to use as the Mac. See the introduction article for more information and links to the other articles in the series. Although the focus of this series is on the needs of designers, artists, and content creators, the content should be relevant to any number of Mac users or Linux users.
Here's an operating system task everyone can relate to: the installation, upgrade, and removal of software installed on the computer. In the context of this article, "installation" means all tasks that are required to make a desired application operational on a computer, "upgrade" means the actions needed to apply patches/fixes/updates/maintenance/etc. to an already-installed application or to replace it with a new version, and "removal" implies the actions needed to uninstall an existing application from a system when it is no longer desired/needed/functioning.
Mac OS X Application Installation
On Mac OS X systems, there are a few different ways an application can be installed. The application might be installed as part of the operating system installation. For example, OS X 10.4 includes Apple's Safari web browser, its Mail email client, and various other applications. The application might also be installed through the use of an actual "installer" program, such as the ones used for the Adobe Creative Suite. The application might be installed using the relatively new "Drag Install" method, where the user simply drags an application's icon from the install disk onto the "Applications" folder on the boot drive to install it. When the application is first launched, it configures itself for its new home automatically. All of these methods are relatively easy and familiar to most computer users except perhaps for the "Drag Install" method, which I've already described here.
The only Mac OS X applications that don't fit the above mold tend to be the open source and freeware applications for the Mac. Some of these must be downloaded in source code form, extracted from an archive, have a configuration script executed, followed by a "make" script to build the source code into object code, followed by a "make install" script that puts the completed code where it belongs and makes sure the system can find it. For Mac users, these are probably the most complicated and frustrating installations to perform. (For Linux users, they are probably the most command and familiar.)
There is yet-another kind of installation possible for those who make use of "Fink", a tool that helps load previously-tested open source applications onto Mac OS X systems. The Fink process essentially automates much of what is described above as being the typical "open source" installation, making it somewhat friendlier to a Macintosh user. Fink attempts to take care of dependencies automatically to ensure a successful build and install, and tries to keep the user's system clean by only installing applications in a special "/sw" directory where all Fink components and Fink-installed applications reside. This means that Fink and the applications it installs can effectively be removed by merely deleting the "/sw" directory and its contents.
There may be other types of installs on Mac OS X, but since the above types account for probably 99.9% of what the typical Mac user sees, they won't be covered here.
For the purposes of illustration, walkthroughs will be provided below for each of the major installation types on the Macintosh, to provide examples of what a Mac user might expect a software installation to "look like".
Mac OS X Application Install Using an Installer
For this example, Microsoft Office 2004 will be installed on an OS X system. The CD-ROM is inserted into the SuperDrive. It automatically mounts on the desktop and displays the following Finder window: 
Double-clicking the "Office Setup Assistant" icon starts the installer: 
The user is warned that administrator permissions are needed to install the software and that virus protection software should be disabled temporarily. After confirming that these conditions are met, the user clicks "Next" to continue. The installer needs the user to enter information for an administrator account under which the software can be installed. After entering the relevant account name and password, the user clicks "OK" to continue installation. 
The user reviews the license agreement and clicks "Next" to install the software. 
The user must click"Accept" to accept the vendor's license agreement or "Cancel" to terminate the installation without accepting the agreement. To continue the installation, the user clicks "Accept". 
The user is requested to supply registration information so that the vendor knows who is using the application. 
The installer provides product identification information to enable the user to obtain technical support later if required. 
The installer allows the user to select the desired components to be installed or left off the computer. After selecting and deselecting components on this window, the user clicks "Install" to continue.
Installation actually begins at this point. As progress is made, the installer informs the user what components are being installed and approximately how close the process is to completion.
Once the components have been installed, the "Finish" screen is displayed, congratulating the user for installing the software and using the product.
Mac OS X Application Install Using a Drag Install Folder
Another common OS X application install method is the "drag and drop" installer. In these installations, the user merely drags an icon from the install disk to their Applications directory and the application is automatically installed (in reality, the installation takes place the first time the application is launched, but this is largely transparent to the user). These types of installs are as simple as copying a file. In the sample below, Netscape Communicator 7.1 will be installed. To begin the installation, the Netscape install disk image is downloaded and double-clicked to be mounted in the Finder. The following window then appears: 
The user drags the Netscape icon from the window onto the "Applications" directory in a Finder window, as illustrated below: 
The Finder begins copying the application from the Netscape install disk to the Applications directory on the boot drive. 
When the file copying is complete, the Netscape icon appears in the Applications directory on the system: 
The user may run Netscape by double-clicking this icon. Doing so will complete the installation and launch Netscape for the user.
Mac OS X Application Install for an Open Source Application (using Fink)
The "Fink" system attempts to make open source software more accessible to Macintosh users by repackaging it such that it can be almost automatically installed from the command line. A separate but related tool named "Fink Commander" provides a GUI to the Fink package installation process, making it even easier to install applications available through Fink. For the purposes of illustration, the "fontforge" (font editing) application will be installed using Fink. The user launches "Fink Commander" which displays a window similar to the following: 
The user clicks the package's name in the Fink Commander window to select it, then right-clicks and chooses "Binary -> Install". 
Fink then begins downloading the application's binary file and any dependencies it requires, installing them automatically in the "/sw" directory: 
Fink requests administrator authentication before continuing to install the software. As the process continues, Fink will encounter parts of the process where input is required from the user. When this happens, it will display a dialog box similar to the following:
To determine what information Fink is looking for, the user must look at the bottom of the window, then enter the relevant response in the dialog box. Once installation is complete, Fink Commander will show the software installed on the user's system. 
In this example, the application failed to install on the user's system. Had it installed properly, the column to the left of its name would have indicated "current" as the status for "fontforge". Based on the information at the bottom of the Fink Commander window, the user can troubleshoot why this install failed and take steps to correct it.
Mac OS X Application Install for an Open Source Application (Manual)
For the purpose of this example, the open source application "man2web" was downloaded and extracted from the tarball into the directory "/man2web-0.88". A Terminal window was launched while logged in as root and the "cd /man2web-0.88" command was used to switch to that directory. Viewing the "INSTALL" document in this directory indicates that to build the application on Mac OS X, the user must enter the "configure" command as follows:
root# ./configure --bindir=/Library/WebServer/CGI-Executables/ --with-distro=macosx
checking build system type... powerpc-apple-darwin8.2.0
checking host system type... powerpc-apple-darwin8.2.0
checking target system type... powerpc-apple-darwin8.2.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... no
checking for mawk... no
.
. <lots of lines snipped here for brevity>
.
config.status: creating src/config.h
config.status: linking ./src/section_h/generic.h to src/sections.h
config.status: executing depfiles commands
The configure process completed successfully. The next step would be to "make" the source code into object code:
root# make
Making all in src
make all-am
if gcc -DHAVE_CONFIG_H -I. -I. -I. -DCONFIG_FILE=\"/usr/local/etc/man2web.conf\" -g -O2 -MT man2web-cmd_opts.o -MD -MP -MF ".deps/man2web-cmd_opts.Tpo" \
-c -o man2web-cmd_opts.o `test -f 'cmd_opts.c' || echo './'`cmd_opts.c; \
then mv ".deps/man2web-cmd_opts.Tpo" ".deps/man2web-cmd_opts.Po"; \
else rm -f ".deps/man2web-cmd_opts.Tpo"; exit 1; \
fi
.
. <lots of lines snipped here for brevity>
.
Making all in doc
Making all in man_sources
make[2]: Nothing to be done for `all'.
make[2]: Nothing to be done for `all-am'.
make[1]: Nothing to be done for `all-am'.
With the "make" command completed, the "make install" command installs the compiled objects into the appropriate places on the system: root# make install
Making install in src
/bin/sh ../helpers/mkinstalldirs /usr/local/bin
/usr/bin/install -c man2web /usr/local/bin/man2web
make[2]: Nothing to be done for `install-data-am'.
Making install in check
.
. <lots of lines snipped here for brevity>
.
make[2]: Nothing to be done for `install-exec-am'.
make[2]: Nothing to be done for `install-data-am'.
Based on the output, it is determined that the software installed into the directory "/usr/local/bin". The application is tested to ensure that it works:
root# cd /usr/local/bin
root# ./man2web rsync
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<style type="text/css">
BODY {font-family: arial, helvetica, sans-serif; }
SPAN.bold { color: navy; }
SPAN.underline { color: purple; }
A:link {color: blue; text-decoration: none; }
A:visited {color: blue; text-decoration: none; }
A:hover {text-decoration: underline; }
</style>
<title>Man Page Lookup - rsync
</title>
. . <lines snipped here for brevity>
.
30 Sep 2004 rsync(1)
</pre>
</body>
</html>
Based on this output, it is easy to see that the application has compiled and installed successfully.
While this example gives the impression that compiling all open source applications on OS X is as easy as running the three typical commands (configure, make, and make install). That is not the case, especially if the open source application makes use of a number of different libraries. For example, installing the Inkscape application from its source code is an extremely involved effort. It's necessary to install a Perl module and at least a half-dozen additional libraries, some of which are extremely difficult to identify and download. This is because OS X doesn't include many of the libraries that Linux contains by default.
Linux Application Installation
Linux applications tend to be installed in one of four ways. Either the application comes bundled with the Linux distribution, in which case installation is no more difficult than clicking a check box during the installation (and perhaps not even that much effort), or the application requires the user to "untar" it from a "tar" file, or it requires a "manual install" where the command line is used to configure, compile, and install the application. The final method involves packaging utilities like Red Hat's "RPM" and others, where the package manager attempts to ensure that all dependencies are resolved during installation. (There are probably several variants of these methods, but the basic actions are similar, so those variants won't be covered here.)
Most Linux applications probably install using the "manual install" method where the user runs a "configure" script, followed by "make", and "make install" to get the software put where it belongs. Additional steps may be needed, such as editing the PATH environment variable or editing parameter files. As noted earlier, while Linux users are probably quite familiar and comfortable with this approach (and in reality it's NOT that hard to do), this is probably the least familiar and least comfortable method of installing an application for a typical Macintosh user.
The "package manager" method is probably closest in operation to the "Fink" process in Mac OS X. Just as Fink attempts to make sure the user's system contains all the relevant components before installation, the Red Hat Package Manager (as one example, there are others) attempts to ensure that dependencies are resolved before the application is installed.
To allow comparison with the Macintosh installation methods discussed earlier, walkthroughs of the major types of Linux software installation methods are provided below.
Linux Application Installation Using a Tar File
One common method of Linux application distribution is the "tar" ("tape archive and restore") file. The compiled and ready-to-run application is stored in a "tar" file, which is a compressed file similar to (but different from) a Stuffit Deluxe file on a Macintosh or a "ZIP" file on a Windows PC. After decompressing and extracting the application from this archive, it is ready to execute. From the Nautilus file manager, this is as easy as right-clicking the file and selecting "Extract Here". The application may then be executed by double-clicking the program inside the extracted folder. This method is, in some ways, comparable to the "drag install" method on Mac OS X.
Linux Application Installation Using the "Manual" Method
For this example, Scribus 1.3.1 will be installed from the source code available on its web site. The source code was downloaded and saved to the desktop in the following file:
This file was moved to the root ("/") directory using Nautilus. From there, a terminal command was used to unpack the source code:
Once the tar process completed, the source code was available in the "scribus-1.3.1" directory. Switching to that directory and listing the files, it is clear that the typical "configure" script is present and therefore should be executed first:
The configure script runs for quite a while, making sure that all the components necessary to build Scribus 1.3.1 are indeed present on the system. Sure enough, we're missing two that it considers important: "Little CMS" and "GhostScript 8.0". A quick check shows that these appear not to be available through the Red Hat update network, so some additional downloading and installing will be needed.
A Google search reveals that "Little CMS" (a color matching system) can be found at "http://www.littlecms.com/". The file "lcms-1.14.tar.gz" is downloaded to the root directory. The same command used to unpack the Scribus source code ("tar -xvf") is used to unpack this one. Sure enough, this package also follows the typical "configure, make, make install" process. The "configure" step completes without incident. The "make" step also seems to complete without a problem, as does "make install". To confirm that "Little CMS" is now installed, the configure script for Scribus is executed again.
This time around, the Scribus configure script is a little happier. It sees "liblcms" (Little CMS) but of course still recommends that the user install GhostScript 8.0. Google identifies that the current GPL version of GhostScript is available from "ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/GPL/current/". It is downloaded and the same "configure, make, make install" process is followed for it. After several minutes, the process completes without incident and GhostScript 8.1.5 is installed. Again, the Scribus "configure" script is executed.
The "configure" script is now satisfied that everything Scribus needs is present on the system. The "make" script is executed in order to turn the source code into executable code for Linux.
This script takes quite a while to run, but completes without error, so it is time to run "make install" to put the finished software on the system.
This, too, completes without a problem (which is as would be expected at this point). This means that Scribus is now installed on the system. To test it, the program is executed from "/usr/local/bin/scribus"::
Success! Scribus 1.3.1 is now functional on the system.
For Linux users, the above description is nothing out of the ordinary. In fact, all things considered, it's probably a pretty simple and straightforward installation. To many Macintosh users, accustomed to things "just working" for them, it's neither straightforward nor very simple. They would question why it's necessary to run 3 different installers to get one application working. They would want to know why it's necessary to do something to add that application to the Applications menu, and why it's not part of the installation process. They would wonder how to go about locating "liblcms" when the configure script indicated it was missing, and be concerned that they found the right one, and not some identically named library. This is precisely the kind of Linux management activity that helps to keep Mac users away from Linux. They want installations to be simple and relatively foolproof, with everything taken care of for them. So, for that matter, do Windows users. (Personally, I don't find this process to be a big deal unless the number of dependencies I need to download and install exceeds about 5.)
Linux Application Installation Using a Package Manager
For the follinw example, the F4L software (which allows a user to
create Macromedia Flash compatible content in Linux) is installed from
a downloaded "rpm" (Red Hat Package Manager) file. This is the RPM
file (Mac users note that a theme is in use here which duplicates OS X
appearance in application windows. This is one example of
customization not currently possible in Mac OS X but possible in
Linux.):: 
The
RPM file is double-clicked in the Nautilus browser window and
automatically launched by the Red Hat Package Manager. The package
manager scans the information in the RPM file to determine what
dependencies may exist: 
Once
RPM has determined which additional components need to be installed, if
any, it presents a screen similar to the following to the user: 
Clicking
"Continue" will install the package and any of its dependencies on the
system. In this example, the installation process is short enough that
capturing the screen is quite difficult. When it is finished, unless
there is an error in installation, RPM quits quietly and the
installation is done.
The application's executable was
located in "/usr/bin/f4l" and executed successfully, confirming that
installation completed properly: 
Although
in some ways not as "slick" as an installer application on Windows XP
or Mac OS X, the RPM process is quite easy to use and something that a
Mac or Windows user could easily pick up. It is, in fact, much simpler
than the manual method shown earlier (though it accomplishes the same thing). Unfortunately, for a Macintosh user moving to Linux, not all applications are distributed in RPM (or any other package manager) format. Many more are distributed in source code form, because this is in many ways the most "portable" method of distributing an application across the many different Linux distros.
Conclusion - Application Installation on OS X vs. Linux
The vast majority of Macintosh applications (at least the commercial products, which are 90% or more of what typical Macintosh artists use) install via an installer or the "drag install" procedure. That means that Macintosh users are most comfortable with, and most familiar with, GUI-based installation methods. There are probably comparatively few Mac users who make use of Fink or "manual" installation methods, though I suspect that number is growing.
What this means in terms of a Macintosh user migrating to Linux is that they will, at least for a while, be pretty uncomfortable installing applications. That is something which would slow down the "full" adoption of Linux by a former Mac user, or perhaps even prevent it outright. That is not a good thing. However, if a Macintosh user sticks with Linux for long enough, they'll find it is actually relatively easy to install the majority of Linux applications.
The growing acceptance (at least it seems to be growing) of package management tools on Linux for handling software installation is a good sign that Linux is moving in the right direction toward making software installation easier. Unfortunately, it is probably going to be a long time before the majority of open source Linux applications is as easily installed as a typical Macintosh application with "drag install" or a GUI installer.
Updating Applications on Mac OS X
With the exception of Fink-installed and manually-installed applications, applying updates to Mac OS X applications is accomplished in one of three ways (though there are always exceptions). The application may be updated automatically through some sort of auto-update feature (e.g., antivirus utilities, Microsoft Office X) or the user will download and run a GUI-based installer to update the application. For applications that are bundled with Mac OS X, the Software Update tool may update them automatically.
Applications installed on OS X using a GUI installer, drag-install, or manual install are generally updated the same way they were originally installed. Since those methods have been previously discussed, they will not be covered again here.
Updating of a Fink-installed application is slightly different than the initial installation, and will be walked through below for illustration purposes.
Mac OS X Application Update Using an Auto-Updater
The Microsoft Office application includes its own auto-updater which can be scheduled to run automatically on a regular basis or executed manually at any time. To run it manually, the user must go to the Applications directory and launch the "Microsoft AutoUpdate" application. A window similar to the following will appear: 
The user clicks "Check for Updates" and a screen similar to the following is displayed: The user clicks "Install" to install the selected updates. Any updates not desired may be unchecked. After the user clicks "Install", the Auto Updater needs to authenticate the user so that the updates can be applied.
Once appropriate administrator credentials are provided, the updates are automatically downloaded and installed, returning the user to the AutoUpdate screen, which displays any remaining updates available or displays no updates (or a message indicating no updates are available) if none are available.
Updating Applications on Linux
Updating Linux applications can be accomplished in a variety of different ways:
- The user receives updated files in an archive and is provided instructions for replacing the obsolete files with the updated files
- The user receives a new set of source code and performs the typical "configure, make, make install" process to install it manually.
- The application update is distributed and applied using the package manager.
All of these methods are substantially the same as the original application installation procedure, and will not be reproduced in detail here. For a reminder, see the Linux application install procedures earlier in the article.
Conclusion - Updating Applications
With the exception of updating Fink-installed applications, the process of updating applications on OS X is essentially identical to the process for installing them originally. For Linux, with the exception of the "replace the obsolete file" type of updates, application updates also mirror their initial installation procedures. As discussed earlier, however, Mac users are going to be most familiar with the GUI based processes (GUI installer or drag-install) and will find those the most comfortable and familiar ways to update software. This may make them resistant to the more common ways to update applications on Linux. However, they should over time become familiar with the Linux way of doing things (if they stick with Linux) and it should become second nature to them.
Removing Applications on Mac OS X
This is an area where the Macintosh operating system has never really taken a clue from Windows or other operating systems. It's very uncommon on Mac OS X for an application to have an "uninstaller" even though it has an "installer". It's very uncommon also for manufacturers to provide "uninstallation instructions" for their products. Manufacturers would seem to be thinking "Why would you ever want to remove this wonderful product you've paid for?" The answer, of course, is an obvious one. Sometimes an application gets corrupted and needs to be reinstalled. Sometimes it stops working and we need to get rid of it. Sometimes it's an expired trial that is no longer needed. Maybe the application just didn't work. Whatever the reason, that application needs to be completely removed from the system.
Sadly, the most common way to remove an application on a Macintosh, even with the advent of Mac OS X, is to locate that application's directory and delete it. This is unfortunate because many applications drop files on the system in places other than their own folders. Removing the application folder alone does not remove everything the application installed. If the user is lucky (and diligent) there may be an install log that specifies which files were installed and where they were installed, so that they can be manually removed.
Removing Applications on Linux
Linux seems to have learned much of the lesson that Apple didn't learn from Windows. Linux applications often include uninstallers or can be removed automatically through an "Add/Remove Programs" functionality, or they store all their components in a single, appropriately-named directory so that they can be easily deleted. Package management systems often make removal simple, too.
This is one area where Mac OS X users should find at least a little "joy" in switching to the Linux platform. While the availability of uninstallers isn't universal by any means, it is probably a lot more common on Linux than on OS X. That means it should be much easier to keep a Linux system from becoming "cluttered" with old applications no loner needed by the user.
Conclusion - Overall
As discussed above, OS X makes the installation of most applications much easier than Linux does, by providing GUI installation methods. Updating applications is essentially the same process, again implying that it is easier on OS X than on Linux. Removal of applications is another matter, however. Developers are more likely to provide an uninstaller on Linux than on OS X, making it easier to get rid of "all" the components of an application.
Stay tuned for the next installment of this series, which will look at the Spotlight search functionality on OS X and compare it to the equivalent functionality on Linux.
Related Blogs:
Related Links:
|
