Re: reiser4 plugins

[Horst von Brand]

Kevin Bowen <kevin@xxxxxxxx> wrote:

[...]

> > So, for instance, if I want to grab all mp3s with Artist "Paul 
> > Oakenfold" and change the genre to "techno" (can you do that?), I can 
> > use Beagle's search tool to find all mp3s by Oakenfold, but to change 
> > the genre, I have to use some separate tool to manipulate id3 tags, 

> Yes, this is basically what I was getting at, although I was thinking
> more in terms of the reiser5/6/whatever set theoretic semantics, which,
> from my point of view at least, reiser4 is simply the first step towards
> building the enabling infrastructure of. But the fact that reiser4
> semantics + trivial shell scripting enables, as illustrated by David,
> the rough equivalent of set-theoretic semantics, demonstrates how
> reiser4 is in fact a step in this direction.

I don't see any "trivial shell scripting", just need for a plethora of
magic extract-this-or-that-metadata programs. Which can very well work
exactly the same on independent files, no need to shove junk /into/ the
indexed files.

> > > moment the case of system-wide or network-wide shared data,
> > I.e., something like 90% of the use of Linux here. OK.

> 90% of *what* exactly? 90% of what machines deal with, or 90% of what
> humans interact with?

Both. Most use here is in computer labs, where most is shared via NFS
(readonly), plus user data mounted read-write.

> > > users needs. In fact, I believe there is currently a JSR in 
> > > progress to develop a more sophisticated Java packaging model.

> > Presumably based on ReiserFS 4, which then has to be ported to 
> > whatever platform you want to run Java on ASAP? Great for you! Wait a
> > bit, and you'll get what you want then, even across the board!

> No, obviously that's not what I was saying. But the need for these kinds
> of domain-specific packaging/metadata formats, each requiring their own
> tools to work with, would be alleviated if there were simply a more
> powerful filesystem semantic.

*Please explain HOW*!! The domain-specific formats /will/ stay (if nothing
else, because the /domains/ have /specific/ needs), the special tools to
work with them /will/ have to be written exactly the same (because of the
above). All for use on /one/ non-standard filesystem. Plus exactly the same
stuff to work on sane filesystems. The kernel is *not* a magic piece of
software that solves the problem of world hunger if you just can figure out
what strange extension to force onto Linus' kernel version.

>                               Clearly forcing reiser on the world is a
> non-starter, but try extending your imagination a little bit to a future
> in which there's a 'new POSIX' specifying a set-theoretic filesystem
> model.

Sorry, I just don't see any need of shoving Oracle into the kernel. It
leads a quite confortable life in userland.

>        So-called 'database-filesystems' ARE coming, whether from
> Microsoft, Apple, or us.

IBM did it, long ago (AS/400 and OS/400 ring a bell?). And is now slowly
moving away from it (and other structured filesystems), AFAICS, towards
(guess what!) POSIX and Linux...

Again, Linux is what it is today in large part because "We have to get
$FEATURE, because if not, $COMPETITOR will win on us!" arguments have no
traction.

>                          Who gets there first will determine who gets to
> make the rules.

So what? Let /them/ make the mistakes and pay for them, and learn how to do
it /right/, even if later!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/