Free diversity in the workplace software for linux

Easiest Edit In Place enables Web (2.0) developers to generate any number of edit in place widgets with only one line of script code.
Using stylesheets and spans, any piece of text can be edited by any type of widget. Easiest Edit In Place features CSS customization and automatic caret positioning.
Main features:
- It requires only 1 line of javascript to make any number of widgets editable.
- Caret positioning. When editing inline, the caret is positioned at the point the user clicked, to make it more intuitive.
- Editor can be anything, from ordinary text input to text areas or custom widgets.
- Everything can be styled using CSS.
Eeip has been tested on Firefox and IE.
Enhancements:
- A bug that could lead to the accidental display of placeholder text when dealing with empty fields in some circumstances was fixed.

Ghost In The Mail is an anonymous e-mail client for linux written in C and designed in GTK+ 2. Look at the screenshots below to have a better idea of how does it works.
This piece of software allows to send e-mails to any person over the net with a fake email address, and also a fake name. Obviously you can use your true identity. gitmail can also send attached files. Ghost In The Mail uses MIME and Base64 technologies.
Enhancements:
- Full review of the code in order to improve stability and performances.
- Rewrite of all functions that contained malloc(CONST_VAL).
- Added functions gitm_malloc & gitm_realloc that check pointers after allocating them.
- Added some commentaries to describe functions.
- New sources files: functions are distributed into files in a more logical way.
- Files cbbentries.* removed (functions in cbbentries.* are now in history.*) Better core/gui splitting.
- Created a constant GITM_VERSION to hold the version number.
- MIME boundary is now randomly generated.
- Server errors are fully displayed.

Rippy the Aggregator project is a lightweight RSS aggregator written in vanilla PHP.
There are several Web sites (Slashdot, for instance) that I visit regularly or semi-regularly to check for the latest news; there are also several more (like, say, the EFF) that post regular updates and that Id like to visit regularly, or that would like to have me visit regularly, but which I dont visit regularly because its just too much work to keep track of all of them, and too disappointing when I remember to check and find nothing new. I even run a Web site of my own which Id like to have people check regularly - but since I dont spend time making the rounds of my friends similar sites, I cant expect them to visit mine. Rippy the Aggregator aims to solve all these problems.
There is a standard called RSS, for Web sites to publish their updates in a machine-readable format. An appropriate client can quickly visit all the Web sites youre interested in, download their updates, and present you with a customized list of all the newest items. Most "blogging", "portal", and "content management" software already generates RSS files (although its operators may be unaware of that!), and there are services like Syndic8 that compile lists of RSS "feeds". So it only remains to get an appropriate client.
That presents a problem. I hacked an RSS output onto my Web-site updating scripts, so I had that aspect covered, but then I wanted to start reading others RSS feeds, and I discovered that the client programs you can get on the Web mostly suck. Some of them are Windows-only, so those are right out. I saw one in Java that looked pretty good, but its Web site didnt provide a way to download it except through some kind of weird Hot-Buzzy-Java-Scripted-Auto-Virus-Install-Plugin-Thing - there was no actual file. I did eventually find its source code, but it required third-party libraries.
Then I looked at several RSS readers that were written in Perl or PHP and designed to run as scripts on a Web site. Those had possibilities, but they required multiple third-party libraries (Perl) or an SQL server and compiled-in PHP modules that most people dont have (PHP).
The best attempt I found was one written in Python, but in order to make it run I had to start not one but two background server daemons, which would make it tricky to use on my office computer at school. There are Web sites that provide the service of RSS reading, but they all require registration, cookies, JavaScript, etc. I couldnt find an RSS reader (or "aggregator", as theyre called) that I could just download and have it work. Thus, it was necessary to create one: enter Rippy!
The name "Rippy the Aggregator" refers to an Arrogant Worms song about a cute, cuddly little alligator who goes "chomp, chomp, chomp," down in the bottom of the swamp, swamp, swamp. Abram Hindle has suggested that Rippy the Aggregator should go "grep, grep, grep," down in the bottom of the net, net, net. Anyone wanna write the rest of the song?
Main features:
- Cute name
- Written in PHP (needs 4.3.0 or above)
- Doesnt require any compiled-in optional libraries that dont ship with PHP
- Stores its cached data in flat files, no database needed
- Freely licensed and customizable under the GNU GPL version 2
Enhancements:
- Parser ruggedness and general stability were improved, and support was added for setting options like user agent and proxying when acting as an HTTP client.

Set photo in Kopete is a really simple service menu that just sets the current photo as your photo in Kopete, nothing more, nothing less.

It doesnt handle directories containing space yet, if someone have a workaround so that KURL dont escapes all characters that would be nice=)

Just put this file in ~/.kde/share/apps/konqueror/servicemenus or use http://www.kde-look.org/content/show.php?content=11435 to install it.

run in xterm is an servcie menu which adds "run in xterm" & "run in xterm as root" to action menu on binary files, scripts etc.

It has 2 languages: english and polish.

Installation:

copy/save this file in
~/.kde/share/apps/konqueror/servicemenus

A Sudoku Solver in C is a console-based Linux program, written in C language, that solves Su Doku puzzles using deductive logic. It will only resort to trial-and-error and backtracking approaches upon exhausting its deductive moves.
Puzzles must be of the standard 9x9 variety using the (ASCII) characters 1 through 9 for the puzzle symbols. Puzzles should be submitted as 81 character strings which, when read left-to-right will fill a 9x9 Sudoku grid from left-to-right and top-to-bottom. In the puzzle specification, the characters 1 - 9 represent the puzzle givens or clues. Any other non-blank character represents an unsolved cell.
The puzzle solving algorithm is home grown. I did not borrow any of the usual techniques from the literature, e.g. Donald Knuths "Dancing Links." Instead I rolled my own from scratch as a personal challenge. As such, its performance can only be blamed on yours truly. Still, I feel it is quite fast. On a 333 MHz Pentium II Linux box it solves typical medium force puzzles in approximately 800 microseconds or about 1,200 puzzles per second, give or take. On an Athlon XP 3000 it solves about 6,600 puzzles per sec. (Solving time is dependent upon degree of difficulty, so YMMV.)
Description of Algorithm:
The puzzle algorithm initially assumes every unsolved cell can assume every possible value. It then uses the placement of the givens to refine the choices available to each cell. I call this the markup phase.
After markup completes, the algorithm then looks for singleton cells with values that, due to constraints imposed by the row, column, or 3x3 region, may only assume one possible value. Once these cells are assigned values, the algorithm returns to the markup phase to apply these changes to the remaining candidate solutions. The markup/singleton phases alternate until either no more changes occur, or the puzzle is solved. I call the markup/singleton elimination loop the Simple Solver because in a large percentage of cases it solves the puzzle.
If the simple solver portion of the algorithm doesnt produce a solution, then more advanced deductive rules are applied.
Ive implemented two additional rules as part of the deductive puzzle solver. The first is subset elimination wherein a row/column/region is scanned for X number of cells with X number of matching candidate solutions. If such subsets (or tuples) are found in the row, column, or region, then the candidates values from the subset may be eliminated from all other unsolved cells within the row, column, or region, respectively.
The next deductive rule examines each region looking for candidate values that exclusively align themselves along a single row or column, i.e. a vector. If such candidate values are found, then they may be eliminated from the cells outside of the region that are part of the aligned row or column.
Note that each of the advanced deductive rules calls all preceeding rules, in order, if that advanced rule has effected a change in puzzle markup.
Finally, if no solution is found after iteratively applying all deductive rules, then we begin trial-and-error using recursion for backtracking. A working copy is created from our puzzle, and using this copy the first cell with the smallest number of candidate solutions is chosen. One of the solutions values is assigned to that cell, and the solver algorithm is called using this working copy as its starting point. Eventually, either a solution, or an impasse is reached.
If we reach an impasse, the recursion unwinds and the next trial solution is attempted. If a solution is found (at any point) the values for the solution are added to a list. Again, so long as we are examining all possibilities, the recursion unwinds so that the next trial may be attempted. It is in this manner that we enumerate puzzles with multiple solutions.
Note that it is certainly possible to add to the list of applied deductive rules. The techniques known as "X-Wing" and "Swordfish" come to mind. On the other hand, adding these additional rules will, in all likelihood, slow the solver down by adding to the computational burden while producing very few results. Ive seen the law of diminishing returns even in some of the existing rules, e.g. in subset elimination I only look at two and three valued subsets because taking it any further than that degraded performance.
Enhancements:
- Code optimization has resulted in a 30% increase in speed.