Ports Search

Scheme 48 is an implementation of the Scheme programming language as described in the Revised^5 Report on the Algorithmic Language Scheme. It is based on a compiler and interpreter for a virtual Scheme machine. The name derives from our desire to have an implementation that is simple and lucid enough that it looks as if it were written in just 48 hours. We don't claim to have reached that stage yet; much more simplification is necessary. Scheme 48 is an implementation of the Scheme programming language as described in the Revised5 Report on the Algorithmic Language Scheme [6]. It is based on a compiler and interpreter for a virtual Scheme machine. Scheme 48 tries to be faithful to the Revised5 Scheme Report, providing neither more nor less in the initial user environment. (This is not to say that more isn't available in other environments; see below.) Scheme 48 is under continual development. Please report bugs, especially in the VM, especially core dumps, to scheme-48-bugs@s48.org. Include the version number x.yy from the "Welcome to Scheme 48 x.yy" greeting message in your bug report. It is a goal of this project to produce a bullet-proof system; we want no bugs and, especially, no crashes.

The skem utility is a sendmail milter, that checks and maintains a list of whitelisted, temporary banned, and permanently blacklisted IP-addresses. How you obtain the entries is up to you, but the included logwatcher module provides one possibility. The list is stored in a directory, each entry being a file (usually -- zero sized) or a symlink (usually -- a "broken" one). Such entries are stored efficiently (within the directory itself) and the directories are searched using the hash tables on modern file systems. At the same time, they can be listed, added, and removed with the simple ls(1), touch(1), and rm(1). This milter does not itself filter spam, instead it memorizes the verdicts issued by your other anti-spam defenses to reduce the system load and resource consumption, by temporarily rejecting the relays suspected of spamming (banned) and, optionally, by permanently rejecting the relays "convicted" of spamming (blacklisted). The idea is to stem the spam from real spam sources, while reducing the ill effects of false-positives to merely delaying, rather than rejecting future messages.

Pandora FMS is a monitoring Open Source software. It watches your systems and applications, and allows you to know the status of any element of those systems. Pandora FMS could detect a network interface down, a defacement in your website, a memory leak in one of your server application, or the movement of any value of the NASDAQ new technology market. Pandora FMS could send out SMS message when your systems fails... or when Google's value drop below US348.60? Pandora FMS runs on any operating system, with specific agents for each platform, gathering data and sending it to a server, it has specific agents for GNU/Linux, AIX, Solaris, HP-UX, BSD/IPSO, and Windows 2000, XP and 2003. Pandora FMS can also monitor any kind of TCP/IP service, without the need to install agents, and monitor network systems such as load balancers, routers, switches, operating systems, applications, or simply printers if you need. Pandora FMS also supports SNMP for collecting data and for receiving traps. A few examples of common resources monitored by Pandora FMS could be processor load, disk and memory usage, running processes, log files, environmental factors such as temperature, or application values like strings contained in web pages or any possible way to collect data in an automatic way.

With the exponential growth of the Internet, a central Whois database that provides host and network information of systems connected to the Internet, and electronic mail (email) addresses of the users of those systems has proven to be very inefficient. The sheer size and effort needed to maintain a centralized database necessitates an alternate, decentralized approach to storing and retrieving this information. RWhois is a Directory Services protocol which extends and enhances the Whois concept in a hierarchical and scaleable fashion. It focuses on the distribution of "network objects"--the data representing Internet resources or people--and uses the inherently hierarchical nature of these network objects (domain names, Internet Protocol (IP) networks, email addresses) to more accurately discover the requested information. RWhois synthesizes concepts from other, established Internet protocols to create a more useful way to find resources across the Internet. The RWhois protocol and architecture derive a great deal of structure from the Domain Name System (DNS) [RFC 1034] and borrow directory service concepts from other directory service efforts, primarily [X.500]. The protocol is also influenced by earlier established Internet protocols, such as the Simple Mail Transport Protocol (SMTP) [RFC 821] for response codes.

Barnyard is a critical tool for the parsing of Snort's unified binary files, processing and on-forwarding to a variety of output plugins. Unfortunately it has not seen an updated in over 4 years and is not going to be maintained by the original developers. With the new version of the unified format (ie. unified2) arriving we need something to bridge this gap. The SXL team love barnyard. So much so that we want it to stay and have been tinkering around with the code to give it a breath of new life. Here is what we have achieved to far for this reinvigorated code base: * Parsing of the new unified2 log files. * Maintaining majority of the command syntax of barnyard. * Addressed all associated bug reports and feature requests arising since barnyard-0.2.0. * Completely rewritten code based on the GPLv2 Snort making it entirely GPLv2. This is an effort to fuse the awesome work of Snort and the original concept of barnyard giving it a fresh update along the way. We've come a long way so far and have a very stable build that we've integrated into our NSMnow framework. If you have any feature requests, bugs or gripes then send them our way.

AfterStep is a continuation of the BowMan window manager which was originally put together by Bo Yang. BowMan was based on the fvwm window manager, written by Robert Nation. Fvwm was based on code from twm. And so on... It is designed to emulate some of the look and feel of the NeXTstep user interface, while adding useful, requested, and neat features. The changes which comprise AfterStep's personality were originally part of BowMan development, but due to a desire to move past simple emulation and into a niche as its own valuable window manager, the current designers decided to change the project name and move on. BowMan development may continue, but we will no longer be a part of it. Major changes from fvwm are: - NeXTstep-like title bar, title buttons, borders and corners. BowMan's Wharf is a much worked-out version of GoodStuff. To avoid copyright complications it is not called a "dock." - NeXTstep style menu. However, the menus are not controlled by applications; they are more of pop-up service lists on the root window. - NeXTstep style icons. These styles are hard-coded in the program, which is good for the consistent look of the NeXTstep interface.

This module corrects the speed problem, at least with respect to scalar variables. When Readonly::XS is installed, Readonly uses it to access the internals of scalar variables. Instead of creating a scalar variable object and tying it, Readonly simply flips the SvREADONLY bit in the scalar's FLAGS structure. Readonly arrays and hashes are not sped up by this, since the SvREADONLY flag only works for scalars. Arrays and hashes always use the tie interface. Programs that you write do not need to know whether Readonly::XS is installed or not. They should just "use Readonly" and let Readonly worry about whether or not it can use XS. If the Readonly::XS is present, Readonly will be faster. If not, it won't. Either way, it will still work, and your code will not have to change. Your program can check whether Readonly.pm is using XS or not by examining the $Readonly::XSokay variable. It will be true if the XS module was found and is being used. Please do not change this variable.

This module implements ISO 8601 date, time and duration parsing. The implementation follows ISO8601:2004 standard, and implements only date/time representations mentioned in the standard. If something is not mentioned there, then it is treated as non existent, and not as an allowed option. For instance, ISO8601:2004 never mentions 2 digit years. So, it is not intended by this module to support 2 digit years. (while it may still be valid as ISO date, because it is not explicitly forbidden.) Another example is, when no time zone information is given for a time, then it should be interpreted as local time, and not UTC. As this module maps ISO 8601 dates/times to standard Python data types, like date, time, datetime and timedelta, it is not possible to convert all possible ISO 8601 dates/times. For instance, dates before 0001-01-01 are not allowed by the Python date and datetime classes. Additionally fractional seconds are limited to microseconds. That means if the parser finds for instance nanoseconds it will round it to microseconds.

Prom-Wl is a procmail reader for Wanderlust on GNU Emacs. If you want to install quickly, you shoud do following steps: (1) add dot.emacs to your ~/.emacs file and change it suitable for your site % cat /usr/local/share/examples/prom-wl/dot.emacs >> ~/.emacs % vi ~/.emacs (2) copy dot.procmailrc to ~/.procmailrc and change it suitable for your site % cp /usr/local/share/examples/prom-wl/dot.promailrc ~/.promailrc % vi ~/.promailrc (3) byte-compile with "byte-comile" script if you want with xemacs-mule code # cd /usr/local/share/emacs/site-lisp # /usr/local/share/doc/prom-wl/byte-compile -l wl xemacs-mule prom-wl Where detail specification for .emacs and .procmailrc may be shown in /usr/local/share/doc/prom-wl/prom-usage.jis or procmail(1). And for usage of byte_compile scripts, run byte-compile with -h option. Run with "M-x prom-wl" in your emacs editors, Wanderlust will be invoked and then search unread mails from procmail log to show unread message from top of entries that you specfied in ~/.pronmailrc. -KIRIYAMA Kazuhiko <kiri@pis.toba-cmt.ac.jp>

More and more people are posting binary files to usenet these days. Because of limitations in the type data that usenet can accommodate, binaries must be encoded into text, and because binary files are commonly very large relative to text files usenet was designed to handle, they frequently must be broken up into pieces. aub, which stands for "assemble usenet binaries", automates the reassembly process for you. aub determines whether or not any new binaries have appeared in selected newsgroups since the last time it was run, and if so, retrieves, organizes and decodes them, depositing them in a configurable location. This process requires no human intervention once aub has been configured. aub also keeps track of binaries which it has seen some, but not all, of the pieces of. It remembers how to find these old pieces, so that when new, previously missing pieces arrive at your site, it will build the entire binary the next time it is run. It also remembers which binaries it has already seen all of the pieces of already, so that it does not waste time rebuilding the same binaries over and over again. run: ``aub -M | more'' for the long form documentation, or ``aub -m | more'' for the short form.