Not really. inotify requires you to set up a watch on every single file or directory that you want to watch. To see how this escalates, install the inotify-tools and do
Kqueue and OS X's file watcher thing are worse than inotify. They give inexact reports of changes, so you have to do a bunch of manual scanning afterwards.
I really don't understand the grandparent's gripe. Inotify scales well, supports race free "watch a whole directory tree", and has a nice API.
There is a per-user limit to the number of inotify handles available (max_user_watches) and the default value is 8192.
The limit exists because there is a ~1KiB kernel memory overhead per watch (though there should really be a way for them to take part in normal memory accounting per-process).
If one wants to watch a directory tree, one needs an inotify watch handle per subdirectory in that tree.
On large trees (or if more than 1 process is using inotify), that number of watches can be exceeded.
As lots of folks are looking for recursive watches, they aren't happy with needing to allocate & manage a bunch of handles when they see what they want as a single item.
That said, I'm not sure the way the kernel thinks about fs notifications internally would allow a single handle recursive watch at the moment.
In any case, the amount of info one can obtain by using fuse (or any fs like nfs or 9p) to intercept filesystem accesses is a bit larger. At the very least, one can (in most cases) directly observe the ranges of the file that were modified (though that's not quite so important for tup, afaik). There also aren't any queue overruns (which can happen in inotify) because one will just slow the filesystem operations down instead (whether this is desirable or not depends on the application).
Fanotify does not replace inotify, it is a super limited thing for hooking into the vfs. It's intended audience is "people porting windows antivirus style things to linux". See the man page: http://man7.org/linux/man-pages/man7/fanotify.7.html
