OSNews

Beyond the usual software updates and bug fixes, Tiger changes some of the Unix conventions in a very fundamental way. Dave was very emphatic that Apple doesn't implement Unix features just because, "that's the way it's always been done". Instead, they look at the problem and try to figure out the best way to solve it. An example of this is launchd, their complete reimplementation of system daemon management. As Dave says, it's "one daemon to rule them all". They looked at the problems inherent in the current daemon implementation in Unix. These problems include:

• Daemons are started in various places (init, inetd, rc.d, etc.)
• Daemon writers have to go through a lot of work programming work to start a daemon properly (disassociating with the terminal, closing file descriptors, etc.)
• The current model doesn't give regular users a way to run their own daemons easily.
• launch on demand and automatic restarting are not handled very well (if at all).

launchd attempts to address all of these issues. It handles all the 'daemonizing', so you can simply throw all this code out of existing daemons. It's one uniform place to start your daemons, and it includes automatic restart and launch on demand features. Plus, each user gets their own launchd so system and user daemons all work in the same way, and the security issues of one launchd for everyone are avoided.

The examples really illustrated the power of launchd, particularly for launch on demand. One example was the handling of repeating jobs via cron. Traditionally the cron daemon is always running, whether or not there are any jobs to run. Now, launchd watches /var/cron/tabs. If there aren't any files in that directory (i.e. there are no user cronjobs configured) then cron isn't running. When a file does appear in that directory, cron automatically starts running. This feature helps reduce the OS memory footprint as daemons with nothing to do just don't run.

Another big change is in system logging. Apple has introduced ASL, the Apple System Logger. Similar to what they are attempting with launchd, ASL regularizes system logging. All logs are now stored in a database and there are powerful tools to filter and prune those logs. For example, you can configure the system to prune away messages from 'chatty' daemons once a week, while for other quieter daemons you might want to keep the log entries for a month. The ASL filtering also occurs in the program generating the log messages, not in some log filtering program. This reduces the overhead as messages are turned off before they are even generated.

One of the historical annoyances with Mac OS has always been the dreaded 'resource fork'. While other OSes have stored all the data in a file in one stream, Mac OS has always split a file into two stream, data and resource. The resource fork stores things such as program icons and i18n text. This works great when you just use the files on one Mac or trade files between Macs. However, the moment you start trading files with other OSes, problems happen. Usually the resource fork will be silently stripped when the file is transported. The workaround has always been to encapsulate the file in question, for example in a disk image or zipfile.

Now there is finally an 'official' mechanism to deal with this: POSIX Extended Attributes. This is a standardized way to add arbitrary name/value pairs to a file. This is used to support Access Control Lists (ACLs), which will also be in Tiger (based on the Windows ACL semantics). It can also store all the resource fork information. One problem is that tools must be modified to support EAs. Apple believes they have modified all the command line tools appropriately, including cp, rm, and tar. Rsync works with the '-E' switch. CVS is one exception, basically because its just too broken to begin with. This work is a welcome development and will go a long way towards smoothing the interoperability issues between Mac OS and other systems.

Any presentation which deviates from "pure unix" is guaranteed to get a big response in the Q&A portion, and this presentation was no exception. One big demand was for dump/restore on Mac OS X. This is where the Apple guys really emphasized they won't implement a unix solution without carefully considering the best way to do it. In this case their response was that the existing Apple System Restore tool is the replacement. Some of the (somewhat cranky) attendees responded there were various problems with that, including the lack of incremental backups with ASR. The main problem, however, seemed to be that no one even knew that ASR existed.

I discovered at the afternoon coffee break that there was again no coffee! The signs on the lobby said, "Coffee Break" so I was quite confused. Memo to Marriott: if you're giving me a coffee break, there better be coffee. Luckily, again, the Starbucks saved the day.

After the break I attended several short paper presentations. These are limited to 15 minutes and provide a good quick overview of the 'state of the art'. However, I found them to be so theoretical that I didn't get much from them. I then retired to finish this report.

In conclusion, today was a productive day at the conference. The NFSv4 and Mac OS X presentations stood out as excellent examples of the best of USENIX. Tonight I will be attending the 30th Anniversary USENIX reception, where the alcohol and reminiscing will be flowing in equal portions. Stay tuned for the next and final update tomorrow.

About the Author:
Phil Hollenback is a System Administrator at a financial company in Manhattan. When he's not taking care of computers, he spends his time skateboarding and working on his website.

---

If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.

Table of contents

1. "Usenix Day Two, Page 1/2"
2. "Usenix Day Two, Page 2/2"