Free to resemble software for linux

Vultures is an isometric graphics interface to NetHack and SlashEM.

Vultures is a fork of the now dead "Falcons Eye" project.

An isometric graphics interface to NetHack. The interface was called "Falcons Eye", because the viewpoint resembles a "birds eye view".

This fork of the original "Falcons Eye" is called "Vultures Eye". "Vultures Claw" is the same interface, but for SlashEM

Booting Ubuntu To RAM is an article aims to document the process of creating a customized Ubuntu that loads an image from the hard disk to RAM, then boots an entire Ubuntu session out of RAM. It is intended for intermediate to advanced Ubuntu users who are familiar with the shell, and may have limited experience customizing the livecd (LiveCDCustomization) and shell scripting. We will customize a LiveCD and copy it to the hard drive, and make a few modifications to bootup scripts so that it copies to RAM via our good friend tmpfs.
WARNING: The author asserts that this procedure works for him, but cannot guarantee that this procedure works for anyone else. Although this procedure is meant to be 100% safe, it is feasible that there may be mistakes, or a chance of misunderstanding the instructions in a manner that causes loss of data. Please make a backup and do not attempt on mission critical systems. Read through this article thoroughly, and do not attempt if you do not comprehend or feel comfortable about any of the instructions!
CAUTION: I hope this is intuitively obvious, but Ill humor you and state it bluntly: Changes you make under the live session are NOT saved and WILL BE LOST when you reboot or shut down. Dont save anything important to the "home directory" and expect it to still be around! If you want to save data permanently, mount a permanent medium (such as your hard drive), plug in a thumbdrive, or use some network functionality built into Ubuntu to save your data to a non-volatile destination.
There are many cases where one would like to boot Ubuntu to RAM:
- Performance: The desktop performance is dramatically improved. A 400MB squashed filesystem in RAM, that holds 1200MB of data, is read back on a 1.6GHz Core Duo in about 3 seconds, including decompression time.
- Power, Noise, Durability: Although modern hard disks dont use much power compared to other system components, this may still be important for some. In laptops, hard disks are often the noisiest components, so this setup can reduce system noise. With the hard disk spun down, a laptop can potentially withstand greater shocks without damage.
- Abrupt poweroff: Since the hard disk is only momentarily used in read-only mode during boot, then never touched again, there are few or no negative consequences of an abrupt poweroff. If a system is used where power is inconsistent, or the system is regularly used in a context where fast shutoffs are required, this is very handy.
- Privacy: Anything you do in this session are lost when you reboot or power off. This is great for kiosks or other systems where permanent modification are not desired. (Note that by default the livecd user has full sudo access, so potentially a malicious user can still make permanent changes by mounting the hard drive and following this HOWTO)

MeTA1 is a modularized message transfer agent consisting of five (or more) persistent processes, four of which are multi-threaded.
MeTA1 is a message transfer agent that has been designed with these main topics in minds:
- Security
- Reliability
- Efficiency
- Configurability
- Extendibility
MeTA1 consists of five main modules of which only one runs as root:
mcp: the main control program is similar to inetd(8): it starts all other MeTA1 modules and watches over their execution. mcp runs as root in order to bind to port 25 and to change the uid of the processes it starts.
- smtps: the SMTP server receives e-mails.
- smtpc: the SMTP client sends e-mails.
- smar: the address resolver provides lookups in various maps including DNS for mail routing.
- qmgr: the queue manager controls the flow of e-mails through the SMTP servers and clients.
All of these modules run persistently. smtps and smtpc make use of the statethreads library which provides a threading API well suited for Internet applications, smar and qmgr use the POSIX threads API.
The syntax of the MeTA1 configuration file is very simple and resembles C programs or the BIND 9 configuration files. A configuration file does not require any special layout, e.g., tabs or one option per line, but relies on braces and semicolons as structuring elements.
The first release of MeTA1 is intended to be used as a secure and efficient mail gateway. It offers features that are not available in sendmail 8 (or some other open source MTAs), however, it does not provide any builtin support for mail content modification, e.g., masquerading of addresses or changing (addition, removal) of headers. Those features are currently only available via the pmilter API.
Enhancements:
- Support for Suns SASL library has been added.
- A length check in smtpc when determining whether the client is talking to a server with the same host name has been fixed.
- The handling of DESTDIR in sm.setup.sh should be correct now.
- A new option for qmgr: double_bounce_address has been added.

Mille provides a simple photo album.

Mille is a simple Web-based photo album. It creates HTML pages that weakly resemble Picasa from Google.

Pod::Compiler can compile POD into an object tree.

This package, based on Pod::Parser, compiles a given POD document into an object tree (based on Tree::DAG_Node). It prints errors and warnings about the POD it reads. The result can be used to conveniently convert the POD into any other format.

The resulting objects have a variety of methods to ease the subsequent conversion.

There are two script based on this package, namely podchecker2, an enhanced POD syntax checker and podlint, which beautifies the POD of a given file.

This package is object-oriented, which means that you can quite easily build a derived package and override some methods in case the given behaviour does not exactly suit your needs.

Package Functions

The following functions can be imported and called from a script, e.g. like this:

use Pod::Compiler qw(pod_compile);
my $root = pod_compile(myfile.pod);

pod_compile( { %options } , $file )
pod_compile( $file )

Compile the given $file using some %options and return the root of the object tree representing the POD in $file. The return value is either undef if some fatal error occured or an object of type Pod::root. See below for methods applicable to this class and for the options.

The special option -compiler => class lets you specify an alternate (derived) compiler class rather than Pod::Compiler.

Compiler Object Interface

The following section describes the OO interface of Pod::Compiler.

$c = Pod::Compiler->new( %options )

Set up a new compiler object. Options (see below) can be passed as a hash, e.g.

$c = Pod::Compiler->new( -warnings => 0 ); # dont be silly

Pod::Compiler inherits from Pod::Parser. See Pod::Parser for additional methods.

$c->initialize()

Initalize, set defaults. The following options are set to the given defaults unless they have been defined at object creation:

-errors => 1

Print POD syntax errors (using messagehandler) if option value is true.

-warnings => 1

Print POD syntax warnings (using messagehandler) if option value is true.

-idlength => 20

Pod::Compiler creates a unique node id for each =head, =item and X, consisting only of w characters. The option value specifies how many characters from the original node text are used for the node id by the built-in make_unique_node_id method. See below for more information.

-ignore => BCFS

This option specifies which interior sequences (e.g. B< ... >) are ignored when nested in itself, e.g. B< ...B< ... >... >. The inner B is simply discarded if the corresponding letter appears in the option value string.

-unwrap => I

This option specifies which interior sequences (e.g. I< ... >) are unwrapped when nested in itself, e.g. I< ...I< ... >... > is turned into I< ... >...I< ... >. While some destination formats may handle such nestings appropriately, other might have problems. This option solves it right away. By the way, from a typographical point of view, italics are often used for emphasis. In order to emphasize something within an emphasis, one reverts to the non-italic font.

name =>

This is used to store the (logical) name of the POD, i.e. for example the module name as it appears in use module;. It is used internally only to detect internal links pointing to the explicit page name. Example: You compile the file Compiler.pm which contains the package Pod::Compiler. You set name to Pod::Compiler (there is no safe automatic way to do so). Thus if the file includes a link like L< Pod::Compiler/messagehandler > it is recognized as an internal link and it is checked whether it resolves. Of course you should have written the link as L< /messagehandler >...

-perlcode => 0

If set to true, the compiler will also return the Perl code blocks as objects Pod::perlcode, rather than only the POD embedded in the file. This is used e.g. by podlint.

$c->option( $name , $value )

Get or set the compile option (see above) given by $name. If $value is defined, the option is set to this value. The resulting (or unchanged) value is returned.

$c->messagehandler( $severity , $message )

This method is called every time a warning or error occurs. $severity is one of ERROR or WARNING, $message is a one-line string. The built-in method simply does

warn "$severity: $messagen";
$c->name( [ $name ] )

Set/retrieve the name property, i.e. the canonical Pod name (e.g. Pod::HTML). See above for more details.

$c->root()

Return the root element (instance of class Pod::root) representing the compiled POD document. See below for more info about its methods.

$c->make_unique_node_id($string)

Turn given text string into a document unique node id. Can be overridden to adapt this to specific formatter needs. Basically this method takes a string and must return something (more or less dependent on the string) that is unique for this POD document. The built-in method maps all consecutive non-word characters and underlines to a single underline and truncates the result to -idlength (see options above). If the result already exists, a suffix _n is appended, where n is a number starting with 1. A different method could e.g. just return ascending numbers, but if you think of HTML output, a node id that resembles the text and has a fair chance to remain constant over subsequent compiles of the same document gives the opportunity to link to such anchors from external documents.

VTWM, one of many TWM descendants, implements a Virtual Desktop, meaning that what is currently on screen is just a portion of a larger workspace. What portion of the virtual desktop that is displayed, and whatever windows might be visible within it, are simple point-and-click operations within a scaled representation of the workspace.
When the X Consortium released the X Window System, they included TWM, the "Tab Window Manager" (aka "Toms Window Manager", after Tom LaStrange, the main author).
It was primitive looking by todays standards, somewhat resembling the not-yet-even-thought-of MS Windows 3 interface. However, it sported shaped titlebars, several forms of icon management, user-defined macro functions, and click-to-type or pointer-driven focus, all configurable on the fly with a text file.
Main features:
- VTWMs is user-configurable: The VDs initial scale, size, and position. The colors of the VD, the real screen, and the windows within. The windows that may or may not be represented within. External image (XPM) files can decorate the VD and the real screen.
- VTWMs is not constrained. The VD can be freely moved and resized - its just another managed window, after all.
- VTWM allows the real screen to be positioned anywhere within the VD, or aligned on an user-defined grid. VTWM can toggle this behavior on-the-fly.
- VTWM has "doors". They move the real screen to preset or set-on-the-fly coordinates in the VD with a single click or keystroke.
- VTWMs root window is really the root window - applications that can draw on the root can do so unhindered.
- VTWM supports the moving and resizing of windows on the display from its representation in the VD.
- VTWM doesnt support moving a window on the display into the VD, or visa-versa. Not yet.
- VTWMs does generate more X protocol traffic than some other implementations, which may be a concern if a remote server is used.
Enhancements:
- m4 processing of the resource file.
- Rather than lifting it from another TWM derivative, its a scratch-written implementation that does away with that little temporary file. Itll even let you pass options to m4 on the command line. A compile-time option. Bravo, Jason!
- Regular expressions ("RE"s).
- If VTWMs own wildcard support in resource files isnt sophisticated enough, this certainly is. A compile-time option.
- Sound effects.
- What? Pocketfluff! But it is kind of fun, the audible cues can be helpful, and it incurs just a little overhead. A compile-time option.
- Applet regions.
- Spending too much time setting geometry strings for all those little tool applications you have up all the time? Youre going to love this!
- Scrolling menus.
- When the number of menu entries exceeds the displays height. Better than cascading menus, we think.
- 3D Doors and Virtual Desktop.
- These last two complete the implementation. Finally.