Though great advances in Linux Desktop usability have been made in recent years, one rather large area of difficulty still exists, posing some serious issues on the ease-of-use front. There is, however, a little-known solution to these problems...Introduction
Many Linux users spend quite some time at a GNOME/KDE desktop. These modern graphical environments have improved the standing of Linux as a desktop OS remarkably over the past few years. They are able to make the system easy to use for newbies and can also allow experts to simply get on with their work without the DE getting in the way.
One of the most notable features of these modern desktop environments is their ability to connect to remote computers for the purposes of accessing files. These files could be on Windows shares, FTP servers or SSH accounts, for example. The desktop environments provide a way to access them just as one would access the files on our local machines... or do they?
While it's true to a large extent that these subsystems - know as Virtual Filesystems (VFS for short) - provide some pretty nifty features, my experience of them has been made fairly miserable for a number of reasons, which I hope to describe to you now. My experience lies mostly with GNOME but I have had similar issues with KDE when I last used it (which was some time ago; so please forgive me for any errors). As it happens, the points I'm about to make are fundamental design issues relating to VFS layers in general and are not aimed at any particular desktop environment.
What's Wrong with the popular VFS implementations, then?
You would be right to ask this question, given that I've just explained how useful a VFS can be. The answer comes down to how the VFS subsystems that are in use have been implemented, rather than the principles behind them.
Have you ever accessed an FTP site via Nautilus (your home directory on a server, for example) and wondered why you can't move files you own to the Wastebasket (instead you have to delete them directly), or see the same types of information in the properties dialogue box as you do for files that live on your desktop machine? How about being told that OpenOffice.org can't open a file on an SSH share you mounted, despite GNOME/Nautilus being able to see it? Why can Totem play files from a remote music library but XMMS can't? Some of the answers to these questions are "because the underlying file service can't support X, Y or Z", however, that's not always the case. Sometimes, users are left wondering why they can't open a file that, to them, clearly exists right in front of them on their screen. This is how the problems of modern-day VFS are made visible. The power users amongst us may know what the problems are caused by and how to fix them, but that doesn't help someone who's accustomed to easier-to-grasp OSes from being totally confused and maybe even unable to do their work effectively because they don't know a way around the problem.
The main issue is that the code which runs the VFS is implemented at the wrong layer in the system. By this, I mean that the VFS is usually implemented too far away from the kernel of the operating system, alongside the high-level desktop infrastructure. This means that they can't provide facilities to programs that run "lower down" in the system - and that's where most of the problems are caused. This will, hopefully, be made clear very soon through some examples.
*Side note:* One of the reasons for their implementation at such a high level is that the desktop environments they're part of, being portable, need to rely on common underlying software to function. Different OSes provide different ways of accessing remote filesystems and that can cause trouble for porting the software. However, there is a solution available for Linux which could be cloned in other OSes and, hopefully in your opinion after reading this, should be used where possible. Anyway, back to the problems caused by the VFS being implemented at the wrong level...
The Problems Caused
Here I'll explain a few situations in which you may have experienced problems with a VFS and explain why this is the case.
*Totem can play remote music but XMMS says "file not found":* This is a common situation and occurs with more programs than just music players. The problem is that Totem, being part of GNOME, has been linked to the GNOME-VFS library, which provides remote file operations for GNOME apps. XMMS, however, has not - so even though Nautilus can see a file on your other box, XMMS can't because it doesn't know how to talk GNOME-VFS. I've also had this type of error whilst trying to open an OpenOffice.org document over a SSH connection to a remote home directory - though I believe the OOo team is working on GNOME-VFS support for the next release, it begs the question "Surely not every app has to provide specific support for every VFS (i.e. separate support for GNOME, KDE,...)?"
- "LUFS, Page 1/2"
- "LUFS, Page 2/2"
