Related link: http://www-106.ibm.com/developerworks/linux/library/l-ivesr.html?ca=dgr-lnxw02Er…
An excellent interview with Eric Raymond is now on IBM’S Developer Works, but one part in particular cuaght my eye.
dW: In your draft of The Art of Unix Programming, you talk about the Macintosh community and how the Macintosh community is merging, in a way, with the UNIX community. Are there projects where you’re actually seeing that happen?
Raymond: I don’t say that in the book and I wouldn’t put it that way. I would say that the communities are looking at each other’s stuff and beginning to learn some things.
dW: So are there shining examples of this kind of convergence?
Raymond: Well, I have one good one. There’s an audio editor called Audacity that I use as a case study in my book, which I think is a brilliant example of how you take the Macintosh ideas of discoverability and interface transparency and move them into a UNIX environment without losing the UNIX virtues in the process.
dW: The other thing that struck me about your book is that you talk about some of the problems with UNIX design. What do you see as the most pressing problems? And what do you see as the problems most likely to get solved in the near future?
Raymond: The most pressing problems that UNIX has right now, in my opinion, are not technical problems. There are technical flaws and gaps in the UNIX design. These are things that the hacker community can address. These are the sorts of things that we’re very good at addressing over time.
I think one gap that has been repaired quite recently is that file attributes are now part of the 2.5 Linux kernel. I went back and forth on this for years, but I now think that I understand that file attributes are extremely useful for a GUI environment. Basically, the reason is that there is a class of properties — things like “where is this application located on this desktop?” for which you want to be able to associate data with those applications — that have exactly the right semantics for file attributes. That is, they are persistent through user sessions, but not something you want to save in a tarball or export over the wire. And that’s exactly the kind of persistence that file attributes tend to have. So I think that’s one gap. I think we’re going to be able to do things that are equivalent to what the Macintosh resource fork does through the new file attribute feature. …
So Eric Raymond says that meta data or, as he puts it, file attributes, are important. Just as Mac OS X drops support for such meta data. So the Linux community learns this from Mac OS X, but where did OS X learn no meta data from?
So what role should meta data play in a modern OS? Does Mac OS X need it?
metadata is in os x...
os x, does metadata as he describes. you can associate any file or extension with a specific app.
what the old mac did with resource fork, was associating a file (keeping it in the fork) with one app across computers. ie. I could send you a pdf to open in acrobat, and on your computer it would open in acrobat. (given that the resource fork was preserved)
os x, disregards this and opens that pdf in your preferred pdf viewer.
BeOS Meta Data
Rumor has it that we might be getting the BeOS meta data underpinnings in Panther.
Meta data is great, it only sucked on MacOS
BeOS Meta Data
I agree with you that Mac OS X, sadly, should require an extension, or else "switchers" would complain about compatibility. Let's hope that if there is meta data support in Panther it will be compatible with Linux.
metadata is in os x...
Besides, Mac OS X has a neat form of metadata, that allow for the creation of bundles with XML based property-lists... made in a platform neutral way.
Metadata in proprietary format cannot travel too far...
metadata is in os x...
HFS types *ARE NOT* stored in the resource fork. They are stored with the rest of the filesyste meta data, like modification date, etc.
File transfers can be made that will and will not preserve the macintosh specific meta data (independent of whether a file has a resource fork.)
metadata is in os x...
not quite accurate ... Mac OS X still uses the HFS+ metadata to associate files with apps (application binding).. this information is not in the resource fork, but Mac OS X also still does have resource forks, where apps traditionally kept the lists of associated file types and creator codes.. new apps (using bundles) keep the same list, but not in a resource fork.. the whole thing is still portable between machines, though the user can modify the standard application bindings on their own computer.. Mac OS X also adds filename extension binding
in 2001, John Siracusa did an article, mostly still accurate, that goes into this subject in detail at
ArsTechnica
BeOS Meta Data
I disagree that OS X should "require" an extension. If "switchers", or anyone else, want to use an extension it should work fine, but it should not be "required". File exchange on OS 9 could transfer files between DOS and HFS+, adding an extension if necessary. If it's not necessary it should not be manditory.
Compatibility should be maintained by the filesystem, not by requiring users to do it. What if someone wanted to copy a Mac OS X file to DOS? Should we now limit Mac OS X to 8-character monocase file names for "compatibility"?
metadata is in os x...
it is DEFINITELY in OS X. anyone who think otherwise should spend a few days making a really nice iMovie presentation. Then they should copy it over to a hard driveon a fs without metadata support. When you copy it back over (after formatting in my case), have fun manually resetting the creator codes through the command line. Because iMovie will not recognize the files otherwise.