User-space NFSv3 Server UNFS3 is a user-space implementation of the NFSv3 server specification. It provides a daemon for the MOUNT and NFS protocols, which are used by NFS clients for accessing files on the server. The goals of the UNFS3 project are, in order of importance: Correctness: it should implement the semantics of NFSv3 as closely as possible. It should also detect races with local file system activity on the server. Portability: it should run on any Unix-like operating system. So far, it is known to work on Linux and SunOS/Solaris. Completeness: it should support all aspects of the NFSv3 specification, within the limits possible from user-space. Performance: it should be as fast as possible. It is impossible to outmatch in-kernel NFS servers from user-space, but UNFS3 should not lag too far behind. So far, UNFS3 passes the basic and general tests of the Connectathon 2004 NFS testsuite and survives fsx stress testing. The tests were run on Linux using the in-kernel NFS client. You can use the links on the left to download the latest version of UNFS3 from SourceForge.net. Please visit the SourceForge.net project page for more information about the project. The unfs3 Subversion repository is hosted on Sourceforge.
unfs3 is a tool in the Build Automation category of a tech stack.
No pros listed yet.
No cons listed yet.
What are some alternatives to unfs3?
A free and open-source package manager designed for the Microsoft development platform. It is also distributed as a Visual Studio extension.
It is a package manager for the Ruby programming language that provides a standard format for distributing Ruby programs and libraries, a tool designed to easily manage the installation of gems, and a server for distributing them.
Bower is a package manager for the web. It offers a generic, unopinionated solution to the problem of front-end package management, while exposing the package dependency model via an API that can be consumed by a more opinionated build stack. There are no system wide dependencies, no dependencies are shared between different apps, and the dependency tree is flat.
With Terraform, you describe your complete infrastructure as code, even as it spans multiple service providers. Your servers may come from AWS, your DNS may come from CloudFlare, and your database may come from Heroku. Terraform will build all these resources across all these providers in parallel.