Messages in this thread | | | From | Hans Reiser <> | Date | Thu, 1 Jul 1999 12:25:43 +0000 (/etc/localtime) | Subject | Re: Summary of how linux can best avoid the need for streams |
| |
Nothing I have said makes it mandatory that you choose to do an open or a create on the directory, or that you use any filters.
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/
| |