posted by Matthew T. Atkinson on Tue 22nd Mar 2005 18:25 UTC
"LUFS, Page 2/2"
*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...

Conclusion

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.
Table of contents
  1. "LUFS, Page 1/2"
  2. "LUFS, Page 2/2"
e p (0)    38 Comment(s)

Related Articles

posted by Tony Steidler-Dennison on Tue 8th Jul 2008 12:02, submitted by jmalasko
posted by David Adams on Tue 8th Jul 2008 04:28, submitted by snydeq
posted by Tony Steidler-Dennison on Mon 7th Jul 2008 18:13, submitted by jmalasko