Free 1.01 software for linux

Kom stands for "Keep old mails". It imports emails in a MySQL database and provides a frontend in gtk2 to search and browse the archived emails. Some options can be used to incrementally import mails (do to it each month for example).

Kom project can also export mails stored in the database, in mbox format or one-message-per-file format, and generate some statistics.

Luca is our new accounting software project. Luca is meant to be a rewritten version of CTB. The main development framework is Python+TurboGears.
Luca is named after Luca Pacioli, the man invented the double-entry accounting method.
Luca is still in early stages of development. Thanks for your patience.
The main framework is TurboGears, so a fair amount of Lucas architecture comes directly from TurboGears stack: Javascript+Mochikit for client-side trickery and AJAX; Kid for HTML templating; CherryPy as controller framework, and SQLObject as database-neutral model.
It was decided long ago (from 2000) that the base development language would be Python, since it has been the best interpreted language around. The next question was which Web framework to use (or go solo and create a mini-framework from scratch). The framework should be free, unobtrusive, "Pythonic" and have a fair learning curve.
Before TurboGears, Zope was considered for Luca. It has really being pushed by the Python community as the "Python on Rails". Zope proved to be too bureucractic (too much typing for too little work) and difficult to learn. However, some specific Zope components e.g. ZODB are really of great value and could be reconsidered for Luca adoption in the future.
Enhancements:
- The code was updated to Turbogears 1.0.2.2 and Python 2.5.
- A ton of bugfixes and many improvements were made.

xmemo is a small X Windows desktop memo.
A memo can be sent to other machines running xmemo, IPMsg or Oboegaki.
Enhancements:
- [New] Presence/Absence mode.
- [New] Pass some command line parameters to XtAppInitialize.
- [New] GNU like installation ( configure, make, make install ).
- [Change] Process of memo data file when the xmemo starts up.

eArea is a simple cross-browser WYSIWYG text editor. It works on Explorer, Firefox/Mozila and Safari/Konqueror.

eArea project even with OS X Dashboard widgets! If eArea comes across a browser it doesnt support (like Opera), it will display an ordinary < textarea > instead.

How does it work?

Putting eArea onto a webpage is really simple. All you need to do is upload the eArea folder to your website and paste a snippet of code into your HTML.

Everything about eArea is customisable: from what buttons are shown to the size of the text area and the style of the text in it. All from within the snippet of code in your HTML! You can even have as many eAreas on you pages as you like!

S-Jinn is a free open-source Linux application written in C. It is designed to be used with external TIA/EIA-232 (RS-232) test, measurement, and control devices and allows for rapid prototyping, automation, and deployment. I believe you will find it easier-to-use, more intuitive, and more concise than stty or C-Kermit with regards to command-line and/or scripted RS-232 data acquisition and control.
Popular Linux communications packages like Minicom are easy-to-use, but are primarily designed to work with modems, PCs, and other standard equipment. They typically lack support for all of the possible combinations of UART communication settings required by RS-232 test, measurement, and control devices on the market.
Many popular communications packages lack command-line support. Some provide scripting languages, but S-Jinn frees you from these application-specific languages. S-Jinn allows you to manipulate your data from your favorite Unix shell and/or scripting language whether it be Bash, Python, Perl, Expect, or you name it.
Main features:
- Control RS-232 DTR and RTS lines from the command-line and optionally display DTR, RTS, CTS & DSR status
- Send control characters (i.e. the NULL character)
- Send values in hex
- Specify read length
- Display the read buffer in ASCII, hex or ASCII-over-hex.
- Program & display coded/programmable delay times
- Supports virutally all baud rates, parity, and data lengths found in standard PC UARTS
- Output Formats: Wrap text, truncate lines, add, display, or supress trailing new lines
It is not designed to be used for serial communications with modems or for use as a terminal emulator. There are a large number of free open-source applications available that are much better suited to those functions. S-Jinn is written to work with RS-232 based data acquisition equipment such as: Multimeters, A/D modules , D/A modules, digital inidicators, gauge multiplexers, temperature sensors, humidity sensors, etc.
Enhancements:
- The code was cleaned up to fix compilation issues with some new versions of GCC.

mp3org is a simple but effective way of getting mp3s in and out of a mp3 player that mounts as a drive.

Lets you preview, organise and generally sort through that back log of "someday maybe" mp3 files.

Installation:

Keep the "detect.sh" and "mp3org.kmdr" files in the same folder.
Edit the "detect.sh" file with a text editor.
There are 3 adjustable variables at the top of the file.
DEV = the mount point of your MP3 drive (user RW access)
INTRAY = where I put all my new mp3s up for consideration
OUTTRAY = the root of my music library on the HD
Edit them as appropriate.
Mount your MP3 player drive.
Chuck some mp3 files in your In Tray folder.
Click "mp3org.kmdr"

Sproxy is a project meant to replace the Scout as the preferred method of URL harvest for Siege.
It is an HTTP proxy server written in perl and designed to collect all URL information in a siege-friendly format. All necessary modules are bundled with the source. Sproxy is built with GNU autotools.
PLATFORM SUPPORT
Sproxy was written on GNU/Linux and should run on all platforms that support perl. It has been successfully tested on recent releases of Solaris, HP-UX and AIX.
Enhancements:
- This version adds GNU/autotools support for the configuration and build.
- It is designed to detect dependencies and dynamically configure the application to fit the environment.
- It bundles all necessary perl modules for the convenience of the user.
-

sdparm utility outputs and in some cases modifies SCSI device parameters. When the SCSI device is a disk, sdparms role is similar to its namesake: the Linux hdparm utility which is for ATA disks that usually have device names starting with "hd".
More generally sdparm can be used to output and modify parameters on any device that uses a SCSI command set. Apart from SCSI disks, such devices include CD/DVD drives (irrespective of transport), SCSI and ATAPI tape drives and SCSI enclosures. A small set of commands associated with starting and stopping the media, loading and unloading removable media and some other housekeeping functions can also be sent with this utility.
This utility currently contains over 500 entries spread across generic mode pages, transport specific mode pages, vendor specific mode pages, Vital Product Data (VPD) pages and their attributes. Rather than try and document all of these here (or in the man page), another approach is taken. This utilitys internal tables can be searched and output with the --enumerate option. Additional explanatory information is output when the --long option is used (and more if the --long option is used twice).
SCSI mode pages
Mode pages hold meta data about a SCSI device which can, in some cases, be changed by the user. In SCSI parlance the "device" is a logical unit of which there may be several in a SCSI target. In the case of a SCSI disk connected directly to a Host Bus Adapter (HBA) the disk is both a SCSI target and a logical unit. The "user" in this case is the person using sdparm which is a SCSI "application client" and it feeds commands into a SCSI initiator. The SCSI initiator is found in the HBA. At the command level SCSI is a client-server protocol with the logical unit (or target device) being the server that responds to commands sent by the application client via the SCSI initiator.
Mode pages are defined in SCSI (draft) standards found at www.t10.org . Mode pages common to all SCSI devices are found in the SCSI Primary Commands document (SPC-4) while those specific to block devices (e.g. disks) are found in SBC-3 and those for CD/DVD drives are found in MMC-5. This diagram shows how various SCSI and associated standards interrelate. Often device product manuals detail precisely which mode pages (and parts thereof) are supported by a particular model and describe the way that the device will react if the generic description in the SCSI (draft) standard needs amplification. There are also transport protocol specific mode pages for transports such as "spi" (the 25 year old SCSI Parallel Interface), "fcp" (Fibre Channel Protocol) and "sas" (Serial Attached SCSI). There are also vendor specific mode pages. Mode pages that are not transport protocol specific or vendor specific are sometimes referred to as "generic" in sdparms documentation.
To see a list of generic mode page names that sdparm has some information about use: sdparm -e. To see a list of transport specific mode page names that sdparm has some information about use (for example) sdparm -e -t sas. Both lists are sorted alphabetically by mode page abbreviation.
Mode pages are not the only mechanism in SCSI devices for holding meta data. Information which seldom if ever changes for a particular device may be found in the Vital Product Data (VPD) pages which are obtained via the SCSI INQUIRY command. Performance statistics are held in log pages which are obtained via the SCSI LOG SENSE command. Recent CD/DVD drives hold a lot of information in feature and profile descriptors (see MMC-4 and MMC-5) which are accessed via the SCSI GET CONFIGURATION command (see the sg_get_config utility in the sg3_utils package).
Each mode page has up to four tables associated with it. These can be thought of like tabs on a spreadsheet, with each tab containing the same size table. The four tables are:
current values: those values that are active at this time
changeable values: bit masks showing those values that the user may change
default values: the manufacturers default values
saved values: those values that will be active after the next power cycle (or format)
The saved values are optional. If the mask in the changeable values indicates a field can be changed then the corresponding field in the current values may be changed. A bit of 0 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may not be changed. A bit of 1 in the changeable values mask indicates the corresponding bit in the current values (and saved values) may be changed. At the point when a current value is changed, the user may also choose to change the corresponding saved value.
The manufacturer obviously knows a lot about the characteristics of its devices. Hence if a current field value (and saved field value) is different from the default field value then there should be some rationale.
Some current values represent a state within the target device or logical unit. If that state changes so does the current value. Such values are not usually changeable by the user.
The sdparm utility has a --get, --set, --clear type of command line interface in which mode page fields are identified by an acronym. In many cases these acronyms will correspond precisely to the standard (e.g. "WCE" for Writeback Cache Enable in the caching mode page of SBC-3). For some longer fields the standards "spell out" a field name (e.g. "Write Retention Priority" in the caching mode page of SBC-3). In such cases the sdparm utility uses an acronym (e.g. "WRP"). In sdparm, acronyms across all generic mode pages are unique (i.e. an acronym matches at most one field of one generic mode page). Each transport protocol has its own namespace of acronyms so that an acronym is unique within a transport protocol. By default, saved values are not changed by --set and --clear. When changing the current values, the saved values can be changed as well by adding the --save. All the current values in a mode page can be changed back to the manufacturers defaults with the --defaults option (and the --save option here will additionally change the saved values back to the manufacturers defaults).
Changing some mode page fields is like jumping off a cliff holding onto a rope which you are not sure is properly secured. If in doubt, change the current value without using the --save option. That way if the setting is disastrous, power cycling the device will restore the previous setting. Once the new setting is known to be safe, then the sdparm utility can be re-executed with the --save option added.
sdparm commands
The --command= option allows a command to be sent to the given device. The currently supported commands are:
capacity: sends a READ CAPACITY and if successful reports the number of blocks, block length and capacity expressed in MibiBytes (1048576 bytes). Valid for disks and CD/DVD drives with the appropriate media loaded.
eject: stops the medium (if it is spinning) and ejects it from the drive. Note that this may be prevented by software in which case use the unlock command first.
load: loads the medium and then spins it up
ready: reports whether the medium is ready for IO. Ready usually means that it is present and spun up. If the device is not ready then the exit status will be 2 (see exit status section below).
sense: reports sense data (from a REQUEST SENSE SCSI command); can include power condition information, a progress indication for a time consuming command (e.g. format) or a report an informational exception (when MRIE=6)
start: spin up the medium
stop: spin down the medium
sync: send a SYNCHRONIZE CACHE SCSI command to the device.
unlock: instructs the device to allow medium removal (i.e. an eject). Beware, the OS may have had a good reason for preventing removal of the medium (e.g. it contains a mounted file system). Use at your own risk.
These sdparm commands send SCSI commands to the given DEVICE. If they dont seem to work, adding a verbose flag (i.e. -v or -vv) may provide more information. The "ready" and "sense" commands need read permissions on the DEVICE while the other commands need both read and write permissions.
Enhancements:
- Changes to SCSI mode and VPD pages that were introduced by t10.org since the last release were incorporated.
- The pass-through interface was updated, and code which is written in C was made to compile cleanly with C++.