Re: reiser4 plugins

[Horst von Brand]

Hubert Chan <hubert@xxxxxxxxx> wrote:

[...]

> Of course.  With file-as-dir, you can "cd /usr/games/tetris/..." and
> mess with the game files, or you can run "/usr/games/tetris" and get on
> with ... stacking blocks.

And doing "tar cf /dev/tape /usr/games/tetris" gives you a nice tangle of
undecipherable junk.

>                            The advantage of doing it in the kernel is
> that you don't need extra support from the applications (or GnomeVFS or
> KDE).

I don't see any advantage here... it has to be implemented, and doing it
in-kernel for one filesystem is /much/ harder than doing it in userland,
where it'll probably work whatever the underlying filesystem is.

Besides, why should the Tetris scores (or icon, or whatever) reside inside
the executable, when said executable is perhaps shared by a bunch of
machines on the network, each of which would like to keep its own? Or
perhaps the sysadmin is terminally paranoid, and mounts /usr read-only
(Hey, the FHS people defined what goes in there with /exactly/ that in mind
too!). 

>        So typing "/usr/games/tetris" from the command prompt does the
> same thing as double-clicking it in the file manager.

Right. And what should happen if I run the (logically equivalent) directory
/home? Or /etc? What if I want to shove a directory into the tetris
executable? Symlinks? Hard links to files inside? Outside? Symlinks from
the outside in? Hardlinks? And if you now move that to another filesystem,
or ship it to another machine? No, the answer "All that will be forbidden"
is /not/ allowed, you want this stuff working "normally". "Unpack" the
contents into real files and directories how? "Pack" a directory into one
of those structured objects? What would be the /practical/ difference
between the packed and unpacked forms? (If none, why do it in the first
place? If the packed version has significant restrictions, why use it? If
the packed version does have significant extra capabilities, why not just
give those to regular objects?)

Yet again, what somebody (I forget who) called the "Zero - one - infinity
principle" (I think it was in the area of programming languages; which
arguably are very complex user interfaces, just like what an operating
system provides): It only makes sense giving zero, exactly one, or how many
you wish for of some item/nesting. Here: Either files got /no/ strange
things inside, or /exactly one/ (and then it becomes questionable, as there
is no space for regular data anymore...), or whatever complex
(sub)structure you want. But in the last case, there is /no/ difference
between a file and a directory... and the whole setup is just mess for mess
sake, nothing else.

>                                                        Of course, this
> change does require file managers to understand default actions when
> it's ambiguous what to do on a double-click -- but MacOS X has that too,
> in the form of the "Open as Folder" option (or whatever it's called).

Right. For the sake of a filesystem among many on a minority operating
system /all/ GUI programs have to be rewritten. And all command-line
stuff. Just because.


Please /do/ think the above through, giving reasonable answers for /all/ of
the operations mentioned. Tell what the advantage of all this would be on a
multiuser operating system, when files are shared via the net, when files
are being handled from read-only media (or filesystems). When different
users want different metadata (I'm interested in the names of members of
the band playing a song, you might want a high-resolution image of the
album cover, the next guy wants the song's lyrics translated into swahili,
all for the MP3s on the shared server or on the CD each of us bought
separately). Consider the scenario where all this works only on /a very
few/ machines (no Sun or *BSD box will have this for a very long time, and
to get a significant fraction of just Linux systems will take some time),
for only a limited selection of tools (existing tools will have to be
rewritten or at least adapted, that doesn't happen overnight). Factor in
space and processing requirements for several, even hundreds, of concurrent
users (or versions of metadata at least). How do you account for that? The
1 byte file with GiB of metadata where everybody and their pet iguana store
their junk is handled how by quota systems? What should happen if I email
such a file with several versions of metadata to someone? Do they get just
my metadata, or everybody's? If I copy it to, say, a CD for safekeeping for
myself? For system backup purposes? What if I copy such a file (with only
my, or everybody's) metadata back from a backup? Or try to merge it with
the version I took with my notebook on a trip, changing my parts while the
otghers change theirs? I'd assume all of those will requiere special tools,
or at least flags selecting the right operation or some other unspecified
magic, and the "simple to use" just went out for lunch.
-- 
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/