Free workplace diversity software for linux

Olive is (yet another) GNU/Linux Live distribution. Olive LiveCD distirbution offers quite a good deal of new technologies, hardly witnessed ever before, as well as some of the more common pieces of software. Its size is approx. 110MiB, yet it allows a lot of software to be used.
Olives whole point is to display how easy to use Linux may be, yet without losing any of the features required for heavy-duty work. Its also supposed to show various unusual new technologies, not widely known or accepted.
Please note that Olive was, partially, built as graduation work at SPSST Panska. Once presented, a release built specifically for school will be available upon personal request.
Main features:
Media
Olive features MPlayer for playing of your favourite movies. It plays most MPEG, VOB, AVI, OGG/OGM, VIVO, ASF/WMA/WMV, QT/MOV/MP4, FLI, RM, NuppelVideo, Matroska files. You can also watch Theora, MPEG4 (DivX/XviD), Real Media, DVD, VideoCD, SVCD movies. MPlayer also supports various filters for better experience. Mencoder is bundled with MPlayer and it allows you to encode movies into virtually any of the formats mentioned above.
Although you can use MPlayer to play your music, theres also an application that was written just for that: Audacious. Audacious is a fork of Beep Media Player (now discontinued), which is in turn fork of the very famous XMMS. It supports various audio formats, including MPEG layer 1, 2, and 3, Ogg Vorbis, Ogg FLAC, Musepack, WAV files and Windows Media, as well as many sequenced formats including MIDI, and a host of different module formats. In addition, Audacious uses Winamp-like skins (and supports Winamp "classic" skins), to provide a familiar and friendly user interface.
You can of course view photos and pictures using GQview, an intuitive image browser. It can generate thumbnails of your pictures, its capable of reading EXIF metadata, has advanced image search function and much more.
Internet
The Internet is part of everyday life for all of us; was it not for the Internet, you wouldnt be able to read this webpage. Olive features Mozilla Firefox web browser, currently the most common web browser used on Linux. For browsing in console, ELinks is a must-have. There is also Sylpheed e-mail client, small, fast and incredibly useful.
These days, Instant Messaging is a common part of our lives. Therefore, Olive sports GAIM2 (beta2) multi-protocol instant messaging client, which is compatibile with protocols such as ICQ, MSN Messenger,Yahoo!, IRC, Jabber or Gadu-Gadu. There is also a client dedicated solely to Internet Relay Chat (IRC), which is X-Chat. As usually, there are console alternatives, which would be CenterICQ and irssi.
You can use Kismet to look for Wi-Fi hotspots. Basic utilities such as telnet or ssh client and server (Dropbear, used in various embedded systems) are not missing as well.
General work
You can perform some elementary office work in Olive as well. Although its obvious that you wont be doing most of your office work on Olive, its quite reasonable to believe it can come in handy. Therefore, Olive has AbiWord word processor to allow you to read and write documents, in various languages, in various characters, without any problem.
AbiWord can also handle various document formats, which includes Microsoft Word or WordPerfect documents. You can also export your documents into HTML for further processing or publication. You can also read Adobe PDF format using Evince, a Gnome/GTK2 document viewer whose PDF backend is based on the Poppler library, which is based on the well-known XPDF. Utilities that allow you export of PDF documents into eg. HTML are also included.
System control
Considering the differences in approach to configuration in various distributions, it may be often hard to configure several things at yet another distribution, such as the X server or preferences of software alternatives. Therefore, Olive features a trivial control panel, allowing any application to be merged in as a new panel. Although it still misses few more desired panels (most notable for network configuration), it already is quite useful for every day usage.
Eye candy
Good-looking environment always helps users to better orientate on the workplace, as well as consider the time they spend with the system more enjoyable. Transparency can be achieved using XComposite extension and xcompmgr + transset.
Though XGL and AIGLX were considered, the decision was made not to use them for their lack of testing and for the demand for support of as many platforms as possible. Please note that even XComposite may have its own issues with other software, most notably Enlightenment and MPlayer, and for this reason xcompmgr is not run by default.
Lightweight
If you consider the above features way too much for you and strive for something lighter, then you can use the FluxBox window manager. FluxBox was finetuned to look and feel as much as Enlightenment as possible, making the transition simple. There are also lightweight versions of some of the software, as mentioned above, such as irssi, CenterICQ or ELinks.
Enhancements:
- A significant bug was found in v0.1, causing ramdisk for people who have 1GiB of RAM or more broken. Please, upgrade to 0.2.

Acme::OneHundredNotOut is a raise of the bat, a tip of the hat.

I have just released my 100th module to CPAN, the first time that anyone has reached that target. As some of you may know, I am getting ready to go back to college and reinvent myself from being a programmer into being a missionary. I dont forsee that many more Perl modules coming out of this.

Of course, this doesnt mean that Im going to abjure usage of Perl forever; any time theres a computer and something I need automated, out will come the Swiss Army Chainsaw and the job will get done. In fact, we recently needed to manipulate some text from a mission handbook to translate it into Japanese, and Perl was there handling and collating all that.

But 100 modules is a convenient place to stop and take stock, and I hope that those of you who have benefitted from my modules, programs or writing about Perl will forgive me a certain spot of self-indulgence as I look back over my CPAN career, especially since I feel that the diversity of modules that Ive produced is a good indication of the diversity of what can be done with Perl.

Lets begin, then, with some humble beginnings, and then catch up on recent history.
The Embarrassing Past

Contrary to popular belief, I was not always a CPAN author. I started writing modules in 1998, immediately after reading the first edition of the Perl Cookbook - yes, you can blame Nat and Tom for all this. The first module that I released was Tie::DiscoveryHash, since Id just learnt about tied hashes. As with many of my modules, it was an integral part of another software project which I actually never finished, and now cant find.

The first module that I ever wrote (but, by a curious quirk of fate, precisely the fiftieth module I released) was called String::Tokeniser, which is still a reasonably handy way of getting an iterator over tokenising a string. (Someone recently released String::Tokenizer, which makes me laugh.) This too was for an abortive project, webperl, an application of Don Knuths WEB system of structured documentation to Perl. However, given the code quality of these two modules, its perhaps just as well that the projects never saw the light of day.

There are a few other modules Id rather like to forget, too. Devel::Pointer was a sick joke that went badly wrong - it allowed people to use pointers in Perl. Some people failed to notice that referring to memory locations directly in an extremely high-level language was a dangerous and silly thing to do, and actually used the damned thing, and I started getting requests for support for it. Then at some point in 2001, when I should really have known better, I developed an interest in Microsofts .NET and the C# language, which I still think is pretty neat; but I decided it might be a good idea to translate the Mono projects tokenizer and parser into Perl, ending up with C::Sharp. I never got around to doing the parser part, or indeed anything else with it, and so it died a lonely death in a dark corner of CPAN. GTK::HandyClist was my foray into programming graphical applications, which started and ended there.

Bundle::SDK::SIMON was actually the slides from a talk on my top ten favourite CPAN modules - except that this changes so quickly over time, it doesnt really make much sense any more.

Finally, Array::FileReader was an attempt to optimize a file access process. Unfortunately, my "optimization" ended up introducing more overheads than the naive solution. It all goes to show. Since then, Mark-Jason Dominus, another huge influence in the development of my CPAN career, has written Tie::File, which not only has a better name but is actually efficient too.

The Internals Phase

1999-2000 were disastrous years for me personally but magnificent years Perl-sonally. Stuck in a boring job and a tiny flat in the middle of Tokyo, I had plenty of time to get stuck into more Perl development. I felt that getting involved with perl5-porters would be a good way of gettting to know more about Perl, and so I needed a hobby horse - an issue of Perls development that I cared about. Since I was in Japan and working a lot with non-Latin text, Unicode support seemed a good thing to work on, and so Unicode::Decompose appeared, while I fixed up a substantial part of the post-5.6 core Unicode support.

Id recommend this way to anyone who wants to get more involved in the Perl community, although I was very lucky in terms of who else happened to be around at the time: Gurusamy Sarathy was extremely gracious in helping me turn my fledgling C code into something fit for the Perl core, and he also helped me understand the perl5-porters etiquette (yes, there was some at the time) and what makes a good patch, while Jarkko Hietaniemi was always good for suggestions of interesting things for keen people to work on. Seriously, get involved. If I can do it, anyone can.
Anyway, this fixation with understanding the Perl 5 internals, and especially the Perl 5 compiler, (due to yet another of my Perl influences, the great Malcolm Beattie) led to quite a torrent of modules, from ByteCache, an implementation of just-in-time compilation for Perl modules, through B::Flags and B::Tree to help visualising the Perl op tree, to uninit, B::Generate, optimizer and B::Utils for modifying it.

Perl About The House

Now we abandon chronological order somewhat and take a look at the various areas in which Ive used Perl. One of these areas has been the automation of everyday life: checking my bank balance with Finance::Bank::LloydsTSB (the first Perl module to interface to personal internet banking, no less) and my phone bill with a release of Tony Bowdens Data::BT::PhoneBill.

Finance::Bank::LloydsTSB was meant to go with Finance::QIF, my Quicken file parser, to produce another now-abandoned idea, a Perl finances manager. It seemed that Im only capable of producing modules, not full standalone applications - or at least, it seemed that way until I produced Bryar, my blogging software, based on the concepts from Rael Dornfests blosxom and beginning my adventures with Andy Wardleys Template Toolkit. Bryar also tuned me in to the Model-View-Controller framework idea, of which more later.

Another project I briefly played with was a personal robot, using the Sphinx/Festival speech handling and recognition modules from Cepstral and Kevin Lenzo. I didnt have X10, so I couldnt shout "lights" into the air in a wonderfully scifi way, but I could shout "mail" and have a summary of my inbox read to me, "news" to get the latest BBC news headlines, and "time" to hear the time. Of course, getting computers to tell the time nicely takes a little bit of work. I dont like "Its eleven oh-three pee em", since thats not what someone would say if you asked them the time. I wanted my robot to say "Its just after eleven", and thats what Time::Human does. Shame about the localisation.

Acovea implements a genetic algorithm for finding the "best" options for compiling programs with the GCC C and C++ compilers.
ACOVEA (Analysis of Compiler Options via Evolutionary Algorithm) implements a genetic algorithm to find the "best" options for compiling programs with the GNU Compiler Collection (GCC) C and C++ compilers.
"Best", in this context, is defined as those options that produce the fastest executable program from a given source code. Acovea is a C++ framework that can be extended to test other programming languages and non-GCC compilers.
I envision Acovea as an optimization tool, similar in purpose to profiling. Traditional function-level profiling identifies the algorithms most influential in a programs performance; Acovea is then applied to those algorithms to find the compiler flags and options that generate the fastest code.
Acovea is also useful for testing combinations of flags for pessimistic interactions, and for testing the reliability of the compiler.
Modern software is difficult to understand and verify by traditional means. Millions of lines of code produce applications containing intricate interactions, defying simple description or brute-force investigation.
A guided, deterministic approach to testing relies on human testers to envision every possible combination of actions -- an unrealistic proposition given software complexity. Yet, despite that complexity, we need answers to important questions about modern, large-scale software.
What sort of important questions? Consider the GNU Compiler Collection. I write articles that benchmark code generation, a task fraught with difficulties due to the myriad options provided by different compilers. For my benchmarks to have any meaning, I need to know which combination of options produces the fastest code for a given application.
Finding the "best" set of options sounds like a simple task, given the extent of GCC documentation and the conventional wisdom of the GCC developer community. Ah, if it were only so easy! The GCC documentation, while extensive, is also honestly imprecise.
I appreciate this style of documentation; unlike many commercial vendors, who make absolute statements about the "quality" of their products, GCCs documenters admit uncertainties in how various options alter code generation. Indeed, code generation is entirely dependent on the type of application being compiled and the target platform. An option that produces fast executable code for one source code may be detrimental to the performance of another program.
"Conventional wisdom" arrives in my inbox whenever I publish a new article. Ranging from the polite to the insistent to the rude, these e-mails contain contradictory suggestions for producing fast code.
In the vast majority of cases, such anecdotal assertions lack any formal proof of their validity, and, more often than not, the suggested "improvement" is ineffective or detrimental. It has become increasingly obvious that no one --myself included -- knows precisely how all these GCC options work together in generating program code.
I seek the Holy Grail of Optimization -- but exactly what is optimization? Understanding the problem is the first step in finding a solution.
Optimization attempts to produce the "best" machine code from source code. "Best" means different things to different applications; a database shovels chunks of information, while a scientific application is concerned with fast and accurate results; the first concern for an embedded system may be code size.
And it is quite possible that small code is fast, or fast code accurate. Optimization is far from being an exact science, given the diversity of hardware and software configurations.
An optimization algorithm may be as simple as removing a loop invariant, or as complex as examining an entire program to eliminate global common sub-expressions. Many optimizations change what the programmer wrote into a more efficient form, producing the same result while altering underlying details for efficiency; other "optimizations" produce code that uses specific characteristics of the underlying hardware, such as special instruction sets.
Memory architectures, pipelines, on- and off-chip caches -- all affect code performance in ways that are not obvious to programmers using a high-level language. An optimization that may seem to produce faster code may, in fact, create large code that causes more cache misses, thus degrading performance.
Even the best hand-tuned C code contains areas of interpretation; there is no absolute, one-to-one correspondence between C statements and machine instructions. Almost any sequence of source code can be compiled into different -- but functionally equivalent -- machine instruction streams with different sizes and performance characteristics.
Inlining functions is a classic example of this phenomena: replacing a call to a function with the function code itself may produce a faster program, but may also increase program size. Increased program size, may, in turn, prevent an algorithm from fitting inside high-speed cache memory, thus slowing a program due to cache misses.
Notice my use of the weasel word "may" -- inlining small functions sometimes allows other optimization algorithms a chance to further improve code for local conditions, producing faster and smaller code.
Optimization is not simple or obvious, and combinations of algorithms can lead to unexpected results. Which brings me back to the question: For any given application, what are the most effective optimization options?
Enhancements:
- Minor changes in the non-free license.
- Support has been added for the latest versions of libcoyotl and libevocosm.

Stanford Exploration Project Library (or SEP, for short) is an industry-funded academic consortium whose purpose is to improve the theory and practice of constructing 3-D and 4-D images of the earth from seismic echo soundings.
Although most of our research is targeted at improvements in the geophysical survey contracting industry, about half of our sponsors and alumni are in the petroleum industry because we focus on overcoming technological limitations of the geophysical survey industry.
SEP pioneered innovations in migration imaging, velocity estimation, dip moveout and slant stack. Today our focus is on 3-D seismic applications such as velocity estimation, wavefield-continuation prestack migration, multidimensional image estimation, and 4-D (time-lapse) reservoir monitoring.
Besides 3-D reflection seismic data, we undertake small 2-D imaging projects with geophysical data of all kinds. The diversity of applications exercises our judgment and skill at combining fundamentals of statistical signal theory, optimization theory, numerical analysis, and wave propagation theory, and this has led us to numerous improvements and some breakthroughs.
We organize our research to facilitate technology transfer by using a formal method of makefile rules. With these, most of our research results are verified by someone other than the original researcher. Research progress reports at least four years old and all PhD theses are made available to the public through our web site.
Enhancements:
- Numerous major new features and major bugfixes.

How do you build a web application without data? Suppose it has many pages, including forms and pages for display. Until theyre developed, users cant enter information. Mock data has to be provided to the application, to test the interaction between screens, business logic, and database.
It may take a good amount of effort to create a mock dataset large and complex enough to mimic real world situations. For example, it is not unusual for an application to be supported by a database schema with hundreds of tables, each with many columns and many foreign key relationships. The database may have millions of rows of data. Datatypes include integer, floating precision, datetime, and string. There are a wide range of values, and they are dependent on each other in ways that must satisfy the business requirements.
Mock data is useful at various points in development. It can be used with an HTTP test client, to simulate the responses a user makes at the front end. It can be inserted directly into the database, to test the database access layer. It can replace the database layer, and be provided directly to the business logic implementation.
It might be nice if the datasets at these different stages come from the same pool, so that their values represent the same underlying model. It would be nice if this model could be constructed once, and then the presentation of the data tailored for the stage at which its used.
Often a great deal of effort is spent reducing the worlds objects into a compact object model. Datamixer goes the other way: it takes a conceptual object model, and explodes it back into a diversity of objects. It tries to make this diversity easy to manage, through configuration and customization. It interacts with data repositories, and is able to mix and merge mock values with real ones. The aim is to make it easy to create the data, so that time can be spent on the data model.
Datamixer does not attempt to analyze a problem domain, in order to generate data that does a better job at testing the domain. It could be driven by a tool that does that kind of analysis.
Installation:
To install, simply unzip or unjar the distribution package to a directory of your choice. A distribution has these directories:
- The data directory has files with samples of commonly used data, such as names. It is intended to grow.
- The doc directory has documentation.
- The examples directory has example Java source and XML configuration scripts. Apache Ant is used to run these examples: type ant build
- The lib directory has all jars required by the application.
Enhancements:
- license changed to BSD.

CORBA::MICO::mapping is a CORBA mapping for Perl.

This document describes a mapping of the CORBA system into Perl. It sticks most closely to the mapping in the CORBA::MICO module, however some reference is also made to the mappings implemented in COPE and ILU/Perl.

These systems exhibit a wide diversity in the details of their object adaptors. CORBA::MICO implements most of the POA specification fashion, including all activation modes, COPE implements a version of the BOA, and ILU has its own object native adaptor different from the BOA, though it implements some of the BOA specificatoin through compatibility classes.

For this reason, this document largely avoids specifying object adaptor details, except for a few specific notes. Details about the manner in which the ORB is initialized and interface definitions are loaded are also not specified here. Conformant implementations may either use conventional stubs or access interface definitions in a dynamic manner. (For instance, by loading them from an Interface Repository.)
The design goal for this mapping was to allow applications to access the complete CORBA specification to be accessed from Perl in a convenient and concise manner, even when this requires sacrificing some amount of speed or convenience for the ORB implementor.

n-genes is a powerful Genetic Algorithms and Programming toolkit written for Java 5.
Using advanced object oriented techniques, like generics and introspection, it is one the simplest system to learn and use. N-geness design allows fast coding and a total flexibility.
n-genes is an open-source project released under GPL. It is free of charges.
Main features:
Stack-based Genetic Programming
The Genetic Programming implemented in n-genes relies on a linear postfix programs, close to Forth or Postscript programming languages. They allow the following advantages:
- High-level and turing-complete language (through flow-control instructions);
- Extendable and customisable instruction set;
- Possibility of using faster and simpler GA operators;
- Efficient bloat removing/controlling algorithms.
Modularity and Dynamic Config Files
All parts of evolutionary computing have been made components, through " Design Patterns" methodology. The benefits are:
- Separation of the behaviour from the representation, i.e. we can use the same operators for a GA doubles individual or for a GP problem;
- Short and readable code, since each object represents only a single operation and therfore has few and shorts methods.
- The possibility to change the components or their behaviour during evolution, for example changing dynamically the size of a population or using self-adaptating mutation operators.
The n-genes platform is coupled with a dynamic config file system. This system is able to instanciate whatever class, passing arbitrary parameters of whaterver types, whithout needing to extend the parser. Object introspection is used at initialisation.
Performances Optimisations
n-genes was written with high performance computing in mind. Here are the optimisations you get for free, using our platform:
- Object-recycling memory management, eliminating the time spent on objects allocation and garbage-collections;
- Efficient individual-level fitness cache, the fitness is lazy-computed and cached until the individual is mutated;
- Population-level individual cache, saving computation time when the population diversity dimish.