Free trip software for linux

RoadMap is an open source (GPL) program that provides a car navigation for Linux and UNIX. It displays a map of the streets, tracks the position provided by a NMEA-compliant GPS receiver, identifies the street matching this GPS position and announces the name of the crossing street at the next intersection. A rudimentary trip feature allows RoadMap to display some basic navigation information (distance to the destination, direction, speed, etc..). Voice messages are generated that duplicate some of the screen information.
It is possible to display a specific area by providing a (complete or incomplete) postal address, the intersection of two streets or an exact position (longitude / latitude).
The map files used by RoadMap are generated from the TIGER files provided by the US Census Bureau, and thus cover the USA only. The RoadMap map format is a binary format that is sensitive to the endianness of the processor. Maps available on this site cover all the USA and have been generated for a little endian processor (such as the Intel Pentium and StrongARM processors).
RoadMap has been designed to be usable on both a desktop or laptop PC, or on a PDA such as the iPAQ from HP (formely from COMPAQ). It can use either the Gtk 1.2 , Gtk 2.0 or QT graphic library for its user interface. The Qt interface supports the Sharps Zaurus PDA. All these machines share the same endianness and can use the maps provided on this site.
RoadMap is at an early stage of development. At this time there are no routing features implemented yet. The plan for the future is to implement some navigation features similar to those found in commercial street navigation systems. The main limit for implementing routing is the lack of navigation information in the US Census Bureau database (for example one-way street are not indicated). The US Census Bureau has clearly indicated that it does not plan to add these information in the future (the USCB does not need them).
RoadMap uses gpsd for the GPS link and flite (festival lite) for the voice messages. Note that flite can be rebuilt with better voices than the default one (such as a US voice instead of a british one--some may disagree :). See the flite README for more information. Here is an example, courtesy of Scot Wilcoxon:
cd flite make clean # to remove old executable files ./configure --with-vox=cmu_us_kal16
RoadMap comes with its own GPS status screen, which provides an overview of the satellites received and highlights those the GPS has a fix on. This status screen allows for placing the GPS device in a position that optimizes satellite reception, even if that means making the GPS devices screen not accessible.
RoadMap uses a binary file format for representing the maps that is compact enough to allow the storage of many maps on a Compact Flash or MultiMedia card. For example, the map of Los Angeles county takes about 10 Mbytes of flash space. RoadMap comes with a set of tools to convert the US Census bureau data (both the 2000 and 2002 versions) into its own map format. Future versions of the US Census bureau data will be supported as well (usually a 1 or 2 months after the data has been released).
When RoadMap starts, it displays a map of the same area that was displayed on the latest session. Clicking on the map screen triggers a "sign" that displays the name of the street, road or freeway (if any) that is the closest to the mouse hotpoint.
Enhancements:
- This version includes some GUI improvements (the user can redefine the toolbar & menu) and bug fixes.
- Improved maps are now available on the web site, which were built from the TIGER 2004se files.

Berkley Snoop for Linux is a module which adds support for the Snoop protocol, a TCP-aware link layer protocol designed that can improve the performance of TCP over networks of wired and single-hop wireless links.
While TCP adapts well to network congestion, it does not adequately handle the vagaries of wireless media. In this thesis, we address these challenges in detail and design solutions to them. These solutions incorporate link-layer techniques as well as enhancements to TCP at the sender and receiver. The Snoop protocol is a TCP-aware link layer protocol designed to improve the performance of TCP over networks of wired and single-hop wireless links.
The implementation is for kernels of 2.6.x series. This software is intended to use on routers acting between big fat pipe(BFP) link and wireless link.
The problem: The wireless link is error prone by its nature and BFP links such as satellite one has very big round-trip time. When error occurs on wireless segment it causes in speed reduction because the TCP protocol on sending side treats this error as link congestion although the error was just a temporary link quality loss and the connection cannt recover its speed.
The fix: The module will cache TCP segmets passing to host on wireless segment until the ACK(nowledgmet) is received or timeout expired. In case of timeout the segment will be retransmitted again. And by the way the module will drop all DUP(licate) ACK(nowledgmets) caused by packet loss on wireless segment and prevent the reduction of speed of flow from the host beyond the satellite link. The module works now only with connections initiated from wireless hosts.
Enhancements:
- fixed issues with improper use of locks & memory allocation the memory allocates now with GFP_ATOMIC priority

Trip Tracker is a position tracking client-server system. Trip Tracker is designed to assist people in setting up a real-time tracking environment with either a private or public tracking server.
The Trip Tracker GPS client sends coordinates to the tracking server to update its position. In the event that the GPS client loses its Internet connection, it can send all collected coordinates to the tracking server as soon as its back online.
The tracking server saves all the coordinates and can forward them to listening map clients.
Version restrictions:
- The map client can only display a map of Norway, as the WMS server is hardcoded in the server-side PHP script "mapservice.php". This may change in the future. If you know any good WMS servers we might add it to the server-side script, but you still need to add the proper WMS layers in the source code to make it work.
- The GPS client version 0.8 does not set up the Java Communications library properly so it most likely wont find your GPS receiver. We hope to address this issue in the next release quite soon.
- And more...

Link Monitor Applet is a GNOME Panel Applet displaying the round-trip time to one or more hosts in a bar graph.
Main features:
- full ICMP and ICMPv6 support
- configurable scale and delays
- HIG 2.0 compliance

Bloboats project is a boat racing game in the spirit of Elasto Mania or X-Moto, introducing a handful of elements from Super Mario Bros-like games.

The objective of Bloboats is to reach MS Enterprise as fast as possible to save if from
the hands of the terrible Tentacle Monsters of an Unknown Master and the same time beat your friend and laugh at his or her puny time.

The journey starts from a place called Tutorial, somewhere in the United States, and somehow the player ends up in the famous HV-Arena of Helsinki. During the trip a number of MS Enterprises are saved, luckily, from the hands of the terrible Tentacle Monsters of an Unknown Master, who actually is your dad. Or then aint.

SAFMQ, one of the first Open Source message queue server, provides high performance message queuing free to the public.
The SAFMQ server provides Asynchronous Messaging. Message Publishers send or enqueue a message with the SAFMQ server.
The SAFMQ server stores that message until the point at which the message can be forwarded on to the client. Message Publishers are assured that the messages are delivered. Thats how SAFMQ got its name.
SAFMQ provides an API to use SAFMQ directly. Simply use the SAFMQ MQBuilder class to specify the location of your SAMFQ server and youre ready to start publishing and subscribing to priority message queues!
Timely Messaging
SAFMQ provides the ability to perform timely message delivery. So, if a Message Publisher wants a message to be read by a Message Subscriber in a certain amount of time, or not read at all, then the Message Publisher can prescribe a Time-To-Live for the message it publishes. SAFMQ will notify the Message Publisher about messages which have outlived their Time-To-Live, or a Message Publisher can choose to ignore the event.
Round-Trip, PsudoSynchronous Messaging
Round-Trip, or PsudoSynchronous Messaging is when a Message Publisher acts as a Message Subscriber after sending a "query" message. A Message Publisher may want to receive information back from the Message Subscriber. Thus after the first message is sent by a Message Publisher and is received by a Message Subscriber, the original Message Publisher and Message Subscriber switch rolls.
SAFMQ provides a special messaging context element for Round-Trip/PsudoSynchronous Messaging. Its called a Receipt ID. When ever a message is Enqueued in a SAFMQ server, it is given a Universally Unique Identifier or UUID for short. When a Round-Trip message event is taking place, the original Message Subscriber publishes a message with a Recipt ID identiacal to the Message ID assigned to the message sent by the original Message Publisher. Then the original Message Publisher (now a subscriber) waits for a message with a Receipt ID equal to the Message ID the original Message Publisher sent.
Batch Processing
Not every task is best handled real-time. Sometime there are real money benefits to send transactions to a trading partner in a large group or batch. SAFMQ can be an intermediary between real-time systems and a back-end batch processor. The real-time system knows that the messages will be delivered, and the batch processor can let data queue up until it is ready to send all the data. The batch system can even respond via SAFMQ and a real-time system can instantly see the results.
Enhancements:
- Additional configuration changes for cross compile to MacOS X

CGI::MxScreen is a multi-screen stateful CGI framework.

SYNOPSIS

require CGI::MxScreen;

my $manager = CGI::MxScreen->make(
-bgcolor => "#dedeef",
-screens =>
{
"state_1" =>
[-class => "STATE_1", -title => "Hello"],
"state_2" =>
[-class => "STATE_2", -title => "Hello #2"],
},
-initial => "state_1",
-version => "1.0",
);

$manager->play();

CGI::MxScreen is a framework for building multi-screen stateful CGI programs. It is rather object-oriented, with some peculiarities brought by persistency constraints: all objects must be handled by Storable.

CGI::MxScreen is based on the CGI module, and co-operates with it, meaning you are able to use most CGI calls normally. The few places where you should not is where CGI::MxScreen supersedes the CGI functionalities: for instance, theres no need to propagate hidden values when you use CGI::MxScreen.

CGI::MxScreen is architected around the concept of screens. Among the set of defined screens within the same script, only one is visible at a time. One moves around the various screens by pressing buttons, which submit data to the server and possibly move you to a different screen. The state machine is handled by CGI::MxScreen, the user only defines which state (screen) a button shall move the application to.

CGI::MxScreen is stateful in the sense that many of the runtime objects created to operate (and screens are among those) are made persistent. This is a very interesting property, because you do not have to worry too much about the underlying stateless nature of the CGI protocol. The CGI module brought the statefulness to the level of form controls, but CGI::MxScreen raises it to the level of the application itself.

CGI::MxScreen is not meant to be used for so-called quick and dirty scripts, or for scripts which do not require some fair amount of round trips between the browser and the server. Youll be better off with using the good old CGI module. However, for more complex web applications, where there is a fair amount of processing required on the server side, and where each script involves several states, CGI::MxScreen is for you.

CBLM is a high performance latency (one-way and round-trip), packet loss, and jitter monitoring probe.
When run on two or more servers, a full mesh of connections is automatically set up between the probes, between which UDP packets are transmitted. Statistics are collected and stored within a MySQL database.
Enhancements:
- This release fixes missing MySQL tables.