A few days ago, I decided to start using NetBSD, as well as Gnome on NetBSD once again, mostly because the lack of their use makes my skills feel rusty in many different areas. While NetBSD has surprised me in a good way (I am running it on a Macbook Pro and things like wireless and DRI work), Gnome has not. There are tons of broken things that prevent a smooth user experience.

One of these broken things is the monitoring of changes in the file system. Actually, this has never worked 100%. But what is this and why does it matter, you ask? Well, file system monitoring is an internal component of the Gnome infrastructure that allows the desktop to receive notifications when files or directories change. This way, if, say, you are viewing the Downloads folder in Nautilus and you start downloading a file from Epiphany into that folder, Nautilus will realize the new file and show it immediately without requiring a manual refresh.

How to monitor the file system depends on the operating system. There are basically two approaches: polling and asynchronous notifications. Polling is suboptimal because the notifications are usually delayed. Asynchronous notifications are tied to the operating system: Linux provides inotify, NetBSD provides kqueue and other systems provide their own APIs.
In the past, Gnome monitored the file system by a combination of FAM, a system-level service that provides an API to file system monitoring, and GNOME VFS, a high-level layer that hides the interaction with FAM. This approach was good in spirit (client/server separation) but didn't work well:

• FAM is abandoned.
  
• Does not support kqueue out of the box.
• FAM runs as root.
  
• FAM is too hard to set up: it requires rpcbind, an addition to /etc/services, a sysctl tweak, and the configuration of a system-level daemon.

To solve some of these problems, a drop-in replacement for FAM was started. Gamin, as it is known, still does not fix everything:

• Gamin is abandoned.
• Supports kqueue out of the box, but does not work very well.
• Actually, Gamin itself does not work. Running the tests provided by the distfile in a modern Linux system results in several test failures.
  

Anyway. Did you notice the abandoned pattern above? This is important: in the new world order, Gnome does not use FAM any more.

The new structure to monitor files is: the low-level glib library provides the gio module, which has some file system monitoring APIs. The GVFS module provides higher level abstractions to file system management, and relies on gio for file system monitoring. There is no more GNOME VFS any more.

The key point is: gio uses inotify directly; no abstraction layers in between. FAM support is still there for platforms without inotify, but as it is not used in Linux any more, it rots. Linux developers will never experience what it is to have a system that needs to use FAM to get this functionality to work.

At last, let's look at the status of all this in NetBSD:

• The FAM package was patched to support kqueue. Although this kinda works, it is not perfect. Also, as mentioned above, FAM is, I'd say, the package with the hardest installation procedure of the whole Gnome platform.
  
• The Gamin packages are nicer than the FAM package regarding their configuration. However, when using Gamin instead of FAM, all sorts of bugs appear in Gnome (it actually gets stuck during startup for me). The breakage of the unit tests does not provide any confidence, and the fact that Gamin is abandoned, the idea of fixing it doesn't make me thrive.
• The glib2 package depends on FAM. This is ugly; really ugly. I had to shout WTF when I saw this, seriously.
• Seeing the direction gio/gvfs take, it is obvious that things can only get worse in the future.
  

If time permits, I'm planning to work on improving this whole situation. Ideas include:

• Splitting the FAM gio module out of the glib2 package. Ideally, this would happen upstream.
• Implement a gio backend for kqueue.
• Check if the core packages still using gnome-vfs have a more recent version that uses gvfs instead and, if so, update them.
  

Can't promise you anything other than, if I get to work on it, I will keep you posted!