Free computing accessories software for linux

VCG TriMeshInfo is a tool designed to inspect 3D models and retrieve many types of topological and geometrical information from them.
It can be used to automate the process of decoding 3D mesh inherent properties and ease data classification and retrieval.
For each analyzed dataset, the following data are extracted:
- Number of Vertices (Unreferenced vertices are listed separately)
- Number of Faces
- Number of Edges
- Number of Connected Components
- Number of Boundaries
- Number of Isolated Vertices (i.e. Unreferenced)
- Manifold
- Genus (Computed only for Manifold Datasets)
- Orientability
- Orientation
- Regularity (We consider as regular those meshes generated through regular subdivision. Each non boundary vertex of a regular mesh has 6 incident edges, if there are only 5 incident edges the mesh is said to be semi-regular, irregular in all other cases)
- Number of Duplicated Vertices
- Self-Intersection (Currently computed only for Datasets with less than 3M faces)
Enhancements:
- This release included a major rewrite of the core component for computing geometrical and topological features of the analyzed mesh.
- Important changes included speeded up self-intersection tests, more robust (and correct) computation of topological genus and volume, and more flexible output with an HTML output option.

Wazobia Linux is a complete Linux-based operating system designed and developed by Leapsoft.

Wazobia Linux distribution delivers quality desktop computing solutions that combine the best of open source technologies with a corporate attention to completeness, usability, and support.

It represents the next step in the evolution of the desktop computing in Africa and the rest of the developing world.

Wazobia Linux provides everything todays computer user needs for home and office desktop computing, including a stabilized, secure, stable and reliable, user-friendly Linux based operating system plus a complete set of desktop applications--office suite, Web browser, instant messaging client, multimedia viewers, and graphical software.

It also offers the latest open source applications for developing applications, setting up a home network, running a Web server, and more. Wazobia Linux includes more than 16,000 pieces of software, but the core desktop installation fits on a single CD.

The OS is accessible in Hausa, Yoruba and Igbo, to make users feel more at home in their computing environment. Leapsoft provides professional support for Wazobia Linux.

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.

libGlass is a library for distributed computing that makes its programming easy.
The Glass framework is a scalable set of components that can be used by applications to perform distributed computing. Applications are built reusing the available components as needed.
One of the major goals of libGlass is to be a user-friendly framework, not only suitable for new applications, but also for legacy code.
This is an important feature, as most available solutions for distributed computing require a substantial amount of rewrite of legacy code; some of them require a complete change of the application design.
libGlass was designed to achieve the following goals:
- User transparency: the library must be as transparent as possible. Any tasks that are repetitive or that can be done automatically should be done by the library, without user intervention.
The API (Application Programmers Interface) should be simple and intuitive, with a smooth learning curve and provide high level primitives that can be easily used to solve any problems. Legacy code should be easy to port.
- Extensibility: the library must be easily extensible, requiring no recompilation or any other modification to support new features; they must work as plug-ins.
- Performance and efficiency: since the library is for distributed computing, it has to be efficient, consuming as little processing time as possible.
- Network protocol independence: an abstraction layer makes it possible to change the underlying network protocols easily. The application can use the network protocol most efficient for its needs.
- Portability and interoperability: heterogeneous clusters and grid computing being every day more common, the library must be not only portable, but allow different architectures to interoperate seamlessly, something that is not true for most implementations of distributed computing solutions.
- Scalability: there is no use for a distributed solution that does not scale well. Glass has to work well in all sorts of environments, from small clusters to huge grids, and be able to adapt itself to achieve best results.
- Reconfigurable network architecture: most existing solutions are based on a fixed network architecture, usually Master/Slave or Client/Server.
Given the requirements of scalability and performance, and the fact that peer-to-peer applications are everyday more common, its unreasonable to fix the network architecture: the developer should be free to define how nodes will connect with each other.
- Reliability and fault tolerance: distributed computing often requires reliability. Its not acceptable that the misbehavior or crash of a single node crashes the entire computation.
As clusters grow in size and grid computing becomes more common, the MTBF (Mean Time Between Failures) shrinks to a point that it cannot be ignored.
libGlass must be able to handle node crashes gracefully, keeping the application running and avoiding deadlocks and other problems that could arise from the node crash. Nodes should be allowed to join or leave at anytime.
- Thread support: the library must be completely thread-safe.
With clusters of symmetric multiprocessors (SMP) computers becoming more common and new technologies such as HyperThreadingTM, its unacceptable for a distributed computing framework to have thread issues.
Main features:
Plugins:
- Synchronous shared memory
- Distributed asynchronous events
- Synchronization barriers
- Remote aliases
Protocols:
- TCP/IP
- UDP/IP (unfinished)
Architectures:
- Client/Server
- Pure peer to peer (planned)
- Hierarchical (planned)
- Anonymous peer to peer (planned)
Bindings for:
- Java (mostly finished)
Enhancements:
- Fixed packaging problems that could abort compilation

AirSnort is a wireless LAN (WLAN) tool which recovers encryption keys. AirSnort operates by passively monitoring transmissions, computing the encryption key when enough packets have been gathered.

802.11b, using the Wired Equivalent Protocol (WEP), is crippled with numerous security flaws. Most damning of these is the weakness described in " Weaknesses in the Key Scheduling Algorithm of RC4 " by Scott Fluhrer, Itsik Mantin and Adi Shamir.

Adam Stubblefield was the first to implement this attack, but he has not made his software public. AirSnort, along with WEPCrack, which was released about the same time as AirSnort, are the first publicly available implementaions of this attack.

AirSnort requires approximately 5-10 million encrypted packets to be gathered. Once enough packets have been gathered, AirSnort can guess the encryption password in under a second.