Free a v software for linux

GeeXboX uShare is a UPnP A/V Media Server. It implements the server component that provides UPnP media devices with information on available multimedia files. uShare uses the built-in http server of libupnp to stream the files to clients.

GeeXboX uShare is a fork from the GMediaServer (UPnP Audio Media Server) from Oskar Liljeblad. It has been stripped down for GeeXboX purpose in order to be a lighweight multimedia media server.

By opposition to GMediaServer, it does _NOT_ grab any information from audio files (like ID3 tags) but is _NOT_ limited to audio files. GeeXboX uShare is able to provide access to both images, videos, music or playlists files (see below for a complete file format support list). It does not act as an UPnP Media Adaptor and thus, cant transcode streams to fit the client requirements.

uShare is written in C by Benjamin Zores for the GeeXboX project. It is designed to provide access to multimedia contents to GeeXboX but can of course be used by any other UPnP client device. It should compile and run on any modern POSIX compatible system such as Linux.

GeeXboX uShare is free software - it is licensed under the terms of the GNU General Public License (GPL).

B.A.L.L.Z game is a platformer with some puzzle elements.

Ballz is a platformer with some puzzle elements. You take control of a ball which is genetically modified by the British secret service. Your mission is to rescue captured British soldiers from a prison in Iran.

The game was in 72 hours for the TINS competition, a competition similar to Speedhack. The name TINS is an recursive acronym for ‘TINS is not Speedhack’.

Hex-a-hop is a puzzle game based on hexagonal tiles. There is no time limit and no real-time elements.

The objective is simply to destroy all the green hexagonal tiles on each of the 100 levels. As you progress through the game, more types of tiles are introduced which make things more difficult and interesting (hopefully).

The project is built on top of SDL, which is an open-source layer for direct media access.

L.A.U.R.A project provides a secure and performant e-mail proxy designed with the goal of shutting down the "Unsolicited Commercial/Bulk E-mail Era".
What is "Greenmarking"?
Greenmarking is something I think I invented myself (I might be wrong though, I coulndt find it anywhere else). Greenmarking works like this: if a triplet of (sender_ip, sender, recipient) is first seen, it gets marked green. The message will be sent unmarked with the meaning of "never seen it before". Next time the triplet is met, the message will also be marked green, meaning "I know this guy already".
Yes I know this sounds like greylisting (its a variation of it, hence the name). However, greenmarking is (and should be) done after greylisting. Why? Greylisting mostly means that the passing message is almost certalny originating from a valid (E)SMTP mail server daemon. Worms usually dont retry too much. So greenmarking is effective especially against evil mail selvers. Its implemented in the project. Just add an Inbox filter to your (web)mail client and move all the messages with a "neverseen" header in a special suspect folder. If you dont want to hassle with them, activate the Inbox filter only after youve run the greenmarking daemon for a while (1/2 weeks maybe?).
Main features:
- ESMTP capability for interoperating with Postfix
- Lightening fast B+ infrastructure for internal database
- No false positives
- No "lost" e-mail messages
- No miss-rate
- BSD license (the most liberal and FREE, in honour to the FreeBSD team)
- Its written in plain old C
- It was designed to be as fast as applicable
- It is (going to be) very secure (multiple audits, formal verifications, programming care)
- No package dependencies - no extra libraries or tools needed
- Hassle-free for admins - just install it
- Hassle-free for users - it just works, without user intervention
- Hassle-free and polite with other Internet neighbours - no rude messages, nothing
- Secure inter-server cooperation for MX backups - without any hassle or complexity (needs to be done)

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.

a-renet project is a distributed gaming network.

It supports client-server TCP-based games.

Run a web server inside LAN is a simple script to run a WWW server inside a Local Area Network. Run a web server inside LAN script assume all iptables features are compiled statically in the kernel, or all modules are loaded.

Otherwise you may encounter some surprises trying to utilize the more featureful and creative commandlines that Ive come up with.

Sample:

#external and internal interfaces
EXT=eth0
INT=eth1

# clear everything, and create my cascading chains
iptables -F
iptables -N e0
iptables -N tcpin
iptables -N udpin

# e0 is the name of our chain for eth0
iptables -I INPUT -i $EXT -j e0

# OUTPUT Chain
iptables -A OUTPUT -o $EXT -j DROP -p icmp --icmp-type ! echo-request

# remote gnutella queries were really pissing me off one day
# iptables -A OUTPUT -o $EXT -j DROP -p tcp ! --syn --dport 6346
# iptables -A OUTPUT -o $EXT -j DROP -p tcp ! --syn --sport 6346

# $EXT Chain
# a single rule to accept SYN Packets for multiple ports (up to 15)
iptables -A tcpin -j ACCEPT -p tcp --syn -m multiport --destination-ports 873,993,995,143,80,113,21,22,23,25,53

# stateful connection tracking is wonderful stuff
# ESTABLISHED tcp connections are let through
# If we send a SYN out, the ACK is seen as RELATED
# then further communication is accepted by the ESTABLISHED rule
iptables -A e0 -j ACCEPT -m state --state ESTABLISHED
iptables -A e0 -j ACCEPT -m state --state RELATED

# certain ports I simply DROP
iptables -A tcpin -j DROP -p tcp --syn -m multiport --destination-ports 6346,139

# UDP rules...
iptables -A udpin -j DROP -p udp -m multiport --destination-ports 137,27960

# I run a DNS server, so we must accept UDP packets on port 53
iptables -A udpin -j ACCEPT -p udp -m state --state NEW --destination-port 53

# lets log NEW udp packets on ports 1024:65535, then let them through
iptables -A udpin -j LOG -p udp -m state --state NEW --destination-port 1024:65535 --log-level debug --log-prefix UDPNEW --log-ip-options
iptables -A udpin -j ACCEPT -p udp -m state --state NEW --destination-port 1024:65535

# lets log NEW tcp packets on ports 1024:65535, then let them through
iptables -A tcpin -j LOG -p tcp --syn --destination-port 1024:65535 --log-level debug --log-prefix TCPNEW --log-tcp-options --log-ip-options
iptables -A tcpin -j ACCEPT -p tcp --syn --destination-port 1024:65535

# lets log INVALID or NEW tcp packets on priveleged ports, then DROP
# (remember I have certain ACCEPT rules higher up the chain)
iptables -A tcpin -j LOG -p tcp -m state --state INVALID,NEW --destination-port 1:1023 --log-level warn --log-prefix TCPPRIV --log-tcp-options --log-ip-options
iptables -A tcpin -j DROP -p tcp -m state --state INVALID,NEW --destination-port 1:1023

iptables -A e0 -p tcp -j tcpin
iptables -A e0 -p udp -j udpin
iptables -A e0 -j LOG --log-level debug --log-prefix NETFILTER --log-ip-options -m state --state INVALID,NEW
iptables -A e0 -j DROP

# NAT Rules
# I run a web server inside...
iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 192.168.1.4:80