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…
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
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
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,…)?”
*Can’t perform some file operations or see some properties information
for remote file-shares:* This problem arises sometimes when the protocol
used to share/access the files is incapable of performing some
functions, but in honesty it shouldn’t happen much. The protocols in use
today are all capable of doing pretty much every common file operation –
it seems to be limitations in VFS implementations which don’t fully
support some protocols that is causing some of these issues.
*Can’t use cp, rm, mv on remote files:* Because they’re not really
“mounted” in the UNIX sense of the word – the kernel has no idea that
the remote system is being accessed and can’t present it in the
filesystem like any other directory. This is a major annoyance for many
people as they’d like to access remote files easily with tools like the
above and any other console programs such as Vim.
*Desktop interoperation is discouraged:* I’m sure many of you are aware
of the amazing work that Freedesktop.org have done in partnership with
GNOME and KDE (and many other DEs) to give users much more choice and
flexibility in which environment they run and that environment’s ability
to talk to programs written for the others. VFS layers pose one of the
last few major hurdles that face interoperability amongst DEs – as
you’ve seen, they are coded to be DE-specific and all the applications
in a given environment are expected to support that environment’s own
VFS. For KWrite to work seamlessly with files mounted by Nautilus would
require the KDE apps to be given support for GNOME-VFS – not something
that would be very popular (either way ’round).
A Solution to All of these Problems
There exists an Open Source project that provides a solution to all of
the issues discussed above – LUFS [http://lufs.sourceforge.net/]. The
initials stand for “Linux Userland FileSystem”. LUFS provides a way for
code in userspace to provide support for various filesystems. These are
mostly remote ones like ftpfs and sshfs, but could be local ones too.
LUFS contains a very small kernel module that links to a userspace
daemon. This daemon provides the basic infrastructure for
filesystem-specific mounting programs to run on top of. The magic thing
about LUFS is that it allows you to access the remote files, no matter
how you mounted them, as if they were local to your system.
The result of this is that *all* of your programs, from rm to vim and
GEdit to JuK, can see and work with the files automatically, with no
extra coding effort required. Interoperation is guaranteed not only
amongst desktop environments but console apps too! Some examples of use
are that you can open your remote music files in any player, regardless
of which desktop environment you run and/or which media player you use.
You can even stream video over FTP as you watch it! Many options can be
passed to the filesystems you mount to control a lot of their workings
and get things set up to your taste.
And if that’s not enough…
LUFS provides the ability to look at file access in a novel way. Because
anyone can develop a program to mount any filesystem that they like,
some very interesting new uses can result. One example is the Gnutella
filesystem, which allows you to echo into a certain file what you’d like
to search for and marvel as the results gradually appear as files in a
directory below this. You can stream the files from the peer that owns
them without even copying them to your hard disk! Though this may be
impractical for some people, it just goes to show what can be done.
Watching films over FTP or streaming music seamlessly is very fun and
not something that you’d want to give up when you’ve tried it. The LUFS
team say they’re working on such things as httpfs, which could provide
an interesting way to navigate the web…
I hope I’ve explained some of the issues involved in the VFS layer as we
know it. Even if you have not had the problems that I have, I hope I’ve
shown how powerful doing things at the right layer can be and how this
could benefit the whole desktop environment scene by promoting
interoperability and getting rid of a load of repeated code that each DE
currently has to maintain. I see no reason why LUFS shouldn’t be part of
Linux (the kernel) already. If it was, adopting solution like LUFS is
something that Freedesktop.org could heavily promote in the future;
after all it will cut down on a great deal of duplication of code (and
bugs, no doubt!) and should also help everyone use the programs they
like regardless of which desktop environment they use. I feel that
freedom of choice is one of the main things that Free Software should
promote – LUFS seems like a prime example of how to do this effectively.
About the author:
Matthew Atkinson is a Computer Science finalist at Loughborough University in the UK. He is co-founder of AGRIP [http://www.agrip.org.uk/] which is an Open Source project that aims to make mainstream games accessible to blind players. Currently Quake has been made accessible. He also recently set up AGDev [http://www.agdev.org/] which is a community site for accessible game developers. He’s used Linux since August 2002, and has been happily reading OSNews since just before then.
/*Author’s note:* Please be aware that I have no relation to the LUFS project; I simply think it rocks and deserves some publicity :-)./
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.