Free server 3.12 software for linux

Rad Upload is a drag and drop file upload applet with a progress monitor. Advanced features of Rad Upload Lite include recursive upload of directories and setting upload limits at the client side.
Bandwidth saving options include filtering out unwanted file types, compression, and resizing images before they are uploaded.
Both HTTP/HTTPS and FTP protocols are supported, and files can be uploaded using copy and paste, as well as with an optional traditional browse button.
Main features:
- Drag and Drop
- Progress Bar
- Applet Size
- Copy and Paste
- FTP upload
- SSL
- Upload Folders
- Redirect After Upload
- Image Scaling
- Client Side Filtering
- Display Thumbnails
- GZip Compression
- Javascript Calls
Installation:
First make sure that your server is correctly configured to accept file uploads. With sites that use PHP you can make use of the included test.html and upload.php files to test your server configuration.
Depending on the version you have downloaded move dnd.jar, dndlite.jar or dndplus.jar onto your web space. Also move the included php files onto the same location as the jar file. Next open applet.php in your favourite text editor and change the url parameter to match your server-side upload handler. Thats it!
The upload.php is a sample PHP script provided to get you started on drag and drop file upload. You may need to modify upload.php to suite the needs of your website or web application.
If you prefer to use perl as your server side handler please copy upload.cgi to your /cgi-bin/ directory and change permissions to 755. Perl upload handling can be tested with test-perl.html
Each licence of Rad Upload Lite, Rad Upload and Rad Upload Plus allows you to install the applet on exactly one website.
Enhancements:
- A minor bug in client side filtering (by file type) and an incompatibility with tnftpd on Mac OS X were fixed.

Eris is designed to simplify client development (and promote code reuse) by providing a common system to deal with the back-end Atlas tasks. Notably, Eris encapsulates most of the work in getting Atlas entities available on your client, logging into a server, and managing updates from the server.

Once the entities are made available locally, Eris also manages updating them as required. Thus it can be considered as a session layer above Atlas, providing persistent (for an entire gaming session) objects as opposed to transient Atlas ones.

WorldForge::Eris project handles the client-side implementation of the meta-server protocol, and querying game servers; out-of-game (OOG) operations (via the Lobby and Rooms), and most important in-game (IG) operations such as entity creation, updates and movement.

HA-Proxy is a TCP/HTTP reverse proxy which is particularly suited for high
availability environments. Indeed, it can :
- route HTTP requests depending on statically assigned cookies ;
- spread the load among several servers while assuring server persistence through the use of HTTP cookies ;
- switch to backup servers in the event a main one fails ;
- accept connections to special ports dedicated to service monitoring ;
- stop accepting connections without breaking existing ones ;
- add/modify/delete HTTP headers both ways ;
- block requests matching a particular pattern ;
It needs very little resource. HAproxy it is event-driven architecture allows it to easily
handle thousands of simultaneous connections on hundreds of instances without risking the systems stability.
Start parameters
There are only a few command line options :
-f < configuration file >
-n < high limit for the total number of simultaneous connections >
-N < high limit for the per-proxy number of simultaneous connections >
-d starts in foregreound with debugging mode enabled
-D starts in daemon mode
-q disable messages on output
-V displays messages on output even when -q or quiet are specified.
-c only checks config file and exits with code 0 if no error was found, or exits with code 1 if a syntax error was found.
-p < pidfile > asks the process to write down each of its childrens pids to this file in daemon mode.
-s shows statistics (only if compiled in)
-l shows even more statistics (implies -s)
The maximal number of connections per proxy is used as the default parameter for each instance for which the maxconn paramter is not set in the listen section.
The maximal number of total connections limits the number of connections used by the whole process if the maxconn parameter is not set in the global section.
The debugging mode has the same effect as the debug option in the global section. When the proxy runs in this mode, it dumps every connections, disconnections, timestamps, and HTTP headers to stdout. This should NEVER be used in an init script since it will prevent the system from starting up.
Statistics are only available if compiled in with the STATTIME option. Its only used during code optimization phases.
Enhancements:
- Content switching is now fully operational using ACLs.
- ACLs can look for matches in path and headers in addition to previously supported criteria.
- Integer comparison is now supported for header values. 15 pre-defined ACLs are provided.
- Error pages can be customized using external files.
- Several bugs have been fixed.
- This version will be maintained as a stable one during further development.

GSnes9x project is a GNOME front end for the Snes9X SNES emulator
GSnes9x is a GNOME front-end for the Snes9X SNES emulator.
It allows setting and preservation of options for each ROM, and keeps a Cheat Codes database, an unlimited amount of codes can be stored.
Enhancements:
- Version 3.12 release
- remove help hackery, use Gnome help system
- include Snes9x Readme v1.37
- patch to use GSNES9X_IMAGE_DIR environment variable from morpheus2371
- Gnomified image loading

Cheyenne Secure Web Server (SWS) is a comprehensive enterprise solution for Apache server. Cheyenne Secure Web Server combines http firewall, JAVA, PHP, PERL and a domain control system with Apache HTTPD platform.

Messa is an instant messager client and server. The client has a curses interface and works on the console.

Messa project supports multilingual messages and private messages. The server supports monoprocess operation (without threads), the ability to choose the listening port, and the ability to run under the console.

Mail::Bulkmail is a platform independent mailing list module.

SYNOPSIS

use Mail::Bulkmail /path/to/conf.file

my $bulk = Mail::Bulkmail->new(
"LIST" => "~/my.list.txt",
"From" => "Jim Thomason" ,
"Subject" => "This is a test message",
"Message" => "Here is my test message"
) || die Mail::Bulkmail->error();

$bulk->bulkmail() || die $bulk->error;

Dont forget to set up your conf file!

Mail::Bulkmail gives a fairly complete set of tools for managing mass-mailing lists. I initially wrote it because the tools I was using at the time were just too damn slow for mailing out to thousands of recipients. I keep working on it because its reasonably popular and I enjoy it.

In a nutshell, it allows you to rapidly transmit a message to a mailing list by zipping out the information to them via an SMTP relay (your own, of course). Subclasses provide the ability to use mail merges, dynamic messages, and anything else you can think of.

Mail::Bulkmail 3.00 is a major major major upgrade to the previous version (2.05), which was a major upgrade to the previous version (1.11). My software philosophy is that most code should be scrapped and re-written every 6-8 months or so. 2.05 was released in October of 2000, and Im writing these docs for 3.00 in January of 2003. So Im at least 3 major re-writes behind. (philosophy is referenced in the FAQ, below)

But thats okay, because were getting it done now.

3.00 is about as backwards compatible to 2.00 as 2.00 is to 1.00. That is to say, sorta. Ive tried to make a note of things where they changed, but Im sure I missed things. Some things can no longer be done, lots are done differently, some are the same. You will need to change your code to update from 1.x or 2.x to 3.00, though. Thats a given.

So whats new for 3.00? Lots of stuff.

Immediate changes are:

* code compartmentalization
* multi-server support
* conf file

The immediate change is that the code is now compartmentalized. Mail::Bulkmail now just handles ordinary, non-dynamic mailings. See Mail::Bulkmail::Dynamic for the merging and dynamic text abilities from the prior versions.

Server connections are no longer handled directly in Mail::Bulkmail (Smtp attribute, Port attribute, etc.), there is now a separate Mail::Bulkmail::Server object to handle all of that.

And everything subclasses off of Mail::Bulkmail::Object, where I have my super-methods to define my objects, some helper stuff, and so on.
Its just a lot easier for me to maintain, think about it, etc. if its all separated. Its also easier for you, the user, if you want to make changes to things. Just subclass it, tweak it, and use it. Very straightforward to modify and extend now. 2.x and below *could* do it, but it wasnt really that easy (unless you were making very trivial changes). This should rectify that.

Another major change is the addition of multi-server support. See the docs in Mail::Bulkmail::Server for more information. You can still specify one SMTP relay if thats all youve got, but if you have multiple servers, Mail::Bulkmail can now load balance between them to help take the stress off. No matter what, the biggest bottleneck to all of this is network performance (both to the SMTP relay and then from the relay to the rest of the world), so i wanted to try and help alleviate that by using multiple servers. I know that some people were doing that on there own with small changes, but this allows you to do it all invisibly.
And finally, finally, finally there is a conf file. Documentation on the format is in Mail::Bulkmail::Object. Its pretty easy to use. This is the conf file format that I designed for my own use (along with most of the rest of Mail::Bulkmail::Object). The software also has the ability to read multiple conf files, if so desired. So no more worrying about asking your sysadmin to tweak the values in your module somewhere up in /usr/lib/whatever

Just have him create the conf file you want, or pass in your own as desired.
conf_files are specified and further documented in Mail::Bulkmail::Object, in an internal array called @conf_files, right at the top of the module. To specify a universal conf file, put it in that array (or have your sysadmin do so). Alternatively, you can also add a conf_file via the conf_files accessor.

Mail::Bulkmail->conf_files(/path/to/conf_file, /path/to/other/conf_file); #, etc.

But the recommended way is to specify your conf file upon module import.

use Mail::Bulkmail 3.00 "/path/to/conf/file";

In addition, there is the usual plethora of bug fixes, tweaks, clean-ups, and so on.

And yes, the horrid long-standing bug in the Tz method is fixed! No, honest.
Im also trying a new documentation technique. The pod for a given method is now in the module by that method, as opposed to everything being bunched up at the bottom. Personally, I prefer everything being bunched up there for clarities sake. But from a maintenance point of view, spreading it all out makes my life much easier.