Free druide db 0.9.6 software for linux

Druide DB project is a simple XML file database API in Java to manage an XML database file system without database complexity (no server or client, and stores only strings).
You should try DruideDB if you are doing the following :
- If you are writing a simple application (swing, awt, RCP, ...) that needs to store some kinds of data in the simpliest way,
- If you need a DataBase whitout installing a server or a client on the final users computer,
- If you dont know SQL and your application needs a DataBase but you dont want to deal with all the pool stuff and inherent complexity,
- If you want to try DruideDB,
- If you think Im a genius (well dont tell it, nobody will believe you !)

PHREL is a per host rate limiter. PHREL will track the rate of incoming traffic to a server and insert a rule into IPTables when a configured threshold is crossed.

The inserted chain may either rate limit or block the offending host for a period of time.

Libral is the rubrica engine. libral library allows you create your addressbooks and to add personal and company cards to them.

Data managed in personal card are: personal data (name, surname, address, etc.), Web links, email addresses, irc uris, telephone numbers, job information (company where contact works, his manager, his collaborator,...), notes.

In company card you can manage Web links, email addresses, telephone numbers, notes. XML is used to store data. Libral can import addressbooks from GnomeCard, Kaddressbook, VCard, Evolution, CSV.

PulseAudio is a networked sound server for Linux and other Unix like operating systems. PulseAudio is intended to be an improved drop-in replacement for the Enlightened Sound Daemon (ESOUND).
Main features:
- Extensible plugin architecture (by loading dynamic loadable modules with dlopen())
- Support for more than one sink/source
- Better low latency behaviour
- Embedabble into other software (the core is available as C library)
- Completely asynchronous C API
- Simple command line interface for reconfiguring the daemon while running
- Flexible, implicit sample type conversion and resampling
- "Zero-Copy" architecture
- Module autoloading
- Very accurate latency measurement for playback and recording.
- May be used to combine multiple sound cards to one (with sample rate adjustment)
- Client side latency interpolation
- Ability to fully synchronize multiple playback streams
Installation:
As this package is made with the GNU autotools you should run ./configure inside the distribution directory for configuring the source tree. After that you should run make for compilation and make install (as root) for installation of polypaudio.
Enhancements:
- padsp has support for SNDCTL_DSP_SETTRIGGER, SNDCTL_DSP_SETDUPLEX, and SNDCTL_DSP_GETOPTR.
- A new ".ifexists" directive has been added to the CLI language for conditional configuration based on file existence.
- FLOAT32RE sample type support has been added.
- There are other bugfixes, cleanups, and portability fixes.

vgrabbj project is made to take input, process it and output it. I know that sounds familiar...
It takes a v4l (not v4l2!) device as input to put it into an jpeg, pnm, or png file. You can add a timestamp into the image. You can also make it automagically upload it to your website via ftp.
Some of the options are made solely for users. I dont have any testing facilities to see if it works.
Enhancements:
- Added all missing options to the manuals, corrected misspelled options. Certain clarifications.
- vgrabbj.c: Added option -X to let daemon mode run in foreground (e.g. not detaching from current terminal)

libtour is a generic tournament processing library. The rules, participants, schedule, and results of a sporting tournament can be defined in the Scheme programming language and given to the library as input.
A CLI application is provided as a reference client implementation. See http://freshmeat.net/projects/qtour/ for a Qt-based client.
ach sporting tournament consists of a number of stages, examples of stages are Preliminary Stage, Quater Finals, Finals.
Each stage includes one or more group; for instance a Preliminary Stage may contain groups A, B, C, and D; Finals may contain a single group of two teams that compete for the winners title.
Each group has two or more teams. Before the tournament starts, only groups of the first stage know their teams. By the completion of the first stage it is usually possible to programmatically determine teams that advance to the following stage, based on their results, and so on for all stages.
Given rules of the tournament (points allocated to a team in a game, as well as sorting criteria for table of standings), initial teams and game schedule it is possible to interpret its results inside a computer program.
Main features:
- simple protocol to communicate with the library through request/reply objects
- queries of data coming from the Scheme definitions (game, team and team result fields, date format etc)
- queries of interpreted data (table of standings, game schedule with results, teams etc)
- notion of the "local team ID" that allows definitions of future stages without knowing real teams
- ability to query the information for stages whose teams hasnt been determined yet
- support for different group formulas (round robin, game count, playoffs)
- support for excessive games (those in the schedule but not necessary to play, like in a playoff stage)
- support for carry-forward game results, and incidentally, predefined games results
- game schedule verification
- support for dynamic creation of (parts of) the game schedule
- support for sorting conflicts within a group (when the rules fail to determine exact team positioning) and providing manual resolution for such conflicts (updated in ver. 0.9.2)
- summary groups (one per stage) provided by the library
- support for creating custom groups on the fly using team and/or game filtering procedures defined in Scheme; information on the interface of available filters (since ver. 0.9.0)
- loading and interpreting more than one tournament at a time
- saving and restoring tournament state
- comprehensive (?) documentation
Version restrictions:
- currently only two-player (not multi-player) games are supported

Yavipind is a secure tunnel aka 2 peers securely forwarding packets toward each other. It forwards any kind of packet (IPv4, IPv6 or other) sent over the virtual point-to-point device (e.g. tun0). It fully runs in linux userspace.

yavipin has been written because i wasnt satisfied by the existing alternatives. i published some security holes i know in alternatives to bring awareness to users and help them to do a knowledgeable choise:

Security analysis of VTun: This text is a security analysis of VTun. It includes a description of the security based on the source and lists the possible attacks. An attacker can modify packets, replay them, learn pattern of the plain text or easily guess low-entropy password.
Security flaws in tinc: This text describes security flaws in Tinc. It includes a description of the security and lists the possible attacks. An attacker can modify packets, replay them and learn pattern of the plain text.

When designing the protocol and writting the software, the author used the following criteria: the security MUST as strong as reasonably possible, yavipin SHOULD be network efficient, easy to use and install.

Network efficiency:

small packet overhead: 26bytes (e.g. ESP with DES+MD5 is 32byte)
Packet compression: Forwarded packets may be compressed using deflate (gzip). (WORK: add stat about efficiency)
NAT compatible: yavipins tunnel may be establish over NAT as all packets of a tunnel are sent over a single UDP/IPv4 connection. Moreover the peer unreachability detection periodically send packets which prevent the NAT engine from timing out the connection state.
Peer unreachabilty detection: If the other peer becomes unreachable, it will be detected. It is done ala IPv6 neighbours discovery (rfc2461.7).
Gracefull shutdown: If a peer purposely stops, it will notify the other which is immediatly aware of it.

Usages simplicity:

it works in userspace and you dont need to recompile the kernel
reuse existing tools: As yavipin use a virtual device, it is possible to apply to the tunnel any tool designed for network device. For example, it is possible to set up a firewall using ipchains/netfilter or to do traffic shapping using the kernels traffic control (see tc).

Securitys strength:

packet security: each packet exchanged during the connection is encrypted using blowfish CFB and authenticated with HMAC-MD5 96bits.
protection against packet replay: It uses strict anti-replay and no packet can be accepted twice. A eavedropper cant take a packet, keep it for a while and make it accept a second time by the destination.
Efficient session key renewal: It uses hash chains for efficiency. It allows smooth key transition not to cause any packet loss during the renewal. It provides forward secrecy inside the connection.
Protect DoS ala TCP syn : It uses cookie exchange (rfc2522.3) during the connection establishement.
Forward secrecy : Even if the attacker cracks the box, he wont be able to decrypt network traffic older than a given delay (default 10min). The diffie-hellman private key and the session key are periodically renewed and securely erased from memory.

jctld is a job/process control system for clusters of machines. The project appeared due to the need for a semi-capable job control system, with the the sorts of features that we need/want on our cluster (the TUNA pi-cluster), and thats free software.
Main features:
- TCP, UDP or UNIX-socket operation
- Fairly lightweight in terms of CPU and memory
- See what jobs are running on machines
- Be able to start/kill/suspend/resume/renice jobs on machines
- Basic node monitoring (e.g. uptime/load)
- Security (trust by private-public key pairs)
- Anything else that we might want to add later on..