Free distributed filesystem software for linux

Coda is an advanced networked filesystem. The project has been developed at CMU since 1987 by the systems group of M. Satyanarayanan. in the SCS department.
Coda is a distributed filesystem with its origin in AFS2. It has many features that are very desirable for network filesystems. Currently, Coda has several features not found elsewhere.
1. disconnected operation for mobile computing
2. is freely available under a liberal license
3. high performance through client side persistent caching
4. server replication
5. security model for authentication, encryption and access control
6. continued operation during partial network failures in server network
7. network bandwith adaptation
8. good scalability
9. well defined semantics of sharing, even in the presence of network failures
Enhancements:
- Coda now works on 64-bit systems.
- The client and server were successfully built and used on a machine with em64t extensions with a 64-bit Linux kernel.
- The new RVM-1.14 and RPC2-2.5 releases also incorporate some essential 64-bit fixes.
- Another welcome change is that venus now tries to keep cached access rights available for users even across system reboots or client restarts, which should improve life for people who frequently shut down or dual boot their machines.

Distributed FTP is a distributed FTP daemon written in java. Instead of usual and well-known serversclient transfer it uses masterclient for control connections and slaveclient for (most) data transfers, the master must tell the slave to initiate/respond to a transfer.

Distributed BEAGLE provides a distributed evolutionary computation system.
Distributed BEAGLE is a master-slave distribution extension of the evolutionary computation framework, Open BEAGLE. Its key features are robustness, fault tolerance, adaptability for heterogeneous networks, and transparency for the user.
Main features:
- Based on the generic framework Open BEAGLE
- Minimal changes required to modify an Open BEAGLE application for distribution
- Ten GA and GP examples converted from Open BEAGLE
- Communication based on TCP sockets using XML encoding
- Data persistency insured on the server by a SQL Database (SQLite)
- Load balancing of computational tasks for uses on heterogeneous LAN
- Open source (LGPL license)
- OS-calls wrapped into generic C++ classes
- Compiles on UNIX (Linux/OS X) with gcc 3.x and Windows with Visual Studio .NET
Enhancements:
- Bug fixe: variable deme size could crash the server (Thanks CG).
- Suggestion: Compression of connections can now be activated by clients if the option is set to "-1".

Distributed Multi-User Compilation System is a system that allows a group of users to share a compilation farm. Each compilation request from each user will be sent to the fastest available machine, every time.
Main features:
- Supports multiple users compiling simultaneously, and scales well to handle the new loads.
- Supports multiple operating systems in the compilation farm.
- Uses all processors of a multi-processor compilation host.
- Makes best use of compilation hosts with widely differing CPU speeds.
- Guarantees that a compilation host will not be overloaded by compilations.
- Takes into account the load on a host caused by non-compilation tasks.
- Supports the dynamic addition and removal of hosts to the compilation farm.
- Works with distcc, which need not be altered in any way.
DMUCS consists of these (main) programs:
- dmucs: the "host-server". This application reads a configuration file indicating the number of CPUs and the "power" of each potential host in the compilation farm. It then receives over the network:
- load average information from each compilation host.
- host requests from compile tasks that need remote hosts on which to run.
- information requests from monitoring applications.
- status requests from an administrator.
- dmucs maintains the database of hosts in the compilation farm, and assigns hosts to compilation tasks, giving out the best host/cpu available when the compilation task asks.
- gethost: a compilation task uses gethost get a host/cpu from the dmucs server. In general, a makefile will perform a compilation this way:
- gethost distcc gcc ...
- gethost contacts the server to get a host, which it puts into the environment variable DISTCC_HOSTS. gethost then calls the program given to it. After that program ends, gethost releases the assigned host back to the dmucs server.
- loadavg: the administrator of the compilation farm must start this application on each compilation host. loadavg sends the load average of the compilation host to the dmucs server periodically. The dmucs server will "downgrade" a compilation host if the hosts load averages goes too high.
- monitor: the administrator (or anyone) may use this program to monitor the busy-ness of the compilation farm. It displays which hosts/cpus are available in the compilation farm, which hosts/cpus have compilation tasks assigned to them, which hosts have been made administratively unavailable, and which hosts are "silent" - i.e., the dmucs server has not received a load average message from the compilation host for a while.

FUR is a application that let the user mount a Windows CE based device on your Linux file system: it uses the brilliant FUSE (acronym of File system in UserSpacE of Miklos Szeredi) and the great librapi2 of the Synce Project, a unix implementation of the RAPI protocol (that your device use to communicate with your other operating $ystem ) which you can find here, along with other very nice tools.
You execute it with proper arguments, then (if everything goes fine) the entire file system of your (previously connected) handheld will appear automagically mounted like a regular Linux file system where you will be able to copy, move read and write data with your favorite programs.
FUR filesystem means FUSE use libRAPI.
What dose not?
- Not very stable, particulary if used concurrently by different processes (but should be usable).
- Not well tested.
- The source is horrible(Tm).
- The implementation is more involved than it should.
- Lack documentation.
- Not even remotely optimized.
- Configuration tools deficient.
- Random access I/O is anti-optimized.
- Write is bugged (maybe a problem with concurrent file access).
- The resource locking system (e.g. to prevent different processes to write on the same file) is only roughly implemented (theres a lot to be done).
- Total absence of a caching system of some sort (which i hope to implement, sooner or later).
- Some errors are to obscure (and maybe not well implemented).
- Some attributes (e.g. ctime) are not implemented (the needed function in the librapi2 library is not yet implemented).
- No UID/GID check: this is not a security issue: only the user that invoke the dccm demon can access the filesystem, but other users should be able to see some kind of error message (which i will implement soon).
- Lot of other things i have forgot now.
- The log reporting suck

Sys::Filesystem project is intended to be a portable interface to list and query filesystem names and their properties.

It hopes to provide a consistent API to list all, mounted, unmounted, and special filesystems on a system, and query as many properties as possible with common aliases wherever possible.

Distributed Checksum Clearinghouse, in short DCC, is a system of clients and servers that collect and count checksums related to mail messages. The counts can be used by SMTP servers and mail user agents to detect and reject bulk mail.
DCC servers can exchange common checksums. The checksums include values that are "fuzzy", or constant across common variations in bulk messages.
Enhancements:
- This release improves the dccifd per-user whitelist default.
- It fixes the server database size estimate.
- Old installations really should upgrade to get the MIME decoding fix.

Distributed RSA Key Generation is a software to generate shared RSA keys. Currently, only keys for two parties using Gilboas protocol are supported. But the protocol stack is extensible, so in the future there may be other protocols supported.

Work has begun on Straubs protocol but is not finished yet, multi-party protocols like Boneh-Franklins may also be added in the far future.