Free summer dresses software for linux

Somawrapper is based on rows of configuration in which all are defined the modalities of access to the various ones somad with relative password, logon SSL or in luminosity,

Soma project started in summer 2003 to manage the digital version of an acitvists radio old spools.

The first release just gave just the chance to play random some audio files in a directory using an external program (at that time mpg123). In despite of that this software was never used, i kept on thinking about soma project for some weeks, until i started directly to work with a group called Reload, which was experimenting at the time a project called "eterete" and creating a place for a web radio at Pergola Tribe (a selfmanaged house in Milan).

We used, of course, a release, which was a little bit better to manage the radio-playlist and of course we implemented the software itself. From september till december soma became a software suite, configurable through file and (remote administration...). Thats thanks to the relationships and the inputs that such a community like Reload can create.

A group of passionate activists was able to make broadcastings and broadcast schedules, to find out new problems and to give implementation advices. They also suggest me the idea that soma (originally a simple play-list manager) could become a programs suite, which has a player, a software for deferred broadcasting, a more user friendly admininstration, documentation and distribution.

Some time after came soma player and soma admin. The player was still very behind compared to my implementation ideas. Somadmin was straight away on line and advertised on radio.inventati.org/somadmin/

In January 2004 we showed Soma at the first italian (web and air-waves) radio meeting in Naples.The meeting was technologically and politically profitable and it was an attempt to build up a real radio-network. Radio.inventati.org was actually the only example od direct cooperation among even very different people: individuals, improvised groups, very old and movement radios and experiences from overseas countries.

On the web site there are occasional streamings, weekly streamings, and 24hrs music flows.

The object of the technical research was a digital environment, which could let individuals or whole communities gain access to a common schedule with resum?s,
repetitions, deferred programs, live broadcastings, regular broadcastings as one national and international network. Soma could satisfy this need and could be easly managed through the web thanks to somadmin, which could update the soma admin in real time.

The developments went on. Somaplayer is now reality. The only music player which can stream directly an mp3, an ogg vorbis, a wav, a track from an audio cd or a streaming directly on an icecast server (icecast 2 or shoutcast) or just play it on a computer using sound drivers or sound daemons.

At the moment more other people work at this project, who debug the software, write docs, work at the website and make installation packages (for debian).

MARC::Charset is a Perl module to convert MARC-8 encoded strings to UTF-8.

SYNOPSIS

# import the marc8_to_utf8 function
use MARC::Charset marc8_to_utf8;

# prepare STDOUT for utf8
binmode(STDOUT, utf8);

# print out some marc8 as utf8
print marc8_to_utf8($marc8_string);

MARC::Charset allows you to turn MARC-8 encoded strings into UTF-8 strings. MARC-8 is a single byte character encoding that predates unicode, and allows you to put non-Roman scripts in MARC bibliographic records.

Soma is a suite of programs that let you play and schedule audio files from the Web.
Soma suite supports extra utilities using run-time loadable modules and includes a broadcasting scheduler, a tool to control it via TCP/IP, and an utility to check configuration file syntax.
Soma project started in summer 2003 to manage the digital version of an activists radio old spools.
The first release just gave just the chance to play random some audio files in a directory using an external program (at that time mpg123). In despite of that this software was never used, i kept on thinking about soma project for some weeks, until i started directly to work with a group called Reload, which was experimenting at the time a project called "eterete" and creating a place for a web radio at Pergola Tribe (a selfmanaged house in Milan).
We used, of course, a release, which was a little bit better to manage the radio-playlist and of course we implemented the software itself. From september till december soma became a software suite, configurable through file and (remote administration...). Thats thanks to the relationships and the inputs that such a community like Reload can create.
A group of passionate activists was able to make broadcastings and broadcast schedules, to find out new problems and to give implementation advices. They also suggest me the idea that soma (originally a simple play-list manager) could become a programs suite, which has a player, a software for deferred broadcasting, a more user friendly admininstration, documentation and distribution.
Some time after came somaplayer and somaadmin. The player was still very behind compared to my implementation ideas. Somadmin was straight away on line and advertised on radio.inventati.org/somadmin/
In January 2004 we showed Soma at the first italian (web and air-waves) radio meeting in Naples.The meeting was technologically and politically profitable and it was an attempt to build up a real radio-network.
Radio.inventati.org was actually the only example od direct cooperation among even very different people: individuals, improvised groups, very old and movement radios and experiences from overseas countries.
On the web site there are occasional streamings, weekly streamings, and 24hrs music flows.
The object of the technical research was a digital environment, which could let individuals or whole communities gain access to a common schedule with resum?s, repetitions, deferred programs, live broadcastings, regular broadcastings as one national and international network.
Soma could satisfy this need and could be easly managed through the web thanks to somadmin, which could update the soma admin in real time.
The developments went on. Somaplayer is now reality. The only music player which can stream directly an mp3, an ogg vorbis, a wav, a track from an audio cd or a streaming directly on an icecast server (icecast 2 or shoutcast) or just play it on a computer using sound drivers or sound daemons.
At the moment more other people work at this project, who debug the software, write docs, work at the website and make installation packages (for debian).
Enhancements:
- This release fixes three bugs related to group permissions, the 31st of months, and an error in libsoma related to buffers and protocols.

CQL::Parser is a Perl module that compiles CQL strings into parse trees of Node subtypes.

SYNOPSIS

use CQL::Parser;
my $parser = CQL::Parser->new();
my $root = $parser->parse( $cql );

CQL::Parser provides a mechanism to parse Common Query Language (CQL) statements. The best description of CQL comes from the CQL homepage at the Library of Congress http://www.loc.gov/z3950/agency/zing/cql/

CQL is a formal language for representing queries to information retrieval systems such as web indexes, bibliographic catalogs and museum collection information. The CQL design objective is that queries be human readable and human writable, and that the language be intuitive while maintaining the expressiveness of more complex languages.

A CQL statement can be as simple as a single keyword, or as complicated as a set of compoenents indicating search indexes, relations, relational modifiers, proximity clauses and boolean logic. CQL::Parser will parse CQL statements and return the root node for a tree of nodes which describes the CQL statement. This data structure can then be used by a client application to analyze the statement, and possibly turn it into a query for a local repository.

Each CQL component in the tree inherits from CQL::Node and can be one of the following: CQL::AndNode, CQL::NotNode, CQL::OrNode, CQL::ProxNode, CQL::TermNode, CQL::PrefixNode. See the documentation for those modules for their respective APIs.

Here are some examples of CQL statements:

george
dc.creator=george
dc.creator="George Clinton"
clinton and funk
clinton and parliament and funk
(clinton or bootsy) and funk
dc.creator="clinton" and dc.date="1976"

The Examiner is an application that utilizes the objdump command to disassemble and comment foreign executable binaries. This app was designed to analyze static compiled binaries but works ok with others. The intention is for forensic research but could also be used in general reverse engineering.
This program can only handle basic dissassembly. If the binary has been modified to resist debugging then the Examinier probably will not be able to analyze the code. Also the Examiner will not analyze live running code. This can be a good thing but if you need to look at code when it runs or deal with complicated disassembly you should probably use Fenris.
Main features:
- Automates objdump usage
- Can generate cross-reference files of functions, interrupts and other useful things
- Locates functions within the binary
- Understands the stack and comments on its state
- Can parse and understand the contents of the .rodata section
- Cross references .rodata calls and comments on them
- Locates .data pointer references to .rodata
- Provides an easy to read CALL syntax for comments
- Understands and looks up interrupts calls
- Utilizes Linux source headers to determine function names based on what interrupt is called
- Can differentiate all of the socketcall functions
- Can comment on some C like constants for function calls
- Separates functions based on ret calls
- Can recognize and attempts to decode UPX compressed binaries
- Works with TCT and Fenris dress utility
- Can detect crippled ELF executables and burneye executables
- Recognizes symbols and will cross-reference dynamic libraries
Enhancements:
- Has rudementary detection of burneye via 7350 sig.
- Can detect crippled ELF header files (optionally uncripple)
- Added a TUTORIAL file
- Modified default working dir to $HOMEexaminer-data
- Can cross-reference .data pointers to .rodata sections
- Now records pushl calls
- Fixed -H to dump headers instead of -R
- Added -o to specify an output file or STDOUT with -
- Added -c to specify a comment character
- Added a new util xhierarchy to print function call hierarchy

Java::Import::Design is the design of the Java::Import Module.

MOTIVATIONS

The original motivation for writing this module came out of a project I was working on during my previous employment. We had built a system in which a major part was implimented using EJBs on a J2EE server. In addition, we had a large component of the system, that already existed, and was written in Perl. We did not want to scrap our Perl work but it was becoming more tedious to maintain two implimentations as more and more things were being added to the system.

So, we decided that the major pieces of business logic would reside on the J2EE server and the Perl would be modified to make calls to the server. After some time and experimentation we began to realize that the memory footprint as well as the amount of time needed to make calls to the server using existing Perl to Java integration sulutions were just not acceptable. We therefore set out to find some other way. We tried all sorts of things but in the end we couldnt find anything that met our requirements and therefore decided to keep the origional system of doing things.

While at that job we never did find a suitable way to integrate our two systems. However, the problem still haunted me. It wasnt until the end of my career at that company that I saw an announcement for Googles first Summer of Code. It just so happened that as Google was announcing their brand new program that I had begun to play with the GNU GCJ suite of Java tools and came up with the idea of taking advantage of their ability to natively compile Java code for use with Perl. This may not have been a new idea but I couldnt find anything that would help me so I decided to write and submit a proposal to Google. Well, I was accepted and you now have Java::Import.

When I began to work on this project I started by creating my own namespace instead of stepping on the toes of the other existing Java/Perl integration project, Inline::Java. I did this primarily because I wanted a clean slate on which I could fully explore the nuances of GCJ, in particular its CNI interface. As I worked my module started to evolve into its own beast and at that point it seemed locigal to keep my own namespace. It is not my intention to replace Inline::Java and I still think that in te future much of the work I have done can be used by Inline::Java as an option to use GCJ specific functionality.

An MP3 LEnder is a simple MP3 server written in C.
AMPLE is short for "A MP3 LEnder" (interesting name just to make a good abbreviation?)
I wrote AMPLE one summer when I was coding for a company and got fed up with having to FTP over all my MP3 files from my home server to the computer at work just to listen to them. And the other "MP3 servers" I could find didnt fit my needs for one of the following reasons:
Depended on libfoo, libbar, python, perl, php3, Apache, libssl, etc, etc, etc...I just wanted to listen to the files
Had a lot of features for "DJ:ing" etc that I really didnt need
Well....it was fun to write too :)
So whats good with AMPLE?
Small, standalone (written in C using no external libraries)
Portable (I think), I often try to compile it on the SourceForge compile farms
Allows you to listen to your own MP3s away from home, nothing more, nothing less
This is beginning to sound like marketing cr*p so Ill just stop right there, check out the links on the left for more info.
Enhancements:
- Make ID3v2 code understand versions 2.2.0 -> 2.4.0 (all currently existing versions)
- Reformat HTML output somewhat
- Fix search-and-replace error in libwrap code
- Made servername a config option
- Renamed -r to -n (NON-recursive)
- Changed the DEF_LOGFILE (it pointed to ample.conf instead of ample.log)
- Much work on autoconf stuff, should work much better now
- Some more testing on other architectures (Ive compiled it on everything from Tru64 to Linux to *BSD)

Arnos IPTABLES firewall script was initially written because I needed to protect my single-homed Linux machine at work. I wrote it at the time I couldnt find any script that really satisfied my needs except for one that was written by a guy called Seven.
I helped him for several months with the work on his script by suppling patches, reporting bugs etc. In this period I was fortunately also able to master scripting for iptables myself because soon Seven discontinued his work, I never got to even talk to the guy ever again. At that point I decided to continue his work, or actually I started my own branch based on his script.
In the summer of 2002 I finally got an ADSL connection at home. Initially I used the iptables firewall that came with the great ADSL4LINUX-package (http://www.adsl4linux.nl). But it didnt take me long to come to the conclusion that their iptables firewall lacked important features like port-forwarding and flexbility with "trusted hosts" etc.
I also didnt like the fact that I had to use a different firewall for my home machine and the machine at work. This made me decide to use some of the ADSL4LINUX knowledge to implement ADSL support.
By now (about 1 year later as of writing) there are only few remnants left of Sevens original script and many, many, many improvements were applied. One major improvement is the ADSL and NAT support (Check the features page with the specifiations of my firewall). For version 2 (alpha) I plan to completely rewrite to script to make it more flexible and to increase the usability for others.
Main features:
- Very secure stateful filtering firewall
- Both kernel 2.4 & 2.6 support
- It can be used for both single- and multi(eg. dual)-homed boxes
- Masquerading (NAT) and SNAT support
- Multiple external (internet) interfaces
- Support multiroute NAT & SNAT (load balancing over multiple (internet) interfaces)
- Port forwarding (NAT)
- Support MAC address filtering
- Support for DSL/ADSL modems
- Support for PPPoE, PPPoA and bridging modem setups
- Support for static and ISP assigned (DHCP) IPs
- Support for (transparent) proxies
- Full support for DMZs and DMZ-2-LAN forwarding. You can also use it to isolate your eg. wireless LAN.
- (Nmap)(stealth) portscan detection
- Protection against SYN-flooding (DoS attacks)
- Protection against ICMP-flooding (DoS attacks)
- Extensive user-definable logging with rate limiting to prevent log flooding
- Includes options to optimize your throughput
- User definable open ports, closed ports, trusted hosts, blocked hosts etc.
- Log & protection options are both highly customizable
- Support for custom iptables rules in a seperate file
- It can be used with chkconfig runlevel system (eg. RedHat/Fedora)
- Main focus on TCP/UDP/ICMP but additional support for *ALL* IP protocols
- It works with Freeswan IPSEC (VPN) & SSH Sentinel (http://www.freeswan.org) (+virtual IPs)
- It works with PoPTop PPTP (http://www.poptop.org)
- It works with UPnP
- DRDOS protection/detection (experimental)
- Its easy to configure
- And much more.
Enhancements:
- This release fixes a nasty bug in the NAT forwarding rules that caused using subnet-source-restrictions not to work.
- It adds an extra rule to the DHCP server section to allow packets from DHCP servers in the same segment.
- There are several plugin updates.
- A Racoon IPSEC VPN plugin and a transparent DNAT plugin have been added.