Hans
Richard Gooch writes:
> Hans Reiser writes:
> > Richard Gooch writes:
> > > Hans Reiser writes:
> > > > Richard Gooch writes:
> > > > > Hans Reiser writes:
> > > > > >
> > > > > > I am not saying put an FS into a file, I am saying make the filesystem
> > > > > > effective enough that nobody needs to create things like structured
> > > > > > storage. Given that as a goal, what is needed?
> > > > >
> > > > > I don't even concede this goal. In some cases "structured storage"
> > > > > inside a file is quite reasonable and efficient.
> > > >
> > > > We disagree.
> > >
> > > I've seen it work. I don't claim it's the best general solution. But
> > > it can and does work in some circumstances, and is favourable to using
> > > directories.
> >
> > I don't understand you. I advocate using directories not streams.
> > You advocate what?
>
> I advocate putting albods/data forks/streams/what-have-you into
> separate files in a directory, and making no changes to the kernel or
> libc. That means the default behaviour of the kernel, libc and system
> utilities is that a directory-based albod is just another directory.
>
> Other (optional) behaviour can be added on top of this.
>
> > > > > NO! This is a terrible idea. The low-level tools *must* provide raw
> > > > > access. This higher-level grouping of data belongs in the GUI.
> > > >
> > > > So you are saying that from an ascii terminal I should not be able
> > > > to access these things?
> > >
> > > No, I didn't say that. What I'm saying is that the most common user
> > > who wants to see albods as atomic is sitting behind a GUI.
> > >
> > > Command-line users who want to see albods as atomic can use some
> > > special tools, or perhaps switches to existing tools.
> >
> > Microsoft integrates features of the gui into the kernel, you
> > advocate integrating features of the kernel into the gui, sigh.
>
> I advocate putting features that don't belong in the kernel/libc
> somewhere else than the kernel/libc.
>
> > All aspects of naming should function completely independently of
> > the gui. They are orthogonal OS components.
>
> Keeping things out of the kernel doesn't mean you can only have them
> in the GUI.
>
> > > But absolutely no way should the kernel/libc translate directory-based
> > > albods into pseudo-files.
> >
> > I don't understand you, except that I think you know how you have
> > seen it done, and think that the way it has been done must be the
> > right way.
>
> You're being offensive.
>
> > > Sure. But I wonder how well it would be received in the developer
> > > community, compared to a plain library that provided the functionality
> > > on top of the existing raw interface?
> > >
> > > I personally would not want to use such a system. I would however be
> > > quite happy to use a GUI that makes things "easier", and some new
> > > command-line tools or switches to existing ones.
> > >
> > > You might win over GUI users, who would never notice the difference.
> > > But power users will curse you. Actually, being Linux they'll develop
> > > their own scheme :-)
> >
> > Power users will love it. If I implemented it only in the gui, then
> > I would have only gui users who can use it.
>
> I'll say it another way in an effort to make it clear. Put your albod
> code into a library. Then write some new command-line tools, or extend
> existing ones (as an option), to make use of this library. Also get
> the GUI writers to use this library (again, an option should be
> provided).
>
> This way, *everybody* can see the cooked format (albod pretends to be
> an atomic object like a file), and *everybody* can see the raw format.
>
> If you stuff around with the kernel/libc, you make it hard/impossible
> for people to see the raw components (real files in real directories).
> I can't stress enough how wrong that would be.
>
> > > But I really think any scheme that tries to pretend (at the lowest
> > > levels) that directories are file is flawed. Not only does it
> > > introduce complexities and compatibility problems, I fundamentally
> > > think it is a *less* convenient approach.
> > >
> > > Sometimes, you really want to get in at the raw interface and play
> > > with things.
> >
> > I suppose that when I introduce database style views (think
> > clearcase, but clean), you'll really hate that....
>
> I'd first like to see some clear explanation of why such a view should
> be imposed, rather than made optional through some new utility.
>
> Regards,
>
> Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/