From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 5 Sep 2007 22:06:14 -0700 From: Roman Shaposhnik Subject: Re: [9fans] Re: everything is a directory In-reply-to: <1187974477.312600.39680@r23g2000prd.googlegroups.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Message-id: <3AF73FB8-1056-4903-BE04-9644ECD0B38B@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1187901241.757160.291890@x40g2000prg.googlegroups.com> <1187974477.312600.39680@r23g2000prd.googlegroups.com> Topicbox-Message-UUID: b8f03884-ead2-11e9-9d60-3106f5b1d025 On Aug 29, 2007, at 2:06 AM, jsnx wrote: > On Aug 24, 3:55 am, leim...@gmail.com (David Leimbach) wrote: >> On 8/24/07, jsnx wrote: >>> On Aug 23, 3:35 am, st...@quintile.net (Steve Simon) wrote: >>>> I'am not trolling, I just don't see their efficacy in plan9. >>> I don't see how to architect the system I discussed without >>> attributes. >> Build yourself a file server that provides the environment you >> want with >> attributes... don't inject it into the core system. Store it for >> real in >> fossil files with a certain format. >> >> Done? > > If I want to have a system with the features of two distinct > filesystems, what then? Attributes allow for composition, whereas the > FS oriented approach appears not to. I apologize for coming into the discussion a bit late. But I always wanted to share the following observation: metadata seems to be very confusing to an average joe. And when I say metadata I mean all metadata, not just resource forks and attributes. Time and again I've seen PC users name their digital picture (or at least directories with the digital pictures) _. Why? Well, because even though date and time are part of the metadata in pretty much every filesystem these days it is extremely difficult to make sure that all the tools handle them and preserve them just the way you want it to be (think about the time picture was taken vs. the time the file was created vs. the time it was last updated or even accessed). On top of the constant paranoia (Quiz-1: what's the option for cp to preserve the timestamp?) the metadata approach makes it very difficult to manipulate collections of files. Quiz-2: what's the moral equivalent of doing: $ cp 09_*_2007*.jpg ~/USA_tour if I didn't have date as part of the name? These usability issues with even the most established bits of file metadata such as date, time, owner, etc. show up often enough to make one think of if not abolishing metadata all together, at least not proliferating it any further. > > I would have to write (or obtain) a TeX fs, a SVN fs and then a TeX- > SVN fs if I wanted to have those feature sets independently, if I am > understanding you correctly. The problem you seem to be alluding to is genuine and I'll try to paraphrase it in order to see whether we're talking about the same thing. Suppose you have a collection of leaf-node objects that you can group together in a number of different ways. Suppose also that these groupings are mostly orthogonal to each other. Now, if you express objects as files -- what is the most natural way of expressing various groupings? To make it even more clear here's a practical example: in my build system I have to produce binaries for SPARC and x86 running under Solaris and Linux and each of those binaries either built for debugging or with maximum optimization. My objects are, obviously, files but how am I supposed to structure the groupings? It looks like three levels of subdirectories should do the trick giving me names like: sparc/linux/opt/binary Now, of course, even if we put aside questions like why not linux/sparc/opt/binary, we still have to figure out how to handle the case where the very same physical binary file happens to be a fat binary that can run on both SPARC and x86 Solaris OSes. Where should it go? Should we symlink to it from "the other" place? Questions like these seem to call for tagging and filter filesystems (see my previous question in this very thread). The scariest part is that they also come dangerously close to the oldest argument in the OS design history: filesystem abstraction vs. database abstraction for managing persistent data. Your hypothetical problem seems to fit exactly the same profile: your leaf-node objects are lines (or perhaps even sets of TeX lexems) and the grouping can either be determined based on which SCM delta a particular object belongs to or where it fits in a tree-like TeX document structure. The problem is genuine, and I don't know the right solution for it, but somehow I don't think the metadata would help here. It seems to me that you could be confusing a building block for a proper solution (e.g. tagging) with the solution itself. After all, if I can convince you that extended attributes ARE just a building block it shouldn't matter how they are implemented as long as the end result works properly. And as for implementation -- David's proposal seems to fit the bill perfectly. Thanks, Roman.