Free a gen software for linux

A-Gen is a web album generator tool that generates static web pages from templates. Templates are just like normal HTML-files with some minor markup for the template processor. A-Gen project takes a template and a set of pictures and outputs a directory containing a web album consisting of static HTML pages.
With A-Gen you can create static web albums feasible for use directly from a directory. Therefore you are not bound to using a webserver (although you can of course put such an album into a directory served by a webserver).
As the album consists of static HTML files only, no further software is needed (apart from a browser of course). These albums should be so easy to use, you could even send one your mother-in-law without getting badly hurt (ok, depends on the contents of your album).
Main features:
- No special software required to view the albums (webbrowser only)
- Low performance requirements (as the albums are static HTML pages, serving can be done without much memory or processor power)
- Decent template system for creation of album themes (templates are based on HTML with a handful of simple template commands)
- standards conformance (depending on the template used, webalbums will comply with HTML or XHTML standards)
- fast (the software is written in C++ so creation of the albums does not depend on some heavy weight interpreter)
Enhancements:
- This release fixes compilation bugs with GCC 4.x (already done in the unreleased 0.1.1 version).
- It fixes dependency problems on Ubuntu and Debian unstable.

Daizu::Gen is a default generator class.

This class, and subclasses of it, are responsible for deciding which URLs should be created (generated) from each file or directory in a working copy, and generating the output which will be served for those URLs. This class itself is used by default, but you can use a different generator class by setting the daizu:generator property to the name of a Perl class. If you set it on a file, it will affect only that file. If you set it on a directory then it will affect that directory and all its descendants, unless they themselves have a daizu:generator property.

The name of the generator class used for each file and directory is stored in the generator column of the wc_file table in the database.

When an object of a generator class is instantiated, it must be given a root file, which is the file on which the daizu:generator property was set (or a top-level file or directory, if no such property applies).

This class creates URLs based on the daizu:url property, and the names of files and directories. The results will be similar to the URLs that the filesystem would have if they were served directly from a webserver. Files with names like _index.html (anything starting with _index followed by a dot) are special in that the filename will not appear as part of the URL. Instead the URL will end with a trailing slash (/).

With this generator class only files generate URLs. Directories are ignored, except when a sitemap XML file is configured as described below.

CONFIGURATION

The only configuration information which this generator currently makes use of is the xml-sitemap element shown here:

< config path="example.com" >
< generator class="Daizu::Gen" >
< xml-sitemap / >
< /generator >
< /config >

The sitemap URL will be generated from the directory at the path indicated. It must be a directory, not a plain file. In this case, the sitemap is likely to have a URL like http://example.com/sitemap.xml.gz. You can give this URL to Google, or any other search engine which supports the sitemaps format, to help their robots find URLs on your website.

The xml-sitemap element may an optional url attribute, which should be a relative or absolute URL at which to publish the sitemap file. Its default value is sitemap.xml.gz

gensink is a simple tcp benchmark program. It is based on original gen/sink code.

htb-gen is meant to be an easy, scalable, yet powerfull, bandwidth management tool. You can set up/down portions of bandwith for each host or network, that goes trough your firewall/router.
Prioritary traffic(web, mail, gaming, ftp, voip, streaming) is preferred over Junk traffic(kazaa, emule, etc). Also dynamic bandwith borrow and re-assignation is done betwen host thanks to htb boundaries.
A web-frontend for config is avaible as well, so remote management is possible. All bash based so it can be used in embedded routers/firewalls (wired/wireless).
Two backend are aviable:
- generates raw tc commands
- generates htb-init conf files (util for integration)
The packet clasification is done by iptables

PurpleBunny is a Firefox extension that can help you quickly and easily read and write comments about the web page youre viewing. You can praise a page, ask a question, read comments about an entire site, discuss the content of a web page with other web surfers -- the possibilities are endless!

PurpleBunny stores these comments in a centralized location for easy access, and the handy toolbar alerts you when a page youre viewing has comments. Using PurpleBunny is like writing notes for future readers in the margin of a library book, but without messing up the original material! Plus, its more organized -- PurpleBunny groups comments by web site, and you can also sort all comments or search for specific keywords

a-renet project is a distributed gaming network.

It supports client-server TCP-based games.

A Sudoku Solver in C is a console-based Linux program, written in C language, that solves Su Doku puzzles using deductive logic. It will only resort to trial-and-error and backtracking approaches upon exhausting its deductive moves.
Puzzles must be of the standard 9x9 variety using the (ASCII) characters 1 through 9 for the puzzle symbols. Puzzles should be submitted as 81 character strings which, when read left-to-right will fill a 9x9 Sudoku grid from left-to-right and top-to-bottom. In the puzzle specification, the characters 1 - 9 represent the puzzle givens or clues. Any other non-blank character represents an unsolved cell.
The puzzle solving algorithm is home grown. I did not borrow any of the usual techniques from the literature, e.g. Donald Knuths "Dancing Links." Instead I rolled my own from scratch as a personal challenge. As such, its performance can only be blamed on yours truly. Still, I feel it is quite fast. On a 333 MHz Pentium II Linux box it solves typical medium force puzzles in approximately 800 microseconds or about 1,200 puzzles per second, give or take. On an Athlon XP 3000 it solves about 6,600 puzzles per sec. (Solving time is dependent upon degree of difficulty, so YMMV.)
Description of Algorithm:
The puzzle algorithm initially assumes every unsolved cell can assume every possible value. It then uses the placement of the givens to refine the choices available to each cell. I call this the markup phase.
After markup completes, the algorithm then looks for singleton cells with values that, due to constraints imposed by the row, column, or 3x3 region, may only assume one possible value. Once these cells are assigned values, the algorithm returns to the markup phase to apply these changes to the remaining candidate solutions. The markup/singleton phases alternate until either no more changes occur, or the puzzle is solved. I call the markup/singleton elimination loop the Simple Solver because in a large percentage of cases it solves the puzzle.
If the simple solver portion of the algorithm doesnt produce a solution, then more advanced deductive rules are applied.
Ive implemented two additional rules as part of the deductive puzzle solver. The first is subset elimination wherein a row/column/region is scanned for X number of cells with X number of matching candidate solutions. If such subsets (or tuples) are found in the row, column, or region, then the candidates values from the subset may be eliminated from all other unsolved cells within the row, column, or region, respectively.
The next deductive rule examines each region looking for candidate values that exclusively align themselves along a single row or column, i.e. a vector. If such candidate values are found, then they may be eliminated from the cells outside of the region that are part of the aligned row or column.
Note that each of the advanced deductive rules calls all preceeding rules, in order, if that advanced rule has effected a change in puzzle markup.
Finally, if no solution is found after iteratively applying all deductive rules, then we begin trial-and-error using recursion for backtracking. A working copy is created from our puzzle, and using this copy the first cell with the smallest number of candidate solutions is chosen. One of the solutions values is assigned to that cell, and the solver algorithm is called using this working copy as its starting point. Eventually, either a solution, or an impasse is reached.
If we reach an impasse, the recursion unwinds and the next trial solution is attempted. If a solution is found (at any point) the values for the solution are added to a list. Again, so long as we are examining all possibilities, the recursion unwinds so that the next trial may be attempted. It is in this manner that we enumerate puzzles with multiple solutions.
Note that it is certainly possible to add to the list of applied deductive rules. The techniques known as "X-Wing" and "Swordfish" come to mind. On the other hand, adding these additional rules will, in all likelihood, slow the solver down by adding to the computational burden while producing very few results. Ive seen the law of diminishing returns even in some of the existing rules, e.g. in subset elimination I only look at two and three valued subsets because taking it any further than that degraded performance.
Enhancements:
- Code optimization has resulted in a 30% increase in speed.