Free royal bank software for linux

The Arusha Project (ARK) seeks to provide a framework and/or tools for collaborative system administration of multi-platform Unix sites with many dozens of machines.

The core ARK developers are interested in using the Arusha Project as a comprehensive solution for system administration.

It is therefore easy to miss the point that the core ARK engine---which simply provides a ``configuration language to say sysadminish things---can be used in many less-than-comprehensive ways.

Here is a ``laundry list... There are undoubtedly hundreds of other weird-and-wonderful possibilities we havent thought of.

Also note that some of these uses are orthogonal to each other. You could pick one (or none) of the ways to tackle software packages and pick one (or none) of the ways to manage the config files in /etc and pick one (or none) of the ways to manage user accounts, etc. -- this gives you many ARK options, without even breaking a sweat.

1. As a multi-platform package manager for user applications, particularly standard freeware packages.

(We arent pleased to have written Yet Another package manager, but the others [RPM, BSD ports, etc.] just arent up to much when you have several diverse Unix platforms for which you want the ``same packages.)

(Other system administration would be done by other means.)

2. To provide an early-adopter `playpen: [a variant on #1] at a site of any size, you will have a small number of people keen to try out beta- and even alpha-quality software. (It is wise to let them do so---they accumulate much ``intelligence which is helpful when deciding about new software to roll out to the general user population.)

You could use ARK to set up a `playpen where early-adopters could do their trials in a controlled and non-problematic way. (The Sidai version wrapper stuff is one way to get a handle on the multiple-versions-live-at-the-same-time problem.)

3. As a `unifier for diverse package managers: Imagine you have a site of Solaris, Linux, and NetBSD boxes, .and you want to use the native package managers for each. But you want the ``same packages on all hosts, and want a site-at-a-time way to manage them; i.e. ark package install ALL should install all packages on all hosts, each in the appropriate way.

4. As a (binary) package producer: One can imagine having a small number of ARK hosts whose job is to produce (say) binary RPM packages of everything of interest to your site. Your (many?) client/production hosts would then simply use the RPMs.

5. As a front-end for Cfengine or PIKT, or similar: Express what there is to know about the hosts, etc., at your site in the ARK object way (including constraints between them), then push a button to generate a configuration for one of the established sysadmin tools, which will do the heavy lifting for you.

6. As a fancy `rdist: A Unix site has bunches of config files that need to be ``the same across many machines, e.g. /etc/hosts or /etc/resolv.conf. The distributed ARK code (notably from team Sidai) is a good way to do this stuff, and you might use ARK just for that.

7. As an `idea bank: Dont run ARK code at all; simply study others sysadmin solutions as a source of ideas. This is a pathetic choice in our view :-), but entirely legitimate!

8. Toss it for system administration and build chip designs with it, instead! (While this is a mostly-facetious suggestion, it reflects the fact that the earliest ARK ideas emerged alongside some chip-building ideas at Glasgow University in 1999.)

Drools is a Rules Engine implementation based on Charles Forgys Rete algorithm tailored for the Java language. Adapting Rete to an object-oriented interface allows for more natural expression of business rules with regards to business objects. Drools is written in Java, but able to run on Java and .Net.
Drools is designed to allow pluggeable language implementations. Currently rules can be written in Java, Python and Groovy. More importantly, Drools provides for Declarative Programming and is flexible enough to match the semantics of your problem domain with Domain Specific Languages (DSL) via XML using a Schema defined for your problem domain.
DSLs consist of XML elements and attributes that represent the problem domain.
Enhancements:
Bug
- DROOLS-294 - WorkingMemory synchronization is not complete (Barry Kaplan)
- DROOLS-314 - MethodMetadataSources need a stopping Class (Barry Kaplan)
- DROOLS-318 - WorkingMemoryEventListenerProcessor implements wrong interface (Barry Kaplan)
- DROOLS-347 - Maven build of drools-spring-jdk5 fails on Mac OS X (Andy Barnett)
- DROOLS-367 - Wrong rule executed when modifying object in workingmemory (Michael Neale)
- DROOLS-374 - Caching of classloaders in causes problems with hot deployment in some J2EE containers (Michael Neale)
- DROOLS-376 - Make source file (c) headers consistent with codehaus (Michael Neale)
- DROOLS-386 - Bug with the Escalation example? (Robert Laflamme)
- DROOLS-401 - Missing semaphore types in schema file (rules.xsd) (Edson Tirelli)
- DROOLS-403 - no-loop incorrectly removes all instances of a rule from the agenda (Michael Neale)
- DROOLS-409 - rename getNoLoop to isNoLoop to obey JavaBean naming convention (Mark Proctor)
- New Feature
- DROOLS-303 - Default rule-method parameter annotation (Barry Kaplan)
- DROOLS-360 - Maven goal for drools-all-src-XXX.zip (Mark Proctor)
- DROOLS-361 - Auto add RuleSet to RuleBase (Barry Kaplan)
- DROOLS-363 - Decision tables in spreadsheets (Michael Neale)
- DROOLS-383 - Integrate java:functions feature in decision tables. (Michael Neale)
- DROOLS-388 - Support for application data (variables), per rule duration, salience and names (Ricardo Rojas)
- DROOLS-408 - Xor Group so only one rule can fire for a specific group (Mark Proctor)
Improvement
- DROOLS-296 - Allow for default id value in parameter annotations (Barry Kaplan)
- DROOLS-297 - Allow multiple consequence annotations per rule (Barry Kaplan)
- DROOLS-301 - Remove Drools prefix from annotations (Barry Kaplan)
- DROOLS-309 - MethodMetadataSource to ignore certain classes (Barry Kaplan)
- DROOLS-310 - Condition sharing for POJO rules (Peter Royal)
- DROOLS-348 - JDK 1.3 no longer supported (Barry Kaplan)
- DROOLS-350 - Utilize 1.4 nested exceptions (Barry Kaplan)
- DROOLS-357 - Packaging between factory and meta needs some attention (Barry Kaplan)
- DROOLS-364 - Update spring libs and config files for 1.2 (Barry Kaplan)
- DROOLS-372 - Update Groovy to JSR-03 (Mark Proctor)
- DROOLS-381 - Add object-condition tests to RuleBuilderTest (Barry Kaplan)
- DROOLS-387 - add ability for a DSL to acces the XML namespace information in a Configuration (James Strachan)
- DROOLS-402 - Refactor maven.xml and drools:dist to make it faster and more intelligent (Mark Proctor)
- DROOLS-410 - Update Janino to 2.3.8 (Mark Proctor)
Test
- DROOLS-346 - Ant build.xml doesnt run drools-jsr94 unit tests (Andy Barnett)
- Task
- DROOLS-351 - Remove drools-annotation and derivitives from 2.1 (Barry Kaplan)
- DROOLS-370 - Add in drools-decisiontables subproject (Michael Neale)

Xrmap is a program running under X that can interactively display portions of the Earth, using the huge CIA world vector map.
The Xrmap program provides a user-friendly X client for generating images of the Earth and manipulating the CIA World data bank II global vector information (a huge geodata set of about 45 MB).
Available features include coastlines and islands, political boundaries, major and minor rivers, glaciers, lakes, canals, reefs, etc. The images can be accurately zoomed in, up to a factor of 100 or more. The package also contains a rather comprehensive data set of world cities and locations - about 20000 cities are listed.
Xrmap is derived from the rmap console only utility by Reza Naima.
However, xrmap has many more features than the original rmap, especially it implements Rectangular, Mercator and Miller projections in addition to the Spherical projection, as well as reverse search of coordinates. All parameters and configurations can be set interactively from the GUI.
Xrmap supports writing images in ppm, xpm, ps or compressed ppm.gz, xpm.gz, ps.gz formats. It can also produce images without entering into the GUI, since most parameters can alternatively be set via the command line options (still, xrmap requires the X environment to do so, in contrast with rmap).
Enhancements:
- Xrmap now directly reads vector formats EPS, SVG or bitmap formats PNG, GIF, JPG. The encapsulated PostScript format EPS is the preferred format for flags, since it is reasonably fast and provides resizable and better looking flags. Other formats are no longer needed to run xrmap, although slower machines can benefit from installing the xpm_150 flags as a fallback, since they load much faster and occupy less disk space...
- Overall handling of images improved, a memory cache is used, more explicit error messages are provided, etc.
- Option -define "picon|..." replaced by more general -define "image|..." which supports all image types recognized by xrmap.
- Bug fixes : option -define "exec|..." was fixed. Thanks to the FreeBSD port maintainer (Serge Gagnon ) for pointing out the bug. Many other small fixes.
- Uploaded version 2.5 of SVG/EPS/PNG/XPM flags, including some additions and corrections (flags of Bangladesh, Morocco, Pakistan, Sudan, United States; French, Danish, Portuguese, Spanish, US and UK territories completed)
- Support for mouse wheel buttons in emx and all xrmap functions (file explorer, scrolling lists)
- An abbreviated menu with the most common functions is now opened by default (rather than the intimidating complete menu).
- Improvement in file explorer (more numerous file types are recognized).
- Data window GUI reworked (and hopefully improved)
- Smarter exit routine (xrmap asks confirmation rather than quitting abruptly).
- New release. The binary size increased by more than 14%. Sloccount indicates more than 25,000 lines of code in total (7% increase with respect to 2.32).

cc65 is a complete cross development package for 6502 systems, including a powerful macro assembler, a C compiler, linker, librarian and several other tools. cc65 is based on a C compiler that was originally adapted for the Atari 8bit computers by John R. Dunning.
The original C compiler is a Small C descendant but has several extensions, and some of the limits of the original Small C compiler are gone. The original copyright allows free redistribution including sources, even if it would not qualify as Open Source Software according to the Open Source Definition.
The original Atari compiler is available from http://www.umich.edu/~archive/atari/8bit/Languages/Cc65/. The complete package consists of the compiler, an assembler, a librarian, a linker, and a C library for the Atari. There are some packages on the net that claim to be adapted as a crosscompiler for DOS or Unix, but was not able to get them working correctly.
Because I wanted a C compiler for my CBM machines, I took the Atari compiler and started a rewrite. Until today, I have rewritten large parts of the compiler, all of the library, completely replaced the assembler, the linker and the librarian, and added a frontend to simplify use. All changes have been done with portability in mind, so porting to new 6502 architectures should be quite easy.
The compiler is almost ISO C compatible, so you should be able to translate many sources from other systems.
Main features:
- The compiler allows single line comments that start with //. This feature is disabled in strict ANSI mode.
- The compiler allows unnamed parameters in parameter lists. The compiler will not issue warnings about unused parameters that dont have a name. This feature is disabled in strict ANSI mode.
- The compiler has some additional keywords that are needed for special features. In strict ANSI mode, the additional keywords start with two underscores.
- The volatile modifier has no effect.
- The datatypes float and double are not available.
- The compiler does not support bit fields.
- C functions may not return structs and structs may not be passed as parameters by value. Struct assignment is possible.
- There are some limitation on the size of local variables. Not all operations are available if the size of local variables exceeds 256 bytes.
- Part of the C library is available only with fastcall calling conventions (see below). This means, that you may not mix pointers to those functions with pointers to user written functions.
There may be other target system dependent limitations. One example is file I/O, which is not implemented on all platforms. This is no technical limitation (as with the stuff mentioned above) but does just mean that no one cared enough to write the actual code.
The compiler is only one of the tools available in this package. The assembler suite (assembler, linker, archiver) is a complete development environment for itself, that may be used to write programs for any 6502 machine. C code and assembler code may be used together and may call each other.
The assembler is a one pass macroassembler and is able to output code for the 6502, the 65SC02 and 65SC816. It has a lot of nifty features like include files, conditional assembly, macros, nested lexical levels (that is, local symbols), and more. The assembler creates object files containing relocatable code. These files must be run through a linker to create the final program.
The linker has a flexible output format and is able to support ROMable code (different load and run addresses for data), banked systems (segments may share the same run address), systems with multiple ROMs, unlimited segments, more than one BSS segment and lots of other things.
The archiver is used to create libraries containing objects files. This simplifies code management. The linker will extract only those modules from a library that are actually needed.
To simplifiy use, there is also a frontend to the tools contained in the cc65 package. The frontend is named cl65. It knows how to build binaries from a list of C files, assembler files, object files and libraries. For smaller projects, just one invocation of the cl65 utility is needed to build a binary from several source files and libraries.

Gestshin is a personnal accounting application running on a web server and released under the GPL licence. Gestshin project is coded in PHP with a MySql Database.
The interface is written in XHTML 1.0 strict to be conform to W3C. Gestshin can manage multiple accounts, currencies and users. Currently, he is writting in English and French since the release 0.2.
The developpement of Gestshin is in progress. Currently, the last release is the 0.2. Gestshin is created since 03 August 2005.
Enhancements:
- Update Smarty to 2.6.11
- Bug session_start() fix with help of Mauricio Araya

LDRUM is an open-source drummachine that offers ten channels, realtime control, a simple pattern sequencer and a graphical user-interface.
LDrum currently runs under Linux only, it is developed in C++ and uses JACK, Qt, ALSA and LADSPA (its a JAQL app;)
LDRUM uses two homemade libraries called libjackpp and libladspapp. These are included in the LDRUM tarball but might be of interest standalone for somebody. So use the following links below to get some infos and the source.
Main features:
10 stereo channels
- Each channel can play a stereo sample. The sample can be changed while playing. A channel can be triggered by the internal sequencer, the keyboard, MIDI or the GUI simultaneous. You can use your favorite sequencer to trigger LDRUM.
16 voices
- LDRUM is limited to 16 channels to be played simultaneous.
MIDI support
- The LDRUM uses the ALSA sequencer api for triggering channels and controlling parameter via MIDI.
Realtime controlable parameters
- Each channel offers a set of parameters which can be controlled in realtime via MIDI or the graphical user interface. You can assign individual MIDI controllers to each parameter via an easy to use MIDI learn function (just right-click over the parameter).
The following parameters are available:
- mute
- solo
- level
- level velocity modulation
- panorama
- equalizer low freq
- equalizer mid freq
- equalizer high freq
- equalizer velocity modulation
- length
- length velocity modulation
- pitch
Sample import
- LDRUM can import all audio file types libsndfile supports.
Load/save drum patches
- A LDRUM patch is stored in an xml file with the extension ".ldp". A patch stores all channel parameters, the channels samples and the MIDI note assignments. Patches can be loaded and saved via the GUI.
Load/save sequences
- A LDRUM sequence is stored in a xml file with the extension ".lds". A sequence stores the sequencer banks which contain the patterns of the channels. Sequences can be loaded and saved via the GUI.
Color schemes
- The LDRUM can be colored the way you like it. It offers an graphical color scheme editor to create you own personal look.

phpSuperMarketTycoon is an online business simulation.
phpSuperMarketTycoon allows players to create individual grocery and super stores and build their supermarket empire while competing against other players building their own empire.
Features include the creation, expansion and trading of individual grocery stores, daily reports for both the players company and the market in general, a bank allowing loans and savings, store management with different effects on your stores, warehousing, NPC chains to compete against your own, a daily newsletter, yearly holidays to effect sales, weekly sales opportunities, and more.
Enhancements:
{Coding}
- Created a ban IP mechanism. Need to do an interface though.
- Added an optional security image for the signup script. Make sure you read the upgrade.txt file on how to update your db.php file to turn this on.
- Added the forums. They sort of work... :)
- Made an adjustment in the players level so that I can create admins later on.
- Adding sorting to the communities list.
- Added company name and email address to the email admin gets when a new player signs up.
- Store Managers have been added to the game. You can hire them, train them if needed (This takes 8 weeks to complete) and assign them to your stores. You can even fire them if you want. They do have a fairly decent effect on your store sales.
- You now get billed 5% of your square footage for electric fees per week.
(Bugs)
- Corrected the link in the footer to the home page of the project. (Bug 1439620)
- Removed 1, 0, l, o, and i from the security image script to avoid confusion.
- Reformatted display numbers to show commas for the thousands place. (Bug 1434685)
- Dealt with the issue of the menu column displaying twice during errors during player signup. I think I got them all. (Bug 1434308)
- Fixed the store counts within communities within the *.sql install file. (Bug 1434684)
- Upgrade script will correct store counts for already installed games (Bug 1440495)
- Cashiers are now being paid. (Oops) Fixed in buildthatsucker.php as well as the upgrade script. Cant believe I missed that... (Bug 1440969)
- The forum was not doing line breaks correctly. Im hoping that this is fixed. (Bug 1440997)
- Fixed the issue with company name not being shown in the webpage after a new company has been created as well as within the email sent to the game admin. Fixed AGAIN! (Bug 1441007)
- Adjusted the size of the email address within the players table. I guess 25 characters isnt enough. Sorry about that. (Bug 1441015)
- Fixed the issue in the viewcommunities page where it was presenting you a link to build a store when there wasnt one available. Fixed this as well in the buildstore.php page. (Bug 1440517)
- For some reason, when you incorrectly created a store that was too large or didnt have enough money, the script would erase the data that it was holding on the store so you always wound up in sector 1. Fixed I think. (Bug 1440734) Still dont know where that one came from as it was something I made sure that worked before the release.
- Fixed a minor bug in the displaycompanies.php file that would list the stores in the incorrect order.
{SQL}
- Upgraded the SQL install file to include the badips, topics, and posts tables.
- Added the first name and last name tables to the file.
- Added the store managers table to the file.
{Upgrading}
- Started a method of upgrading. It might even work.