It turns out that Finlay Dobbie’s problems contributing to Darwin
may not be Apple’s fault after all. However, minors such as Mr Dobbie
can’t enter contracts, such as the
involved with Darwin. Bill Bumgarner describes the
barriers to allowing minors
to contribute, the worst being that the minor’s parents could potentially
require his or her contributions to be removed at a later date.
The law itself is well-intentioned, and Apple desire to protect their
NDAs is reasonable.
It’s unfortunate that they work together to prevent intelligent youth
such as Mr Dobbie from participating. (via
MWJ)
#
Soft links and aliases
Computers generally refer to files in one of two ways. Unix systems
refer to files by their name (often called a “pathname”). For example,
if some software keeps a list of files I’ve worked with recently, a
Unix-like way to do so would be to store a name like “/projects/surfboard/designspec”,
which identifies the file “designspec” in the directory “surfboard” in the
directory “projects”. (In an actual Unix system, there would be a few more levels,
but this is a quick example.)
The other method, used by the Macintosh, involves assigning each file a
unique number when it’s created. The user generally never sees this number
directly, but applications can create “alias records” for files, which contain
this number. We’ll call this number an ID. If the program I described before
used IDs, then it would store the file’s number instead of its name.
The difference between names and IDs might not be obvious, but it has to
do with stability. IDs are stable: as long as the original file, exists, you can
be sure that its ID will always refer to it, even if its name changes. In
contrast, the name is only good as long as every element in the name doesn’t
change. If I rename the “projects” directory to “products”, then the name
“/projects/surfboard/designspec” is no good anymore. Similarly, if I rename
a file and then create a new file with the old name, programs that use
names would try to use the new file, whereas programs that use IDs would
continue working with the old one. Depending on the circumstances, either
behavior may be desired. That’s why a good filesystem should allow for
both methods to be used. (Then, of course, the system has to know whether
users want to refer to a specific file or whatever file happens to have
that name when creating references. The details there aren’t important,
as long as it isn’t done in a confusing fashion.)
Bill Bumgarner describes one way in which
aliases can be annoying:
Every
time I upgrade OmniWeb by replacing the existing copy of the
application with a new copy, the system [Mac OS X] continues to point to the old
version—that it can’t run—that is now in the trash. Once the trash
is emptied, the system reverts to IE. The Internet preferences are using
an FSRef to point to the web browser. Fine; if you move the web browser
app, the system still finds it. However, if I upgrade the app in place
(or anywhere else), the system does exactly what I don't want it to.
According to Mr Bumgarner, Mac OS X should be using
file names rather than IDs to locate OmniWeb. That is, instead of
remembering that OmniWeb’s code is in file #2346081 (say), the system
should remember that its code is at “/Applications/OmniWeb”. That
solves the upgrade problem, but is problematic because it depends on
an unstable reference. If the user needs to move the file containing
OmniWeb, or rename them for some reason, then the reference is lost.
Mr Bumgarner argues that users should not do these things, but
my feeling is that the computer should anticipate modifications to
anything users can modify and still work.
You’ll note that I referred to “the file containing OmniWeb”
rather than just “OmniWeb”. That’s not simply me being pedantic;
the fact is that file names and IDs both refer to files.
Applications exist in a different conceptual area, even though it’s common
to identify them by the files which contain their computer code.
The best way to refer to OmniWeb is to refer to the application itself
rather than the name or ID of the file containing its code. That way,
it can be moved or replaced by a new version without breaking old
references.
Interestingly enough, the classic Mac OS has such a method.
Each application is required to have a unique creator ID, and the system
is able to use it to refer to applications. That’s how the system
implements double-clicking on files: it looks up the creator ID for
the file and then tells the application with that creator ID to open
the file. (Windows operates by looking at the file name and keeping
a list of entries like “open files ending in ‘.txt’ with ‘Notepad’”.
Unix requires you to identify the application whenever you open the
file.)
Unfortunately, the Mac OS creator ID scheme doesn’t deal well
with having multiple versions of the same program available. Furthermore,
since looking up a program by creator ID is slower than file ID, most
references to applications use the latter. Hence, the problems Mr Bumgarner
describes.
As I see it, the solution is for the system to keep an index of all
applications. Software should be able to get a stable reference to any
specific version of an application or to the “current” version. This
would be independent of file name, so users can move application files
without causing problems, and independent of file IDs, so users can
upgrade without causing problems.
#
Postscript: In the same article, Mr Bumgarner describes
a problem where Macintosh applications corrupt data by writing over the
old file but failing to completely rewrite the new file. He proposes
that instead they should write the new data to a new file, and then
rename the new file so that it replaces the old file. That way, there
are no intermediate states when the file can be completely lost if nothing
goes wrong. The error in his argument is the fact that all well-written
Macintosh applications already do something like that, only the routine
used also resets the file ID. If he’s seeing problems where certain applications
aren’t acting correctly, it isn’t Apple’s fault.