OSNews

Looks like a cool idea when you first see it. But really, it is quite impractical. Networks are quite different from local devices, there are all sorts of latency, connection and authentication issues that, in the end, if you want decent usability, must be dealt with in the application. I guess an asyncrounous API extended for dealing with networks could work.

What you don't realize is that all the problems you can have with a networked filesystem can happen in some local ones, too.

Think about the spin-up of CD/DVD drives, not to mention scratches on the disk. And what if the user decides to eject the CD while something still accesses it? I know, Linux locks the CD tray by default, but that's a horrible idea from a usability POV. And anyway, there are removable devices that simply *cannot* be locked, such as USB sticks.

To summarize, network transparency only makes *already existing* problems more apparent. Once those *already existing* problems are fixed, network transparency is no longer problematic.

In the kernel? No way. Stick it in a library. (But this is coming from a person who thinks that the local FS and disc drivers should be in libraries too!) If you're writing an OS, make these libraries your API, not what the kernel exposes.

You're obviously right. That's what FUSE and the KIO-Bridge are all about, as has been mentioned before.