Free global strategies and implementations software for linux

Fast MD5 Implementation in Java is a heavily optimized implementation of the MD5 hashing algorithm written in Java.
Fast MD5 Implementation in Java includes an optional native method for even greater speed improvements.
How Fast Is It?
Short answer:Much faster than any other Java implementation that I have tested and (surprisingly) even faster than the native, non-Java MD5 implementation on some systems.
Long answer:First of all, it is important to note that the term "fast" is used here in relative terms. The implementation of the MD5 message digest algorithm available on this page is written in Java and is fast compared with other implementations written in Java, both because it is heavily optimized by itself and because there is an optional native method that makes it even faster when the platform supports it. How it compares to a sensible implementation written in a language, such as C, that is compiled directly to machine code, is heavily dependent upon how good of a job the JIT compiler in your JVM does in compiling the code or whether you are able to use the optional native method.
Enhancements:
- Martin West contributed a bug fix and some code refactoring to make all targets work out of the box in the Ant build file. Previously, the "dist" target did not work if the "docs" directory was not present.

MySQL Global User Variables UDF is a MySQL extension to store persistent variables.

This shared library adds simple user functions to MySQL in order to keep persistent shared variables in memory. These variables and their values are available to all clients. Any data can be stored into these persistent variables, including BLOBs. Since updates are atomic and way faster than MEMORY tables, this is an easy and efficient way to handle counters and sequences.

Usage:

Storing a value

An unlimited number of user variables can be created, as long as memory is available.
The GLOBAL_STORE(, ) stores a new shared global variable.

Examples:

mysql> DO GLOBAL_STORE("online_users", 42);
mysql> DO GLOBAL_STORE("secret_key", "pajfUyfnd");

The GLOBAL_STORE() function always returns 1 unless an error occurred.

Fetching a value

Reading the value of a variable is the job of the GLOBAL_GET() function.
The value is returned, or NULL is the variable is undefined.

Example:

mysql> SELECT GLOBAL_GET("online_users;);
42

mysql> SELECT id FROM pxs WHERE secret_key = GLOBAL_GET("secret_key");
1

Atomic increments

A single function call can read the previous value, add an integer (that can be negative), and store the new value into the variable.

The function is GLOBAL_ADD(, ) and the return value is the new value of the variable.
Updates are always atomic, if the old value is 18 and you add 1, you will always get back 19.

Example:

mysql> DO GLOBAL_ADD("online_users", 1);
mysql> SELECT GLOBAL_ADD("online_users", -4);
39

If the value of a variable was a string, the new value is the increment:

mysql> SELECT GLOBAL_ADD("secret_key", 12);
12

Adding a value to an undefined variable returns NULL.
A handy variant is GLOBAL_ADDP(, ). GLOBAL_ADDP() is similar to GLOBAL_ADD() but returns the PREVIOUS value of the variable instead of the new one.

Example:

mysql> DO GLOBAL_SET("xxx", 10);
mysql> SELECT GLOBAL_ADDP("xxx", 1);
10
mysql> SELECT GLOBAL_ADDP("xxx", 1);
11

Installation:

On most systems, compiling and installing the library should be as simple as typing (as root):

make install

The shared library is installed as /usr/local/lib/udf_global_user_variables.so

If the base directory of your MySQL installation is not in /usr/local, just type:

make

and then copy udf_global_user_variables.so to the right location for UDFs on your system (maybe /usr/lib/).

The name of a variable is limited to 256 bytes. If that limit is too low for your specific application, just edit the MAX_NAME_LENGTH variable on top of the .c file and reinstall. Variable names can contain binary characters.

Values are limited to 65536 bytes. If that limit is too low for you, edit the MAX_VALUE_LENGTH variable and reinstall.

Global Village project is a gnome application designed to place a front-end, or graphical user interface onto the CLI interface of Xplanet, by Hari Nair.
Originally intended to create and update the desktop wallpaper in a gnome environment, showing a traditional rectangular projection of the planet Earth, the scope of the project has been expanded. Global Village now provides as many of the features of Xplanet as seem reasonable, and with the ability for plugins the scope is nearly limitless. But do take it with a grain of salt...
Current Status
Currently, Global Village is barely functional. It can be considered in the pre-alpha stage of development.
It can currently show a preview of the final image, and then display that image on the desktop at user specified intervals (in seconds), and has an icon in the notification area of the Gnome panel.
Plugins are semi-working, but undergoing a lot of change as I decide what they do adn dont need to be capable of. The idea is that plugins will manage all the extra features users require, like cloudmaps, marker and arc files.
Main features:
- Select a planet.
- Select a projection.
- Bodys North Type.
- Rotate the bodys North Pole
- The Zoom level
- The Suns glare
- Latitude and Longitude, which can be set as:
- North Pole
- South Pole
- Equator
- Random Latitude and Longitude
- Or any number of user configerable locations.

GFS (Global File System) is a cluster file system. It allows a cluster of computers to simultaneously use a block device that is shared between them (with FC, iSCSI, NBD, etc...). GFS reads and writes to the block device like a local filesystem, but also uses a lock module to allow the computers coordinate their I/O so filesystem consistency is maintained. One of the nifty features of GFS is perfect consistency -- changes made to the filesystem on one machine show up immediately on all other machines in the cluster.

GFS consists of a set of kernel patches and userspace programs.
The GFS lock module lock_dlm depends on CMAN and DLM.
The GFS lock module lock_gulm depends on GULM.
The GFS lock module lock_nolock depends on nothing.
Some GFS tools depend on the iddev library.

Building and Installing

1. build and install from cluster tree
cd cluster
./configure --kernel_src=/path/to/kernel
make; make install

- This builds and installs kernel modules, libraries and user programs.

- Kernel modules can also be built within the original kernel source tree by applying the kernel patches from cman-kernel/patches, dlm-kernel/patches and gfs-kernel/patches.

2. build device mapper user space
cd device-mapper
./configure
make; make install

3. build lvm2/clvm
cd LVM2
./configure --with-clvmd --with-cluster=shared
make; make install
LVM2/scripts/clvmd_fix_conf.sh /usr/lib

Load kernel modules

depmod -a
modprobe dm-mod
modprobe gfs
modprobe lock_dlm

Modules that should be loaded: lock_dlm, dlm, cman, gfs, lock_harness and dm-mod if device-mapper was built as a module.

Startup procedure

Run these commands on each cluster node:

> ccsd - Starts the CCS daemon
> cman_tool join - Joins the cluster
> fence_tool join - Joins the fence domain (starts fenced)
> clvmd - Starts the CLVM daemon
> vgchange -aly - Activates LVM volumes (locally)
> mount -t gfs /dev/vg/lvol /mnt - Mounts a GFS file system

Shutdown procedure

Run these commands on each cluster node:

> umount /mnt - Unmounts a GFS file system
> vgchange -aln - Deactivates LVM volumes (locally)
> killall clvmd - Stops the CLVM daemon
> fence_tool leave - Leaves the fence domain (stops fenced)
> cman_tool leave - Leaves the cluster
> killall ccsd - Stops the CCS daemon

PHP-Authentication provides a Tomcat-like authentication for PHP.
You give the source to authenticate against (DB, file, XML-RPC, etc.) and the directories that shall be protected, and the class handles the rest.
No including of any call to a class method on every page is necessary. You can also use it as if it were a standard Auth-class, using a call to "isLoggedIn" on every page that shall be protected.
Whats New in 1.3.3 Release:
- added logging, use option logFile
- clean up the session handling, remove global-use
- fix some win-issues
- optimize the isUrlProtected method, to work better on win
Whats New in 1.3.5 Release:
- first implementation of SOAP

LGeneral is a turn-based strategy engine heavily inspired by Panzer General. With LGeneral you play single scenarios or whole campaigns turn by turn against a human player or the AI.

Entrenchment, rugged defense, defensive fire, surprise contacts, surrender, unit supply, weather influence, reinforcements and other implementations contribute to the tactical and strategic depth of the game.

The engine itself has no playable data but there is a converter for Panzer General (DOS version).

vars::global is a Perl module that tries to make global variables a little safer.

SYNOPSIS

# In the place/package where we want to create globals
use vars::global create => qw( $foo @bar %baz );

# Add some more global symbols
vars::global->create(qw( $hello @world %now ));

# Somewhere else, where we need to access those globals
use vars::global qw( $foo @bar %baz );

# Dont try to use globals that do not exist
use vars::global qw( $Foo ); # typo, croaks
use vars::global qw( @inexistent ); # we dont create by default
# use create as above

# You can also import and create new globals
use vars::global qw( $foo %baz ), create => qw( $hey @joe );

# If youre lazy, you can import all the globals defined so far
use vars::global :all;

This module lets you define global variables and gain a slight advantage over blind use of package variables.

The global variables live inside the vars::global package, with the names given by the user. Where the advantage? Its two-fold:

there is an import mechanism that lets you access the global variable without the need to fully qualify its name (i.e. using $foo instead of $vars::global::foo);
the import mechanism ensures that you can import only the global variables that have been explicitly declared so far, which reduces the possibility of a typo.
If you have already "created" the global variable $foo, the import operation is equivalent to do:
*{__PACKAGE__ . ::foo} = $vars::global::foo;
that is, the package variable in the current package is made an alias for the global variable.

The anti-typo check is simply obtained by doing a check before the above import.
Typical usage is as follows:

creation

Early in the module or in the program you create variables prepending the create word, as follows:

use vars::global create => qw( $foo @bar %baz );

access

In the modules where you need to access a given global variable, you can import them very simply:

use vars::global qw( $foo %baz ); # I dont need @bar here ;)

The creation step above automatically imports all the new globals into the current package.