Free flightgear 0.9.10 software for linux

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.

rbot is a ruby IRC bot. Think of him as a ruby bot framework with a highly modular design based around plugins. It is somekind of a infobot. See more RbotFeatures, or perhaps an ExampleSession.
Main features:
- Runtime configuration via irc chat
- User authentication and access levels for using different bot features
- Built in infobot-style keywords. See example session below.
- Support for underlying fact database (infobot fact files), which can be overridden or supplemented by runtime keyword controls
- Multi-language support - comes with english, dutch and german definitions so far - more translations welcome
- Powerful plugin architecture, comes with plugins for:
- DNS queries
- Babelfish translation
- Google searching
- Excuse generation
- Insult generation
- Karma
- Checking the weather
- Querying slashdot
- Doing Math
- Per-channel quote storage, searching and retrieval
- Reminders
- rot13 translation
- Check the spelling of a word
- Webserver Server: header examination
- RPG dice rolling
- larting people
- conversation stats
- more...
Enhancements:
- Many new and updated plugins, including one to poll RSS feeds.
- A first step towards a better auth system (total revamp due in 0.9.11).
- Improvements to network and server code, which should provide greater stability.
- A new message queueing mechanism with bit rate throttling.
- A new logging framework for debugging and tracing the activities of the bot.
- A new split-db registry system for better performance and transactional usage of bdb for resilience.
- More integration with Nickserv where available, including optional automatic ghost-killing.

Kanjisaver is a screensaver that displays characters from a set of those commonly found on the JLPT, the Japanese Language Profiency Test. Kanjisaver can also display the on and kun readings of the kanji as well as their English meanings.
You should install a font with Japanese character support before using Kanjisaver.
You might also be interested in Kannasaver, which is also available here on KDE-Apps.org, and upon which Kanjisaver is based.
Enhancements:
- New support for data overload, allowing you to display both readings with or without romaji and translations.

JSBSim Flight Dynamics Model is an open source flight dynamics model (FDM) that compiles and runs under many operating systems, including Linux, Apple Macintosh, Microsoft Windows, Linux, IRIX, Cygwin (Unix on Windows), etc.
The FDM is essentially the physics/math model that defines the movement of an aircraft under the forces and moments applied to it using the various control mechanisms and from the forces of nature.
JSBSim has no native graphics. It can be run by itself as a standalone program, taking input from a script file and various aircraft configuration files; or, it can be run as an integrated part of a larger flight simulator implementation that includes a visual system.
The most notable example of the use of JSBSim is currently seen in the open source FlightGear simulator. JSBSim models the aerodynamic forces and moments by the classic coefficient buildup method.
JSBSim has seen the growth of a fairly large user base, with some of the more notable projects (of which I am aware) described on the Users page.
Main features:
- Fully configurable flight control system, aerodynamics, propulsion, landing gear arrangement, etc. through XML-based text file format.
- Rotational earth effects on the equations of motion (coriolis and centrifugal acceleration modeled).
- Configurable data output formats to screen, file, socket, or any combination of those.
Enhancements:
- This release includes new options for the standalone JSBSim executable, including improved real-time capability.
- This release also includes experimental (but tested) logic to reduce ground reactions jitter while on the ground.

Prelude-LML is a signature-based log analyzer monitoring your log file and received syslog messages for suspicious activity.
It handle events generated by a large set of components, including but not limited to: APC Emu, BigIP, Cisco PIX, Clamav, Dell-OM, Grsecurity, Honeyd, ipchains, Netfilter, ipfw, Nokia ipso, Apache ModSecurity, Ms-SQL, Nagios, Norton Antivirus Corporate Edition, NTsyslog, Pam, Portsentry, Postfix, Proftpd, SSH, and others.
Enhancements:
- SSH rules are now IPv6 compliant, allowing you to merge old IPv6 only rules with IPv4 rules.
- Incorrect target user assignment has been fixed in SSH rule, as well as incorrect PCRE reference in assessment.impact.description.
- CISCO router acl lists can now use names instead of numbers (this made rule id=500 in cisco-router.rules fail to alert on packet denys on newer cisco devices).
- Apache formatting when Apache logname or user is set has been fixed, as has invalid user.user_id(0).name assignment in SSH rule 1913.
- Various other bugfixes and minor improvements were also made.

Nasal is a language that I wrote for use in a personal project. Ostensibly it was because I was frustrated with the dearth of small-but-complete embeddable scripting languages, but of course I really wrote it because it was fun.
It is still young and incomplete in a few places, but is under active development and has been integrated as the extension language for the FlightGear simulator.
Documentation is still sparse. There is a design document available, which talks at length about the "whys" behind the design of Nasal and includes documentation for the built-in library functions.
More useful to the experienced programmer is the tutorial-style sample code, which explains and demonstrates all the syntax features of the language.
Like perl, python and javascript, nasal uses vectors (expandable arrays) and hash tables as its native data format. This is a well-understood idiom, and it works very well. I felt no need to rock the boat here.
Like perl, and unlike everything else, nasal combines numbers and strings into a single "scalar" datatype. No conversion needs to happen in user code, which simplifies common string handling tasks.
Like perl, but unlike python, hash keys must by scalars in nasal. Python supports a "tuple" constant type that can be used as well, but there is no equivalent in nasal (you cant use vectors as keys because they might change after the insertion).
Like perl and python, nasal uses a # character to indicate and end-of-line comment. There is no multiline begin/end comment syntax as in Javascript.
Like perl, nasal functions do not have named parameters. They get their arguments in a vector named "arg", and can extract them however they like. Unlike perl, Nasal takes advantage of this feature to do away with function "declaration" entirly; see below.
Like python, there is no hidden local object scope in a function call. The object on which a method was called is available to a function as a local variable named "me" (python calls this "self" by convention, but because nasal has no declared function arguments, there is no opportunity to change it).
Like perl, "objects" in nasal are simply hash tables. Looking an item up by name in a hash table and extracting a symbol for an object are just different syntax for the same operation (but read on for an important exception):
a["b"] = 1 means the same thing as: a.b = 1
The above paragraph is a minor lie. The "dot" syntax is also the clue to the interpreter to "save" the left hand side as the "me" reference if the expression is used as a function/method call. That is, these expressions are not equivalent (one is a plain function call, the other a method invocation on the object "a"):
a["b"](arg1, arg2) isnt the same as: a.b(arg1, arg2)
Like javascript, nasal lacks a specific "class" syntax for OOP programming. Instead, classes are simply objects. Each object supports a "parents" member array; symbol lookup on the object at runtime bounces to the parents (and the parents parents) if the symbol is not found in the hash. The parents field is just like any other object field, you can set it however you like and even change it at runtime if you are feeling especially perverse.
Like lisp, javascript and perl, nasal supports lexical closures. This means that the local symbol namespace available to your function when it is assigned remain constant over time. If you dont know what this means, you dont need to care. It is this feature that allows functions to use variables declared in the outer scope when it is defined (e.g. seeing "module" variables).
Like all other scripting languages, functions are just symbols in a namespace, but unlike all other scripting languages, there is no function "declaration" syntax. A function is always an anonymous object (a "lambda," in the parlance), which you assign to a variable in order to use. Like so:
myfunction = func { arg[0] + 1 }
myfunction(1); # returns 2
One annoyance of this feature is that Nasal functions dont have unique internal "names". So a debugging or exception stack trace can only give you a source line number, and not a function name as reference.
Nasal has a straightforward, readable syntax which is closest to javascript among other scripting languages. Like later versions of javascript, it includes has a hash lookup syntax as well as an object field accessor syntax (that is, you can do both a.b and a["b"]).
Unlike python, nasal has a grammar which is not whitespace-sensitive. This doesnt make python hard to write, and it arguably makes it easier to read. But it is different from the way the rest of the world works, and makes python distinctly unsuitable for "inline" environments (consider PHP, Javascript, ASP or in-configuration-file scripts) where it needs to live as a plain old string inside of another programs code or data file.
Nasal garbage collects runtime storage, so the programmer need not worry about manual allocation, or even circular references. The current implementation is a simple mark/sweep collector, which should be acceptable for most applications. Future enhancements will include a "return early" capability for latency-critical applications. The collector can be instructred to return after a certain maximum delay, and be restarted later. Fancy items like generational collectors fail the "small and simple" criteria and are not likely to be included.
Like python, nasal supports exception handling as a first-class language feature, with built-in runtime-inspectable stack trace. Rather like perl, however, there is no special "try" syntax for exception handling, nor inheritance-based catching semantics. Instead, you call a "try" function on another function, and inspect the return value on your own. Code simply calls die with an argument list, which is returned from the closest enclosing try() invocation. Elaborate exception handling isnt really appropriate for embedded scripting languages. [NOTE: this isnt finished yet]
Nasal tries to be stricter than perl. Operations like converting a non-numeric string value to a number, reading or writing past the end of an array or operating on a nil reference, which are generally legal in perl, throw exceptions in nasal. Perl sometimes bends over backwards to do something "reasonable" with your instructions (e.g. whats the boolean truth value of a hash reference?); nasal doesnt try ("error: non-scalar used in boolean context at line 92")
Nasal is very small, very simple, written in ANSI C, and generally an excellent choice for embedded applications. It uses a simple and transparent syntax interpretable by a simple "bracket matching and operator precedence" parser. It does not depend on any third party libraries other than the standard C library. It does not depend on third party tools like (f)lex and yacc/bison. It builds simply and easily, supports a reasonably simple extension API and cohabitates well with other code.
Nasal makes no use of the processor stack when running recursive code. This is important for embedded languages as it provides the ability to "exit early" from a Nasal context. An outside application may have realtime constraints, and Nasal can be instructed to run for only a certain number of "cycles" before returning. Later calls will automatically pick up the interpreter state where it left off.
Nasal provides "minimal threadsafety". Multithreaded operations on Nasal objects are safe in the sense that they cannot crash or corrupt the interpreter. They are not guaranteed to be atomic. In particular, poorly synchronized insertions into containers can "drop" objects into oblivion (which is OK from an interpreter stability standpoint, since the GC will clean them up normally). Race conditions have to be the programmers problem anyway, this is just another symptom. Garbage collection will block all threads before running. [NOTE: this part is still unimplemented.]
Enhancements:
- This release contains the updates that have been available in SimGear for some time now.
- Important new functionality includes bugfixes, many performance enhancements, a declared function argument syntax, a ternary (?:) operator, indexable and mutable string objects, interpreter thread safety features, and much work to the "standard" library (including stdio, bitfields, Unix system calls, and PCRE regular expressions).

Sabayon Linux is a live DVD designed to transform a computer into a powerful Gentoo Linux system in less than 5 minutes.
Gentoo Linux is a Linux distribution powered by a software install manager engine called "Portage". Besides functioning as a live DVD, Sabayon Linux can also be installed on a hard disk, acting effectively as an easy-to-use Gentoo installation disk.
The live DVD includes a large range of desktop environments and open source software applications, such as KDE, GNOME, XFce, Fluxbox, KOffice, OpenOffice.org, FreeNX, amaroK, Kaffeine, etc.
Whats New in 3.4 Release:
- The most advanced: Linux Kernel 2.6.22 with extra Power Management (PowerTop), Wireless (mac80211), Ext4 Filesystem, Scheduler (CFS) and Virtualization (KVM,Virt-Manager,VirtualBox) support
- Gaming oriented: featuring,
- Savage 2
- FlightGear
- DangerDeep
- Warsow
- Nexuiz
- Torcs
- Battle of Wesnoth
- Latest NVIDIA (100.14.11) and AMD (8.38.6) GPU drivers
- The most Windows-aware: supporting NTFS in read/write and Wine Doors utility, that let you install Windows applications as easy as 1-2-3 (using Wine 0.9.40).
- The first to support Ext4 File System: for the braves, Sabayon Linux Installer can easily handle it.
- The most Stable Cutting Edge DVD: featuring Compiz Fusion and Metisse (Technology Preview) integration
- Much more flexible: the Installer now features a really improved execution speed, RAID10 support, Ext4 Support, UUID device naming support, a Packages Selector, a Boot Services Selector and also a Core/Minimal Install Method (Server deployments)
- The Most Laptop Aware: tested and optimized also for Laptop usage
- X.Org 7.3 with automatic Monitor configuration
- KDE 3.5.7
- GNOME 2.18.2
- Strong identity: no Server applications installed (you will find them in the Business Edition)
- Less Duplicated Packages: removed about 140 duplicated applications
- Better Mactel support: added support for Intel ICH8M, Atheros Wireless cards, Backlight management and new Synaptics touchpads
- Better Out of the Box hardware support: Agere et131x,
- VMware Guest Installation Support
- Media Center capabilities: featuring GeeXbox 1.1 and Elisa Media Center (Technology Preview)
- Incredible set of installed and preconfigured Applications (see Packages List below)
- The most tested Stable Release: in the last 4 months, our Core Beta Team have done a great work to accomply our always growing QA standards. This transformed Sabayon Linux 3.4 in the most reliable version ever released.
Enhancements:
- We are happy to announce Sabayon Linux 3.4 Revision E. Distribution updates: introduced a (teaser) pre-alpha release of the Entropy stack (Equo application); updated Portato to 0.8.0; updated Compiz Fusion to work with XGL and AMD/ATI cards; updated WINE to 0.9.42 and fixed Wine Doors; re-introduced sudo after install; updated Second Life to 1.18.0.6; fixed partitioning issues on some system caused by dmraid stack (disabled by default now); re-introduced old and stable ipw3945 driver; updated pommed to 1.7 (better MacBook support); re-introduced old bcm43xx wireless driver.