Free performant software for linux

Spring-RCPs mission is to provide an elegant way to build highly-configurable, GUI-standards-following rich-client applications faster by leveraging the Spring Framework, and a rich library of UI factories and support classes.
The Spring Rich Client Project (RCP) is a sub-project of The Spring Framework. Spring-RCPs mission is to provide an elegant way to build highly-configurable, GUI-standards-following rich-client applications faster by leveraging the Spring Framework, and a rich library of UI factories and support classes. Initial focus is on providing support for Swing applications but a goal of Spring-RCP is to be view agnostic as much as possible.
Spring Rich Client Projects goal is to provide a viable option for developers that need a platform and a best-practices guide for constructing Swing applications quickly.
Specifically, spring-richclient seeks to:
Provide a way to build structured, highly-configurable, GUI-standards-following Swing applications faster by leveraging the Spring Framework.
Foster integration with existing rich-client-related projects where it make sense. For example, jgoodies-forms and TableLayout are two good layout managers. We dont need to develop another one.
Adhere to the principles set forth by the Spring Framework--programming to interfaces; the importance of sound OO design, documentation, and testing.
Main features:
- A command framework that provides centralized configuration of Swing actions and appropriate handler registration based on the current active view. Command configuration, as well as action bar contribution policies (to menus or toolbars), can be defined centrally and externalized in Spring bean defintiions.
- A forms data binding and validation framework, for connecting edits made in your UI controls with your domain model automatically--with as you type feedback.
- Support for multiple window management, page configuration, and view management. The concepts here are inspired by Eclipses perspective/view constructs. Views can be defined in the Spring container, associated with one or more pages, and a default page can be configured to be loaded at startup.
- Common support classes addressing various rich client requirements including: well formed dialogs, wizards, input validation (typing hints and validation results reporting), button bars,internationalization, image/icon caching, progress monitoring, UI threading (classes cleanly promoting responsive UIs), treetable/property sheet, table sorting/high-volume table updates, GUI standards builders/helpers, help/about, etc.
Spring-rich adds value for people needing to develop Swing applications and do so in a way that promotes consistent, well-designed, configurable Swing applications. The spring-rich developers strongly feel the old days of Swing apps not looking native and not being performant or web-accessible are gone with JDK1.4.2 and 1.5 and webstart.
It is our belief the only problem with Swing is that there are a limited number of higher-level abstractions available that assist in making the toolkit simpler and easier to use, and a limited number of design best practices. The goal of spring-richclient is to provide that.
Enhancements:
- [RCP-400] - jgoodies forms not included as spring-rich dependencies
- Regression bug: icons on MessageAreaPane didnt show up

OpenSER is a collaborative project of its users, to develop a scalable and robust SIP server.
Anyone can contribute to one of next items:
- code development - OpenSER core, modules and adjacent applications
- documentation- writing or enriching documentation
- miscellaneous - different management tasks (e.g., web site maintenance)
- ideas - new ideas bring brilliant solutions
Main features:
- robust and performant SIP (RFC3261) Registrar server, Location server, Proxy server and Redirect server
- stateless and transactional statefull SIP Proxy processing
- support for UDP/TCP/TLS transport layers
- scripting language for configurations file. With a syntax similar to sripting languages, the configuration offers a powerful and flexible way to deploy custom SIP services.
- management interface via FIFO file and unix sockets
- pseudo-variables to access and manage parts of the SIP messages and attributes specific to users and server
- authentication, authorization and accounting (AAA) via database (MySQL, Postgress, text files), RADIUS and DIAMETER
- CPL - Call Processing Language (RFC3880)
- NAT traversal support for SIP and RTP traffic
- ENUM support
- load balancing and least cost routing extensions
- support for replication - REGISTER offer new functions for replicating client information (real source and received socket).
- logging capabilities - can log custom messages including any header or pseudo-variable and parts of SIP message structure.
- modular architecture - plug-and-play module interface to extend the servers functionality
Enhancements:
- This is the second patch release in 1.2.x series, including minor enhancements and bugfixes done since 1.2.1 was released.

OpenDaemon (Formerly OpenXMLD) started as an open-source native XML database server, which aims at achieving the following special goals:
- Performant enough that it can eliminate all the performance problems related to XMLs nature (e.g the need to make a parse tree for each document). so it can offer XMLs extensibility in places where any other non-XML database server can be used.
- As much SQL-compliant as possible so it can replace the current non-XML servers easily and with a minimum of effort (e.g having ODBC and JDBC drivers with no SQL XML translation stuff.)
After about a year of development, it was found that its better to concentrate in the first place on the platform containing the server rather than the query parsing and data extraction functionaltiy, the decision was to do everything on its own, by creating a server platform that provides a generic and flexible model of work the same previous goals could be achieved easier and in a more open and distributed manner.
In this direction, OpenDaemon could reach the stage at which it can be a server of any protocol, and the protocol implementation can utilize a broad set of capabilities built inside the server.
Because portability is a concern, OpenDaemon contains well-defined interfaces between its modules, to allow for easy replacement of any part for portability or performance reasons. Last but not least - OpenDaemon is written with object orientation in mind in the C programming language.
OpenDaemon is an extension of the efforts formerly done in KXParse.
Enhancements:
- Generlized the engine interface so it is not XML-specific.
- Engine capability specification.
- Support for a broader range of functionality within the engine API.
- Configuration parser and API rewrite using bison and flex.
- Support for interface association to a particular port.
- Support for interface parameters and interface instances.
- Generic, more flexible storage API and associated walker.
- Multi-process multi-tasker cleanups.
- Initial support for engine association to file types using the file extension.
- Error reporting model across engines and interfaces.
- Improved and more efficient connection handling.
- Better organization for the source code tree.
- Renamed to OpenDaemon.

SimCList project is a high quality C library for handling lists.
SimCList is available for free, under restrictions imposed by the BSD license.
SimCList API is good because:
- it is simple, yet powerful
- it makes elegant and consistent use of information hiding
- it abstracts the actual data type to store
- it is fairly total
The library itself is very performant and makes a good compromise between performance in terms of time and space:
- insertion is O(n) [typically n/8]
- extraction and deletion are O(n) [typically n/8]
- iteration is O(1)
- sorting is always O(n logn), without worst case
Thread safety
The SimCList library is thread safe, meaning that many threads can run SimCList operators on different lists concurrently without hurt, or also read operations on the same list.
However, of course, no safety guarantee is made for performing concurrently write+write or read+write operations on the same list (eg: insertion, deletion, sorting, ...). For performance and portability reasons, protecting such operations from concurrency is left to the library adopter.
Performance
SimCList has been designed with ease to use and performance in mind. There is some example factors that have been taken into account, and against which the code has been optimized when implementing SimCList:
- overhead of function calls
- cache locality
- number of branches, possible CPU stalls or pipeline flushes
- dynamic memory allocation weight on the OS
- other mathematic/probabilistic optimizations for avoiding worst-case or improving average case behaviours in algorithms
Many parts of SimCLists code have been deeply improved with profiling analysis.
Enhancements:
- Transparent inclusion in C++ applications is natively supported.
- Sentinels are used to improve performance on list traversals.
- A problem was fixed with list_insert_at, which could output inconsistent lists when inserting into even-sized lists in position 0.

CryptoFS project is a encrypted filesystem for the Linux Userland FileSystem.

CryptoFS will use a normal directory to store files encrypted. The mountpoint will contain the decrypted files. Every file stored in this mountpoint will be written encrypted (data and filename) to the directory that was mounted.

If you unmount the directory the encrypted data can only be access by mounting the directory with the correct key again. Like other LUFS filesystems it does not need root access or any complicated setup like creating a filesystem on a encrypted disk using the loop device.

This package will create a shared library that can be used by LUFSs lufsd to mount a directory containing encrypted data to another directory.

I first used the evfs kernel patch that does nearly the same thing as CryptoFS. But it seems that it has been abandoned. The last patch was available for kernel 2.4.20 and has not been updated for newer kernels since then.

When I found LUFS I thought I could be a good base for a crypto filesystem that works like evfs and allows a user to mount any directory as an encrypted storage without having root access and creating a crypto filesystem using the loop device. So when I found no other program that offers this posibilities I started to write my own filesystem for LUFS.

Usage

Put the shared library into a directory where the system linker can find it (this will usually be done by "make install") or add the directory to the search path by setting the LD_LIBRARY_PATH environment varibale.

First you have to set up the source directory by copying the file cryptofs.conf to /.cryptofs. You can adjust the values in the file, but the default should work fine.

After that you can mount the source directory with lufsmount cryptofs://

You will be asked for the password you want to use for this filesystem. It will be used to generate the cipher key.

After that you should be able to use the directory like any other directory, but all data will be read and written to the directory in an encrypted form.

Encryption

When a filesystem is mounted CryptoFS first generates a key for the requested cipher algorithm (CRYPTOFS::cipher) using the message digest function (CRYPTOFS::md). Every algorithm has a specific key size and every message digest function has a specific length of the generated message digest. If the message digest size is smaller then the keysize the message digest will be repeated until the key size is reached.

After they primary key has been generated CRYPTOFS::salts subkeys (initialization vectors) will be generated by encrypting 0 bytes with a 0 initialization vector. These will later be used to encrypt blocks with different subkeys to make sure the cipher text will first repeat after (salts * blocksize) bytes (If the same data is encrypted).

When files or links are created or renamed the name will be encoded with the selected cipher, the primary key and the first subkey. The result will then be encoded using a modified Base64 algorithm because the encrypted filename could contain characters that are not allowed by the target filesystem. (The original Base64 algorithm uses / for encoding. This is the directory delimiter so it was replaced by _)

When files are written the data will be encrypted. CryptoFS always has to write full blocks. So if only a part of a block should be written the original block will first be read, decrypted, the part replaced and then the result then written encrypted back to disk. To keep this performant that block size must not be too large.

But to make sure the cipher text does not repeat to early, CryptoFS uses salts to encrypt blocks. Every block will be encoded with the (blocknumber module salts)th salt. (NOTE: Linux always reads or writes "pages" of size 4096 bytes, these writes will be forwarded by lufsd to CryptoFS. So if you use a blocksize of 4096 bytes reading the old block before writing can be omitted and writing should be faster).

Mail::Summary::Tools::YAMLCache is a low performance cache which is easy to edit/fix.

SYNOPSIS

use Mail::Summary::Tools::YAMLCache;

my $cache = Mail::Summary::Tools::YAMLCache->new(
file => Path::Class::file("/tmp/foo"),
);

$cache->get("foo:bar");

$cache->set("foo:bar", "moose");

This is a hacky implementation of the Cache API, suitable for caching long lived values, like shortened links, and links to google group threads (which require WWW::Mechanize under normal circumstances).

The main point of this module is to create a file that is easy to edit/alter/delete, not to be performant or multiprocess friendly.

QiLinux is a Linux distribution made completely from scratch. QiLinux distribution has the aim of integrating the work of the vast community of free software developers in order to creare a modern, performant, safe and easy to use system for system administrators and desktop users.
Whats New in 1.2 Stable Release:
- 2.6.11.8 kernel
- proprietary ATI and nVIDIA video drivers integrated
- support for many USB ADSL modems
- graphical installation tool Qist (QiLinux Installation Tool) giving a choice among a tenth of groups and thousands of packages
- installations and updates management with apt and the graphical tool synaptic
- remote desktop administration with freenx
- detailed installation guide
- a lot of new software packages for multimedia, graphics, office and productivity
- Linux Standard Base compliant to 99,9% of the tests

Gitarella project aim to provide a more performant, complete and friently Web frontend for GIT other than gitweb. The language of choice is Ruby because it makes simpler to handle both CGI and FastCGI with the same code, and many libraries already exists for common tasks like page templates and diffs handling.
The current version supports the basic browsing of repositories and diffing of files, and uses memcached as a backend for short-term storage of extracted data.
The development is handled through GIT at the url git://farraugt.flameeyes.is-a-geek.org/gitarella.git . Web interface is available on gitarella itself.
Version 0.001 is a pre-alpha version, that shows the current status of the code, it does work for basic browsing.
Enhancements:
- This version features lots of bugfixes, especially in handling of tags, remote (pushed) branches, and commit descriptions.
- It also adds graceful and not-entirely-graceful handling of exceptions (depending whether they are thrown during the initialisation phase or during the request) so that the user is never (or should never, at least) presented with an unanswered request.
- It makes the ruby-filemagic extension optional, although recommended, and make use of log4r extension for logging ability.