Comments on: Linux is based on text files http://www.aquick.org/blog/2005/01/09/linux-is-based-on-text-files/ entertaining hundreds of millions of eyeball atoms every day Sun, 12 Aug 2012 17:06:22 -0400 http://wordpress.org/?v=2.8.4 hourly 1 By: Adam http://www.aquick.org/blog/2005/01/09/linux-is-based-on-text-files/comment-page-1/#comment-171 Adam Tue, 11 Jan 2005 14:05:58 +0000 /?p=487#comment-171 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. 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.

]]>
By: Histrionic http://www.aquick.org/blog/2005/01/09/linux-is-based-on-text-files/comment-page-1/#comment-170 Histrionic Tue, 11 Jan 2005 13:41:07 +0000 /?p=487#comment-170 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. 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.

]]>
By: Jon Hendry http://www.aquick.org/blog/2005/01/09/linux-is-based-on-text-files/comment-page-1/#comment-168 Jon Hendry Sun, 09 Jan 2005 20:49:24 +0000 /?p=487#comment-168 "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. “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.

]]>