Free fizzball 1.01 software for linux

MOOzilla provides a MOO/MU* client that supports HTML rendering.
MOOzilla is an HTML rendering MOO/MU* client developed as an add-on component for Mozilla. It allows inline HTML text to be rendered as part of a MOO/MU* session, similar to the Windows-only Pueblo client, but with the power of the Mozilla rendering engine.
Main features:
- Command history
- Scrollback buffer
- Text configuration
- Tab completion
- Context web search
- Automatic hyper-linking
- Command hyper-links
- Inline HTML rendering
- HTML entity rendering
- Independent Single and Multiline Text Edit
- Unicode UTF-8 input and output (screenshot)
- HTML logging (with timestamps) and log viewer

Filemerge is a tools that allows you to merge two files in to one big file. Filemerger will run under linux but will not work with Freebsd.
Usage:
fm [argument] file1 file2 newfile
-v Display the version of mlm
-? Display this help file.
Example:
This will read the file test1, test2 and write all the file contents to the file test3.
fm /root/test1 /root/test2 /root/test3
File test1:
Line 1
Line 2
File Test2
Line2
Line3
File Test3
line1
Line2
Line3
Enhancements:
- Changes were made to the help file.

Memoize - Make functions faster by trading space for time.

SYNOPSIS

# This is the documentation for Memoize 1.01
use Memoize;
memoize(slow_function);
slow_function(arguments); # Is faster than it was before

This is normally all you need to know. However, many options are available:

memoize(function, options...);

Options include:

NORMALIZER => function
INSTALL => new_name

SCALAR_CACHE => MEMORY
SCALAR_CACHE => [HASH, %cache_hash ]
SCALAR_CACHE => FAULT
SCALAR_CACHE => MERGE

LIST_CACHE => MEMORY
LIST_CACHE => [HASH, %cache_hash ]
LIST_CACHE => FAULT
LIST_CACHE => MERGE

`Memoizing a function makes it faster by trading space for time. It does this by caching the return values of the function in a table. If you call the function again with the same arguments, memoize jumps in and gives you the value out of the table, instead of letting the function compute the value all over again.

Here is an extreme example. Consider the Fibonacci sequence, defined by the following function:

# Compute Fibonacci numbers
sub fib {
my $n = shift;
return $n if $n < 2;
fib($n-1) + fib($n-2);
}

This function is very slow. Why? To compute fib(14), it first wants to compute fib(13) and fib(12), and add the results. But to compute fib(13), it first has to compute fib(12) and fib(11), and then it comes back and computes fib(12) all over again even though the answer is the same. And both of the times that it wants to compute fib(12), it has to compute fib(11) from scratch, and then it has to do it again each time it wants to compute fib(13). This function does so much recomputing of old results that it takes a really long time to run---fib(14) makes 1,200 extra recursive calls to itself, to compute and recompute things that it already computed.

This function is a good candidate for memoization. If you memoize the `fib function above, it will compute fib(14) exactly once, the first time it needs to, and then save the result in a table. Then if you ask for fib(14) again, it gives you the result out of the table. While computing fib(14), instead of computing fib(12) twice, it does it once; the second time it needs the value it gets it from the table. It doesnt compute fib(11) four times; it computes it once, getting it from the table the next three times. Instead of making 1,200 recursive calls to `fib, it makes 15. This makes the function about 150 times faster.

You could do the memoization yourself, by rewriting the function, like this:

# Compute Fibonacci numbers, memoized version
{ my @fib;
sub fib {
my $n = shift;
return $fib[$n] if defined $fib[$n];
return $fib[$n] = $n if $n < 2;
$fib[$n] = fib($n-1) + fib($n-2);
}
}

Or you could use this module, like this:

use Memoize;
memoize(fib);

# Rest of the fib function just like the original version.

This makes it easy to turn memoizing on and off.

Heres an even simpler example: I wrote a simple ray tracer; the program would look in a certain direction, figure out what it was looking at, and then convert the `color value (typically a string like `red) of that object to a red, green, and blue pixel value, like this:

for ($direction = 0; $direction < 300; $direction++) {
# Figure out which object is in direction $direction
$color = $object->{color};
($r, $g, $b) = @{&ColorToRGB($color)};
...
}

Since there are relatively few objects in a picture, there are only a few colors, which get looked up over and over again. Memoizing ColorToRGB sped up the program by several percent.

Luca is our new accounting software project. Luca is meant to be a rewritten version of CTB. The main development framework is Python+TurboGears.
Luca is named after Luca Pacioli, the man invented the double-entry accounting method.
Luca is still in early stages of development. Thanks for your patience.
The main framework is TurboGears, so a fair amount of Lucas architecture comes directly from TurboGears stack: Javascript+Mochikit for client-side trickery and AJAX; Kid for HTML templating; CherryPy as controller framework, and SQLObject as database-neutral model.
It was decided long ago (from 2000) that the base development language would be Python, since it has been the best interpreted language around. The next question was which Web framework to use (or go solo and create a mini-framework from scratch). The framework should be free, unobtrusive, "Pythonic" and have a fair learning curve.
Before TurboGears, Zope was considered for Luca. It has really being pushed by the Python community as the "Python on Rails". Zope proved to be too bureucractic (too much typing for too little work) and difficult to learn. However, some specific Zope components e.g. ZODB are really of great value and could be reconsidered for Luca adoption in the future.
Enhancements:
- The code was updated to Turbogears 1.0.2.2 and Python 2.5.
- A ton of bugfixes and many improvements were made.

KObelisk is a tool that connects to the Asterisk PBX and gives information to the user about incoming calls. KObelisk also provides some basic functions like calllists, ringtones or a callback function.

Installation:
1) use ./install.sh (as root) to install after this you will find a KObelisk entry in your menu

2) start the program

3) configure KObelisk by rightclicking on the little KObelisk Icon at the traybar (most important is the Asterisk module configuration)

Mcube project is a 4x4x4 Rubiks Cube solver.
Mcube solves 4x4x4 Rubiks Cubes. It is platform independent and supports both a pipable console-only format and a graphical format.
CGI version:
First finished release of mcube Solves 4x4x4 rubiks cube via a CGI web-based environment. The cube class can be used in other programs as well.
Command-line version:
This is the command-line version of the 4x4x4 solver. The algorithm is identical to the normal (CGI) version. Use this if you like do-it-yourself console programs.
Enhancements:
- Fixed concise() bug not updating mov[] correctly.
- Added "input page" generator on output page, for easier debugging.

MACTS project is a traffic shaper that uses MAC addresses which are associated with users to classify traffic.
This allows fair usage of bandwidth among many machines. Additionally, there is a statistics monitor which displays current statistics on the terminal or stores them in round robin databases.
The stored data may then be used to generate graphs with the included Perl/CGI scripts. The configuration file is straight-forward and requires little knowledge of networking or the underlying traffic control mechanism. Setup should be easy.
Components:
macts - This clears the current traffic classifiers and sets up new ones, as directed by /etc/macts/macts.conf. It also stores some temporary state data in /etc/macts/handles.cache.
macts-stats - With no args, this displays statistics on a terminal, including data rate (kb/s), packet rate (packets/s), and backlog (packets) for each machine. Given the -r flag, it stores the statistics in round robin databases (one for each machine), located in /etc/macts/stats/.
macts-chart - This is a CLI chart generator which reads data from RRDs stored in /etc/macts/stats/.
macts-chart.cgi - This is a CGI wrapper for macts-chart.
Installation:
- mkdir /etc/macts
- mkdir /etc/macts/stats
- create /etc/macts/macts.conf
- add the following lines to /etc/sysctl.conf:
net.ipv4.conf.default.accept_source_route = 1 # is this necessary?
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
- move macts, macts-stats, and macts-chart to /usr/local/bin/.
- (optional) install rrdtools and the perl rrdtool interface
- (optional) add the following line to roots cron:
*/5 * * * * /usr/local/bin/macts-stats -r 2&> /dev/null
- (optional) move macts-chart.cgi to your web servers cgi directory.
Enhancements:
- Installation instructions have been fixed.

issPolicy is a free open-source utility for converting an ISS RealSecure Network Sensor and ISS Proventia Inline Appliance Policy to a static HTML file.
Written in Perl, issPolicy allows for granular parsing of ISS RSNS and ISS Proventia policies (also refer to the "support" section), and supports a wide variety of features (see "features" section) allowing the HTML generation to be customized based on different policy parameters.
Main features:
- issPolicy automatically detects whether the policy is a ISS RealSecure Network Sensor or ISS Proventia Inline Appliance policy and generates a static HTML file based on the policy type and its features.
- issPolicy extracts the following information from the ISS RealSecure Network Sensor Policy:
- Signatures Policy (Signature Name, Signature Description, Signature Status, Signature Priority, Configured Responses, Logging Type)
- IP Filters Policy (Filter Name, Filter Description, Filter Status, Protocol, Source Address, Source Port, Destination Address, Destination Port)
- Event Filters Policy (Filter Name, Filter Description, Filter Status, Filtered Event, Source Address, Source Port, Destination Address, Destination Port)
- issPolicy extracts the following information from the ISS Proventia Inline Appliance Policy:
- Signatures Policy (Signature Name, Signature Description, Signature Status, Signature Priority, Configured Responses, Logging Type, Drop Options, DynamicBlock Options)
- IP Filters Policy (Filter Name, Filter Description, Filter Status, Protocol, Source Address, Source Port, Destination Address, Destination Port)
- Event Filters Policy (Filter Name, Filter Description, Filter Status, Filtered Event, Source Address, Source Port, Destination Address, Destination Port)
- issPolicy contains various useful options allowing for a tailored HTML Policy file to be generated, based on one or more of the following criteria:
- Signature Policy Criteria:
- Whether signature is enabled or disabled
- Based on signature priority (High, Medium, or Low)
- Whether drop is enabled [only on ISS Proventia Inline Appliance Policies]
- Based on drop options (ConnectionWithReset, Connection, or Packet) [only on ISS Proventia Inline Appliance Policies]
- Whether dynamicblock is enabled [only on ISS Proventia Inline Appliance Policies]
- Based on dynamicblock options (IsolateTrojan, BlockWorm, BlockIntruder) [only on ISS Proventia Inline Appliance Policies]
- IP Filter Policy Criteria:
- Whether IP filter is enabled or disabled
- Event Filter Policy Criteria:
- Whether Event Filter is enabled or disabled
- issPolicy uses an "API" structured format, pushing the entire policy to hash arrays, allowing the possibility for other output methods to be developed (CSV, XML, etc...)