Free cow software for linux

The library born to solve a problem I had when working with the Linux Kernel archives that I use to replicate using hard links. Replicating archives with hard links is both fast and space saving, and it helped me a lot in speeding up my operations when working on the kernel source.

A recent Archs mailing list thread that suggested that use of hard links to create archive cached revisions pushed me to write the FL-COW library. What is the problem with hard links when, for example, Im working with kernel sources? The problem is that I do a:

$ cp -al linux-2.6-test6 linux-2.6-test6.vm-fix

This command replicate at light speed the vanilla (Linus) archive into an archive I can start hacking on. The problem is that I have to manually remember to break hard links on files I start working on, otherwise even the original copy get modified.

This might break because I forgot doing so and it might also break because other tools might eventually touch file they were not supposed to touch. If it happens that I forget to decouple a file hard link, the next command:

$ diff -Nru linux-2.6-test6 linux-2.6-test6.vm-fix

will skip all changes done on the file I forgot, because my changes has been applied to the original file also. The library works by intercepting all file open operations happening inside a configured path list, and by decoupling the hard link with a COW if a write operation is requested.

The library is installed using the environment variable LD_PRELOAD and in this way it is able to hook glibc open(2) functions and it is able to perform the COW when necessary. The environment variable FLCOW_PATH control which paths should be subject to COWing. The logic that the library follow to know if a file should be COWed is the following:

Is the file being opened with O_RDWR or O_WRONLY modes?
Is the file inside one of the paths listed inside the FLCOW_PATH environment variable?
Is the file being opened a regular file?
Is the (struct stat)->st_nlink variable greater than one?

If all those answers are yes, the file is COWed by leaving the calling application with a non hard linked version of the file. To setup the library you must start with building it doing a (for example):

$ ./configure --prefix=/usr
$ make
$ make check
$ su
# make install

If all those steps complete correctly you will have your library installed in /usr/lib/libflcow.so that is ready for use. I use to set the LD_PRELOAD inside my .bashrc file so that I am sure that no tool will screw up my hard-linked archives.

This is the relevant section of my .bashrc file:

export LD_PRELOAD=/usr/lib/libflcow.so:$LD_PRELOAD
export FLCOW_PATH=/usr/src/:/home/davide/arch-archives/

Cow is something like a waveform editor in that it generates a wave file from one or more graphs for amplitude and frequency. It has a graphical user interface that simplifies this process.

First i wrote some classes to generate wavefiles with graphs for amplitude and frequency. Thats really simple sound synthesis. The waveformeditor of Christopher Rowley[1] inspired me. As it worked i made a little GUI just because its more compfortable to edit the
graphs... Ok. I could produce sounds, thats fine. Someone lend me a midi-keyboard and i programmed something to play the sound at different tonepitches. Well, thats it. Was a funny project, still works for me, but i guess it is dead. This will be the last release so
far. Hope you have fun with it .

cowman reads midi-events from /dev/midi00 and plays the apropriate note on /dev/dsp. You must start it with a cow-file as command-line-option or with a configfile. See manpage.

Code::Splice injects the contents of one subroutine at a specified point elsewhere.

SYNOPSIS

use Code::Splice;

Code::Splice::inject(
code => sub { print "fredn"; },
package => main,
method => foo,
precondition => sub {
my $op = shift;
my $line = shift;
$line =~ m/print/ and $line =~ m/four/;
},
postcondition => sub {
my $op = shift;
my $line = shift;
$line =~ m/print/ and $line =~ m/five/;
},
);

sub foo {
print "onen";
print "twon";
print "threen";
print "fourn";
print "fiven";
}

This module removes the contents of a subroutine (usually an anonymous subroutine created just for the purpose) and splices in into the program elsewhere.

Why, you ask?

Write stronger unit tests than the granularity of the API would otherwise allow

Write unit tests for nasty, interdependant speghetti code (my motivation -- hey, you gotta have tests before you can start refactoring, and if you cant write tests for the code, youre screwed)

Fix stupid bugs and remove stupid restrictions in other peoples code in a way thats more resiliant across upgrades than editing files you dont own

Be what "aspects" should be

Screw with your cow-orkers by introducing monster heisenbugs

Play with self-modifying code

Write self-replicating code (but be nice, were all friends here, right?)

The specifics:

The body of the code { } block are extracted from the subroutine and inserted in a place in the code specified by the call to the splice() function. Where the new code is spliced in, the old code is spliced out. The package and method arguments are required and tell the thing how to find the code to be modified. The code argument is required as it specifies the code to be spliced in. That same code block should not be used for anything else under penalty of coredump.

The rest of the argumets specify where the code is to be inserted. Any number of precondition and postcondition arguments provide callbacks to help locate the exact area to splice the code in at. Before the code can e spliced in, all of the precondition blocks must have returned true, and none of the postcondition blocks may have yet returned true. If a postcondition returns true before all of the precondition blocks have, an error is raised. Both blocks get called numerous times per line and get passed a reference to the B OP object currently under consideration and the text of the current line:

precondition => sub {
my $op = shift;
my $line = shift;
$line =~ m/print/ and $line =~ m/four/;
},
... or...
precondition => sub { my $op = shift; $op->name eq padsv and $op->sv->sv =~ m/fred/; },

Its possible to insert code in the middle of an expression when testing ops, but when testing the text of the line of code, the spliced in code will always replace the whole line.
Ill probably drop sending in the opcode in a future version, at least for the precondition/postcondition blocks, or maybe Ill swap them to the 2nd arg so theyre more optional.

Do not attempt to match text in comments as it wont be there. The code in $line is re-generated from the bytecode using B::Deparse and will vary from the original source code in a few ways, including changes to formatting, changes to some idioms and details of the expressions, and formatting of the code with regards to whitespace.

The splicing code will die if it fails for any reason. This will likely change in possible future versions.
There are also label and line arguments that create preconditions for you, for simple cases. Of course, you shouldnt use line for anything other than simple experimentation.

References to lexical variables in the code to be injected are replaced with references to the lexical variables of the same name in the location the code is inserted into. If a variable of the same name doesnt exist there, its an error. ... but it probably shouldnt be an error, at least in the cases where the code being spliced in declares that lexical with my, or when the variable was initiailized entirely outside of the sub block being spliced in and was merely closed over by it.

See the comments in the source code (at the top, in a nice block) for my todo/desired features. Let me know if there are any features in there or yet unsuggested that you want. I wont promise them, but I would like to hear about them.

Gnome Wireless PC Lock is a Gnome applet that locks your desktop when you walk away from your desk.

A small gnome program that locks your desktop when you walk away from your desk. It is tested with a Sitecom cn-129 Wireless PC Lock.

Kopete Avatar script sets your avatar in Kopete with current amaroK cover.
Compatible with now listening module(include in kopete).
To install it, set global identities in kopete with photo == /tmp/kopete-amarok-cover.png
To use default avatar, edit .avatarrc in your home.
ex:
gnumdk@milouse:~$ cat .avatarrc
/mnt/Datas/tof/Cow.jpg
gnumdk@milouse:~$
Based on Kopete Now Listening:
http://kde-apps.org/content/show.php?content=33503
Enhancements:
- Now works directly when activated
- Switch to default avatar when disabled

Basic Local Alignment Search Tool is a set of similarity search programs designed to explore all of the available sequence databases regardless of whether the query is protein or DNA.
It uses a heuristic algorithm which seeks local as opposed to global alignments, and is therefore able to detect relationships among sequences which share only isolated regions of similarity.
It can be run locally as a full executable, and can be used to run BLAST searches against private, local databases, or downloaded copies of the NCBI databases. It runs on Mac OS, Win32, LINUX, Solaris, IBM AIX, SGI, Compaq OSF, and HP- UX systems.
Main features:
Nucleotide
- Quickly search for highly similar sequences (megablast)
- Quickly search for divergent sequences (discontiguous megablast)
- Nucleotide-nucleotide BLAST (blastn)
- Search for short, nearly exact matches
- Search trace archives with megablast or discontiguous megablast
Protein
- Protein-protein BLAST (blastp)
- Position-specific iterated and pattern-hit initiated BLAST (PSI- and PHI-BLAST)
- Search for short, nearly exact matches
- Search the conserved domain database (rpsblast)
- Protein homology by domain architecture (cdart)
Translated
- Translated query vs. protein database (blastx)
- Protein query vs. translated database (tblastn)
- Translated query vs. translated database (tblastx)
Genomes
- Human, mouse, rat, chimp cow, pig, dog, sheep, cat
- Chicken, puffer fish, zebrafish
- Environmental samples
- Protozoa
- Insects, nematodes, plants, fungi, microbial genomes, other eukaryotic genomes
Special
- Search for gene expression data (GEO BLAST)
- Align two sequences (bl2seq)
- Screen for vector contamination (VecScreen)
- Immunoglobin BLAST (IgBlast)
- SNP BLAST
Meta
- Retrieve results

libmpd is very new, I wrote it to abstract the mpd abstraction out of the code in gmpc. Therefor making gmpc code easier to read, but even more important easier to debug.
Libmpd will now be released as a set of C files. The main goal is to make it a seperate library. Comments/suggestions are more then welcome, just keep in mind this is a pre-release.
Goal:
Trying to provide a easy to use high level, callback based access to mpd. It tries to be fast and keep the data transfer with mpd to the minimum. Todo this it implement qeues for deleting and adding songs. There is extra functionallity added for the eas of the programmer.
Its written in plain C and uses the following header files:
- regex.h
- libmpdclient.h
- stdio.h
- stdlib.h (using __USE_GNU)
- debug_printf.h (should come along with libmpd)
Main features:
- Basic player access.
- Playlist access.
- Error handling.
- Command queues.
- Advanced search.