Free uniform software for linux

Antiprism project is a suite of programs for the generation, manipulation, and visualisation of polyhedra.
Make a cube
This can be done with unipoly, which can be used to make all the uniform polyhedra.
unipoly cube > cube.off
Display with
off2pov -o cube.pov cube.off
povray +a +p cube.pov
Make the dual octahedron
pol_recip is used for making duals by polar reciprocation.
To make a nice compound the radius of the sphere used for reciprocation needs to be the distance from the cube centre to the mid-point of an edge, and the sphere centre must be the centre of the cube.
unipoly has centred the cube on (0, 0, 0), which is the default centre for pol_recip. The radius can be specified using the -R option and passing two adjacent vertex index numbers of the cube. Use off2pov with the -n option to display the cube with its vertex numbers.
off2pov -x vf -n -o cube.pov cube.off
povray +a +p cube.pov
Vertices 3 and 5 are adjacent, so make the dual octahedron like this, and display it.
pol_recip -R 3,5 cube.off > oct.off
off2pov -o oct.pov oct.off
povray +a +p oct.pov
Merge the polyhedra
OFF files are merged with off_merge
off_util cube.off oct.off > cub_oct.off
Display the result.
off2pov -o cub_oct.pov cub_oct.off
povray +a +p cub_oct.pov
Use colours
To make it clearer that this is a compound of a cube and octahedron the two polyhedra could be given different colours using off_color.
Colour the cube faces red, and the octahedron faces green.
off_color -f 1,0,0 cube.off > red_cube.off
off_color -f 0,1,0 oct.off > green_oct.off
Now merge and display as before, this time making the edge and vertex elements smaller than the defaults
off_util red_cube.off green_oct.off > color_cub_oct.off
off2pov -v 0.02 -e 0.016 -o color_cub_oct.pov color_cub_oct.off
povray +a +p color_cub_oct.pov
Enhancements:
- Edge handling has been improved.
- The GLU tesselator is used for all polygon tesselation, making polygon display more consistent in export formats.
- The minimum enclosing ball is used for camera positioning, allowing better use of screen space.
- Special duals can be calculated automatically.
- There is a new program which spirals points on a sphere, and another which arranges points in rings on a sphere.

RCUNIT is a robust C unit testing framework. Requiring only an ANSI compliant C compiler, It is a highly portable testing tool.
Main features:
- Uniform interfaces for managing test cases
- Optional setup and tear down functions for each test case (test function) to isolate a particular test.
- Optional setup and tear down functions for each test suite (test module).
- Multiple test registries and test suites for structuring test cases. Also provides a default test suite and default test registry.
- Output redirection mechanism to redirect log and test run report when a file I/O facility is not available in the test platform.
- Log handler mechanism for redirecting logs.
- Allows optional test run callback function (test run hook).
- Alternative mechanism to ANSI Cs assert() function (non-test run assertions). Also allows assertion callback function (assertion hook)
- A runtime memory leak check facility
- An extensible exception handling mechanism
Enhancements:
- This is is the pre-release version of 1.0.
- There were no major changes from version 0.1, and it is fairly stable.

Surumi project is a modular event-driven programming framework. It offers a generic and uniform interface.

You certainly heard of event-driven programming, but in any window system,
those events are usually bound on ``window objects and very few pre-defined
events could be chosen. Yes, I know they always give you so call ``client data
and you could carry everything by those ugly ``void-typed pointer.

Now you have another good choice, your program would be ``plug-in based,
and they are vivid module rather than those GUI toys (or gadgets), you have
any possible event type with any possible client data carried. Ah~ this is
what we called ``modular.

It originated from an idea of home theater framework ``freevo by Python
but Surumi offered more generic and uniform interface to do better jobs.
You will be very surprised about how such a flexible programming model would give you so much fun during your projects development.

It has a core event engine to dispatch every programming logics via events.
As we know that such an event-driven programming model gives the best mechanism to those response interaction via ``on-demand occasion.

When your project is decomposed into event-driven working logics, you will find how it provides the flexibility can ease the jobs and this also prevents many cases of multi-threading. Yes, you have a good opportunity to dump those annoyed threads.

Besides, this works very efficiently, very little overhead, very tiny footprint
of executable image size if you wish. Why not try it today and your program speaks to you naturally and lively amongst the codes.

Since this is a GPL project, your program would become GPL if you used Surumi. However, I am not a selfish programmer, contact me if you have any concern about GPL or you want to use this in your commercial projects. By some other possible extra service, you may have a contract deal with me and my framework.

1). You need choose either libevent or nano-X as surumis core event engine Use freshmeat.net or any other search engine to locate these source projects.

2). It supports uClibc++ and certainly you will be familiar to it if you work on uCLinux platform (a non-MMU Linux usually used in an embedded system).

3). It has a X86 emulation sample which always needs libevent. Thus, if you want to begin your programming journey, go to libevent site and retrieve the up-to-date copy.

Again, this is just a beginning, I wish you will know how this architecture
can help your application to be easier to extend.

Animadead is a skeletal animation library designed to load and play skeletal animations.
Animadead supports models that are composed of several swappable meshes bound to a single skeleton that can be driven by multiple animations. There is an export plug-in for Maya, and others are in development, including plug-ins for 3D Studio Max and Lightwave.
It is written in C++ and has no dependencies. However, an example implementation is provided that uses OpenGL and SDL.
I wrote a shader in CG for OpenGL, which didnt work well on my system, I think due to the best OpenGL CG profile my card supported doesnt utilize the full potential of my card, and I had trouble with passing the list of bone matrices to the card.
The compiler for the supported profile had a ridiculously low number of uniform parameters I could send. So for my simple boxman demo, which has 41 bones or so, I couldnt get it to work, and I didnt feel like making a model with fewer bones.
So after running into a bit of trouble with CG, I wrote a shader in GLSL, which at first had problems as well, but it turns out all I needed to do was upgrade my graphics drivers. Once I did that I got the shader to work, and its nice and fast.
I plan to have both shaders working well and will provide them with the next release.
Main features:
Exporting and file types:
- Custom file types used for meshes and animations.
- Meshes can be static, or deformable and bound to all or a subset of the skeleton.
- Animations use a skeletal hierarchy and local transformations for every bone at every frame.
Loading files:
- The library loads and caches animations and meshes by filename.
- Meshes are broken down into surfaces, which have a texture name, vertices, faces, and a pointer to user defined data.
- A callback function can be set that can load textures when the mesh is loaded, and set the user data for that surface.
- Models in animations can be moving, but when the model is loaded, the movement of the root bone is extracted and removed. This information is stored, and can be used to move the frame of the model at the speed the modeler intended or used to scale the speed of the animation.
Setup (initialize):
- A model is composed of several animations and swappable meshes, but can also contain blends and bone selection masks.
- Blends are used to calculate a pose, usually from two other poses.
- One type of blend is an animation player, which is used to keep track of the current time in the animation and can generate a skeletal pose at that time (between two frames).
- Another type of blend is a blend between blends. When this blend is calculated, it first calculates the two blends its blending, and then blends those together with a user-defined weight. Since this is a recursive definition, blends can in fact be setup in a hierarchy, and the user only needs to call the top level calculate function.
- A bone selection mask is a selection of a subset of the entire skeleton. The hierarchy is used to make the selection process simpler. Essentially, all bones are the same selection state as their parent, unless set directly.
- In addition to being able to calculate a pose from a complex system of blends, the calculate function can be given an optional bone selection mask, which limits the calculations done for that blend to only the subset of bones defined by the selection. This allows you to calculate different parts of a skeleton with different animations.
Drawing:
- The library doesnt actually draw the model, but provides all of the necessary information for your engine to draw the model.
- Data is prepared and organized for use in vertex shaders.
- A pose can be converted to a set of matrix world transformations. (Most shaders like the data like this)
- Examples are shown that actually draw the model.

bandwidth monitor is a small application which polls /proc/net/dev for the byte counts for a given network device , and calculates the RX and TX bandwidths. Originally a shell script, then a Perl script, now rewritten in C so that it can easily be used on embedded devices like the Linksys WRT54G as well as.

This program started as a shell script that I ran on my home-brew firewall wireless router (Linux, of course, on a 486/66) to keep track of my incoming and outgoing bandwidth. This let me know that I was getting the bandwidth that I paid for, and it also helped me keep an eye on the throttling of bulk traffic so that I didnt choke out my interactive sessions. Of course, that was before I had QOS.

The program is probably tied to Linux, since it grabs the byte counts for the requested interface right from /proc/net/dev. It could pretty easily be modified to grab the same information from the output of /sbin/ifconfig, but that would waste resources to spawn a new process to parse the /proc/net/dev file and regurgitate it to us. Also, I havent bothered to look at how uniform the output of the byte counts from /sbin/ifconfig is on other operating systems.

As a side note, the C version also uses nanosleep() and gettimeofday() to get more accurate polling intervals and track the overall time (since sleep(), usleep(), nanosleep(), et. al. only guaruntee to wait at least as long as you request, but do not guaruntee that it wont be possibly much longer...) So, if you were interested in porting it, youd have to make sure that nanosleep() and gettimeofday() were also available, or lose the resolution of the time used in bandwidth calculations.

BUILDING

$ gcc -O3 -o bandwidth_monitor bandwidth_monitor.c

URI is Uniform Resource Identifiers (absolute and relative). This module implements the URI class. Objects of this class represent "Uniform Resource Identifier references" as specified in RFC 2396 (and updated by RFC 2732).

A Uniform Resource Identifier is a compact string of characters that identifies an abstract or physical resource. A Uniform Resource Identifier can be further classified as either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). The distinction between URL and URN does not matter to the URI class interface. A "URI-reference" is a URI that may have additional information attached in the form of a fragment identifier.

An absolute URI reference consists of three parts: a scheme, a scheme-specific part and a fragment identifier. A subset of URI references share a common syntax for hierarchical namespaces. For these, the scheme-specific part is further broken down into authority, path and query components. These URIs can also take the form of relative URI references, where the scheme (and usually also the authority) component is missing, but implied by the context of the URI reference. The three forms of URI reference syntax are summarized as follows:

< scheme >:< scheme-specific-part >#< fragment >
< scheme >://< authority >< path >?< query >#< fragment >
< path >?< query >#< fragment >

The components into which a URI reference can be divided depend on the scheme. The URI class provides methods to get and set the individual components. The methods available for a specific URI object depend on the scheme.

countertrace project is a userland, iptables QUEUE target handler for Linux 2.4 kernels running Netfilter, which attempts to give the illusion that there are multiple, imaginary IP hops between itself and the rest of the world.

The imaginary hops that countertrace projects also have the ability to introduce accumulative, imaginary latency.

How it works:

Netfilter provides a mechanism for passing packets for processing to a userland program, which can examine the packet and determine if it should be permitted through or dropped on the floor. countertrace utilizes this mechanism to drop received packets which have a TTL less than the number of hops its attempting to project, and then generates ICMP time-exceeded messages for those dropped packets with the source address of the bogus hop. If latency is also being simulated, the generated time-exceeded messages are queued for the specified period of time before being sent.

Requirements:

countertrace requires the NetPacket, Time::HiRes, and IPTables::IPv4::IPQueue perl modules, available from CPAN, the Net::RawSock and a Linux 2.4 kernel with iptables (CONFIG_IP_NF_IPTABLES) and QUEUE target (CONFIG_IP_NF_QUEUE) support. If latency is not being simulated, iptables TTL match support (CONFIG_IP_NF_MATCH_TTL) may also be useful.

Configuration:

The countertrace program takes only one command line argument, the name of its configuration file. To get started, the only configuration file command you need to know about is the "hop" command, which takes the form of "hop < address > [latency]". Hops must be added in the order in which they are to be simulated. Latency is accumulative -- at run time, the latency for each hop is determined by calculating the sum of all previously specified latency values. Additional configuration commands are available for specifying how much information is logged for each received packet; see the example-hops-configuration file for more information.

In addition to configuring countertrace itself, iptables must also be configured to pass packets to countertrace for processing using the iptables QUEUE target. If latency is not being simulated, the iptables TTL match support can be used to only pass packets to countertrace which have a TTL less than or equal to the number of hops being simulated. Otherwise, more than likely youll want all received packets to pass through countertrace, so that the latency will appear to be uniform when tracerouting, in addition to when transferring data. However, the danger is that if the countertrace program dies for any reason, iptables will drop any packets which would have been queued for userland processing, rendering the box unreachable to the outside world. To avoid the problem, it may be wise to specify at least one "backdoor" address from which packets will be accepted without passing through countertrace.

For an example startup script, see the example-startup-script.sh file.