Free summer software for linux

The following is an excerpt from a poster presented at the American Astronomical Societys 2000 Summer meeting in Rochester, NY.

ADS roughly 1,000,000 scanned pages contain numerous diagrams and figures for which the original data sets are lost or inaccessible. Having scans for the figures invites digitizing the data points to recover at least a part of these data.

Performing this digitization automatically is still beyond the capabilities of current OCR systems, but the computer can ease this process for a human.

This was the starting point for Dexter, a Java applet that runs in the users browsers and provides an interface for selecting the part of the page that is of interest. On that selection, coordinate axes, points and error bars can be marked and, of course, corrected. [...]

In the future, we plan to implement some recognition algorithms that would, e.g., trace a line for the user or automatically search for markers.

The FlightGear flight simulator project is an open-source, multi-platform, cooperative flight simulator development project. Source code for the entire project is available and licensed under the GNU General Public License.

The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing.

There are many exciting possibilities for an open, free flight sim. We hope that this project will be interesting and useful to many people in many areas.

FlightGear is a free flight simulator project. It is being developed through the gracious contributions of source code and spare time by many talented people from around the globe. Among the many goals of this project are the quest to minimize short cuts and "do things right", the quest to learn and advance knowledge, and the quest to have better toys to play with.

The idea for Flight Gear was born out of a dissatisfaction with current commercial PC flight simulators. A big problem with these simulators is their proprietariness and lack of extensibility. There are so many people across the world with great ideas for enhancing the currently available simulators who have the ability to write code, and who have a desire to learn and contribute. Many people involved in education and research could use a spiffy flight simulator frame work on which to build their own projects; however, commercial simulators do not lend themselves to modification and enhancement. The Flight Gear project is striving to fill these gaps.

There are a wide range of people interested and participating in this project. This is truly a global effort with contributors from just about every continent. Interests range from building a realistic home simulator out old airplane parts, to university research and instructional use, to simply having a viable alternative to commercial PC simulators.

Flight Dynamics Models

With FlightGear it is possible to choose between three primary Flight Dynamics Models. It is possible to add new dynamics models or even interface to external "proprietary" flight dynamics models:

1. JSBSim: JSBSim is a generic, 6DoF flight dynamics model for simulating the motion of flight vehicles. It is written in C++. JSBSim can be run in a standalone mode for batch runs, or it can be the driver for a larger simulation program that includes a visuals subsystem (such as FlightGear.) In both cases, aircraft are modeled in an XML configuration file, where the mass properties, aerodynamic and flight control properties are all defined.

2. YASim: This FDM is an integrated part of FlightGear and uses a different approach than JSBSim by simulating the effect of the airflow on the different parts of an aircraft. The advantage of this approach is that it is possible to perform the simulation based on geometry and mass information combined with more commonly available performance numbers for an aircraft. This allows for quickly constructing a plausibly behaving aircraft that matches published performance numbers without requiring all the traditional aerodynamic test data.

3. UIUC: This FDM is based on LaRCsim originally written by the NASA. UIUC extends the code by allowing aircraft configuration files instead and by adding code for simulation of aircraft under icing conditions.

UIUC (like JSBSim) uses lookup tables to retrieve the component aerodynamic force and moment coefficients for an aircraft... and then uses these coefficients to calculate the sum of the forces and moments acting on the aircraft.

Extensive and Accurate World Scenery Data Base

Over 20,000 real world airports included in the full scenery set.
Correct runway markings and placement, correct runway and approach lighting.
Taxiways available for many larger airports (even including the green center line lights when appropriate.)
Sloping runways (runways change elevation like they usually do in real life.)
Directional airport lighting that smoothly changes intensity as your relative view direction changes.
World scenery fits on 3 DVDs. (Im not sure thats a feature or a problem!) But it means we have pretty detailed coverage of the entire world.
Accurate terrain worldwide, based on the most recently released SRTM terrain data.) 3 arc second resolution (about 90m post spacing) for North and South America, Europe, Asia, Africa, and Australia.
Scenery includes all vmap0 lakes, rivers, roads, railroads, cities, towns, land cover, etc.
Nice scenery night lighting with ground lighting concentrated in urban areas (based on real maps) and headlights visible on major highways. This allows for realistic night VFR flying with the ability to spot towns and cities and follow roads.
Scenery tiles are paged (loaded/unloaded) in a separate thread to minimize the frame rate hit when you need to load new areas.

Accurate and Detailed Sky Model

FlightGear implements extremely accurate time of day modeling with correctly placed sun, moon, stars, and planets for the specified time and date. FlightGear can track the current computer clock time in order to correctly place the sun, moon, stars, etc. in their current and proper place relative to the earth. If its dawn in Sydney right now, its dawn in the sim right now when you locate yourself in virtual Sidney. The sun, moon, stars, and planets all follow their correct courses through the sky. This modeling also correctly takes into account seasonal effects so you have 24 hour days north of the arctic circle in the summer, etc. We also illuminate the correctly placed moon with the correctly placed sun to get the correct phase of the moon for the current time/date, just like in real life.

Flexible and Open Aircraft Modeling System

FlightGear has the ability to model a wide variety of aircraft. Currently you can fly the 1903 Wright Flyer, strange flapping wing "ornithopters", a 747 and A320, various military jets, and several light singles. FlightGear has the ability to model those aircraft and just about everything in between.

FlightGear has extremely smooth and fluid instrument animation that updates at the same rate as your out-the-window view updates (i.e. as fast as your computer can crank, and not artificially limited and chunky like in some sims.)

FlightGear has the infrastructure to allow aircraft designers to build fully animated, fully operational, fully interactive 3d cockpits (which even update and display correctly from external chase plane views.)

FlightGear realistically models real world instrument behavior. Instruments that lag in real life, lag correctly in FlightGear, gyro drift is modeled correctly, the magnetic compass is subject to aircraft body forces -- all those things that make real world flying a challenge.

FlightGear also accurately models many instrument and system failures. If the vacuum system fails, the HSI gyros spin down slowly with a corresponding degradation in response as well as a slowly increasing bias/error.

Moderate Hardware Requirements

The intention of FlightGear is to look nice, but not at the expense of other aspects of a realistic simulator. Our focus is not on competing in the "game" market and not on the ultra-flashy graphic tricks.

The result is a simulator with moderate hardware requirements to run at smooth frame rates. You can be reasonably happy on a $500-1000 (USD) machine (possibly even less if you are careful) and dont necessarily need $3000 (USD) worth of new hardware like you do with the many of the newest games.

That said, the more hardware you throw at FlightGear, the better it looks and runs, so dont feel like you have to chuck your expensive new hardware if you just purchased it. :-)

Internal Properties EXPOSED!

FlightGear allows users and aircraft designers access to a very large number of internal state variables via numerous internal and external access mechanisms. These state variables are organized into a convenient hierarchal "property" tree.

Using the properties tree it is possible to monitor just about any internal state variable in FlightGear. Its possible to remotely control FlightGear from an external script. You can create model animations, sound effects, instrument animations and network protocols for about any situation imaginable just by editing a small number of human readable configuration files. This is a powerful system that makes FlightGear immensely flexible, configurable, and adaptable.

Networking options

A number of networking options allow FlightGear to communicate with other instances of FlightGear, GPS receivers, external flight dynamics modules, external autopilot or control modules, as well as other software such as the Open Glass Cockpit project and the Atlas mapping utility.

A generic input/output option allows for a user defined output protocol to a file, serial port or network client.

A multi player protocol is available for using FlightGear on a local network in a multi aircraft environment, for example to practice formation flight or for tower simulation purposes.

The powerful network options make it possible to synchronize several instances of FlightGear allowing for a multi-display, or even a cave environment. If all instances are running at the same frame rate consistently, it is possible to get extremely good and tight synchronization between displays.

Flight Gear and its source code have intentionally been kept open, available, and free. In doing so, we are able to take advantage of the efforts of tremendously talented people from around the world. Contrast this with the traditional approach of commercial software vendors, who are limited by the collective ability of the people they can hire and pay. Our approach brings its own unique challenges and difficulties, but we are confident (and other similarly structured projects have demonstrated) that in the long run we can outclass the commercial "competition."

Contributing to Flight Gear can be educational and a lot of fun. A long time developer, Curtis Olson, had this to say about working on Flight Gear:

Personally, Flight Gear has been a great learning experience for me. I have been exposed to many new ideas and have learned a tremendous amount of "good stuff" in the process of discussing and implementing various Flight Gear subsystems. If for no other reason, this alone makes it all worth while.

Pineapple is an adventure game.

You are sherif of a small village in the far west.

During a dark night of summer, the gang of reds, a bad group of crazy minded people, come to your town to kill every one.

You must kill them all before all citizens are killed !

ferite is a lighweight, portable, threadsafe scripting engine with a language that is very easy to pick up and use.

ferite is a scripting engine and language written in c for complete portability.

ferite is a clean language with influences from various places: objects from Java/C++, functions from C/php, closures from scheme, block calling from ruby, namespaces from C++, as well as its own a sane loose typing mechanism, variant type and set of nice APIs.

Its origins are from one of those "it seems like a good idea", the good idea was provoked by finding perl a real pain in the arse to embed (from what I gather its easier nowadays). It started in the summer of 2000 (with various tries and fails within the pre-ceding two years). It reached version 1.0 in the second quarter of 2005.

Somawrapper is based on rows of configuration in which all are defined the modalities of access to the various ones somad with relative password, logon SSL or in luminosity,

Soma project started in summer 2003 to manage the digital version of an acitvists radio old spools.

The first release just gave just the chance to play random some audio files in a directory using an external program (at that time mpg123). In despite of that this software was never used, i kept on thinking about soma project for some weeks, until i started directly to work with a group called Reload, which was experimenting at the time a project called "eterete" and creating a place for a web radio at Pergola Tribe (a selfmanaged house in Milan).

We used, of course, a release, which was a little bit better to manage the radio-playlist and of course we implemented the software itself. From september till december soma became a software suite, configurable through file and (remote administration...). Thats thanks to the relationships and the inputs that such a community like Reload can create.

A group of passionate activists was able to make broadcastings and broadcast schedules, to find out new problems and to give implementation advices. They also suggest me the idea that soma (originally a simple play-list manager) could become a programs suite, which has a player, a software for deferred broadcasting, a more user friendly admininstration, documentation and distribution.

Some time after came soma player and soma admin. The player was still very behind compared to my implementation ideas. Somadmin was straight away on line and advertised on radio.inventati.org/somadmin/

In January 2004 we showed Soma at the first italian (web and air-waves) radio meeting in Naples.The meeting was technologically and politically profitable and it was an attempt to build up a real radio-network. Radio.inventati.org was actually the only example od direct cooperation among even very different people: individuals, improvised groups, very old and movement radios and experiences from overseas countries.

On the web site there are occasional streamings, weekly streamings, and 24hrs music flows.

The object of the technical research was a digital environment, which could let individuals or whole communities gain access to a common schedule with resum?s,
repetitions, deferred programs, live broadcastings, regular broadcastings as one national and international network. Soma could satisfy this need and could be easly managed through the web thanks to somadmin, which could update the soma admin in real time.

The developments went on. Somaplayer is now reality. The only music player which can stream directly an mp3, an ogg vorbis, a wav, a track from an audio cd or a streaming directly on an icecast server (icecast 2 or shoutcast) or just play it on a computer using sound drivers or sound daemons.

At the moment more other people work at this project, who debug the software, write docs, work at the website and make installation packages (for debian).

An MP3 LEnder is a simple MP3 server written in C.
AMPLE is short for "A MP3 LEnder" (interesting name just to make a good abbreviation?)
I wrote AMPLE one summer when I was coding for a company and got fed up with having to FTP over all my MP3 files from my home server to the computer at work just to listen to them. And the other "MP3 servers" I could find didnt fit my needs for one of the following reasons:
Depended on libfoo, libbar, python, perl, php3, Apache, libssl, etc, etc, etc...I just wanted to listen to the files
Had a lot of features for "DJ:ing" etc that I really didnt need
Well....it was fun to write too :)
So whats good with AMPLE?
Small, standalone (written in C using no external libraries)
Portable (I think), I often try to compile it on the SourceForge compile farms
Allows you to listen to your own MP3s away from home, nothing more, nothing less
This is beginning to sound like marketing cr*p so Ill just stop right there, check out the links on the left for more info.
Enhancements:
- Make ID3v2 code understand versions 2.2.0 -> 2.4.0 (all currently existing versions)
- Reformat HTML output somewhat
- Fix search-and-replace error in libwrap code
- Made servername a config option
- Renamed -r to -n (NON-recursive)
- Changed the DEF_LOGFILE (it pointed to ample.conf instead of ample.log)
- Much work on autoconf stuff, should work much better now
- Some more testing on other architectures (Ive compiled it on everything from Tru64 to Linux to *BSD)

beyond is a driver for the multimedia installation for Prof. Jill Scotts "Beyond Hierarchy" (Dortmund, Zeche Zollern, Summer 2000).

NEsGUI is a peer-to-peer file sharing application written by Neill Miller in GTK+ which utilizes the NEshare library.NEsGUI is a Napster like application. Its one of the simplest and least creative applications utilizing the NEshare peer-to-peer file sharing library.
I started writing NEshare for many reasons. One reason is because I enjoy file sharing with others and I found that there were no true Free Software implementations or designs from the ground up. Thats one of the most important reasons to me personally, but I understand its probably not the reason youre reading this page. Second, I realized that most file sharing implementations that Ive played with simply DO NOT WORK well. The one implementation that worked *extremely* well for all of the time I participated in using it was Napster. As for the GnutellaNet (and the like), I tend to have problems with the decentralized nature. This is vague, I know. Specifically, they require an extraordinary amount of bandwidth as compared to a centralized counterpart such as Napster. They tend to generate a lot of garbage since they are responsible for tying themselves to a number of other nodes, which are likewise tying themselves to you. The *only* benefit that Ive realized with decentralized networks such as the GnutellaNet is the anonyminity involved. At best, you can see what IP address is downloading or uploading while the upload or download is occuring on your system. Beyond that, there is no record or trace of the transaction and does not involve user names which can be stored or screened, passwords which can be broken or stolen, or any form of user messaging or chat which is prone to SPAM or porn advertisments -- like the sad state of (the oldest widespread and possibly least recognized peer-to-peer system) IRC.
Another reason for writing NEshare is to help you realize that you should not be dependent on a corporation to dictate what you can and cant do with file sharing (a la Napster, FastTrack clients, or any other corporate owned network which you may have become attached to). For example, Napster allowed the sharing of digital music files. Where do you go if you are more interested in sharing original digital pieces of art amongst your friends? What about copies of an ever evolving digital document? Thus, I wanted to provide NEshare to you in case Napster or FastTrack or whatever you use suddenly becomes unavailable, or never suited your needs in the first place. Being Free Software, youre free to modify it and improve it under the terms of the GPL. And if you cant write code, call in a favor from a friend!
NEshare takes the best architectural ideas of centralized networks and mixes them with the best ideas of decentralized networks. It allows anonyminity since there is no messaging system, no username, no password and no record of you once youve left the network. It also works in a reliable manner (minus bugs!) because of the centralized nature. The basic method of transaction is similar to the familiar Napster and FastTrack clients. A user connects to an NEshare server and uploads a file list. The user can search and get results back from the server. Once the results are retrieved by the user, the user connects directly to another user for exchanging files. Thats the basic gist of the centralized approach, however the NEshare architecture is flexible and can work in a decentralized manner with relatively little modification if the benefits become more apparent.
One of the biggest advantages of a purely decentralized network (aside from the anonyminity aspect) is the fact that there is no central server which all users must rely on. In the world today, we see the prevention and the hindering of new technologies because big businesses fear to compete. This is wrong. Decentralized networks address this by not allowing a single entity to have complete control over a system. Thus, although threats can be made, they cannot be enforced against all users of a decentralized network. Contrast this with some centralized models - where a corporation takes control of an entire system. They are only pitting themselves against the giants and unfortunately they probably cannot win since (in recent U.S. history at least), Corporations (with cash) suppress our rights (Constitutional, fair rights, whatever) and dont ever look back. Look at the recent headlines regarding the RIAA and Hollywoods general reaction to Napster and other file sharing services. Everyone pounced on Napster and Napster did not survive. Sure, the company may still have a vision for itself, but everything that you and I enjoyed about the service is gone. The vision weve created for it is gone. I havent used Napster since late 2000.
Im not advocating using this software for actions which are questionably legal. Im providing this software for educational reasons because I believe that there is a lot to learn about networking applications and weve only seen the tip of the iceberg. This software has many legitimate uses such as online collaboration on any number of projects, sharing original works or documents, browsing which new Free Software packages are available amongst your peers, learning how a multi-threaded server works, learning how to use sockets, seeing an example of how a network protocol can be written from scratch, congesting your local network for bandwidth experiments and measurements, etc. The uses are endless. And the uses are legitimate. This software may help other to find something new. This software may *be* something new to others. Whatever the case, its all about vision.
By designing a Free Software implementation of a peer-to-peer protocol, Im offering it to you to suit your vision. I dont want to see one central server out there that everyone connects to for whatever use. I want to see the decentralization of the centralized model. I want to see something like what happened to the webserver to happen to NEshare. Each person that is interested in this kind of project should run and manage their own server for their own intranet. Choices are good. Although NEshare is centralized right now (like a webserver) -- wouldnt it be a horrible thing if all information on the web was hosted on the same server? This is what Napster tried to acomplish. They took the centralized server a little too far to prevent people like you and me from having our own visions and creative uses for the technology. NEshare should work differently. For example, if you look at streaming radio servers -- these are central servers all over the place which have several central resources (i.e. webpages) which tell you about which ones are available and their current status. This feature is planned for NEshare, although the first release of the server will have to be tracked manually if youd like to advertise your server to others.
Id like to add that I do believe that decentralized networks inherently have some cool ideas behind them, so I did not exclude the possibility of NEshare working in a fully decentralized manner. The first version that Im working on will be only centralized, but decentralization is an option since it should not prove to be too difficult given the architecture. However, since in my experience the fully decentralized network tends to have more issues than benefits, I would like to keep NEshare centralized. Again, a decentralization of the centralized model would be ideal.
The other major design goal of NEshare is to make it a toolkit. What I mean by this is that currently, there is a client library which can readily be dropped into an application of any kind. This means that for developers who are working on applications, if peer-to-peer file sharing would be useful, it can be easily used under the terms of the GPL inside of their own applications. This also makes for a more lightweight graphical user interface, since the bulk of the work is inside the client library. In order for all of NEshare to work in a purely decentralized manner, the work of the server must be integrated into the client library and a few new messages will need to be developed so that it can act as a servent. The architecture is rather flexible, and this will remain a design goal moving forward.
Needless to say this takes a lot of work. Im a single hacker at best and Ive been working on this project in free time since the summer of 2001. I can only do so much, and Im limited by my imagination and programming skills. Thats why I need your help. So far, my work consists of designing the networking protocol capable of accomplishing file sharing in a peer to peer manner, implementing this protocol in code, testing the code, improving the code, etc. I cant do this by myself (although unfortunately so far I have been and will continue to if no one volunteers). I would appreciate help in the areas of testing, documentation, and of course good old fashioned hacking. If this project sounds interesting to you, feel free to contact me.
Enhancements:
- Code now honors the std namespace so that its gcc-3.x compatible
- Fixed some event handling that caused erroneous message boxes to appear
- Better unexpected peer disconnection handling
- Added proper ChangeLog entries