Free idle hands software for linux

dlq lets modem/isdn users download files, without disrupting normal traffic, by using idle bandwidth.

Users enqueue files to grab, and a daemon retrieves file bits whenever the line is idle for a few moments (~30 seconds), pausing whenever other traffic resumes.

dlq project is written in perl ans supports triggers.

adesklets is an interactive Imlib2 console for the X Window system. adesklets project provides to scripted languages a clean and simple way to write great looking, mildly interactive desktop integrated graphic applets (aka "desklets").
Since this is adesklets, others still have plenty of space to start similar projets, from bdesklets to z, excluding g, which is already taken.
Seriously though, all those packages are nice. Nevertheless, the first two have very heavy requirements in terms of library dependencies; basically, gDesklets requires a complete GNOME desktop to be installed (plus specialized libraries such as gnome-python, while SuperKaramba needs almost all of the KDE libraries and base environment.
This reflects on performance for the task at hand1. On the other hand, while GKrellM is significantly lighter (it still depends on GTK+ though), it does not deliver the same experience in terms of ?eye-candiness? (to the authors taste, of course) or ?scriptability? than the other two.
Thus, adesklets was born. It provides:
- a minimal framework for X Window desklets seamlessly integrated into the desktop, with an easy to use central management for starting, positioning and stopping them.
- a generic, rich and easy to use drawing API similar to gDesklets and SuperKaramba regarding its high visual quality, thanks to the Imlib2 library.
- very limited library dependencies: uses the very good (and lightning fast) Imlib2 library for all graphic-related operations. No window toolkit used whatsoever; the program relies directly on xlib.
- a light, robust and small interpreter potentially usable with all sorts of scripting languages thanks to a clean, limited and homogenous syntax. As on version 0.4.2, support for Python is provided out of the box. Future support for Perl and Ruby is planned. Feel free to contribute support for your favorite language!
- Minimal disk space, memory footprint and CPU usage. Typically, on glibc 2.3.4 Linux 2.6 x86, a unique executable is less than 130 KB on disk, takes less than 3 MB of virtual memory per desklet right after initialization, and almost no processor cycles (including cycles from a Python interpreted script) when idle.
Enhancements:
- This is a bugfix release.
- It compiles without warnings on all gcc 4.x releases while retaining compatibility with all previous versions of the compiler.
- A new test/timing.py framework was added to help diagnose potential timing issues.

doinkd project is a "daemon" that runs on a machine to keep an eye on current users. If users have been idle for too long, or have been logged on for too long, it will warn them and log them out appropriately. The types of checks that doinkd performs are the following:

maxuser: *NEW* If a declared number of sessions, either by group or userid, are active, that user and subsequent users/sessions are warned and their sessions are terminated.

idle: If a user is idle more than their allotted time, as specified by the doinkd configuration file, he/she will be warned. If no action has taken place during the warn time, the user will then be logged out.

session: If a user is logged on for longer than the allotted time, he/she will be warned and logged out in warntime seconds if the user is still logged on then.

multiple: If too many user sessions are active (ie. many users logged on, or some users logged on many times), doinkd will choose X many sessions for each user to keep, waning the others, and logging those out in sleep seconds (such as 120) if there are still too many logged in then. X is either specified as a number of multiples per user, or is proportional to the threshold of sessions before multiple logouts are in effect.

refuse: If a user matches this setting, doinkd will terminate the users session after about a 5 second warning. The basically "refuse"s access for that user (or tty, or group) to the machine, though there may be some time allowed when doinkd is sleeping between checks.

doinkd is configurable without recompilation for its settings, such as the maximum allowed idle times, session limits, thresholds before session limits and multiple login checks begin, and also the important exemption lists. The configuration file is automatically re-read every sleep seconds (specified in the configuration file). If the
configuration file missing or contains errors when doinkd attempts to update its configuration, it will simply report the errors to its log file and continue normal operation, either with its previous settings (in the event of the file not being there or not being readable) or with all valid settings (in the event of errors in the conf file). doinkd must exit, however, if the configuration file is doesnt exist or is not readable when it first starts, and will also exit at the start if there are errors in the configuration file (since they should be fixed then).

Exemptions can be set for any user, group, host the user is logged in from, or tty for any of the checks that doinkd performs, such as allowing idle timeouts to default to 60 minutes for everyone, but exempting the staff group from these timeouts.

doinkd has the ability to handle the console as special, so that X-Windows environments can have appropriate settings. The special handling includes giving an idle time, session limit, and allowed multiple logins specifically for the user on console. All of these logout checks can also be disabled for the windows owned by the user on console. Idle activity is found by checking the keyboard and mouse if the user is in X-Windows. Special checking is also done to see if the person on console is running xlock (or some terminal locking program--the name is configurable at
compilation time) and logging the user off if the xlock program runs longer than the allowed console idle time. The special xlock check prevents users from running xlock and leaving the terminal for a long period of time, but not getting logged off, since other users may press a key or move the mouse to see if the machine is available, and in doing so makes the logged in user no longer idle. See TODO file for a comment on xlock. doinkd also has the ability to work with some implementations of XDM.

The configuration files path may be specified on the command line, so that one executable can be used on multiple machines with different path structures. Also, doinkd can read in separate files (specified in the config file) to get a list of users to apply a timeout/session/refuse/exempt command to.

lns.http is a simple framework for writing Common Lisp web applications. The project handles the incoming connections, parses HTTP headers and queries, and finally hands control over to your URL handler.

lns.http is a HTTP/1.1 compatible web server but tries to achieve compatibility with lesser (down to the informal HTTP/0.9) clients.

The lns.http web server uses lisp-network-server to take care of network handling.

This software is licensed unter the LGPL.

Growler is a C++-based distributed object and event architecture. It is written in C++, and supports serialization of C++ objects as part of its Remote Method Invocation, Event Channels, and in its Interface Definition Language.

Its primary application has been in support of interactive, distributed and collaborative visualization, computational steering, and concurrent visualization.

IDL example:

Growler has an Interface Definition Language (IDL) for generating stub/skeletion code for distributed communications. Growlers IDL is one of its most unique features. The interface definition language for Growler is called PIDL: The Parsifal Interface Definition Language.

Here are some example PIDL files:

This eventchannel definition is used for distributing field data from a live fvGCM run:

%cinclude < lib/buffer.h >
%cinclude < lib/vector.h >
%cinclude < lib/array.h >
%cinclude < lib/utility.h >

enum { DataVectorPort = 10100 };

typedef lib::Array< uint32_t,3 > dimarray;

struct MetaData {
int32_t lat, lon;
uint32_t nymd, nhms;
uint32_t pdt;
uint32_t nsteps;
uint32_t stride;
std::vector fields;
}

eventport DataVectorChannel
{
metadata(MetaData mdat) state;
datavec[16](lib::Vector< float > dv);
}

This is the cpumon.pidl specification used by NodeMon for distributing cpu statistics:
%import < nodemon/nodemon.pidl >
%cinclude < lib/vector.h >

/*
* About /proc/stat:
*

The very first "cpu" line aggregates the numbers in all of the other "cpuN"
lines. These numbers identify the amount of time the CPU has spent performing different kinds of work. Time units are in USER_HZ (typically hundredths of a second). The meanings of the columns are as follows, from left to right:

- user: normal processes executing in user mode
- nice: niced processes executing in user mode
- system: processes executing in kernel mode
- idle: twiddling thumbs
- iowait: waiting for I/O to complete
- irq: servicing interrupts
- softirq: servicing softirqs
*/

struct CPUData {
uint32_t v[7]; // the seven columns
}

// CPUDataVector: array of cpu data rows from /proc/stat
typedef std::vector< CPUData > CPUDataVector;

typedef std::vector< uint32_t > CPUSetVector;
typedef std::vector< std::string > CPUSetNameVector;

eventport CPUMonChannel
{
cpu_data(CPUDataVector) nonqueued;
cpuset_data(CPUSetVector) state;
cpuset_names(CPUSetNameVector) state;
}

port CPUMon : nodemon::NodeMonAgent
{
CPUMonChannel_ptr getMonChannel(out uint32_t cpucount);
}

xenConsole is a curses-based tty/console monitor for Xen 2.0, basically presenting the output from xm list in a full-screen interface with additional domain information from SNMP, colours and somewhat realtime updates.
Main features:
- Xen/domain/host information shown:
- Most output from xm list
- Load averages for individual domains, if available
- Uptime for individual domains, if available
- CPU & memory consumption shown as percentages for each domain
- Calculated total CPU busy/idle times/percentages
- Total Xen host CPU load is indicated in various ways
- Continously updates screen automatically
- Full screen application, colourized
- Easy to use, type q to quit

Bloboats project is a boat racing game in the spirit of Elasto Mania or X-Moto, introducing a handful of elements from Super Mario Bros-like games.

The objective of Bloboats is to reach MS Enterprise as fast as possible to save if from
the hands of the terrible Tentacle Monsters of an Unknown Master and the same time beat your friend and laugh at his or her puny time.

The journey starts from a place called Tutorial, somewhere in the United States, and somehow the player ends up in the famous HV-Arena of Helsinki. During the trip a number of MS Enterprises are saved, luckily, from the hands of the terrible Tentacle Monsters of an Unknown Master, who actually is your dad. Or then aint.