Free project 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.)

Project document and management tracking system written in PHP using PostgreSQL to store user, project and document related data and MySQL to store the documents, with revision control.

How to:

How to setup the system:

Just untar every thing in your webdirecorty:
cd /var/www/html/
tar -xvzf ueber-1.0.tar.bz2

How to setup the DB:

- Create ueberp user in PostgreSQL [ueberp@psql]$ psql -U admin -c "CREATE USER ueberp WITH PASSWORD ueberp CREATEDB"
- Create a ueberp database in PostgreSQL
[ueberp@psql]$ createdb -U ueberp ueberp
- execute db-setup.psql to setup the PostgreSQL database.
[ueberp@psql]$ psql -U ueberp -d ueberp -f db-setup.psql
- Basic data is in db-data.psql for setting up the system
[ueberp@psql]$ psql -U ueberp -d ueberp -f db-data.psql
- Create a database in MySQL (i.e. ueberp)
- execute db-setup.mysql to setup the MySQL database.
- execute db-data.mysql to insert the basic data.

Finally edit ueberp/lib/config.inc and try to log into the system (user: admin, pass: admin)

Note: In order to have correct "Account Manager" and "Project Manager" entries
in the projects, the acronym for the "Account Manager" must be AM and for
the "Project Manager" PM.

The Pawn Project aims to make computing easy for anyone with an easy-to-use desktop environment.

How often have you felt that your computer could be smarter ? Arent you tired of the old drag and drop style desktop and the horribly command promps.

Well Open Pawn Projekt (OPP) is about to change all that. The Pawn shall make it possibly for you to command your computer exactly what you would like it to do.

Order it in plain and simple english or whatever your natural language is.

Pawn is written in Perl, TCL TK and C++. Just to make it so portable as possible. Currently it will run on any Unix/Linux system.

This is a project to create 64-bit virtual CPU, create a 64 bit assembler for the CPU and then port C to it, and then create scripts to port GNU/Linux to it.
The aim is to run 64-bit Linux on common 8/16/32 bit CPUs in applications where speed is not an issue.
Enhancements:
- Added C code intended tor a PIC Preliminary documentation More updates to Gambas program

MapGeneration Project is a project featuring a server and helper programs to collect GPS information from various sources and to then automatically generate a continuously improved, time annotated road map.
Nowadays gps-receivers are quite cheap and many people use them for route planning in their cars. On the other hand updated maps for the route planing systems are relativly expansive, if available at all.
The idea is to collect the data that people have recorded with their gps-receivers and combine it into one freely available road map. Besides being cheap and always current this map would also contain actual driving time information: Route planning on such a map would not have to use road type based approximations to calculate the fasted route.
In the MapGeneration Project we implement such a program and the end user tools needed to access the data. At the moment we concentrate on two programs: The MapGenerator itself and the MapGeneratorGUI used to administer the generator.
The MapGenerator is a server that accepts incoming data via network and combines the received road information into one big map. As the map might become quite big a database is used as storage. The MapGeneratorGUI connects to this database and displays the map.
As the best way to understand a program is to use it we will now give a short introduction to using the program.
Enhancements:
New features
- (Server) New filter to detect gaps in the input traces.
- (Server) Calculates and outputs total length and time of processed traces.
- (Server) Added full support for more than one processing thread, 2 is default now.
Changes
- (Server) Rewrote TraceServer and TraceConnection to support commoncpp2 1.0.x.
- (Server) Server tries to bind to 127.0.0.1 if no interfaces are found.
- (Server) Added curvature as a criterion for merging -> much better merging!
- (Server) Improved avoidance of double processing of nodes.
- (Server) Moved parsing of traces into TraceFilter.
- (General) Added lots of new methods to handle distances, bearings and interpolation.
- (General) Configuration system supports boolean values.
- (Buildsys) Changed parameters to specify config files to --with-wx-config and --with-ccgnu2-config
Bugfixes
- (Server) Protected data handling between thread with mutexs.
- (GUI) Fixed some string literals for full unicode support.
- (General) Cache: Fixed all size calculations and the size handling system.
- (General) Raised requirements for wxWidgets to 2.6 (beta versions since 2.5.3 should work).
- (General) Some small fixes to build with commoncpp2 1.0.x.

The Aurora Project is an attempt to create a new generation of Linux distributions. It will try to break free from old patterns and establish Linux as a serious world player.
Currently, Aurora Project consists of the Aurora Desktop Environment which, unlike most other Linux-based desktop environments, dont attempts to accomplish everything but to remove the focus from system configuration and desktop customizing by creating an easy-to-use out-of-the-box intuitive and beutiful desktop experience.
The UI is (for now) somewhat Microsoft Windows-inspired. I am satisfied with the general layout of the panel and start menu, currently I am busy designing the core functionality of the desktop with the panel as my number one priority. Also there is the session manager, the desktop manager and the shared library.
The Aurora Project currently consists of two major components - the panel and the shared library.
Main features:
- Windows-like user interface with a start menu.
- Freedesktop-compliant application menu (compatible with GNOME and KDE).
- Frequently used applications are easy to access.

The Freiburg project is an infrastructure to replace shared libraries with a client/server interface. This system converts a shared library into a "service" using Unix or inet domain sockets for communication.
The "service" will be usable by any programming language without additional C programming requirements. An application is a composition of multiple services using an event-based message bus for communication.
A service can reside locally or remotely using the "client" or the inetd super-server for startup.
Enhancements:
API update
no libtool for build-environment
-significant speedup for build
-no libtool bug issues anymore
-no libtool porting issues anymore
update transaction work-flow
-no return-handles anymore
-no public transaction API anymore
speed improvements
-better internal caching of used objects
-improved header parsing
API now thread-safe
-need MUTEX lock for MqCreate
-need MUTEX lock for MqDelete

The Stewie Radio Automation Project is a stand-in replacement for the "XMMS playlist on random" style of independent radio station.
Once properly configured, the user will enjoy the low maintenance of a "random playlist" station while still being able to use legal IDs, liners, multiple playlists, and music logs.
Main features:
- Low maintenance
- Multiple playlists
- Liners
- Legal IDs
- Logs every song and liner played
- Records errors and keeps truckin
Enhancements:
- Fixed a few bugs in install script
- Created error log/warning system
- Main script now updates the settings in stewie.conf in order to continue running. The only thing that *should* kill it, is not having any music available in the "master" playlist.
- Config file can be updated while script is running
- install-stewie gives "not found" audio players another chance
- Rewrote README file