Free us 0.99 software for linux

Salvation Focus project is a web application that allows you to focus your prayer on individuals who have not yet come to know Jesus Christ as Lord and Saviour.

The intent is to cycle through a list of prebelievers, as we like to call them, and pray for each one for as long as you feel led to pray.

Salvation Focus makes administration simple and allows you to keep track of the information of the people who submitted the prebelievers name for prayer. In this way, we hope that the list does not get filled up with people we have lost contact with or those we had little information for to begin with.

Ymusk project is a Perl/Tk mush client.
ymusk stands for Yenzies Mush Klient. It is a mush client written in Perl, and it is built around the Net::Telnet and Tk modules.
It is meant to be a simple program which is easily customizable. Its features include logging, macro definition, speech filters, command history, and ANSI colors.
Main features:
- Mouse wheel support (new in v0.99).
- Three types of text scrolling: none, automatic or more-like (for those weaned on tinyfugue).
- Support of ANSI colors.
- Text filters - have your character speaks in pig latin, or in rot13, or, worse still, in French. Okay, so I was kidding about French. But pig latin and rot13 are really there, and they are nearly as incomprehensible. :)
- Logging function.
- Inline commands. If you know Perl, you can add any type of commands you may think of.
- Configuration file including worlds definition, setting of colors, margin and paragraph spacing, etc.
- ICQ-like GUI to manage pages.
- Possibility to call Perl directly from the input window.
- Multi-output screen offering a separated view of channel discussions, pages, game messages and IC text.
- Multi-input boxes for the multi-taskers among us.
- Clock telling you how much time you wasted on the mush. :)
- Spell-checking (for Un*x platforms only).
- Alarms.
- Automatic warning when connection is lost.
- Forms to send @mail, pages and general (but usually long) stuff. Great for bboard posting and @descs.
Enhancements:
- Mouse wheel support has been added.

Veusz is a scientific plotting package written in Python. It uses PyQt (Wiki) and Numarray. Veusz is designed to produce publication-ready Postscript output.
Veusz provides a GUI, command line and scripting Python interface to its plotting facilities. The plots are built using an object-based system to provide a consistent interface.
Main features:
- X-Y plots (with errorbars)
- Stepped plots (for histograms)
- Line plots
- Function plots
- Stacked plots and arrays of plots
- Plot keys
- Plot labels
- LaTeX-like formatting for text
- EPS output
- Simple data importing
- Scripting interface
- Save/Load plots
- Dataset manipulation
- Embed Veusz within other programs
Enhancements:
- The application was largely rewritten and is now based on Qt4/PyQt4 and Numpy rather than Qt3 and numarray.
- Linux and Windows binaries are available.
- It now features a much improved user interface with separate formatting and properties and a better import dialog.
- It can export PDF and PNG files natively.
- Other improvements include anti-aliasing on screen, INF/NaN support, color bars, and different sized subgraphs in a grid.

KGSSueMe aims to provide a sample implementation of a client for the popular Kiseido Go Server.

KGSueMe project stresses documenting the protocol by giving developers code, so that they can write their own clients, rather than to provide a featureful client.

File::pushd is a Perl module to change directory temporarily for a limited scope.

SYNOPSIS

use File::pushd;

chdir $ENV{HOME};

# change directory again for a limited scope
{
my $dir = pushd( /tmp );
# working directory changed to /tmp
}
# working directory has reverted to $ENV{HOME}

# tempd() is equivalent to pushd( File::Temp::tempdir )
{
my $dir = tempd();
}

# object stringifies naturally as an absolute path
{
my $dir = pushd( /tmp );
my $filename = File::Spec->catfile( $dir, "somefile.txt" );
# gives /tmp/somefile.txt
}

File::pushd does a temporary chdir that is easily and automatically reverted, similar to pushd in some Unix command shells. It works by creating an object that caches the original working directory. When the object is destroyed, the destructor calls chdir to revert to the original working directory. By storing the object in a lexical variable with a limited scope, this happens automatically at the end of the scope.

This is very handy when working with temporary directories for tasks like testing; a function is provided to streamline getting a temporary directory from File::Temp.
For convenience, the object stringifies as the canonical form of the absolute pathname of the directory entered.

Quagga is a routing software suite, providing implementations of OSPFv2, RIP v1 and v2, RIPv3 and BGPv4, OSPFv3 for Unix platforms, particularly FreeBSD, Linux, Solaris and NetBSD. Quagga is a fork of GNU Zebra which was developed by Kunihiro Ishiguro. The Quagga tree aims to build a more involved community around Quagga than the current centralised model of GNU Zebra.
The Quagga architecture consists of a core daemon:
zebra
Which acts as an abstraction layer to the underlying Unix kernel and presents the Zserv API over a Unix or TCP stream to Quagga clients. It is these Zserv clients which typically implement a routing protocol and communicate routing updates to the zebra daemon. Existing Zserv clients are:
ospfd
implementing OSPFv2
ripd
implementing RIP v1 and V2
ospf6d
implementing OSPFv3 (IPv6)
ripngd
implementing RIP v3 (IPv6)
bgpd
implementing BGPv4+ (including address family support for multicast and IPv6)
Additionally, the Quagga architecture has a rich development library to facilitate the implementation of protocol/client daemons, coherent in configuration and administrative behaviour.
Quagga daemons are each configurable via a network accessible CLI (called a vty). The CLI follows a style similar to that of other routing software. There is an additional tool included with Quagga called vtysh, which acts as a single cohesive front-end to all the daemons, allowing one to administer nearly all aspects of the various Quagga daemons in one place.
Enhancements:
- Numerous BGP, OSPF, and RIP bugfixes.

DFM is a file manager for Linux and other UNIX like Operating Systems. DFM is the abrvabation for Desktop File Manager.
"Desktop" stands for the capability to place icons on the root window. The idea to write DFM came from OS/2. For a long time I had worked with OS/2.
Using Linux I miss a desktop that provides easy launching programs, managing files and their association. I think only a program like the WPS can provide this.
Main features:
- Normal view, Detail view, Structure view
- Icons may have any size
- placement of icons is free (Normal view)
- every file have its own icon and startcommand
- copy, move and link files
- The desktop is a special folder in the homedirectory - There the user can place links to favourite programs or folders of the system
- every DFM-window have its own backgroundpixmap or color
- XV thumbnails are used as icons
- XDND drag support
- Offix drag support

LWJGL (Lightweight Java Game Library) is a solution aimed directly at professional and amateur Java programmers alike to enable commercial quality games to be written in Java.
LWJGL provides developers access to high performance crossplatform libraries such as OpenGL (Open Graphics Library) and OpenAL (Open Audio Library) allowing for state of the art 3D games and 3D sound. Additionally LWJGL provides access to controllers such as Gamepads, Steering wheel and Joysticks.
All in a simple and straight forward API. LWJGL is not meant to make writing games particularly easy; it is primarily an enabling technology which allows developers to get at resources that are simply otherwise unavailable or poorly implemented on the existing Java platform.
We anticipate that the LWJGL will, through evolution and extension, become the foundation for more complete game libraries and "game engines" as they have popularly become known, and hide some of the new evils we have had to expose in the APIs.
LWJGL is available under a BSD license, which means its open source and freely available at no charge.
Please visit us on the Freenode IRC Network: #LWJGL. Do idle if there is no one to answer any of your questions, we are on different timezones.
In response to everything here Id like to state our goals with LWJGL:
- Speed
- Simplicity
- Ubiquity
- Smallness
- Security
- Robustness
- Minimalism
and this will help explain how we got to where we are today and more importantly where were going and where were not going.
Speed
The whole point of LWJGL was to bring the speed of Java rendering into the 21st century. This is why we have:
Thrown out methods designed for efficient C programming that make no sense at all in java, such as glColor3fv.
Made the library throw an exception when hardware acceleration is not available on Windows. No point in running at 5fps is there?
Ubquity
Our library is designed to work on devices as small as phones right the way up to multiprocessor rendering servers. Just because there arent any phones or consoles yet with fast enough JVMs and 3d acceleration is neither here nor there - there will be, one day. Were carefully tailoring the library so that when it happens well have OpenGL ES support in there just like that. This means that:
We had to have a very small footprint or itll never catch on in the J2ME space at all. Thats why the binary distribution is under half a meg, and that takes care of 3d sound, graphics, and IO.
Even under desktop environments having a 1-2mb download just to call a few 3D functions is daft.
Weve worked to a lowest common denominator principle rather than attempting to design for all possibilities, but weve made sure that 99% of required uses are covered. Thats why weve only got one window, and why we dont guarantee that windowed mode is even supported (its officially a debug mode and hence we dont even supply some very basic windowy abilities that youd get in AWT) and why we dont allow multiple thread rendering contexts.
Simplicity
LWJGL needed to be simple for it to be used by a wide range of developers. We wanted relative newbies to be able to get on with it, and professionals to be able to use it professionally, maybe typically coming from a C++ background. We had to choose a paradigm that actually fits with OpenGL, and one that fits with our target platforms which ranges from PDA to desktop level. This is why:
We arent catering for single-buffered drawing
We dont require that an instance of GL is passed around all over the place but we do not prevent this style of coding. See below for why.
We removed a lot of stuff that 99% of games programmers need to know nothing about
We have decided that consistency is better than complexity. Rather than allowing multiple ways to call the same methods and bloating the library weve just said, "Right, no arrays. Theyre slower anyway. Get used to buffers, as this is what buffers are meant to be used for."
Smallness
See ubiquity above. We had to be small.
Small == simple. The less ways there are to do something, the easier it is to learn the only way that works or is allowed.
Small == our code is less buggy. Wouldnt you rather be hunting for bugs in your own code, not ours?
Small == downloadable. No version nightmares. LWJGL is small enough to download with every application that uses it.
Small == J2ME.
Security
We realised a few months ago that no-one was going to take us seriously if we couldnt guarantee the security of the LWJGL native libraries. This is why we:
No longer use pointers but exclusively use buffers instead
Are gradually adding further checks to buffer positions and limits to ensure that the values are within allowed ranges to prevent buffer attacks
Robustness
Similarly to security we have now realised that a reliable system is far more useful than a fast system. When we actually had a proper application to benchmark finally we had some real data. Many of our original design decisions were based on microbenchmarks - well, you have to start somewhere! But with a real application to benchmark we now know we can throw out asserts and replace them with a proper if (...) check and a thrown exception. We know also that we can move all that GL error checking out of native code and into Java code and we will no longer need a separate DLL for debug mode.
As for runtime exceptions, they have their place. Theres not a reasonably well defined argument as to when you should use a runtime exception and when you should use a checked exception. When I made OpenGLException a checked exception all it did was end up littering my code with try {} catch {} sections - except that if youve got an OpenGLException there is very little sensible you can do to rectify it because it should never have occurred in the first place.
Thats why its a runtime exception. You should simply not write code than can throw it because it is generally not recoverable nicely. However for robustness (and security) we are required to throw an exception if something is amiss. It falls, I believe, into exactly the same category of trouble as NPEs, ArrayIndexOOBs and ClassCastExceptions: should never occur but needs to be trapped somewhere.
Minimalism
This is another critical factor in our design decisions. If it doesnt need to be in the library, its not in the library. Our original aim was to produce a library that provided the bare minimum required to access the hardware that Java couldnt access, and by and large were sticking to this mantra.
The vector math code in the LWJGL is looking mighty scared at the moment because its probably for the chop - well, at least, from the core library - as its not an enabling technology at all, and there are numerous more fully featured alternatives. We chucked out GLU because its mostly irrelevant to game developers except for a few functions that we really need to get redeveloped in pure Java - but basically, GLU is just a library of code built on top of the enablement layer.