Re: reiser4 plugins

[David Masover <ninja@slaphack.com>]

Horst von Brand wrote:
> Kevin Bowen <kevin@ucsd.edu> 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.
> 
> 
>>>>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.

One filesystem that exists right now.

/proc, as people have made clear, was originally implemented on *one* 
"non-standard" Unix.  Others then copied it.  I see no reason why if 
/meta is a good idea, and programs start using it, that other FSes won't 
implement it.

> Plus exactly the same
> stuff to work on sane filesystems.

"sane" -- I assume you mean "traditional".

Well, yeah.  So?

How big a program do you need to create a new interface to an existing 
system?

Consider:  BitTorrent has at least three interfaces that I can remember 
at the moment.  btdownloadgui.py, btdownloadcurses.py, 
btdownloadheadless.py.

Are you saying that btdownloadgui.py was so much work if you start from 
btdownloadcurses.py that there should be no GTK library, because it 
takes so much work to convert existing curses apps to GTK?

Remember, even if I have GTK installed, I can still get to my curses 
apps, and they may not even know that GTK exists.  Even if I have /meta 
enabled, I can still use my POSIX apps, and they may not even know that 
/meta exists.

>>       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...

Linux over POSIX, I think.  Because Linux is big and open-source, not
beacuse POSIX is so great.

> 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.

I agree with that, at least.  But Linux is also what it is today in 
large part because "I don't need $FEATURE, so it should be kept out" 
isn't a particularly good argument either.