Re: The argument for fs assistance in handling archives (was: silent semantic changes with reiser4)

[Horst von Brand <vonbrand@inf.utfsm.cl>]

Spam <spam@tnonline.net> said:
> Dave Kleikamp <shaggy@austin.ibm.com> said:
> >Spam <spam@tnonline.net> said:

[...]

> > You're missing the point.  We don't need transparency in all apps.  You
> > can write an application to be as transparent as you want, but you don't
> > need every app to to understand every file format.

>   No, but not every user "can write an application" either, or even
>   have the skills to apply patches. What I was talking about wasn't
>   just tar, which itself isn't the best example anyway, but the idea
>   that users can load plugins that will extend the functionality of
>   their filesystems. That idea seem to be to be _much_ better than
>   trying to teach every user how to write applications or patch
>   existing ones.

Why compare "write application or apply patches" to "load plugin"? It
would be locical to compare running applications with loading plugins (and
even so, loading plugins is presumably root-only).

[...]

> > There are userland tools that deal with hundreds of file formats. Use
> > the tool you need, rather than try to have the kernel do everything.

>   No, but if I wanted to have an encryption plugin active for some of
>   my files or directories then why should I not be able to? I still
>   want to edit, view and save my encrypted files.

Use an editor that knows about encrypted files. Decrypt/edit/encrypt if no
other option (I'm sure emacs can be coerced to do that transparently ;-). I
for one would be _way_ more confortable with my users doing that than them
loading random modules into the kernel. Besides, if one of my users doesn't
trust the system encryption programs, and prefers hers, she can be happy.

>   Again, this was just an example of what could be done with plugins.
>   It is not said that every conceivable plugin will be written, nor
>   loaded per default. Even though plugins cannot today be dynamically
>   used, they will be eventually. Reiser4 is still very young.

Modules of the kernel were supposed to have all those magic properties too,
until there were nasty races... and it was _seriously_ considered to take
them out. They stayed because they are root-only business, and (un)loading
is rare. FS plugins are kernel modules, AFAIU, and are subject to the same
problems.

>   Please separate your thoughts for specific plugins from those of the
>   idea to have plugins at all.

If you can't find concrete uses for specific plugins, they are the
proverbial solution searching for a problem.
-- 
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