Linux is based on text files
Jeremy is putting aside his Mac for 2005, and notes in the process:
“More importantly, the open source software I want to use (vim, emacs, firefox, thunderbird, gaim, the gimp, etc) are all first class citizens on Linux. On the Mac I always feel like they don’t quite belong�they are second class citizens. It’s very difficult for me to articulate why this is or exactly why I feel this way. I’m hoping someone else who’s had this experience can do a better job than I can.”
http://jeremy.zawodny.com/blog/archives/003868.html
I know exactly what he’s talking about. I think it’s because Linux (and unix before it) is based around simple text files. Most things are text files, with the expectation that you can change text files, and that if you change a text file, you don’t have to worry about anything else. In some cases, this doesn’t hold – maybe you have to re-process the text file after you change it – but, for the most part, this is how things work on a Linux machine. The files are self-contained (even if they’re not, there’s still a design sensibility that says that this is the wrong behavior, and they should be).
On the Mac, you’re still carrying around a lot of baggage of non-self-contained files. I’m not a big Mac user (and this is largely why!), but I’m told that this has something to do with resource forks. For as long as I can remember, dealing with files (even just copying a file) on the Mac has been a huge hassle, because you always have the risk that the resource fork will get out of sync. But it’s not limited to that – it’s a whole design philosophy that says it’s okay to put different pieces of the same information in different places. You’re littering my network shares with .DS_Store files, and it’s sloppy.
On Linux, the design goal of the OS is “I’m going to make things easy for you by putting everything that’s related in one place”. This is not necessarily always the outcome, and it doesn’t always bubble up to the applications, but it’s always there in the background as a guiding principle. On the Mac, it’s “I’m going to make things easy for you by presenting you the information you might want in one place, but that’s not how I’m going to store it”. Slightly related to this is the Linux/unix principle of “do one thing, and do it well”, which seems to be completely lost on the Mac.
These applications feel out of place on the Mac, because they grew up in an environment where the guiding principles were different.
(On a slightly related note, “easy” on the Mac is defined by “How Steve Jobs works”, not “How you work”. It keeps coming back to this, but the real reason I don’t use Macs, and most other reasons stem from this same root cause, is that I must click on the bottom right corner of a window to resize it. It’s so frustrating and stupid.)
January 9th, 2005 at 3:49 pm
“On the Mac, you’re still carrying around a lot of baggage of non-self-contained files. I’m not a big Mac user (and this is largely why!), but I’m told that this has something to do with resource forks. ”
This is a bit out of date.
While resource forks are still supported, and used (mostly by older Mac applications), OS X prefers something called a ‘bundle’, which is just a regular folder containing resources which are regular files (or bundles).
GUI applications on OS X are bundles. If you go into an application’s “.app” folder, there’s another folder called “Contents”. Inside that, there’s a folder for Resources (which are just more files and folders) and a folder for executables. Inside the Resources folder you find images used by the application, as image files, and interface definition bundles for the Interface Builder application.
Things like drivers are also stored as bundles, as are some document formats.
The bundle idea comes from NeXTSTEP.
January 11th, 2005 at 8:41 am
To clarify a bit, .DS_Store files are not resource forks of files. They are not data about files themselves. They generally contain view data about the folder they are stored in — what view style (icon/list/column) was selected by the last privileged user who viewed that folder and how that view was layed out (particularly important for icon view, where icons can be positioned). These .DS_Store files are supposed to be created on non-native filesystems (in general, non-HFS Plus) because that that data is still important to the user’s experience and thus shouldn’t get lost — but there’s no where else to put them (to Apple’s thinking). That’s why you see them in your directories.
If I open up my home directory on a Tru64 UNIX system, I see a lot of dot files there, too. I may be annoyed at them, and I may delete them. Deleting some will cause greater consequences than deleting others. Deleting .DS_Store files created by Mac OS X will only affect the view for a directory seen in the Mac OS X Finder.
Resource forks are another issue entirely, as a another poster mentioned, and are there for legacy support of Mac OS classic (9.x and earlier) and applications which were ported from there to Mac OS X. They aren’t widely used today, and Apple has discouraged their use. Still, resource forks were an attempt to do exactly what you’re describing: in the Mac’s dual-fork filesystem, they combined data (the data fork) with metadata (the resource fork) into two forks of the same file.
Bundles, as mentioned by the previous commenter, look like they attempt to get some of the older benefits of resource forks on filesystems that can’t support multiple streams. Bundles are just directories. As such, they are generally as easy to manipulate with as files on the command line, and if you need to edit some of the contents for some reason (a bundled shell script, for example), you can still do it.
Text files are used widely for configuration on Mac OS X. Flat files are used for a lot of options on the pure-UNIX software. Most native Mac OS X programs use XML property lists for configuration of preferences. They are generally stored in well-defined domains that affect various numbers of users: Network (essentially a network group, and little used right now), System, Local, and User. The XML property lists control your experience (your own, and depending on the domain, that of other users on your computer or network group) and are completely editable. As with other traditional text file edits in the system, they can produce results immediately or after some processing (perhaps quitting and relaunching an application). They can also be viewed and/or edited with command line utilities like `defaults.` Granted, the XML plists are not always as convenient as they could be (they can have a hierarchy of options and suboptions, but that can make them difficult to deal with), but they appear to be an attempt to bridge the gap from Mac OS 9’s (resource forked based) preferences files with the flat file UNIX configuration files (with many kinds of formats), without lapsing into a monolithic registry like Windows.
Anyway, Apple engineers seem to have thought about a lot of issues related to this — some of them have posted papers, and some thought is on display in the Mac OS X System Overview doc (free download from Apple’s Developer site) — and where they’ve made compromises, there seems to have been reasoning applied to them. That’s all we can say for any of our choices, I guess, whether we like the outcome or not.
HTH.
January 11th, 2005 at 9:05 am
Thanks for the clarification – these are great comments.
I actually seem to be one of the small number of people who think the registry is a good idea. Poorly implemented, terribly organized, badly handled by the system, subject to corruption, hard to back up – all these are true. But…. they’re all fixable, and none of them changes the fact that a central repository, well-handled, is a decent place to store system, applications, and user settings.
I didn’t mean to imply that .DS_Store files are related to resource forks, just that they’re indicative of an additional layer of metadata that’s not directly in the filesystem, not stored with the application/system, not particularly friendly with other network OSes, and actually kind of frivolous. Personally, I see it as rude behavior for the Mac to add all of these files to my filesystem (I view hidden files by default, so they’re everywhere) for something as trivial as where the icons go. Maybe it’s “critical to the user experience”, but if so, I see no reason why the system can’t store this data in a lookup table somewhere by path. Maybe I’m just being overly sensitive, but this makes it pretty annoying to share files with a Mac on a network drive that’s just for data.
I think that moving to Unix was an interesting, and very good, move for Apple. But I don’t think they’ve fully grokked the minimalism yet.