Free creationism vs evolution software for linux

Scalix Connect for Evolution provides full-function connectivity between Novell Evolution and the Scalix Server.
Scalix Connect for Evolution natively supports IMAP and iCal, resulting in compatibility with the full range of functionality offered by Evolution. No end user retraining is required when Evolution users move to Scalix.
Scalix offers the industrys richest third party support for Novell Evolution, enabling organizations to make centralized enterprise email, calendar and scheduling, address book, and contacts a reality for users on Linux desktops. Whether using Evolution, Outlook or Scalix Web Access, Scalix users enjoy full interoperability with other Scalix clients regardless of the operating platform, email client or web browser.
Scalix Connect for Evolution provides full-function connectivity between Novell Evolution and the Scalix Server. Compatible with Evolution 2.4.x, Scalix Connect natively supports IMAP and iCal resulting in compatibility with the full range of functionality offered by Evolution. No end user retraining is required when Evolution users move to Scalix.
Main features:
- Integrated email, calendar, and directory services
- Rich Text Format (RTF) message formatting
- Offline email folder synchronization (IMAP offline mode)
- Free/Busy directory lookup for group scheduling
- Client- and server-based rules
- Public folders
- Folder management, storage and sorting
- Public distribution lists
- Full Evolution address book & contacts

Brutus is an Open Source connector for Exchange 5.5, 2000 and 2003, to put it short. Our aim is to scratch one of the most annoying itches that the Open Source community have endured. This particular itch has been experienced for almost a decade.
The problem that we are addressing is the problem of platform independent access for client applications to Microsoft Exchange from version 5.5 onwards.
Our solution to this problem will enable a feature-by-feature compatible Microsoft Outlook replacement for Linux, Microsoft Windows, the BSDs or almost any other platform.
How do we do it?
We have developed a CORBA based framework on top of the Messaging Application Programming Interface commonly known as MAPI.
Our development framework is offering client applications MAPI based access to any MS Exchange server from version 5.5 onwards. We believe that we are providing the Open Source community with a development framework that are superior to any other approach.
Our solution is distributed under the GNU General Public License (commonly known as the "GPL") or a commercial license.
Why do we do it?
We feel that there is a strong customer need for a non-Microsoft client application with full Exchange integration that is feature-by-feature comparable with Microsoft Outlook.
The only technically feasible way to achieve this level of integration is to build a client access framework on top of MAPI.
Out strategy is therefore to provide this framework to the Open Source community free of charge under the GPL and to the any commercial entity under a commercial license.
Enhancements:
- Support for OpenSUSE 10.2 was added.
- brutus-keyring is now used instead of gnome-keyring.
- A thread storm when updating the folder summary is now avoided.

The Distributed Hardware Evolution Project allows the distribution of a genetic algorithm evolving hardware designs across the Internet by setting up an island on each clients PC which will evolve during idle time. Individuals from these islands will migrate between each other as they compete for survival.

All source code is available at Sourceforge under the projects named JaGa, DistrIT, and IslandEv. The source code is generalizable to any genetic algorithm or distributed processing task.

CEIConvert provides an email conversion program for kMail, Netscape, Evolution, and Eudora.

This tool will convert your individual emlx mail files (found in ~/Library/Mail/) to the old mbox format, used by almost every UNIX/Linux mail client and recognized by many more.

Basically, it helps you migrate your email messages to a different mail client.

Evolution# is a .NET language binding for various Ximian Evolution libraries.

Building & Installing Evolution#:

The Linux build is the traditional:

./configure
make
make install

You may want to consider using configures prefix option to install Evolution# using the same prefix as Mono. That way all of your .NET assemblies get placed in the same place, and you dont need to do any extra "configuring" to make it so mono (and mint) can find your assemblies. In other words, doing something like:

./configure --prefix=/your/mono/prefix
make
make install

If you are compiling from CVS, you will need libtool and the auto* tools and will need to replace the configure above with autogen.sh.

Evolution Exchange 2.27.3 is professionally designed as the Ximian Connector for Microsoft Exchange, which adds support for Microsoft Exchange 2000 and 2003 to Evolution. Evolution provides integrated mail, addressbook and calendaring functionality to users of the GNOME desktop.

Evolution Data Server provides a single database for common, desktop-wide information, such as a users address book or calendar events.
Evolution Data Server is also a dependency of the clock applet from the gnome-applets package, 2.10 release.
Evolution provides integrated mail, addressbook and calendaring functionality to users of the GNOME desktop.
Enhancements:
Bug Fixes:
- #261084 - "match-all" and "match-threads" in evolution camel needs translator comments (Jared Moore)
- #313221 - Import of vcards misses type information (Milan Crha)
- #314709 - Add GEO field to EVCard and EContact (Cosimo Cecchi)
- #327977 - Crash in e_account_set_string at e-account.c:929 (Milan Crha)
- #352346 - Cannot create Maildir account (Milan Crha)
- #355640 - crash on invalid response to the IMAP command "XX FETCH 1 BODY" (Sankar)
- #387806 - camel_text_index_new() faults instead of handling allocation failure (Rob Bradford)
- #415891 - Use EFlag for synchronization (Matthew Barnes)
- #420462 - Crash while clicking refresh in folder subscription (Srini)
- #427469 - Incorrect importing of VCard (Milan Crha)
- #439147 - Dont print pages of debug information (Jeff Cai)
- #451003 - Build fails because SOUP_SESSION_TIMEOUT is undefined (Ross Burton)
- #455799 - Remove all .cvsignore and update svn:ignore porperty in whole directories (Hiroyuki Ikezoe)
- #458670 - Crash while autocompleting in composer (Srini)
- #460999 - Crashing while looking up passwords (Srini)
- #461989 - Memory leaks fixes on e-categories* (Hiroyuki Ikezoe)
- #464252 - Use /usr/share/lib/zoneinfo/tab/zone_sun.tab on Solaris (Jeff Cai)
- #465419 - crash in e_gw_item_append_to_soap_message (Suman)
Updated Translations:
- Jorge Gonzalez (es)
- Daniel Nylander (sv)
- Ankit Patel (gu)
- Kjartan Maraas (nb)
- Ilkka Tuohela (fi)
- Takeshi AIHANA (ja)
- Runa Bhattacharjee (bn_IN)
- Danishka Navin (si)
- Daniel Nylander (sv)
- Kjartan Maraas (nb)
- Priit Laes (et)

Evolution SpamBayes Plugin is an Evolution plugin that allows Evolution to use the SpamBayes bayesian filtering system.
The plugin is based on the Bogofilter EPlugin by Mikhail Zabaluev with some "pass message to process" code from the built-in SpamAssassin filtering plugin by Vivek Jain (amongst others).
The plugin is implemented using two python support scripts, one (sb_evolution_plugin_server) which sets up a DBus server holding the SpamBayes database and another (sb_evolution_plugin_client) which can query the client and tell it to train or untrain on messages received on stdin.
The Evolution plugin is implemented as a simple C EPlugin for Evolution using some junk-mail hooks in the evolution EPlugin architecture which is not published on the web yet (for unknown reasons).
Training SpamBayes
Evolution sports a button for marking a message as spam, and it is clear that when the user clicks this button the message should be marked as spam, that much is clear. But messages which are not marked as spam has no way to be marked as ham.
One way to fix this could be to train all messages that are marked as ham (in the checking function) as ham - and then call untrain ham and then train spam for messages when they are marked as spam.
The same problem applies when messages arrive that are marked as spam (but are ham), should they also automatically be trained as spam and then untrained as spam and re-trained as ham?
It could also be that SpamBayes is happy to only be trained when it does something wrong, rather then also when it does something right.
Where does unsure fit in?
Should the plugin do something specific to facilitate the unsure result of the SpamBayes engine?
Ideally Evolution wouls support the unsure option and make it possible to either mark the message as spam or ham (both buttons/menu-options should be active), but the message should still be delivered in the normal fashion.
An "unsure" icon in the message list (or a, maybe orange, background color in the message list), would also improve usability in my oppinion.
Conflicting with existing spam filtering plugins
Evolution apparently only supports one junk filtering plugin at the time, so you have to disable the built-in SpamAssassin plugin before the SpamBayes one will work.
Enhancements:
- Now uses Evolution 2.10.