posted by Thom Holwerda on Mon 5th May 2008 21:00 UTC

"Filesystem layout"

Filesystem layout

The filesystem layout is actually remarkably straightforward. I hope I can keep this paragraph short, because that would mean it reached its goal - to be self explanatory. The raw data:

/System
/System/Utilities

/Users
/Users/User 1
/Users/User 2
/Users/User 3
/Users/Shared

/Programs

/Settings
/Settings/User 1
/Settings/User 2
/Settings/User 3

There are two main themes behind this layout. The first is to separate the base operating system files from everything else, and tuck them safely away in /System. This directory contains the kernel, drivers, resource files (f. ex. icons), preference panels, and so on. I also took a cue from Mac OS X by creating the specific /System/Utilities directory, where the operating system can store utilities such as the Activity Monitor, graphical Bluetooth tools, Network Utilty (graphical ping, whois, etc.), those sorts of things. What does and doesn't go into that directory is fairly arbitrary, and is open for debate. Other binaries that usually reside in /bin on UNIX systems can also go into /System (say, something like /System/Binaries, since this is the 21st century - why use unclear acronyms).

The second theme is the separation between between /Programs, which carries the actual self-contained program directories (program bundles), and /Settings, where the program bundles can store their setting files in user-specific directories (f. ex. /Settings/User 1/Garden Designer - the name must be the same as the program bundle's name). The idea is that these setting files are more or less human readable (preferably in a standard format, shared by all programs), so that advanced users can modify them by hand. An added benefit is that people can share settings files with one another, which might help in troubleshooting scenarios.

To prevent the mess Mac OS X has with separating settings files from the program bundles, the system should somehow 'know' the two belong together - this shouldn't be too hard to realise. One option would be to use BFS-like attributes; the Garden Designer settings file could have an attribute attached to it that links it to the Garden Designer application bundle, for instance. This way, when you want to remove Garden Designer from your system, the system can ask you if you want to delete its settings files too.

The /Programs directory contains all the, well, programs. Unlike most other systems, the programs themselves will be distributed as program bundles, analogous to applications on RISC OS and Mac OS X/NEXTSTEP. This way, possible uncommon dependencies can be shipped within the program bundle itself, to prevent the idiotic situations where users of Linux are confronted with having to download and install a whole batch of gibberish that will only confuse them.

This still leaves one question unanswered: how are we going to manage all these applications? Wasn't one of my points of criticism on Mac OS X, in the introduction, that it lacked a centralised method of updating applications? Indeed.

Cue BFS-like attributes and live queries.

Table of contents
  1. "Introduction; Privileges"
  2. "Filesystem layout"
  3. "Harold Kelley would be proud"
  4. "The beauty"
e p (4)    69 Comment(s)

Technology White Papers

See More