Free delayed shutdown 2.01 software for linux

livecoding 2.01 is yet another excellent utility for any developers It actually provides code reloading support library for Python.

There are two key facets this library:

• The code reloading functionality it provides.
• The bypassing of the standard module system with a custom one.

The standard module system is still there and continues to work with the custom one, but only the custom one is covered by the code reloading functionality of this library.

In order to decide whether you want the flexibility of the code reloading that this library provides, you need to decide whether you can live with writing the reloadable scripts within the custom module system.

Major Features:

1. Automatic code reloading on script file changes.
2. Less interruptions to developer workflow.
3. Code reloading allows a running application to change its behaviour in response to changes in the Python scripts it uses. When the library detects a Python script has been modified, it reloads that script and replaces the objects it had previously made available for use with newly reloaded versions.
4. As a tool, it allows a programmer to avoid interruption to their workflow and a corresponding loss of focus. It enables them to remain in a state of flow. Where previously they might have needed to restart the application in order to put changed code into effect, those changes can be applied immediately.

Requirements:

• Python

Rad SFTP Applet is a graphical secure FTP (SFTP) applet. It is multi-threaded and thus capable of carrying out several concurrent uploads and downloads and resuming interrupted transfers.
The applet received a four star rating from jars.com - the premier java software review site and became featured on the official java website as well.
The secure FTP applet is ideal for Internet Service Providers and web hosting companies as a value addition to their service. The applet will also help web and software companies to reduce license costs with its per web site license model.
The desktop client is suited for individuals or organizations looking for a secure alternative to FTP.
Enhancements:
- Bugfixes and other improvements related to the management of hidden files and folders.

etherdump project is a very small and efficient ethernet sniffer.
EtherDump is a fork by Peter Willis of ipdump2-pre1 (by Christophe Devine) with a few small improvements and feature add-ons with the end result being able to stream raw frames over a network and eventually convert them into pcap format and import into a pcap-reading prog of your choice (I personally love Ethereal).
Pretty simple use; just run the prog with no arguments and you will get the usage instructions. Log a session to a file using ASCII hex dump and when you are done run `text2pcap hex_dump pcap_file and read `pcap_file with Ethereal or another libpcap-aware program.
Since version 2.01 EtherDump supports some minimal packet filtering rules. Some of the rules you can use are "proto" or "protocol", "sport" or "sourceport", "dport" or "destinationport", "src" or "source", and "dst" or "destination". You can also give "!" or "not" to negate a particular rule.
If you execute EtherDump from a symlink named "tcpdump", the default print out method is tcpdump-like.
On uClibc the compiled size is ~8kB so this is very well suited for embedded systems where you want to debug a network interface but dont have room for a whole libpcap+application_layer program. Instead just combine netcat or a CGI script + httpd with EtherDump and read the traffic (converted to pcap) on another machine on the network.
Enhancements:
- Changes by Peter Willis since 2.0:
- Changed configuration option to reflect new name is "etherdump", not "packetdump". -p is now -e.
- Added basic [ipv4] filtering rules.
- Improved tcpdump output.
- If etherdump was run as a program named tcpdump, defaults to tcpdump-like output.
- Added -i to specify interface.
- If EtherDump is executed as "tcpdump", tcpdump-like output is the default output type.

JoeDog::Config provides a perl extension for parsing data/configuration file.

It reads columns, key-value pairs, and INI style config files into arrays, hashes and hashes of hashes. It can take characters or regexes for separators.

ABSTRACT:
This is a autoloadable module which allows the programmer
to read data from an configuration file into various perl
data types, arrays, multi-dimentional arrays and hashes.

INSTALLATION
JoeDog::Config.pm was built using perl Make::Maker utility
If you are familiar with that utility you should have no
problem with this installation as it will be familiar:

$ perl Makefile.PL
$ make
$ make test
$ su
$ make install

USAGE
use JoeDog::Config;
my $cnf = new JoeDog::Config(filename);
my @array = $cnf->get_column();
my @arrays = $cnf->get_columns(sep);
my @aoa = $cnf->get_table(sep,num);
my @aoa = $cnf->get_table(sep,[num1, num2, etc...]);
my %hash = $cnf->get_hash(sep);
my %hashes = $cnf->get_hashes(sep);

AtExit is a Perl module that can perform exit processing for a program or object.

SYNOPSIS

use AtExit;

sub cleanup {
my @args = @_;
print "cleanup() executing: args = @argsn";
}

## Register subroutines to be called when this program exits

$_ = atexit(&cleanup, "This call was registered first");
print "first call to atexit() returned $_n";

$_ = atexit("cleanup", "This call was registered second");
print "second call to atexit() returned $_n";

$_ = atexit("cleanup", "This call shouldve been unregistered by rmexit");
rmexit($_) or warn "couldnt unregister exit-sub $_!";

if (@ARGV == 0) {
## Register subroutines to be called when this lexical scope is exited
my $scope1 = AtExit->new( &cleanup, "Scope 1, Callback 1" );
{
## Do the same for this nested scope
my $scope2 = AtExit->new;
$_ = $scope2->atexit( &cleanup, "Scope 2, Callback 1" );
$scope1->atexit( &cleanup, "Scope 1, Callback 2");
$scope2->atexit( &cleanup, "Scope 2, Callback 2" );
$scope2->rmexit($_) or warn "couldnt unregister exit-sub $_!";

print "*** Leaving Scope 2 ***n";
}
print "*** Finished Scope 2 ***n";
print "*** Leaving Scope 1 ***n";
}
print "*** Finished Scope 1 ***n" if (@ARGV == 0);

END {
print "*** Now performing program-exit processing ***n";
}

The AtExit module provides ANSI-C style exit processing modeled after the atexit function in the standard C library (see atexit(3C)). Various exit processing routines may be registered by calling atexit and passing it the desired subroutine along with any desired arguments. Then, at program-exit time, the subroutines registered with atexit are invoked with their given arguments in the reverse order of registration (last one registered is invoked first). Registering the same subroutine more than once will cause that subroutine to be invoked once for each registration.

An AtExit object can be created in any scope. When invoked as a function, atexit registers callbacks to be executed at program-exit time. But when invoked as an object-method (using the $object->method_name syntax), callbacks registered with an AtExit object are executed at object-destruction time! The rules for order of execution of the registered subroutines are the same for objects during object-destruction, as for the program during program-termination.

The atexit function/method should be passed a subroutine name or reference, optionally followed by the list of arguments with which to invoke it at program/object exit time. Anonymous subroutine references passed to atexit act as "closures" (which are described in perlref). If a subroutine name is specified (as opposed to a subroutine reference) then, unless the subroutine name has an explicit package prefix, it is assumed to be the name of a subroutine in the callers current package. A reference to the specified subroutine is obtained, and, if invocation arguments were specified, it is "wrapped up" in a closure which invokes the subroutine with the specified arguments. The resulting subroutine reference is added to the front of the list of exit-handling subroutines for the program (atexit) or the AtExit object ($exitObject->atexit) and the reference is then returned to the caller (just in case you might want to unregister it later using rmexit. If the given subroutine could not be registered, then the value zero is returned.

The rmexit function/method should be passed one or more subroutine references, each of which was returned by a previous call to atexit. For each argument given, rmexit will look in the list of exit-handling subroutines for the program (rmexit) or the AtExit object ($exitObject->rmexit) and remove the first matching entry from the list. If no arguments are given, then all program or object exit-handlers are unregistered! The value returned will be the number of subroutines that were successfully unregistered.

At object destruction time, the DESTROY{} subroutine in the AtExit module iterates over the subroutine references in the AtExit object and invokes each one in turn (each subroutine is removed from the front of the queue immediately before it is invoked). At program-exit time, the END{} block in the AtExit module iterates over the subroutines in the array returned by the exit_subs method and invokes each one in turn (each subroutine is removed from the front of the queue immediately before it is invoked). Note that in both cases (program-exit, and object-destruction) the subroutines in this queue are invoked in first-to-last order (the reverse order in which they were registered with atexit).

rshaper is a Linux kernel module that limits the incoming bandwidth for packets aimed at different hosts.

While the former issue can be addressed with the conventional shaper driver, the latter cant be easily addressed by the standard shaper. As a matter of facts, I have not been able to use the shaper to address the former situation, either; this because effective filtering can only be achieved through source-routing, but when I had to deal with this problem, the shaper only existed for Linux-2.1 while my production setup was constrained to be 2.0. Moreover, with netfilter and rshaper the outgoing traffic can be shaped

While running rshaper with 2.0 and 2.2 requires patching the network driver, the 2.4 "netfilter" feature helps rshaper by avoiding the need to patch the netword driver.

The Zaval Proxy Suite is an easy-to-use solution that allows monitoring TCP-based protocols, such as HTTP, NNTP and others. It is extremely useful in software development and can be used as a debug tool. Another area of appliance is multiple connections logging with proxy facilities. As soon as its a pure java solution it can be used almost everywhere.

The Zaval Proxy functions as a proxy and transfers data between the server and the client writing incoming and outgoing traffic into log files. So you can see these raw data as is.

On start the Zaval Proxy Suite goes through configuration file and creates the specified number of proxy servers and the shutdown server.

"Proxy server" is a server socket listening on the specified port. When the client is connected proxy connects to the target server and transfers data between them logging entire traffic. On each connection 2 files are created - xxx-input (request data from the client) and xxx-output (response data from the server). The "xxx" means here the sequential number of the connection for the proxy server. The traffic is logged into the separate directory for each proxy.

Shutdown server is needed to close all open connections correctly and close the program.

So, in the particular case you should specify address of proxy server in client application (web browser, for example) and address of the target server in the proxy configuration file. You can create any number of proxy servers that run at the same time, however, they should use different port numbers.