Free built from software for linux

FlatFrag is a multiplayer action shooter game. With its deathmatch fights it strives to be an entertaining arcade-style experience.
The game is played from a birds eye view and contains some 3D effects in order to make it not seem too flat. Currently only the game mode deathmatch is available, but others will probably be developed in the future.
The game has been built from scratch, though a few important libraries were used in the process. For example, OpenGL is used for fast 3D graphics and SDL provides the game with many cross-platform functions.
It is developed by a single person as a hobby project, but it is released under the terms of the GPL (GNU General Public License), which makes it Open Source software. So everybody is able to get the sourcecode and do his own changes to the project.
Main features:
- Cross-platform support currently for Linux and Microsoft Windows (planned: Mac OS X, BSD, though you can try it anywhere with the provided sourcecode)
- 3D graphics using OpenGL -- the game is played from a birds eye view, but the individual tiles are 3D cubes
- 3D sound using OpenAL -- 2D would probably be more appropriate
- SDL is used for cross-platform input, networking and window creation
- Multiplayer network games with up to 32 players (actually there is no fixed limit set yet)
- Support for Lua-scripted modifications (more like planned, but the console already expects Lua code as input)
- File types: Ogg Vorbis used for sound compression, PNG used for image compression
- Advanced particle system
- Dynamic lighting
- Bots
- Ridable cars and usable stationary guns
- 14 different weapons (some of them very unconventional)
- In-game map editor
- Game modes: deathmatch (more planned)
- Dedicated game server
- A server list function, which fetches a list of servers. You can also see the list of servers here.
- Completely free software -- free as in speech and free as in beer -- Licensed under the GPL

Linux From Scratch (LFS) is a project that provides you with the steps necessary to build your own custom Linux system.
There are a lot of reasons why somebody would want to install an LFS system. The question most people raise is "why go through all the hassle of manually installing a Linux system from scratch when you can just download an existing distribution?". That is a valid question which I hope to answer for you.
The most important reason for LFSs existence is teaching people how a Linux system works internally. Building an LFS system teaches you about all that makes Linux tick, how things work together, and depend on each other. And most importantly, how to customize it to your own taste and needs.
One of the key benefits of LFS is that you are in control over your system without having to rely on somebody elses Linux implementation. You are in the drivers seat now and are able to dictate every single thing such as the directory layout and boot script setup. You will also know exactly where, why and how programs are installed.
Another benefit of LFS is that you can create a very compact Linux system. When you install a regular distribution, you end up installing a lot of programs you probably would never use. Theyre just sitting there taking up (precious) disk space. Its not hard to get an LFS system installed under 100 MB. Does that still sound like a lot? A few of us have been working on creating a very small embedded LFS system. We installed a system that was just enough to run the Apache web server; total disk space usage was aproximately 8 MB. With further stripping, that can be brought down to 5 MB or less. Try that with a regular distribution.
If we were to compare a Linux distribution with a hamburger you buy at a supermarket or fast-food restaurant, you would end up eating it without knowing precisely what it is you are eating, whereas LFS gives you the ingredients to make a hamburger. This allows you to carefully inspect it, remove unwanted ingredients, and at the same time allow you to add ingredients to enhance the flavour of your hamburger. When you are satisfied with the ingredients, you go on to the next part of putting it together. You now have the chance to make it just the way you like it: broil it, bake it, deep-fry it, barbeque it, or eat it raw.
Another analogy that we can use is that of comparing LFS with a finished house. LFS will give you the skeleton of a house, but its up to you to install plumbing, electrical outlets, kitchen, bathtub, wallpaper, etc.
Another advantage of a custom built Linux system is added security. You will compile the entire system from source, thus allowing you to audit everything, if you wish to do so, and apply all the security patches you want or need to apply. You dont have to wait for somebody else to provide a new binary package that fixes a security hole. Besides, you have no guarantee that the new package actually fixes the problem (adequately). You never truly know whether a security hole is fixed or not unless you do it yourself.
Enhancements:
- The LFS LiveCD Team is proud to announce the release of the x86-6.2-3 version of LFS LiveCD. This version is built using LFS 6.2 and many Beyond Linux From Scratch packages from the Subversion branch. Source packages for LFS 6.2, and the LFS book itself, are included on the live CD. The CD is also suitable as a host for building x86 and x86_64 Cross LFS systems. Other features and bugfixes: the CD supports hibernation; the CD file system can be written to; the CD contains a visually pleasing and easy-to-use window manager, XFce...

Devel::DebugInit is a Perl extension for creating a debugger initialization files from C header file macros.

SYNOPSIS

use Devel::DebugInit::GDB;
my $gdb = new Devel::DebugInit::GDB filenames => ["/my/path/to/library.h"];
$gdb->write("/my/path/to/library/.gdbinit");

Devel::DebugInit is aimed at C/C++ developers who want access to C macro definitions from within a debugger. It provides a simple and automated way of creating debugger initialization files for a specific project. The initialization files created contain user-defined functions built from the macro definitions in the projects header files.

By calling new(), the files specified by the filenames parameter are parsed by the C preprocessor, and all macros #defined in the file (and if desired, all macros #defined by all #included files as well), will be parsed and expanded. By then calling the write() method, these macros can be written to an output file in the format of user-defined functions specific for your debugger.

By automating the process, a new file can be created whenever the code of a project changes, and that way there will not be antiquated copies lying around to trap the unwary.

NOTES

This module requires the use of one of the debugger-specific backend modules, such as Devel::DebugInit::GDB which is supplied with DebugInit. The backends supply the output routines which are specific for that debugger.
This module also requires both the C::Scan and Data::Flow modules and will not function without them.

XML::XPath::Builder is a SAX handler for building an XPath tree.

SYNOPSIS

use AnySAXParser;
use XML::XPath::Builder;

$builder = XML::XPath::Builder->new();
$parser = AnySAXParser->new( Handler => $builder );

$root_node = $parser->parse( Source => [SOURCE] );

XML::XPath::Builder is a SAX handler for building an XML::XPath tree.

XML::XPath::Builder is used by creating a new instance of XML::XPath::Builder and providing it as the Handler for a SAX parser. Calling `parse() on the SAX parser will return the root node of the tree built from that parse.

DeniX Server OS is an independent Linux based distribution built from scratch by Denis Salmanovich. They aim to offer a user-friendly full-featured server operating system, pre-configured, well structured and easy to work with, and filled with the latest stable versions of Linux apps.
Its easy to install and configure. Every package is downloaded from the authors source and compiled when installed.
Main features:
- Domain Controller
- ADSL/CABLE Router (PPPoE)
- Network Firewall
- Anti Virus Gateway
- Anti Spam Gateway
- Mail Server (local & external) + Web Mail
- Calendar Sharing Support
- Network File Server
- DHCP Server
- TFTP BOOT Server
- WINS Server
- FTP Server
- VPN Server
- DNS Server
- DDNS Server
- MySQL Server
- HTTP Apache Server
- Remote Backup Solutions
- Remote control and administration
- Print Queue Server
- Proxy Server

Data::DPath::Builder is a SAX handler for building an XPath tree.

SYNOPSIS

use AnySAXParser;
use Data::DPath::Builder;

$builder = Data::DPath::Builder->new();
$parser = AnySAXParser->new( Handler => $builder );

$root_node = $parser->parse( Source => [SOURCE] );

Data::DPath::Builder is a SAX handler for building an Data::DPath tree.

Data::DPath::Builder is used by creating a new instance of Data::DPath::Builder and providing it as the Handler for a SAX parser. Calling `parse() on the SAX parser will return the root node of the tree built from that parse.

Makejail employs short configuration files to help administrators create and maintain chroot jails. Makejails attempts to guess and install into the jail all files required by the daemon.

You have to understand how it is designed to make it work efficiently.

To have an idea of how the configuration files look like, have a look at these examples (shipped in the tarball): apache, bind, mysqld, ntpd, postgresql and sshd

To have an idea of the actions done, look at these log files: apache on OpenBSD 3.0, bind on GNU/Linux Debian woody.

The list of these files is built from several sources:
- the main method is to trace what files the daemon attempts to access, add them into the jail and restart again until no further file is found.
- a list of files manually given in the configuration file.
- the files which belongs to a package and eventually the packages it requires.

When a file is added into the jail:
- the shared librairies it needs (given by ldd) are added too.
- upper directories are created if needed.
- if the file is a symbolic link, the target is added too.
- all the checks to determine what files a file needs are recursive.
- all files are copied maintaining the originals ownerships and permissions.

Some files are handled with a special method:
- when the file is below /proc, the procfs filesystem is mounted inside the jail.
- when the file is a socket, its not copied.
- when the file is the shared library cache, its not copied, ldconfig is run at the end.

The steps of makejail are:
- eventually remove the files in the jail first.
- if you specified some packages, add all the files which belongs to them.
- if you specified some paths to include, add the files matching these patterns.
- start the daemon inside the jail, and trace it with strace, add the files it attempts to open which exist outside the jail, kill it and start again until no more file is found.
- start the daemon inside the jail, and trace it while running some test processes outside the jail, see with strace what files the daemon attempts to open.