Martin Pool's blog

Mail me RSS Bazaar distcc Canonical is hiring! flickr

Hans Reiser interview

Slashdot has an interview with Hans Reiser

There will always be more features that I would like to implement than I can implement. Users and sponsors for the most part want good things to be added, and it is really not so bad to first implement the features that someone is willing to pay for, and hope that in a few years someone else will pay for other features. I take a 30 year perspective on the project, and I have as my final objective the elimination of reasons to not use the filesystem as the unifying namespace of the operating system. That makes for quite a lot of features that I am willing to add.;-) [....]

It is important to be true to oneself. You should maybe understand that some years ago I put the suit my mother bought me into the fireplace along with all my ties. If a restaurant requires a suit and tie, I just don't go there, it is not for the likes of me. If you need some corporately commercial justification for our website design, then let it be that I am willing to be cool and appealing to the younger generation, etc., instead of bland. If a pedagogical justification will work for you, then let me point out that military manuals with their cartoon based approach are far more effective in engaging the reader than the pedagogical techniques employed by most college textbooks. The military is more advanced in its pedagogical technique than the university system, which is really rather amusing, and I think it is due to the greater pretentiousness of universities in this matter. [...]

I predict that in 20 years version control in filesystems will be standard and expected by all users as a basic feature. [...]

This is very interesting. I have never previous thought that version control (as such) in the filesystem was a good idea. I think having some kind of backup/rollback facility as in NetApp is a good idea, and I wrote a very sketchy prototype of that years ago. But version control is so much more that just keeping backups: it implies being able to annotate and label versions, merge them intelligently and so on. The filesystem interface is just not really rich enough to do this, so you need some external support. (So Clearcase does some things through the filesystem, primarily retrieving versions, but most modifications and queries require extra commands.)

After thinking about Hans's comments, I think I would refine that to: the *Unix* filesystem interface is not rich enough to do it. If you could create copy-on-write trees, or attach annotations, or view all edits with a single operation then it might make sense. Being able to directly edit a comment on a version *as a file* without needing to then do some kind of commit operation would be great.

However, the plain-hierarchical filesystem has been remarkably resiliant (or stubborn.) Scores of commercial, academic and hobby projects have tried to replace it with some kind of content-addressible or richly structured database and few or none have been really broadly successful. Probably some large fraction of this is due to technical conservatism, but I think it's also hard to think of a new design that is really generally useful. A plain tree is adequately useful by itself, and allows you to innovate in the application space.

Hans is probably right that making the tree more efficient and flexible is a start though.

Are you sure that it wouldn't be better to hang out in cafes and bookstores for 4 years, and at the end of it write some piece of a filesystem? Cafes, bookstores, and attending random seminars will educate you better, and writing some piece of a filesystem will employ you better.

If only one could get student loans for the purpose of hanging out in cafes and bookstores for 4 years I would have been so happy....

When something becomes stable enough for you to use it yourself without it crashing, and you don't know how to make it crash, you should release it (with lots of warnings). Fortunately, there are people who like to play with technology, and they will help you find its bugs while understanding that it is still experimental code. Each order of magnitude increase in the number of users will find as many bugs as the previous order of magnitude. After some number of years, if you are kind to your users and only do new features on a new branch, the stable branch will get to where months go by and there are no bug reports at all even though there are millions of users.[...]

Linux is an ecosystem, and in this ecosystem there is fast growth vegetation and slow growth vegetation. The fast growth vegetation are the people who took what had already been done by Unix, and without changing its design they copied it while making coding improvements.

Then there are those who look at Unix, err, Linux, and see something just barely begun that needs a complete overhaul. These are the slow growth vegetation. Namesys is slow growth vegetation that got started a long time ago.

Now it is human nature that however a human being is, he is inclined to think that is the right way to be. There are those who think that design does not matter, and one should just make incremental coding improvements. There are also those who think that just coding without introducing fundamental new ideas is unimportant. Both of these sets of persons are fools. To say that one approach is better than another is like saying that grass is better than trees, or trees are better than grass. For Linux to prosper as an ecosystem it must have both.

posted Thu 19 Jun 2003 in /software/people | link

Copyright (C) 1999-2007 Martin Pool.