May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor


News Syntax Recommended Links Reference tail     Pipes
Perl re-implemenations uniq sort   AWK Tips Humor Etc

Unix tail tail command is a standard way of watching log files in Unix. There is also less well known, but more useful utility called logtail. This is a  Perl script which allows a system administrator to watch entries, as they are added, in any number of log files on one or more machines on a network. Logs which transfer to new files are automatically followed, and an option allows translation of numeric Internet addresses into the corresponding hostnames where possible. Log items can be relayed to one or more other hosts on the network, permitting a machine's local log files to be monitored there.

logtail [-t] -flogfile [-ooffsetfile]

logtail reads a specified file (usually a log file) and writes to the standard output that part of it which has not been read by previous runs of logtail. It prints the appropriate number of bytes from the end of logfile, assuming that all changes that are made to it are to add new characters to it.

logfile must be a plain file. A symlink is not allowed.

logtail stores the information about how much of it has already been read in a separate file called offsetfile. offsetfile can be omitted. If omitted, the file named logfile.offset in the same directory which contains logfile is used by default.

If offsetfile is not empty, the inode of logfile is checked. If the inode is changed, logtail simply prints the entire file. If the inode is not changed but logfile is shorter than it was at the last run of logtail, it writes a warning message to the standard output.


-f logfile to be read after offset

-o offsetfile stores offset of previous run

-t test mode - do not change offset in offsetfile


Old News ;-)

Top updates

Softpanorama Switchboard
Softpanorama Search


Old News ;-)

logtail - What is logtail

Definition: logtail: Returns parts of logfiles that have not already been returned This program will read in a standard text file and create an offset marker when it reads the end. The offset marker is read the next time logtail is run and the text file pointer is moved to the offset location. This allows logtail to read in the next lines of data following the marker. This is good for marking log files for automatic log file checkers to monitor system events. This program is mainly used by logcheck, because it returns only parts of the system logfiles that have not already been checked.

Source: Debian 3.0r0 APT / Linux Dictionary V 0.16
Author: Binh Nguyen linuxfilesystem(at)yahoo(dot)com(dot)au

logtail- watch multiple log files on multiple machines

Different logtail from

a Perl script. In order to use it, you must have Perl installed on your system. logtail was developed using Perl 4.0, patch level 36.

If you're running logtail on a non-System V Unix (for example, BSD-derived systems such as SunOS 4.x), you may have to change the definitions of $AF_INET and $SOCK_DGRAM to agree with those in your system's /usr/include/sys/socket.h file. Please refer to the comments at the beginning of which explain this in more detail and include a small C program you can run to determine the correct settings for your machine.

The host name lookup (-r option) and relaying between hosts (-e and -l options) make extensive use of Unix networking and process control facilities. They are unlikely in the extreme to work on non-Unix systems, at least not without a great deal of modification.

The -r option, which attempts to translate numeric Internet addresses into host names, can cripple a heavily loaded system by a flood of name server requests. Read the discussion of whether this option is appropriate to use on your system in the OPTIONS section above before enabling it.

When logtail begins monitoring a new cycle of a file, entries written between the time the file was cycled and the time logtail transferred to monitoring it are not printed; only subsequently added entries will be seen. This is deliberate: the HTTP log of a busy Web site, for example, can grow to a very substantial size in the interval between being cycled and logtail's discovering it. Processing all the backed up items may be very time-consuming, and relaying them to other hosts may run into maximum network packet size restrictions which would require substantial additional complexity to work around. Since logtail is intended to provide an overview of system activity, a few overlooked messages on those infrequent occasions when files are cycled doesn't seem unreasonable.


MultiTail lets you view one or multiple files like the original tail program. The difference is that it creates multiple windows on your console (with ncurses). It can also monitor wildcards: if another file matching the wildcard has a more recent modification date, it will automatically switch to that file. That way you can, for example, monitor a complete directory of files. Merging of 2 or even more logfiles is possible. It can also use colors while displaying the logfiles (through regular expressions), for faster recognition of what is important and what not. It can also filter lines (again with regular expressions). It has interactive menus for editing given regular expressions and deleting and adding windows. One can also have windows with the output of shell scripts and other software.

When viewing the output of external software, MultiTail can mimic the functionality of tools like 'watch' and such.
For a complete list of features, look here.


inotail is a replacement for the 'tail' program found in the base installation of every Linux/UNIX system. It makes use of the inotify infrastructure in recent versions of the Linux kernel to speed up tailing files in the follow mode (the '-f' option). Standard tail polls the file every second by default while inotail listens to special events sent by the kernel through the inotify API to determine whether a file needs to be reread.

Currently inotail is not fully compatible to neither POSIX or GNU tail but might be in the future. (Note: I'm currently working on correct tailing from pipes which would make inotail fully compatible to POSIX tail)

2007-09-07 - inotail 0.5 released

Released version 0.5 of inotail containing only small fixes. Please refer to the changelog for details.


Debian users can find the inotail package in the Debian package archive. inotail is also available in the Ubuntu Universe repository.

PPT tail

#!/usr/bin/perl -w

# A Perl implementation of tail for the Perl Power Tools project by
# Thierry Bézecourt <>. Includes an implementation
# of Chip Rosenthal's xtail.
# Please see the pod documentation at the end of this file.
# 99/12/24 : made tail -f work on VMS (thanks to Joe Kazimierczyk)
# fixed a bug when tailing small files
# 99/11/19 : important performance improvement for tail on big files
# (now usable for any file size)
# 99/03/07 : implemented xtail in the -f option
# 99/03/03 : fixed the -f option which was completely broken
# 99/03/02 : first version

PPT tail

This is the homepage for the Perl Power Tools implementation of the standard tail command.

Current Perl implementations are: Baseline documentation:

Perl Tail


use File::Tail;
$file=File::Tail->new( $file_to_tail );
while (defined($line=$file->read))
print $line;

The tail Command

The output from other commands can be piped (i.e., sent) to tail to use as its input. For example, the following sends the output from the ls command (which by default lists the names of the files and directories in the current directory) to tail, which, in turn, prints the final ten lines of the output that it receives from ls to the monitor screen:

ls | tail

This output could easily be redirected, for example to a file named last_filenames as follows:

ls | tail >> last_filenames

It could also be piped to one or more filters for additional processing. For example, the sort filter could be used with its -r option to sort the output in reverse alphabetic order prior to writing to a file:

ls | tail | sort -r >> last_filenames

The -q (i.e., quiet) option causes tail to not print the file name before each set of lines and to eliminate the vertical space between each set of lines when there are multiple input sources. The -v (i.e., verbose) option causes tail to print the file name even if there is just a single input file.

Tail could be viewed as a counterpart of the head command, which always starts reading from the beginning of files and which can continue until any specified distance from the beginning. However, there are a few differences. Perhaps the most useful of these is that tail is somewhat more flexible in that, in addition to being able to start reading any specified distance from the end of a file, it can also start at any specified distance from the beginning of a file.

Tail can be instructed to begin printing from some number of lines or bytes from the start of a file by preceding the number with a plus sign instead of a minus sign. For example, the following would print each of the designated files to the display monitor beginning with the seventh line and until the end:

tail +7 aardvark anteater armadillo

The c option could be used to tell tail to print each of the designated files beginning with the seventh byte instead of the seventh line:

tail +7c aardvark anteater armadillo Project details for inotail

inotail is a replacement for the 'tail' program found in the base installation of every Linux/Unix system. It makes use of the inotify infrastructure in recent versions of the Linux kernel to speed up tailing files in the follow mode (the '-f' option). Standard tail polls the file every second by default, while inotail listens to special events sent by the kernel through the inotify API to determine whether a file needs to be reread.

TTTT head and tail

Similarly, tail shows the last few lines (again, 10 by default) of a file or stream:
% ypcat passwd | tail
cal:*:1492:160:Calvin Hobbes:/home/cal:/bin/csh
adams:*:116:100:John Adams:/home/pkduck-b/adams:/bin/csh
gary:*:1177:20:Gary North:/home/pkduck-e/gary:/bin/csh
quincy:*:1092:20:Quincy Lizard:/home/triton-a/quincy:/bin/csh
talbot:*:1679:75:Bob Talbot:/home/enterprise-a/cadmec/talbot:/bin/csh
help:*:1034:31:Help Desk:/home/lewey-a/processor/help:/bin/csh
glen:*:1543:20:Glen Carpenter:/home/pkduck-e/glen:/bin/csh 
brent:*:1799:706:Brent Adams:/home/dogbert-a/brent:/bin/csh
lou:*:1701:30:Lou Grant:/home/pkduck-h/lou:/bin/csh 
adam:*:1124:317:Adam Baker:/home/lewey-d/adam:/bin/csh

As with head, you can specify the number of lines from the end of the file at which to start display by prefacing the number with a hyphen ("-"). You can also specify the location as a number of lines from the beginning by prefacing the number with a plus sign ("+"):
% wc -l /usr/man/man1/tail.1
     143 /usr/man/man1/tail.1
% tail +141 /usr/man/man1/tail.1
Various kinds of anomalous behavior may happen with character special
% tail -3 /usr/man/man1/tail.1
Various kinds of anomalous behavior may happen with character special

Since the tail man page has 143 lines, "tail +141" is equivalent to "tail -3" in this case.

Unlike with head, tail will operate on units other than lines. By adding the character "b" to the number, you can display the last blocks, and with "c" the last characters:

% tail -10c /usr/man/man1/tail.1

Don't forget about newlines.

tail also has the unexpected function that it allows you to reverse the lines spewed. By default, with just the "-r" flag, tail displays the whole file in reverse order by line:

% cat > foo << END
% tail -r foo

A number of lines to reverse can be included, but it cannot be relative to the beginning of the file, only the end. ("+" acts just like "-")

tail also has the wildly useful feature that it can be told to wait around for further input to a file rather than stopping when it gets to the end. This is especially useful to monitor the progress of a process whose output you have redirected to a file:

% clearmake >& Transcript &
[1] 12688
% tail -f Transcript
[the output from the clearmake will be displayed here as it arrives in "Transcript"]
When called in this manner, the tail will continue to read lines from the file and wait for more until you kill it ("^C" is handy here ;-) even after the clearmake has completed and there is no longer output being appended to the file.

One final difference between head and tail: while head will operate on multiple files, tail will not, so don't expect something like "tail foo bar biff" to show anything more than the last 10 lines of "foo".

logtail -- Monitor multiple log files on multiple machines

logtail [ -dnqu ] [ -ehostname ] [ -l[port] ] [ -pinterval ] [ -rtime ] [ -stime ] [ -tport ] [ -vlevel ] [ -wcols ] logfile...

Long-term survivors in the system administration game know that an excellent way to spot little emerging mouselike problems before they mature into moose-sized disasters is keeping an eye on the various system log files. In days of yore this was quite simple since almost everything of interest went into the master Unix logfile and, if a networked system supported the "loghost" facility, logs for a number of machines on a network could be consolidated onto a single server.

As more and more services have come into use, log files have proliferated. Today, an administrator might want to keep an eye on:

and various others. Many of the widely-used dæmons for these functions do not use the common Unix log mechanism, insisting instead on appending entries to their own private log files. In the case of commercial firewall, backup, and UPS dæmons, source code is not usually available, so modifying them to use the system log is not an option.

When there was a single log file, monitoring it couldn't be simpler--just use:

    tail -f /var/adm/messages

(or whatever the log file is called on your system). The -f option causes tail to start at the end of the file and periodically monitor it for growth, printing any additions to the file. Unfortunately, tail only monitors a single file, so the only way to watch multiple files is to launch separate jobs each running tail on an individual file--yuck. Worse, to prevent log files from growing without bound, consuming all available disc space, many programs that write logs provide a mechanism, automatic or semi-automatic, to periodically cycle the log to a new file, renaming the previous log file. Unfortunately, tail -f does not detect that this has happened, and just waits forever at the end of the old log, not knowing a new file is now being written. If servers are run on a number of different machines (or you simply want to watch Unix log files on all the hosts you're responsible for to keep an eye out for developing disc problems, etc.), you would then have to rsh copies of tail -f on every machine you wanted to monitor, and then make sure the process got restarted when a machine rebooted.

Enter logtail, which allows you to monitor any number of log files on any number of machines (assuming they support Perl with networking and use ASCII log files). Logs from any machine can be echoed to as many other machines as you like. Log files are closed and re-opened at a user-defined interval, so cycling of log files into new files is followed automatically.


Log messages received from other hosts are normally prefixed with the hostname followed by a colon, for example, ``wombat:''. Specifying the -d option causes the full domain name to be shown: ``''. If host name lookup on your machine does not return full domain names for local hosts, this option will have no effect.

Messages from logfiles on this host are relayed to a copy of logtail running on machine hostname. If you want to only relay messages, and not also print them locally, specify the -q (Quiet) option as well. Messages are sent to the named host on the port given by the -t option, defaulting to port 5741 if no -t option is present. If no copy of logtail is running on hostname and listening on the proper port, relayed messages will silently go to packet heaven with no indication they're being lost. You can relay to as many other machines as you wish by specifying multiple -e options; the same port is used for relays to all hosts.

Listen for messages relayed from other hosts on the specified port, or port 5741 if no port is given. Note that you must specify the -l option in order to receive messages relayed from other hosts; otherwise logtail only examines local log files.

When the -r option is specified, logtail normally uses fork to spawn a child process to perform each host name lookup. This blocks processing of other items until the possibly lengthy host name lookup is complete. The very act of creating a large number of child processes may itself, however, cause problems on certain implementations of Unix. In particular, some systems leak resources when processes are created and destroyed which, in time, may bring the system to its knees. The -n option, specified along with the -r option, causes logtail to perform host lookups in the main process instead of spawning a child process for each. While this may serve as a work-around on lightly loaded systems, the forced serialisation of lookups and log item processing will generally prove intolerable on servers with moderate to heavy load. Conversely, if your accesses are exclusively from local machines whose names can be looked up rapidly, the -n option may reduce overhead by avoiding the creation of processes for lookups which can be completed without significant delay.

To avoid filling up disc drives with huge, ever-growing log files, many dæmons periodically, either automatically or at the direction of a user, cycle their log files; the existing log file is closed and renamed, logging continues in a newly created file, and the oldest log file is deleted. When a log file is cycled, logtail has no way to directly discover this has occurred. If it continues to watch the old file, it will not find entries written into its replacement. To mitigate this situation, logtail periodically closes and re-opens the files it monitors. This allows logtail to begin monitoring the new file instead of the now-renamed older cycle. By default logtail performs this close and reopen operation every 15 minutes. To change the frequency, specify the -pinterval option with interval the desired time in minutes. Specifying an interval of 0 completely disables the close and reopen mechanism. If you know none of the files being monitored are ever cycled, this will eliminate the overhead of periodically closing and reopening them.

Quiet: don't print log items on the local machine. If you want to relay log items to another host or hosts with the -e option but not print them locally, specify the -q option. This makes sense for "headless servers" administered from other workstations. You can specify the -q option without the -e option, but doing so simply consumes system resources while producing no output whatsoever.

When the -r option is specified, logtail attempts to replace any sequences which resemble numeric Internet addresses (IP addresses) with the corresponding host name, looked up with gethostbyaddr. For example, an HTTP log item such as: - - [05/Nov/1997:17:05:12 +0100] "GET / HTTP/1.0" 200 2668

might be translated into: - - [05/Nov/1997:17:05:12 +0100] "GET / HTTP/1.0" 200 2668

If the host name lookup is unsuccessful, the original numeric address remains intact.

Host names corresponding to numeric IP addresses are saved by logtail in an internal cache so multiple accesses from a given host do not require repeatedly querying the system's host name lookup mechanism. Entries in the name cache are purged after time minutes of inactivity, with 10 minutes the default if no time is given.

At first glance, this host name lookup may appear to be the niftiest single feature of logtail, but before you turn it on, ponder carefully the consequences for the system running the program. If, for example, you're monitoring the HTTP access log of a heavily loaded Web site, the -r option may result in thousands, perhaps millions, of calls to gethostbyaddr every hour, most of which will require multiple Internet accesses to resolve the host name from the IP address. In order to make these requests without blocking the processing of other items, logtail performs each of these lookups in a separate Unix process, but if your system's resolver is single-threaded, everything may still grind to a halt due to the resolver bottleneck. Worse, your own resolver and those of upstream Internet sites may grow to enormous size due to all the requests cluttering up its own internal cache.

As long as the volume of log items is relatively small (say, a couple per minute), and/or the vast majority of references are to local hosts whose names can be looked up almost instantaneously, the -r option can substantially increase the comprehensibility of the log. But if you switch it on while monitoring a million-hit-per-day Web site, you're almost certain to end up regretting it.

logtail will sleep time seconds between checks for growth of the files it's monitoring. The default, one second, is the same used by the -f option of tail. If the files you're monitoring are only updated infrequently, a longer sleep time can reduce the overhead of running logtail. If you've specified the -l option to listen for messages from other hosts, choose a sleep time appropriate for the fastest-arriving stream of relayed messages. If the sleep time is too long, relayed messages may be lost if the network input queue overflows.

Transmit messages relayed to other hosts with the -e option on port. Note that the same port is used to relay to all hosts named in -e option specifications. If no -t option is given, the default port of 5741 is used.

Print how-to-call information and a summary of options.

Verbose: print internal debugging information. You probably won't find this interesting unless you're modifying the program. The greater the level, the more detailed (and voluminous) the debugging information will be.

Wrap output lines at column cols. By default, lines are wrapped at column 79. A cols specification of 0 disables line wrapping. logtail attempts to wrap lines so as to preserve their meaning. Lines are broken at white space whenever possible. If this cannot be done (frequently the case in HTTP logs which contain lengthy CGI GET requests), an attempt is then made to break the line at a comma or ampersand, major delimiters in such strings. Finally, if the line still cannot be broken, it is split at a slash or plus sign. If none of these delimiters succeeds in breaking the line, it is simply output unbroken. Continuation lines are indented to distinguish them from the first line of the next log item.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Debian -- Details of package logtail in sid

This program will read in a standard text file and create an offset marker when it reads the end. The offset marker is read the next time logtail is run and the text file pointer is moved to the offset location. This allows logtail to read in the next lines of data following the marker. This is good for marking log files for automatic log file checkers to monitor system events.

The package also provides logtail2, which better deals with rotated log files: If logtail2 finds that the inode of the file was changed, it assumes that the log has been rotated, and tries to find the file it was rotated to using heuristic plugins. If it finds the file, it will print the remainder of the file starting at the offset saved to the offset file. If a file with the correct inode was not found, logtail2 will only print the new file in its entirety before writing a new offset file.

Tags: System Administration: Logging, Implemented in: Perl, User Interface: Command Line, Role: Program, Scope: Utility, Purpose: Data Visualization, Works with: System Logs

SNMPServerLogtail - SNMP::Server::Logtail - Tails logfiles and presents counters via SNMP

since - What is since

PPT tail

tail (Unix) - Wikipedia, the free encyclopedia man pages section 1 User Commands

TTTT head and tail Project details for inotail

inotail is a replacement for the 'tail' program found in the base installation of every Linux/Unix system. It makes use of the inotify infrastructure in recent versions of the Linux kernel to speed up tailing files in the follow mode (the '-f' option). Standard tail polls the file every second by default, while inotail listens to special events sent by the kernel through the inotify API to determine whether a file needs to be reread.


FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  


Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy


War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes


Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law


Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least

Copyright © 1996-2016 by Dr. Nikolai Bezroukov. was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.

This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...

You can use PayPal to make a contribution, supporting development of this site and speed up access. In case is down you can use the at


The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: June 04, 2016