Christian Neumair a core contributor to the Nautilus and gnome-vfs project for GNOME
detected some critical design flaws inside gnome-vfs and brought up some concerns wether these problems can be fixed at all. He also mentioned that these critical design issues might lead into loss of important data and other nasty things.
Write-Up on GnomeVFS Headaches
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Add this to the list of flaws:
gnome-vfs is completely unorthogonal to the rest of the system.
What does that mean?
http://blog.allanhalme.net/?p=59 It’s explained here.
No one wants to read your damn blog. Either explain it or don’t. Stop trolling for page hits.
If you had something in your head(except air, just my conjecture) you’d probably see that neither the blog is mine nor do I have anything to do with it. When people try to be helpful and do a google search so other people don’t have to ask, you get a slap on the face.
Please don’t take this the wrong way, but that link wasn’t really helpful. It didn’t articulate what the original poster was talking about, and it was rather turgid and a little pseudo-intellectual.
Linking to blogs on the other hand is fine. There’s little value in repeating text unnecessarily.
I just wanted to help… nothing else.
I understand. I’m not certain why your post was moderated down really. If anything his flame would be a better target.
The blog was even more confusing. I understand what orthognality is all about. I just don’t understand why the author states gnome-vfs is unorthogonal to the rest of the system. By “system,” does he mean GNOME. And if so, how is it unorthogonal? Examples would be useful.
That’s more philisophical wanking than you can shake a stick at.
Presumably the original commentor is referring to the overlapping functionality of GNOME-VFS and the system VFS. You can copy and read files within GNOME programs on “filesystems” that you can’t manipulate from the shell, or from non-GNOME programs in general.
Once you realize that KDE and GNOME operate on multiple operating systems with incompatible filesysem architectures, you get over that rather quickly.
I disagree: now that Linux has FUSE I think it would make sense to have a special case for VFS which would use FUSE when available (and still do it autonomously on other OS or on older Linux).
The advantage would be that these VFS would now be accessible through the shell or to non-desktop specific application.
Of course ideally competing VFS such as Gnome’s or KDE’s would collaborate otherwise it would awkward..
If I remember correctly there is a FUSE module that allows to mount KIO slaves, so FUSE and a VFS infrastructure do not make each other unnecessary.
http://sole.infis.univ.ts.it/~chri/
http://kde.ground.cz/tiki-index.php?page=KIO+Fuse+Gateway
This is not news worthy and NOTABUG.
http://mail.gnome.org/archives/nautilus-list/2006-January/msg00058….
Now I wish someone did the opposite i.e. use the FUSE infrastructure to drive GnomeVFS and KIO-slaves.
As FUSE implements its services as file systems, you can use the file:/// access implementation of the two VFS systems.
Of course this way around you’ll loose the remote context. The application won’t be able to supply authentification data, maybe assume that certain calls are fast (stat for example), not be able to supply metadata like referrer/user agent for HTTP, etc
I think a common vfs api is the way to go.
But then it shouldn’t be binded close to the linux kernel. We cannot forget that gnome/kde are used together with other kernels. Like opensolaris, *bsd etc…
This is really something that should be stolen from http. It would be so cool if a program such as ls or nautilus could open ~/some.tar and negotiate a direcory/filsystem representation of it from the OS.
Or for sort to negotiate with the OS to get stdin as XML or other sutiable table representation (in memory DOM-tree?),
1 .To implement it, take the UTI conecpt from Apple.
2. Develop a library(?) of pluggable translators that can be used in pipes or from apps directly.
3. Add semantics to open for the negotiation part (HTTP style?).
The only down side I can see is the problem with lossy vs. lossless translation. Most translation WILL result in a loss of semantics.