Comment ReiserFS and /etc/ (Score 1) 343
First of all anyone who hasn't read the Future Vision for Reiser4 should. From the comments so far it seems like most people are unaware of the main goal of the project, which is too bad because it is probably the most ambitious free software project in existence.
This doesn't really do it justice, but what the project is trying to accomplish is to push a great deal of the functionality of databases into the filesystem. In a better world than ours you wouldn't need a table with keys and values, you could just have a folder (table) with filenames (keys) and file contents (values). The problem is that storage is allocated in large blocks, and so the kind of small files that one would use as values end up wasting enourmous amounts of space. This is the virtue of ReiserFS: it has efficient small file performance. With future version the namesys crew seems to intend to add all the wonderful searching abilities that we would want directly into the system calls.
Ask yourself this, which is less hassle to use, /proc or /etc? Wouldn't it be nice to be able to change your resolution in X with
echo "800x600" > /etc/X11/Resolution?
The general idea is that settings could be stored hierarchically, so that /etc/password, for example would look like this
/etc/passwd/
/etc/passwd/root/
/etc/passwd/root/password => sldk7w9xh3
/etc/passwd/root/uid => 0
/etc/passwd/root/gid => 0
/etc/passwd/root/name => Sir Walter Raliegh
/etc/passwd/root/home => /root
/etc/passwd/root/shell => /bin/bash
/etc/passwd/root/luser/
...
where => is some sort of operator that displays the contents of a file.
Essentially this adds all the benefits of a registry (e.g. you change your password with echo "opensesame" > /etc/luser/password), without adding the complication of a half-assed database (e.g. our friend the Windows registry).
Think for one second about how easy this would make adding a GUI configuration to your favorite program ("You mean I don't have to write a seperate parser for every program"), without, of course, requiring a GUI. It has simplicity, it has elegance, it has closure.
My question for Hans is this: it seems that you have put in place a system to let the filesystem take on all the functionality that I was going on about above, how do you intend to get people to use it? Making reiser a filesystem does add a high level of commitment: users have to reformat their drives, and people writing applications can't really assume that their users will have it, and so will be reluctant to rely on it. Obviosuly it is immediatly useful for in-house projects that can have very specific requirements, but how can we get the rest of the world to switch over?
This doesn't really do it justice, but what the project is trying to accomplish is to push a great deal of the functionality of databases into the filesystem. In a better world than ours you wouldn't need a table with keys and values, you could just have a folder (table) with filenames (keys) and file contents (values). The problem is that storage is allocated in large blocks, and so the kind of small files that one would use as values end up wasting enourmous amounts of space. This is the virtue of ReiserFS: it has efficient small file performance. With future version the namesys crew seems to intend to add all the wonderful searching abilities that we would want directly into the system calls.
Ask yourself this, which is less hassle to use,
echo "800x600" >
The general idea is that settings could be stored hierarchically, so that
where => is some sort of operator that displays the contents of a file.
Essentially this adds all the benefits of a registry (e.g. you change your password with echo "opensesame" >
Think for one second about how easy this would make adding a GUI configuration to your favorite program ("You mean I don't have to write a seperate parser for every program"), without, of course, requiring a GUI. It has simplicity, it has elegance, it has closure.
My question for Hans is this: it seems that you have put in place a system to let the filesystem take on all the functionality that I was going on about above, how do you intend to get people to use it? Making reiser a filesystem does add a high level of commitment: users have to reformat their drives, and people writing applications can't really assume that their users will have it, and so will be reluctant to rely on it. Obviosuly it is immediatly useful for in-house projects that can have very specific requirements, but how can we get the rest of the world to switch over?
