Free trip software for linux

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...

GridMPI is a new open-source free-software implementation of the standard MPI (Message Passing Interface) library designed for the Grid. GridMPI project enables unmodified applications to run on cluster computers distributed across the Grid environment.
GridMPI team found that it is feasible to connect cluster computers and to run ordinary scientific applications in distance upto 500 miles. Simple experiment has shown that most MPI benchmarks scale fine upto 20 millisecond round-trip latency which corresponds to about 500 miles in distance, when the clusters are connected by fast 1 to 10 Gbps networks. 500 miles covers the major cities between Tokyo--Osaka in Japan.
Thus, applications which are too large to run on a local cluster should run on multiple clusters in the Grid environment with acceptable performance. However, it is only feasible when using an efficient MPI implementation [1]. Existing implementations are not efficient enough mainly because of the two reasons: their focus on security features and TCP performance problems.
GridMPI skips security layers assuming dedicated secure links. The institutes housing large clusters tend to have their own networks to connect to other institutes in most cases. GridMPI so focuses on the performance on TCP. Since existing implementations are in most cases designed for MPP machines and recently clusters with special hardware, their performance on TCP with Ethernet is not optimal.
Also TCP performance itself is not optimal for the work load of the MPI traffic. In addition, support for heterogeneous combinations of computers of the existing MPI implementations is not satisfactory. Thus, GridMPI is designed and implemented from the scratch. GridMPI is carefully coded and tested with heterogeneity in mind.
Main features:
- Full conformance to the standard: GridMPI passes 100% of the functional tests of the large test suites from ANL and Intel (MPI-1.2 level).
- Full heterogeneity support: GridMPI is fully tested with combinations of processors of 32bit/64bit and big/little-endian.
- Primary support of TCP/IP and sockets: GridMPI is written from scratch and it is new and clean. It is efficient with sockets, and thus suitable for the Grid as well as ordinary Ethernet-based clusters.
- Cooperation with Grid job submission: GridMPI can be used with Globus, Unicore, tool from NAREGI project, etc.
- Checkpointing support: GridMPI supports checkpointing on Linux/IA32 platforms to restart long-running applications from failure.
- Vendor MPI support: GridMPI supports IBM-MPI, Fujitsu-Solaris-MPI, Intel-MPI, and any MPICH-based MPI for clusters with special communication hardware.
Enhancements:
- Minor bugfixes were made.

DataGridField is a product which consists of a table input component for Plone.
It uses Javascript to make entering tabular data more user friendly process - there are no round trip HTTP requests to the server when inserting or deleting rows.
Main features:
- Any number of columns set by a developer
- Any number of rows filled by a user
- Insert and deleting rows without submitting a form
- Many different column types

Data::Serializer package contains modules that serialize data structures.

SYNOPSIS

use Data::Serializer;

$obj = Data::Serializer->new();

$obj = Data::Serializer->new(
serializer => Storable,
digester => MD5,
cipher => DES,
secret => my secret,
compress => 1,
);

$serialized = $obj->serialize({a => [1,2,3],b => 5});
$deserialized = $obj->deserialize($serialized);
print "$deserialized->{b}n";

Provides a unified interface to the various serializing modules currently available. Adds the functionality of both compression and encryption.

EXAMPLES

Please see Data::Serializer::Cookbook(3)

METHODS

new - constructor
$obj = Data::Serializer->new();


$obj = Data::Serializer->new(
serializer => Data::Dumper,
digester => SHA-256,
cipher => Blowfish,
secret => undef,
portable => 1,
compress => 0,
serializer_token => 1,
options => {},
);

new is the constructor object for Data::Serializer objects.

The default serializer is Data::Dumper
The default digester is SHA-256
The default cipher is Blowfish
The default secret is undef
The default portable is 1
The default encoding is hex
The default compress is 0
The default compressor is Compress::Zlib
The default serializer_token is 1
The default options is {} (pass nothing on to serializer)
serialize - serialize reference

$serialized = $obj->serialize({a => [1,2,3],b => 5});

Serializes the reference specified.
Will compress if compress is a true value.
Will encrypt if secret is defined.
deserialize - deserialize reference

$deserialized = $obj->deserialize($serialized);

Reverses the process of serialization and returns a copy of the original serialized reference.

freeze - synonym for serialize
$serialized = $obj->freeze({a => [1,2,3],b => 5});

thaw - synonym for deserialize
$deserialized = $obj->thaw($serialized);

raw_serialize - serialize reference in raw form
$serialized = $obj->raw_serialize({a => [1,2,3],b => 5});

This is a straight pass through to the underlying serializer, nothing else is done. (no encoding, encryption, compression, etc)

raw_deserialize - deserialize reference in raw form
$deserialized = $obj->raw_deserialize($serialized);

This is a straight pass through to the underlying serializer, nothing else is done. (no encoding, encryption, compression, etc)

secret - specify secret for use with encryption
$obj->secret(mysecret);

Changes setting of secret for the Data::Serializer object. Can also be set in the constructor. If specified than the object will utilize encryption.

portable - encodes/decodes serialized data

Uses encoding method to ascii armor serialized data

Aids in the portability of serialized data.

compress - compression of data

Compresses serialized data. Default is not to use it. Will compress if set to a true value $obj->compress(1);

serializer - change the serializer

Currently have 8 supported serializers: Storable, FreezeThaw, Data::Denter, Config::General, YAML, PHP::Serialization, XML::Dumper, and Data::Dumper.
Default is to use Data::Dumper.

Each serializer has its own caveats about usage especially when dealing with cyclical data structures or CODE references. Please see the appropriate documentation in those modules for further information.

cipher - change the cipher method

Utilizes Crypt::CBC and can support any cipher method that it supports.

digester - change digesting method

Uses Digest so can support any digesting method that it supports. Digesting function is used internally by the encryption routine as part of data verification.

compressor - changes compresing module

This method is included for possible future inclusion of alternate compression method Currently Compress::Zlib is the only supported compressor.

encoding - change encoding method

Encodes data structure in ascii friendly manner. Currently the only valid options are hex, or b64.

The b64 option uses Base64 encoding provided by MIME::Base64, but strips out newlines.

serializer_token - add usage hint to data

Data::Serializer prepends a token that identifies what was used to process its data. This is used internally to allow runtime determination of how to extract Serialized data. Disabling this feature is not recommended.

options - pass options through to underlying serializer

Currently is only supported by Config::General, and XML::Dumper.

my $obj = Data::Serializer->new(serializer => Config::General,
options => {
-LowerCaseNames => 1,
-UseApacheInclude => 1,
-MergeDuplicateBlocks => 1,
-AutoTrue => 1,
-InterPolateVars => 1
},
) or die "$!n";

or

my $obj = Data::Serializer->new(serializer => XML::Dumper,
options => { dtd => 1, }
) or die "$!n";
store - serialize data and write it to a file (or file handle)
$obj->store({a => [1,2,3],b => 5},$file, [$mode, $perm]);

or

$obj->store({a => [1,2,3],b => 5},$fh);

Serializes the reference specified using the serialize method and writes it out to the specified file or filehandle.

If a file path is specified you may specify an optional mode and permission as the next two arguments. See IO::File for examples.

Trips an exception if it is unable to write to the specified file.

retrieve - read data from file (or file handle) and return it after deserialization

my $ref = $obj->retrieve($file);

or

my $ref = $obj->retrieve($fh);

Reads first line of supplied file or filehandle and returns it deserialized.

Illustrated project is aiming to provide a way to share picture and photos in a structured way. Therefore just like most other web galleries, a title and a description can be added to each photo. But pictures can also be presented as groups within chapters, where they illustrate the text.
I started developping it because although there are many Web galleries already, none was made to do what I wanted to do. The project is very young and therefore much features are too be implemented.
What is Illustrated, and what it is not
- Illustrated is made to share pictures with others with a structured description.
- It supports multilanguage description: you can either add a single description, or add various descriptions with < intl-xx > tags (for instance: < intl-en >English description< /intl-en >). The language used will then depend on the browser settings.
- Within a same album, pictures are shared by chapters, allowing you to storytell what those photos are meaning, just like you would do if you showed to your friends photos of a trip.
- Illustrated is not made to upload loads of pictures for visitors to browse just like with a picture viewer. You could do that, but I would rather recommend you Gallery or Coppermine.
- It is not made to post daily photos and let visitors write some comments. Comments are not supported, and I do not plan to implement this. If you are looking for a photoblog, I would rather recommend you Pixelpost.
How to install it
Illustrated should work on any system as long as PHP, MySQL, and ImageMagick or GD are present. Since it is still at an early development stage, it does not include yet a guided installation, so you will have to set it up manually. This is quite simple though.
Edit the connect.php and index.php files, then just upload all PHP and CSS files in a directory of your web space, and create a directory called pictures with permissions for writing.
Create the database. To do so, if you have access to a command line, just run the following line with your own MySQL login and password.
mysql -ulogin -ppassword < illustrated.sql
If you have access to a phpMyAdmin interface, you can use it to import the file. Just pay attention to the maximum file size.
At last, if you do not have other option left (which would be surprising), you can write a PHP script to build the database. I will write one later.

ferrisfuse is a FUSE module for mounting libferris filesystems through the Linux kernel.
About libferris
In non technical terms libferris makes the file system and other hierarchical storage systems easier to use. For the geeks out there, libferris is a virtual file system (VFS) that runs in the user address space. The FAQ contains entries related to installation, configuration and the usage of libferris.
As of July 2005 libferris can mount many interesting things ranging from a filesystem from your local Linux kernel through to LDAP, Evolution, PostgreSQL, dbXML, and RDF. To get an impression of the current capabilities of libferris mounting see the plugins/context directory of the lastest release. New things to mount are always being added.
Other than mounting things as a filesystem, the other core concept of libferris is extraction of interesting metadata from your libferris filesystems. This means that simple things like width and height of an image file become first class metadata citizens along with a files size and modification time. The limits on what metadata is available extend far beyond image metadata to include XMP, EXIF, music ID tags, geospatial tags, rpm metadata, SELinux integration, partially ordered emblem categories and arbitrary personal RDF stores of metadata.
Though some consider the last point of purely academic interest the end result is that you can add metadata to *all* libferris objects even those you only have read access too, for example, you can attach emblems to this website just as you would a normal file. The metadata interface gives all metadata from file size to digital signature status information equal standing. As such you can sort a directory by any metadata just as easily as you would ls -Sh to sort by file size. Sorting on multiple metadata values is also supported in libferris, you can easily sort your files by mimetype, then image width, then modification time with all three pieces of metadata contributing to the final directory ordering.
Late in 2004 extensive support for both fulltext and metadata indexing was added to libferris. This means you can supply queries against the contents or metadata of any libferris accessable object and have the results returned as a virtual filesystem. With the above mentioned metadata available for searching, finding your files can be done in many different ways instead of being forced to generate fixed directory trees using part of a file collections semantics as directory names. The metadata and virtual filesystem play together here allowing you to geospatially tag both your digital pictures, trip plans, and relevent websites and recall these objects in a single virtual directory no matter what their path or URL may be.
There is also a Samba VFS module which allows you to expose a libferris filesystem as a Samba share. Kfsmd uses the inotify kernel interface to allow libferris to watch changes made to your kernel filesystem by non libferris applications and update its indexes appropriately. Ferriscreate provides a command line and GTK+2 application for creating "new files" with libferris. With this you can create a new db4 database, dbXML database or fulltext index just as easily as you can make a regular file.
The ego filemanager is a GTK+2 interface built on top of libferris. It provides GTK treeview , gevas/edje and gecko based interfaces and makes extensive use of libferris clients to provide its functionality.
If you have a project you wish to use libferris with and want extensions made dont hesitate to contact one of the developers to arrange consulting.
For the geeks out there, libferris is a virtual file system (VFS) that runs in the user address space. At the moment libferris is a shared object that each application can dynamically link to in order to see the file system through a nicer abstraction.
New additions to the XML module allow for data to be converted from one format to another by the VFS for you. To copy data to an XML file:
fcreate --create-type=xml --rdn=2.xml root-element=fred /tmp
gfcp -av Makefile.am --dst-is-dir /tmp/2.xml/fred
To copy data to a db4 file
fcreate --create-type=db4 --rdn=2.db /tmp
gfcp -av Makefile.am --dst-is-dir /tmp/2.db
Ferris presents a C++ interface that makes heavy use of the STL and IOStreams. Currently ferris has two main internal abstractions: Context and Attribute. A context is much like a traditional file or directory in a file system, the major differences being that a context can have both byte content (like a file) and subcontexts (like a directory). An attribute is a chunk of metadata about a context. Contexts can have many attributes.
Some attributes may be large, for example a base 64 encoded version of the contexts content (133% context size). On the other hand an attribute can be small, for example the file size is exposed as an attribute.
Access to all contexts and attributes is performed by first requesting either an IStream or IOStream for that context or attribute. In this way the same context/attribute can be open many times at the same time, just like normal kernel based IO.
Ferris uses Loki from "Modern C++ Design" by Alexandrescu. Most objects use automatic garbage collection based on the SmartPtr template class from Loki. Where possible objects in ferris use a FerrisRefCounted policy to provide COM like intrusive reference counting. This style is used for Context, Attribute and special wrappers of IOStreams that are provided. IOStreams are wrapped to provide a more flexible API than could be offered using references to IOStreams.
There are also new stream classes provided, for example NullStream and LimitingStream. Templates are provided to make SmartPtrs to standard IOStreams act just like the underlying stream would, for example, one can have SmartPtr ss; ss >> stringObj; and does not have to dereference the SmartPtr to use standard IOStreams extractors or inserters.
Ferris uses GModule from glib2 to dynamically load both context and attribute classes at run-time. This way resources are conserved until they are needed. The native file system context is statically linked to ferris at present. When loading either contexts or attribute classes ferris uses a double dispatch factory method. Put simply this means that for each plugin there are two libraries, one that tells ferris if the main one really needs to be loaded or not. Using this scheme ferris can load all the meta factory classes at any time and use these very small meta factories to check if the main factory can create objects that are going to be useful.
This scheme is of great use for attribute classes. Attribute classes take a context and can "generate" attributes from the context. An example of this sort of class would be a MD5 or Base64 attribute. Both can be generated from the base context. More interesting attributes are PCM audio and RGBA-32bpp image data. By using the double dispatch factory ferris can handle a great deal of attribute generators and load them on demand.
Ferris currently can decode mp3, read id3 tags, decode many image formats and break some animation formats into frames. This makes ferris a solid starting point for multimedia applications.
Ferris will automatically mount sub file systems for you. Examples of a sub file system include a Berkeley database or XML file. For example it is possible to read a context such as /tmp/myxml.xml/mynode. Using this automatic mounting the differences between storage formats effectively disappear. To a ferris enabled application loading data from a native disk file, a Berkeley database, and XML file, or mbox file appear to be the same. This allows the user of the application to choose the correct storage for the data at hand.
It is planned to move to a microkernel architecture in Version 2.1 of ferris. I choose 2.1 so that ferris does not fall into version 2 syndrome.
Enhancements:
- Many changes were made to better support rsync(1).
- Extended Attribute support was greatly improved.
- write() now also updates mtime.

blueMarine project is about an open source workflow for digital photography.

What does it mean?

Start thinking of an opensource application like Aperture or Lightroom that enables you to organize, develop, print and publish your photos. Pretty standard stuff nowadays. Opensource, at first sight, means that the application is free. Now think of an application written with the Java™ language: the application runs everywhere, Mac OS X, Linux, Windows. Now think of a community of people that adds code, plugins, crazy ideas, integrating some of the latest, cool technologies around, such as GPS positioning or geo-mapping.

Well, this is just the core concept of the blueMarine project.

Lets go on and lets think of the workflow. For the existing commercial applications the workflow starts just after shooting the photo and ends with a print on paper, the photo archived and maybe a web gallery published.

Just for a starter, we could do these things in innovative ways. For instance, trip reports could take advantage of GPS positioning data and Google Maps. Galleries could be presented in form of a virtual 3d gallery with walls and pictures hang on them.

Thinking of it twice, there are holes in workflows supported by current commercial applications. For instance, if you want to filter your images with a sophisticated noise reduction algorithm or if you want to create a bigger composite photo out of several shots, you likely have to use an external application. Some communities, such as amateur astrophotographers, need some very special processing that is usually performed by means of specific software. Wouldnt be better to have all of these facilities integrated in a single front end?

Now, lets broaden our workflow horizon. It can extend well beyond the print or the archival. For instance, an ornithologist usually manages field notes about the bird observed and photographed: directly binding them to photos and maybe GPS positioning data is much better than keeping a separate Excel sheet. It can also start much before shooting the photo. Think of trip planning: maybe you travel to nice places and spot interesting subjects, but not all the conditions are favorable: the weather, the light, the sun position, or the season (snow, blossomed flowers, foliage colors). Maybe you take some photos but at home you decide: hey, Im going to return there next Fall when the trees are reddish. Wouldnt be cool if a software application could allow you to easily manage all of these wanna-shoot-again photos, maybe providing assistance to guess which will be the sun position in a certain day and hour and integrating weather forecasts? And synthetising a trip program that can be uploaded on your palm gear?

Theres a further point with opensource photo workflow. Its related to the world of camera raw formats, that is the way professional DSLR cameras work. They provide you with the raw bits from the sensor that need to be extensively cooked, or developed, for getting a good image. This approach gives a tremendous amount of control to the photographers - too bad that most formats are proprietary and not documented. blueMarine supports the OpenRAW initiative and provide an opensource implementation of developing tools for camera raw formats from an ever increasing number of vendors.

Well, all of this and more is the aim of the blueMarine project.