GNOME 2.22 released

Posted Mar 13, 2008 17:52 UTC (Thu) by coulamac (guest, #21690)
In reply to: GNOME 2.22 released by ajross
Parent article: GNOME 2.22 released

Alex Larsson, who principally wrote gio/gvfs, has been the maintainer of the gnome-vfs for
many years and has first hand knowledge of the problems with the earlier API, which, by the
way, was modeled on POSIX i/o calls.

Also, Gnome could not rely directly on FUSE because it is not portable across all the
different platforms.  gio/gvfs gives people the option of using FUSE without forcing it upon
the users or making the i/o operations inoperable on such platforms as Windows.

If you google gio, gvfs or Alex Larsson, you will probably get links to some of his
presentations on the subject.

At any rate, if after some review you still disagree with the design decisions, that's your
prerogative, but your comment that "the authors don't really understand what they're doing" is
grossly unfair.

GNOME 2.22 released

Posted Mar 13, 2008 23:06 UTC (Thu) by epa (subscriber, #39769) [Link] (4 responses)

Platforms such as Windows?  Does GNOME support such platforms?

GNOME 2.22 released

Posted Mar 13, 2008 23:25 UTC (Thu) by ajross (guest, #4563) [Link] (3 responses)

Platforms such as Windows? Does GNOME support such platforms?

Glib and Gtk do, so the requirement isn't specious. There's nothing wrong with portability per se.

But what annoys me here is that we've been here before. Early KDE and Gnome versions had these I/O abstraction APIs to allow tools to use URLs as "files" and everyone agreed that this was a nifty feature. But the APIs were complicated and not universally used, so not every application actually supported the capability. And they were slow for many common tasks. And they didn't support error handling that looked like the old Unix calls, so when things went wrong they did so mysteriously and inscrutably. And they broke the abstraction of a "file" pretty badly too (you can open this string as a "file", but never find it in your chooser dialog, or feed it to a script, etc...).

And the kernel folks saw this, and fixed it by providing a nice way for a userspace process to provide something that looked like a filesystem to other userspace processes. And the Gnome folks announced that they would use it, and I thought everyone agreed that these awful abstraction APIs were going away. But instead, we have an all new abstraction API that we're all supposed to use.

That's just wrong. The lesson of the first round of these things wasn't that they should have been done better, it was that they shouldn't have been done at all at the level of an abstraction API. I/O is the job of the kernel, it's simply too basic a feature to put in a complicated external library. GVFS is going to have all the same annoyances as the older abstractions, because it simply isn't capable of fixing the problems they had. And that lesson appears to have been lost on the Gnome folks.

GNOME 2.22 released

Posted Mar 14, 2008 1:23 UTC (Fri) by drag (guest, #31333) [Link] (1 responses)

Well I would not pass judgement on gvfs until I see how well (or not) it actually works.

Although I find the term 'Legacy Applications' pretty damn insulting considering that means
90% of all applications made for the Linux desktop now and into the future. I mean it's not
like Posix-compatable file systems are going away any time soon or that GVFS will ever come
close to replacing any posix fs.

If their FUSE binding is fast and if it's transparent then it can still be a very good thing.
That is if you drag a file from sftp:// folder in nautilus to the terminal it will put the
proper ~/.gvfs/ path WITH NO EXTRA USER ACTION... Then that would be totally kick-ass. Fonts,
search results, etc etc. It's up to the GVFS stuff to figure out if it should pass the GIO
path or the FUSE path to the application.

GVFS can be a wonderful thing. The concept is so-so, IMO, but if the execution is good then it
will totally make up for it.

GNOME 2.22 released

Posted Mar 14, 2008 4:27 UTC (Fri) by drag (guest, #31333) [Link]

Oh.. And one more thing to keep in mind about FUSE is that current implimentations require
setuid root binaries and permissions granted to /dev/fuse to get it to work. So it's a bit of
a security hole if you want to have locked-down environments.

I don't know how serious it is, but requiring regular users root rights to a kernel interface
in order to use Gnome can't be a great idea when it comes to security.

The ultimate work around for FUSE, I would expect, is to have a daemon in charge of FUSE
mounts and use policykit and dbus to regulate and communicate to the daemon.

GNOME 2.22 released

Posted Mar 17, 2008 14:36 UTC (Mon) by dcoutts (guest, #5387) [Link]

There are a couple reasons beyond portability. One is a standard interface for various kinds
of urls, like http etc. I suppose it might be possible to set this up using FUSE, perhaps
running a FUSE daemon and mounting ~/.gvfs/http or something. The point is that there has to
be a known mapping between urls and local FUSE paths.

Another reason is that not all resources behave like local POSIX files. This is obviously true
of most network resources and it was one of the acknowledged flaws with GnomeVFS that it tried
to pretend that everything was POSIX. I don't know enough about FUSE to know if it helps with
that issue but it would appear on the face of it to be tricky.

GVFS help by providing asynchronous APIs for almost all VFS actions, which again makes a lot
of sense for network resources. I presume with FUSE we must rely on the somewhat limited POSIX
AIO interfaces.