Free can receive software for linux

gdvrecv is a set of tools for FreeBSD to receives audio and video data from a digital camcorder via an IEEE 1394 (widely known as FireWire) link and stores them into an DV file.
This software package is composed by :
- firewire, a Python module for the FreeBSD firewire sub system
- dvrecv, a command line tool to receive a DV stream
- gdvrecv, a Gtk tool to receive a DV stream
- Basicaly, gdvrecv does the same thing as the fwcontrol -R command, but is more user-friendly.
- You can use Kino (FreeBSD port: multimedia/kino) for editing the DV files recorded with gdvrecv.
- Note : gdvrecv is written for FreeBSD 5.3 or better. Other operating systems or FreeBSD versions are not supported (but youre welcome to send me patch for other operating systems).

Dnstracer determines where a given Domain Name Server (DNS) gets its information from, and follows the chain of DNS servers back to the servers which know the data.
Enhancements:
- Better handling of timeout (instead of a static value, start with five seconds and double it each retry)
- Warnings are printed if you receive a different RR type than the one you asked for (for example when you ask for an A record and receive a CNAME)
- Fixed problems when records received in the authority field are shorter than the domain the nameserver is authoritative for.
- When compiled without IPv6 support on an IPv6 capable machine the machine tried to query the IPv6 translated IPv5 address anyway.
- -C caches hosts which havent answered too.

archmage project is an extensible reader/decompiler of files in CHM f format(Microsoft HTML help, also known as Compiled HTML).
There is three ways to use arCHMage package now:
1) Extract .chm to directory(directory will be created):
archmage < chmfile > < directory >
2) Run as http-server, which will publish chm file contents on specified port.
archmage -p < port > < chmfile >
3) Tune your apache to publish chm file contents if there is trailing slash in request to that file(you will need working mod_python for that):
Add that lines to your httpd.conf:
AddHandler python-program .chm
PythonHandler mod_chm
Restart apache.
Lets suppose, you have file sample.chm in DocumentRoot of your apache. After that tuning you can receive raw chm file, if you point your browser to
http://yourserver/sample.chm
or you can view chm file on the fly if you point your browser to
http://yourserver/sample.chm/ (note trailing slash)
Enhancements:
- The "dump" option was added for dumping HTML data from a CHM file as plain text (using external tools such as lynx or elinks).

MMS Decoder provides a script for sending MMS messages to a Web page.
MMS Decoder can receive MMS messages, decode them, and display them on a Web page. This is done by acting as an MMSC, which is a server to which MMS messages are sent.
The only requirement to get this to work is an internet connected webserver, with PHP support and a phone which can send MMS (some operators may have blocked all MMS servers except their own, and the application will not work with these).
When an MMS is sent, its usually sent to the operators MMSC, which notifies the reciever (by a binary encoded SMS) that she or he has an MMS to retrieve, then his or her phone connects to the MMSC server and fetches the MMS which has been made available on the server via HTTP. What my web application actually do is to pretend to be an MMSC, recieves the MMS, decodes it (its encoded as specified in the WAP-209-MMSEncapsulation-20020105-a and wap-230-wsp-20010705-a specifications) and then stores it.
The only thing you need to do to make this work on your phone, is to set the phones MMSC (may also be labeled Service Center, MMS Center, or MMS Server) to http://domain.com/mms/get.php, or something like that, and then start sending MMS messages. And best of all, it will not cost you like 20 cents which the phone operators charge, the only cost is what your operator charge for WAP access (usually a lot less than the MMS cost), since the MMS is sent over WAP.
MMS Decoder was first written as a school project, and therefore Ive written a very detailed report of the decoding mechanism. This is, how ever, written in swedish so it would not be useful to anyone who doesnt know swedish. You can grab the report here.
Enhancements:
- An installation script, which creates the database or/and the tables, was added.
- A phpMyAdmin dump of the database structure was added.
- The directory structure of the package was changed.

trickle is a portable lightweight userspace bandwidth shaper. It can run in collaborative mode (together with trickled) or in stand alone mode.
trickle works by taking advantage of the unix loader preloading. Essentially it provides, to the application, a new version of the functionality that is required to send and receive data through sockets.
It then limits traffic based on delaying the sending and receiving of data over a socket. trickle runs entirely in userspace and does not require root privileges.
INSTALL
$ ./configure
$ make
$ su
# make install
Enhancements:
- The polling functionality (poll() and select()) was reworked.
- Protocol messages are encoded using XDR in order to allow for host to host communications and sharing of bandwidth management.
- A control protocol and utility, tricklectl, was added in order to control a running trickled.

FBUI is a small, in-kernel graphical user interface for Linux. It permits you to put windows in each framebuffer-based virtual console, to read keyboard input, track a mouse pointer, and respond to typical GUI events. Each process may have more than one window.
- FBUI exists to reduce the software bloat that plagues modern operating systems. It does this by virtue of its being a simple windowing system in the form of a small, 32 kilobyte driver which for some purposes may be quite sufficient. Liberation from bloat is desirable for a number of reasons that I explain in the Philosophy section.
- FBUI exists to assists people who are prohibited from using X Windows because they are using resource-limited platforms such as old computers and embedded devices. On these, X is an impossible burden. However a vanilla framebuffer is often too primitive. FBUI is "just right", and libfbui makes using FBUI even easier to use by providing abstractions and additional functions.
- FBUI exists to correct a flaw in the Linux operating system architecture. The traditional GUI -- X Windows -- is unlike any other subsystem of Linux in that the hardware-accelerated video drivers it uses are located within the X server, outside the kernel. Notice: normally Linux drivers and vital subsystems such as keyboard, USB, filesystem, serial I/O, et cetera are all located inside the kernel. FBUI simply puts the graphics UI driver where it belongs: inside the kernel with all the other drivers.
Main features:
- Unlike X Windows, FBUI supports windows on every virtual console.
- Each program may have more than one window.
- Overlapping windows are currently not supported, but I am adding support for them now.
- There is no concept of parent and child windows.
- Programs can receive raw keystrokes from FBUI which they can then translate to ASCII using a library routine. One process is permitted to have keyboard focus.
- Each process accesses its windows completely independently of all other processes.
- In X, the library has to send all drawing commands to the server process, which puts them in a queue and executes them whenever it has a chance. If the server is busy, or another X application is flooding the queue, then an X application must wait. Not so with FBUI, where the ioctl takes a list of drawing commands that go directly to be executed if the window is visible and irregardless of what any other window is doing. To further ensure the above concurrency is the norm, use of semaphores within FBUI to access common data is made as brief as possible.
- Each virtual console can have its own optional window manager process. But this is not necessary and for instance many programs that Ive written are also designed to run in standalone mode, examples being fbcalc, fbview, fbscribble, and the my FBUI variant of mpeg2decode.
- Im providing a fairly basic window manager fbwm, but current development is centered on fbpm, which is my panel-based window manager.
FBUI offers a sufficient set of drawing routines:
- draw point, line, horizontal line, vertical line, rectangle
- draw text (8-bit)
- window clear, fill rectangle, clear rectangle
- copy area
- put pixels (3-byte RGB, and 4-byte (unsigned long) RGB, and native)
- wait for event
- poll for event
- the window manager process can hide and unhide other processes windows, move, resize, re-expose, and delete windows.
- read point
- FBUI is currently written for 8,16,24, and 32-bit directcolor and truecolor. I am presently adding 4-bpp VGA. (Note : on VESA, Ive done testing for 24 bit only.)
Sample programs provided (I suppose Ive gotten carried away) :
- panel-based window manager (current focus of work)
- conventional window manager
- JPEG+TIFF image viewer
- very simple MPEG playback based on circa 1995 MPEG2 library
- terminal emulator (based on ggiterm)
- load monitor
- "scribbler" drawing program
- analog clock
- simple calculator
- "Start" button program, which invokes fblauncher menu program
- POP3 mail checker
- "to do list" displayer program