Free states 2.1 software for linux

Autostatus is a network and server monitoring program. The project is designed to support large, arbitrarily complex networks of computers, and still provide feedback in a very timely fashion. To that extent, it has the following goals:
- Speed - Autostatus attempts to probe for network status as quickly as possible.
- Efficiency - Autostatus will not attempt to check for status on portions of the network it already knows are down, eliminating redundant checks.
- Accuracy - Autostatus presents as accurate a picture of the network status as it can from its perspective.
Autostatus has some features which make it fairly unique among network monitoring programs:
Dependency Resolution
Autostatus can be given information about the path it takes to reach network segments, or other dependencies in network or server topology. Given this dependency information, autostatus will then query for status in the proper order in order to guarantee that:
- Nothing is queried before all of the items upon which it depends have already been queried.
- Nothing is queried if an item upon which it depends is down.
- Items are not incorrectly marked as down when they are simply unreachable due to a dependency failure.
This dependency resolution is, of course, fully recursive. The software will also warn about abnormal conditions in the configuration file such as cyclical dependencies.
Parallel status gathering
Autostatus uses the excellent fping program written by Roland J. Schemers III at Stanford University. (see the fping copyright below). By intelligently grouping services together for parallel testing, Autostatus minimizes the amount of time necessary to scan large numbers of networks or servers.
For testing TCP services, Autostatus uses a component called tcpcheck to perform parallel checks of TCP connections. tcpcheck was developed specifically for Autostatus, but has considerable utility outside of Autostatus.
Status Web Page
Autostatus automatically generates a status web page which reflects the current-known network and server status on a per-item basis.
Email notification
Autostatus sends email when the state of a monitored item changes (based upon configurable thresholds). Using an email to pager program (such as hellpage, by the author, or various other paging programs), it is very easy to route notifications for each service to the correct party.
Multiple service monitoring
Autostatus can monitor both routers/hosts via ICMP messages, and specific services on machines via TCP connections. In keeping with the themes of autostatus, TCP connections may be avoided if the machine is not reachable via ICMP, or may be tried at all times.
Usage: tcpcheck < timeout > < host:port > [host:port]

GNOME audio player based on GStreamer and Mono.

Sonance is a brand spankin new audio player based on the GStreamer media library and is developed on the Open Source Mono .NET Platform, written in C#. It uses the gst-sharp GStreamer bindings, which are currently only available via CVS.

Version 0.2 now supports shuffle/repeat modes, playlist searching, recursive directory additions, and saves the window/widget states in GConf.

Sonance may currently act as a simple drop-in XMMS/Beep replacement. It sports a basic playlist, with add/remove/clear/reorder support, and metadata support through GStreamer. Now that Sonance has a stable base, the goal is to create an entire music organization and playback platform, much like Rhythmbox and iTunes.

However, Sonance will have a much smaller footprint, and will be more versatile: you dont have to utilize a music library. Sometimes its just nice to have a standalone player that isnt dependent on any kind of database.

Sonance is multi-threaded. Playback is always smooth and fast, based on a solid, featureful GStreamer core, and adding lots of files to the playlist is no problem, because additions are done in a separate thread. Sonance is easy to use, simple, yet powerful, and its future is very bright.

Swing AutoMenu is a automatic menu generator that makes it easy to create JBarMenus and popup menus from XML definitions when building GUIs in Swing.
Main features:
Bar/Popup menu
- menu item
- checkbox item
- radio button item/group
- separator
- submenus
- support icons
- named disable map
- event dispatcher
Popup menu
- invoker state item - a special item that can be enable/disable according the state returned by a named function from invoker
- invoker state check - a special item used to change some named invoker state
- hintlist - a special item that can dinamicaly build a submenu with given list itens from invoker
Enhancements:
- Some new dynamic functions were added, like a hintlist that get a list from the invoker object and builds a submenu.
- Putting a bar menu in your application can now be done very easily by using the ABarMenu class.

Having worked with IP Filter on Solaris for a few years now, when I work on IP Tables in Linux I come to miss State Top. So I decided to write a version for IP Tables. IPTState is a state top along with a "single run" mode to quickly display states once. IP Tables State has customizable sorting (including reverse), customizable refresh rates, etc. etc. See the README, the man page and the -h option for details.

IPTState is now in the Debian, Redhat, Fedora Core, Mandrake, Gentoo, FloppyFW, and Devil Linux distributions as well as the pkgsrc project.

Sawdog (Simple Active Watch-DOG) is a suite of scripts that informs the system operators of mission critical servers in the case of a failure.

A set of small executables (i.e. expect scripts) are executed, and if one executable fails, it sends an email or an SMS to the sysop. There are 3 states known to sawdog: alive, unknown, and dead. Only certain state transitions trigger a notification.

On a Web interface, the states of all hosts are visible. So far, there are scripts to check for DNS, FTP, HTTP, HTTPS, ICMP, IMAP, MS SQL, MySQL, Notes, NTP, POP3, PostgreSQL, SMB, SMTP, SNMP, SSH, telnet, TWS, VNM, and Webmin.

FSA::Rules is a Perl module to build simple rules-based state machines in Perl.

Synopsis

my $fsa = FSA::Rules->new(
ping => {
do => sub {
print "ping!n";
my $state = shift;
$state->result(pong);
$state->machine->{count}++;
},
rules => [
game_over => sub { shift->machine->{count} >= 20 },
pong => sub { shift->result eq pong },
],
},

pong => {
do => sub { print "pong!n" },
rules => [ ping => 1, ], # always goes back to ping
},
game_over => { do => sub { print "Game Overn" } }
);

$fsa->start;
$fsa->switch until $fsa->at(game_over);

This class implements a simple state machine pattern, allowing you to quickly build rules-based state machines in Perl. As a simple implementation of a powerful concept, it differs slightly from an ideal DFA model in that it does not enforce a single possible switch from one state to another. Rather, it short circuits the evaluation of the rules for such switches, so that the first rule to return a true value will trigger its switch and no other switch rules will be checked. (But see the strict attribute and parameter to new().) It differs from an NFA model in that it offers no back-tracking. But in truth, you can use it to build a state machine that adheres to either model--hence the more generic FSA moniker.

FSA::Rules uses named states so that its easy to tell what state youre in and what state you want to go to. Each state may optionally define actions that are triggered upon entering the state, after entering the state, and upon exiting the state. They may also define rules for switching to other states, and these rules may specify the execution of switch-specific actions. All actions are defined in terms of anonymous subroutines that should expect an FSA::State object itself to be passed as the sole argument.

FSA::Rules objects and the FSA::State objects that make them up are all implemented as empty hash references. This design allows the action subroutines to use the FSA::State object passed as the sole argument, as well as the FSA::Rules object available via its machine() method, to stash data for other states to access, without the possibility of interfering with the state or the state machine itself.

Audacious is a media player based on BMP and XMMS. Audacious is a fork of beep-media-player 0.9.7.1.
Why did you fork beep-media-player?
First off, the fork has no political reasons, it is based entirely on technical merit. Its based on a few issues:
- There have been some quirks in beep-media-player that have annoyed users. (ID3v2 tag handling can be buggy for some users.)
- BMP classic is no longer actively maintained by the development team.
- We had our own ideas about how a player should be designed, which we wanted to try in a production environment.
- Beep lacked functionality that is useful for people who do streaming, such as the songchange plugin from XMMS.
Therefore, a fork seemed most logical as a choice for accomplishing our goals. descender &c have done very good work, but their ideas for a next-generation beep do not align with ours.
So, why not work with XMMS2?
Working with XMMS2 does not seem like the best choice for us because we are not interested in developing a media client. Were looking to develop a media player based on our concepts of design, functionality and usability. However, interest has been expressed for offering a "frontend mode" where the Audacious GUI acts as a frontend for XMMS2. This concept seems absolutely interesting, and will be investigated at a later date.
Were also fairly interested in a codesharing relationship with XMMS2 regarding codec support.
What about BMPx?
BMPx has a number of good concepts. Were very interested in sharing common code with them, including the new BMPx media library. That looks stunning in and of itself.
Will you support Winamp Modern skins?
Possibly in the future. We wish to make the player GUI an optional module, and even support operating Audacious as a media server, somewhat like XMMS2 -- for people who go that route.
Controlling BMP:
When you start up BMP, you will get a console very similar to that of WinAmp.
- On the top is the window title bar. To the right you will see 3 buttons,
Left button will minimize BMP.
Middle button will make BMP only display the title bar.
Right button will end the BMP session.
- The area in the upper left part displays the following:
- Play state: Paused, Stopped, or Playing
- Time elapsed in the current song or if you click on it, the reversed.
- Spectrum analyzer of the sound being played. Right mouse click will bring up the Visualization menu. Left mouse button will change the analyzer to an oscilloscope and/or none.
- To the right of the Spectrum analyzer is the title of the file being played.
This also contains the length of the song being played, as well as its position in the [unsorted] playlist. Right clicking in this window will bring up a new menu with some more options that are self explaining.
- In the left part of the Spectrum analyzer youll have letters (at least if you use the default skin) O A I D V. This is known as the "clutterbar. Left-clicking on these will open up menus or perform the listed actions.
O : Options menu
A : Always on top
I : File info box
D : Double size mode
V : Visualization menu
- Underneath the track title are the following static informational data:
- bit rate in KBps (usually 128 or 112)
- Sample Rate in KHz (usually 44)
- Stereo or Mono channel mixing
- Underneath the informational data are a few controls you can play with:
- The first slider controls the volume
- The second slider controls the balance between speakers
- The button marked "EQ" loads up the graphic equalizer
- The button marked "PL" loads up the playlist editor
- The LARGE slide bar moves from left to right as the song plays. You can
drag this to jump to another location in the current file.
- On the bottom of the console are the standard buttons you would see on a CD player: Previous track, Play, Pause, Stop, Next track, eject, shuffle and repeat.
- The eject button doesnt REALLY eject, of course. It opens up the file requester. The File Requester builds a playlist for the current BMP session. You can use it to load files, add files to the list, or load all mp3s in a directory.
- The shuffle button randomizes the sequence of the playlist.
- The repeat button when enabled makes the playlist loop when it reaches the end of the playlist.