Free to operate software for linux

The Contiki Operating System is mostly known as an operating system for networked embedded systems. A few years ago, however, Contikis primary claim to fame was its Commodore 64 port.
With the help of JAC64, a Java-based C64 emulator developed by my colleague and fellow Contiki developer Joakim Eriksson, you can now experience the C64 port of Contiki 1.2-devel1 again, directly in your web browser!
Enhancements:
- Contiki now does dynamic run-time loading and linking of standard ELF files.
- Rime, a protocol stack designed for low-power radio communication, has been added.
- Cooja, a Java-based network simulator for Contiki is included.
- The build system has been reworked to allow for easy cross-compiling for many platforms.
- A new port for the Tmote Sky sensor board has been added.

Inferno is a compact operating system designed for building distributed and networked systems on a wide variety of devices and platforms.
Inferno was originally developed at Bell Labs (the research division of Lucent Technologies).
Inferno Operating System is a well-designed, economical operating system particularly suitable for use in networked devices such as advanced telephones, hand-held devices, TV set-top boxes, and many other embedded applications.
Inferno can run in native mode on an embedded system or in emulation mode under many different operating systems. Inferno has many features in common with Plan 9.
Cross-Platform Portability
Inferno can run as a user application on top of an existing operating system or as a stand alone operating system. Most of the popular operating systems and processor architectures are supported:
Host Operating Systems:
- Windows NT/2000/XP
- Irix
- Linux
- MacOS X
- FreeBSD
- Solaris
- Plan 9
Supported Architectures:
- Intel x86 (386 & higher)
- Intel XScale
- IBM PowerPC
- ARM StrongARM (ARM & Thumb)
- Sun SPARC
Inferno also runs as a plug-in under Internet Explorer version 4 and higher. Each Inferno system presents an identical environment to the applications, irrespective of the underlying host OS or architecture, allowing the developer to work with a truly homogeneous environment across multiple different platforms.
Portable Applications
Inferno applications are written in Limbo, a modern, safe, modular, concurrent programming language with C-like syntax. It is more powerful than C but considerably easier to understand and debug than C++ or Java. Limbo code is compiled into architecture independent byte code which is then interpreted (or compiled on the fly) on the target processor. This means that any Inferno application will run identically on all Inferno platforms.
Transparent Resources
Inferno offers complete transparency of resources and data using a simple but powerful namespace system. By representing resources as files and having one standard communication protocol, resources such as data stores, services and external devices can easily be shared between Inferno systems. A resource interface may be imported to the local system and used by the applications without them knowing, or needing to know, whether it is local or remote.
Security
High level security is an important part of the Inferno system. By using one standard protocol for all network communication, security can be focused on one point and provided at a system level. Inferno offers full support for authenticated, encrypted connections using a certificate based user identification scheme and variety of algorithms including:
- IDEA, 56 bit DES, 40, 128 and 256 bit RC4 encryption algorithms
- MD4, MD5 and SHA secure hash algorithms
A Complete Solution
Inferno is not only an operating system, it is also a complete development environment, providing all the tools necessary for creating, testing and debugging the applications that run within it.
- Acme IDE: includes editor, shell, advanced pattern matching tools & more
- Fast Compiler: with full syntax and compile time type checking
- Graphical Debugger: with full stack trace for currently executing threads
- Powerful Shell: with sophisticated scripting capabilities
- UNIX like commands: including bind, grep, gzip, mount, ps, tar, yacc...
Enhancements:
- New licence terms (a `dual licence scheme allowing use as Free Software)
- Styx revision based on 9P2000, and consequent changes to Sys
- Authentication changes
- Improved colour graphics support, including compositing
- Scalable fonts using Freetype
- Revamped Tk implementation
- Window management moved out of Tk to a separate window manager in Limbo
- Limbo: exception handling and fixed-point
- Limbo: other possible changes
- Dis VM changes
- More commands and library modules
- Better network service configuration
- /net/dns served by host and native DNS resolver
- Hosted kernels configured from a parts list as for native kernels
- Signed modules
- Internet Explorer plug-in revised and in source form
- Expanded documentation

AutoLoader is a Perl module that can load subroutines only on demand.

SYNOPSIS

package Foo;
use AutoLoader AUTOLOAD; # import the default AUTOLOAD subroutine

package Bar;
use AutoLoader; # dont import AUTOLOAD, define our own
sub AUTOLOAD {
...
$AutoLoader::AUTOLOAD = "...";
goto &AutoLoader::AUTOLOAD;
}

The AutoLoader module works with the AutoSplit module and the __END__ token to defer the loading of some subroutines until they are used rather than loading them all at once.

To use AutoLoader, the author of a module has to place the definitions of subroutines to be autoloaded after an __END__ token. (See perldata.) The AutoSplit module can then be run manually to extract the definitions into individual files auto/funcname.al.

AutoLoader implements an AUTOLOAD subroutine. When an undefined subroutine in is called in a client module of AutoLoader, AutoLoaders AUTOLOAD subroutine attempts to locate the subroutine in a file with a name related to the location of the file from which the client module was read. As an example, if POSIX.pm is located in /usr/local/lib/perl5/POSIX.pm, AutoLoader will look for perl subroutines POSIX in /usr/local/lib/perl5/auto/POSIX/*.al, where the .al file has the same name as the subroutine, sans package. If such a file exists, AUTOLOAD will read and evaluate it, thus (presumably) defining the needed subroutine. AUTOLOAD will then goto the newly defined subroutine.
Once this process completes for a given function, it is defined, so future calls to the subroutine will bypass the AUTOLOAD mechanism.

Subroutine Stubs

In order for object method lookup and/or prototype checking to operate correctly even when methods have not yet been defined it is necessary to "forward declare" each subroutine (as in sub NAME;). See "SYNOPSIS" in perlsub. Such forward declaration creates "subroutine stubs", which are place holders with no code.

The AutoSplit and AutoLoader modules automate the creation of forward declarations. The AutoSplit module creates an index file containing forward declarations of all the AutoSplit subroutines. When the AutoLoader module is used it loads these declarations into its callers package.

Because of this mechanism it is important that AutoLoader is always used and not required.

Using AutoLoaders AUTOLOAD Subroutine

In order to use AutoLoaders AUTOLOAD subroutine you must explicitly import it:

use AutoLoader AUTOLOAD;

Overriding AutoLoaders AUTOLOAD Subroutine

Some modules, mainly extensions, provide their own AUTOLOAD subroutines. They typically need to check for some special cases (such as constants) and then fallback to AutoLoaders AUTOLOAD for the rest.

Such modules should not import AutoLoaders AUTOLOAD subroutine. Instead, they should define their own AUTOLOAD subroutines along these lines:

use AutoLoader;
use Carp;

sub AUTOLOAD {
my $sub = $AUTOLOAD;
(my $constname = $sub) =~ s/.*:://;
my $val = constant($constname, @_ ? $_[0] : 0);
if ($! != 0) {
if ($! =~ /Invalid/ || $!{EINVAL}) {
$AutoLoader::AUTOLOAD = $sub;
goto &AutoLoader::AUTOLOAD;
}
else {
croak "Your vendor has not defined constant $constname";
}
}
*$sub = sub { $val }; # same as: eval "sub $sub { $val }";
goto &$sub;
}

If any modules own AUTOLOAD subroutine has no need to fallback to the AutoLoaders AUTOLOAD subroutine (because it doesnt have any AutoSplit subroutines), then that module should not use AutoLoader at all.

Package Lexicals

Package lexicals declared with my in the main block of a package using AutoLoader will not be visible to auto-loaded subroutines, due to the fact that the given scope ends at the __END__ marker. A module using such variables as package globals will not work properly under the AutoLoader.

The vars pragma (see "vars" in perlmod) may be used in such situations as an alternative to explicitly qualifying all globals with the package namespace. Variables pre-declared with this pragma will be visible to any autoloaded routines (but will not be invisible outside the package, unfortunately).

Not Using AutoLoader

You can stop using AutoLoader by simply

no AutoLoader;

AutoLoader vs. SelfLoader

The AutoLoader is similar in purpose to SelfLoader: both delay the loading of subroutines.

SelfLoader uses the __DATA__ marker rather than __END__. While this avoids the use of a hierarchy of disk files and the associated open/close for each routine loaded, SelfLoader suffers a startup speed disadvantage in the one-time parsing of the lines after __DATA__, after which routines are cached. SelfLoader can also handle multiple packages in a file.

AutoLoader only reads code as it is requested, and in many cases should be faster, but requires a mechanism like AutoSplit be used to create the individual files. ExtUtils::MakeMaker will invoke AutoSplit automatically if AutoLoader is used in a module source file.

Hydrate is a Java tool that provides for fast efficient and error-free transformation of data between three different representations: relational databases, objects in an object-oriented programming language and extended markup language (XML).
Each of these representations has its strengths and weaknesses as shown in the diagram below; but which should you use as a basis for your application design?
Hydrate relaxes some of the pressure on this decision by providing tools for moving data from one representation to another, guided by a master UML class representation of that data.
- You want to lay a domain object model view over an existing database or set of databases. Hydrate gives you the tools to design that model in UML and map your existing data to that model. Once in the object space, you can perform complex manipulations on the objects, calculate results and save information back to a relational cache for searching or reloading, as well as converting the results to XML for sending to downstream systems or transforming to a readable format for display.
- Your project involves taking various data files fed from external systems that you want to pull into an object model on your server before writing the results down to a fully relational database. You can now respond to requests from external systems by rehydrating the data from its relational form and sending it out as XML documents or transforming those documents to a readable format for display.
- You are building a data warehouse in which you have the broad specifications for the model, but want to provide for flexibility and adaptability for future unpredicted requests. Based on a core data model, Hydrate gives you the tools to create you database schema, and write information to it, but more significantly to subsequently lay a completely different object model perhaps aggregating some of the data over the top of that schema to process it in unforeseen ways.
- You need to integrate data from many different data sources in a highly performant manner. SQL permits you to read a huge data set a row at a time and perform running calculations and filtering on that data. But the performance pressures can lead to code that is highly coupled with the database and what do you do if you need to integrate data from elsewhere in order to complete your calculations? Hydrate permits you to operate in the object space and integrate information from other sources on-the-fly.
Main features:
- To integrate legacy and other data schemas over which you have little control. Map data from many different data sources into a single self-consistent in-memory model. Different parts of the same object, as well as different sub-populations of the same object type can be drawn from different data sources, different schemas and even different database architectures.
- Load, populate and connect up multiple object types from a single query. There is no limit to the number of object types that can be loaded from a single query, or to the complexity of the relationships that can be resolved between them. Objects read from a query are automatically merged into objects already in memory.
- Full control over the SQL that runs against the database (if you need it). Any SQL queries simultaneously from multiple JDBC drivers, even using database specific optimizations, as long as they returns a result set.
- Access and manipulate the same data through the rich and powerful XML toolset. Use the same meta data that describes your objects to easily read from, write to and validate any consistent XML schema. Use XML for display, data transmission or XSLT transformation. Load XML data back into objects.
- Highly optimized performance for reading and writing SQL and XML. Since native types are used and SQL chatter is non-existent, database performance is comparable with doing the mapping by hand. XML reading and writing uses SAX exclusively.

Stone is an application layer TCP/IP packet repeater. It repeats TCP and UDP packets from the inside of a firewall to the outside or vice versa.

It is simple, supports OpenSSL for encrypting and decrypting packets, performing client and server verifications, and sending a substring of the subject of the certificate to the destination, can operate as an HTTP proxy, and performs POP to APOP conversion. It also supports IPv6 and can convert between IPv4 and IPv6 each other.

One-Wire Weather is a client program for Dallas Semiconductor / AAG 1-wire weather station kits, providing a graphical (animated) display to monitor outside temperature, wind speed and direction, rainfall, and humidity.
Extra temperature sensors may be added. A 1-wire "hub" may be used for improved reliability and range. Weather data may be logged to CSV files, parsed to command line programs, sent to the Henriksen Windows client, or uploaded to Web servers at Dallas, The Weather Underground, and HAMweather.
Enhancements:
- Changes to libusb calls, to operate correctly with recent Linux kernels.
- Added facility for waveform slew/timing adjustment for DS2490.
- Locale now set to POSIX when creating output for wunderground, &c - so you can log e.g. with comma as decimal separator, but wunderground gets a full stop.
- Rain from a remote source is integrated for upload (but please could people check if this works for you).
- Initial support for DS2760 - e.g. AAG TAI8560 thermocouple adapter (but the thermocouple Voltage isnt interpreted yet).
- Added facility for placing control characters in parser strings, as C-style escape sequences.
- Added dailyrain statistic for wunderground uploads, &c.
- Implemented rapid update for wunderground.

Sauerbraten is an experimental engine based on Cube, can be seen as "Next-Gen Cube", or "Cube 2". Much like cube, the aim of this engine is not to produce the most eyecandy possible, but rather allow map/geometry editing to be done dynamically in-game, and make map editing a lot of fun.

Sauerbraten has an even simpler world model than cube (fewer exceptions, just one kind of building block), is quicker to edit geometry with, yet allows for significantly greater class of shapes. One way to see the transition from Cube to Sauerbraten is to say Cube was a 2-directional heightfield (floor and ceiling), and Sauerbraten is a 6-directional heighfield (heighfields can be modeled in all 6 directions).

The world consists of an octree of deformable cubes. It being an octree has just one important effect: it allows the mapper to work at any scale, from large landscape areas to small architectural details. The octree is largely invisible to the mapper though, he can arbitrarily break up larger cubes or merge them, and the engine takes care of the rest.

The deformable cubes are geometric shapes made out of maximally 8 vertices. In its maximum size, it is a regular cube that fills the entire octree node it sits in, as minimum size all 8 vertices coincide which is to say the cube is "empty". Anywhere in between theres a variety of slanted cubes and wedge shapes that are possible to any degree and orientation, and together with neighbouring cubes can form any shape easily.

The editor is similar to the one in Cube but much easier / direct to use, as there arent all the different kinds of cubes to worry about. Here, you can simply "push and pull" geometry with your mousewheel in 6 directions, depending on the orientation of the surface you are looking at. Modifier keys allow you to influence single vertices on a cube, connected vertices touching multiple cubes, edges, faces and entire cubes. Selections can be made to operate on more primitives at once. Many complex shapes are quick and easy to make. It is definitely the most fun way to model architecture to date.

The internal representation of a deformable cube is very different from a vertex based representation, and is based on "edge spans" which allows the engine to represent any kind of shape uniformly in just 12 bytes. This means it can hold great amounts of geometry in memory and maps on disk are small. To render this kind of geometry, the engine goes through a process of converting the internal representation to vertices using plane intersections based on the edge ranges, culls coinciding faces, merges vertices etc. to arrive at something which renders efficiently by hardware and caches this in chunks based on the octree. This allows Sauerbraten a significantly higher polygon throughput than Cube while maintaining its ability to have dynamic geometry.

The current implementation inherents all the non-world geometry related code from Cube, and as such works without modification: entities, AI, gameplay, network, console/script. For the new code, rendering and editing are close to done, physics and lighting are working quite well, level loading/saving is complete, SP & MP work, but plenty of more advanced stuff like occlusion culling & LOD is missing.

UPDATE: Sauerbraten has now started as a Cube community Open Source Engine (& Game) project. It interesting for developers & mappers, but maybe not players yet (though SP & MP do work). If you are interested in checking it out, or even in contributing, I suggest you visit the forums (see below).

NEWS: may 24 2005 release with lightmaps and working MP/SP gameplay! download from sourceforge below.