Re: reiser4 plugins

[mjt@nysv.org (Markus Törnqvist)]

On Wed, Jun 29, 2005 at 01:19:12PM -0400, Horst von Brand wrote:
>> What pisses me off is the fact that Gnome and friends implement
>> their own incompatible-with-others VFS's and automounters and
>> stuff.
>Then get them to agree on a common framework! They are trying hard to get
>other parts of the GUI work well together, so this isn't far off in
>wishfull thinking land.

Looking at the situ with devfs vs udev, which should have been clear
ages ago, I don't think this will easily happen.

What would a gnome developer say if I told him to bugger off,
for the storm front of ivman is approaching?

Having the mount system in userspace makes sense, it's implemented
and done.

Having metadata in some database chunk in userland makes less
sense. For something that handles files and directories already,
it must be easier to patch them to look at the assorted meta
stuff inside the data object/file-as-dir.

>> Surely supporting this in the kernel and extending the LSB
>> to require this is the best step to take without infringing
>> anyone's freedom as such.
>
>Right. So then we have Gnome's way of doing things (Gnome isn't just for
>Linux!), KDE's way, XFCE's way, ... (ditto). Plus the kernel way. Flambee
>with a monthly thread on all reachable fora about "Why on &%@# does the
>%&~#@ GUI not use the *#%&@ kernel's way?!".

Sure it's not "Dictum, factum" but having the kernel team bless
an extended VFS which allows for metadata in any given FS is
a significantly bigger thing than a pissing contest between Gnome,
KDE and XFCE.

Gnome not being only for Linux, well, make the official stance that
the userspace VFS part is deprecated and to be used only on non-conforming
systems.

I haven't really used Gnome in long times, but if I have a picture
and Nautilus shows me a thumbnail of it, doesn't the thumbnail live
in a metadata VFS in userspace?
That's a lot less usable than an in-kernel solution, where
a serialized file can be sent to a conforming system or just
the most important, or wanted, part of the file to a non-conforming one.

That's the one thing all distros and managers and all have in
common, the kernel.

>This is /not/ the way of fxing that particular problem. Shoving random
>stuff into the kernel /can't/ force its use. At least not until Linux is
>the only Unixy system around, and that is still some way off. And when that
>has happened, the kernel's way must be /clearly/ better for /all/ users, or
>it won't matter.

No use in making bigger deals of other Unixes on which Gnome
and friends may run; my opinion and is that Linux should extend 
things further than the tradition so far has been.

Maybe being better than the competitors may include breaking some
rules, changing the playing field, making it more flexible.

And the file system, and the VFS, is one of those things that are 
nice to have in the kernel.

On a digressing side note, I found this classic:
http://kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs

"If the kernel tomorrow switches to randomly assign major and minor numbers
to different devices, it would work just fine (this is exactly
what I am proposing to do in 2.7...)"

Apparently there isn't a 2.7 and no solid-enough testing ground
for this either..

-- 
mjt

Attachment: signature.asc
Description: Digital signature