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

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Solaris Snoop Packet Sniffer

Old News See also Recommended Books Recommended Links Reference Options filter expressions Recommended Papers Sniffers
Examples -V -v verbose mode -d -i -o -P -N  
from to port and or not expr Humor Etc


Snoop is built-in Solaris sniffer and is located in the /usr/sbin directory. It is pretty cable sniffer equal or better then TCPdump.  Snoop file format was is different from PCAP and was defined in RFC 1761, Snoop Version 2 Packet Capture File Format, B. Callaghan, R. Gilligan, February 1995. Conversion is possible with Ethereal tool editcap

You can display packets as soon as they are received or saved to a file. When snoop writes to an intermediate file, packet loss under busy trace conditions is unlikely. Snoop itself can be use read and interpret the file (print summary expended summary and full packets dumps).  It has pretty powerful packet filtering engine (see especially expr capability)

The snoop command can capture both IPv4 and IPv6 packets. It can display IPv6 headers, IPv6 extension headers, ICMPv6 headers, and neighbor discovery protocol data. By default, the snoop command displays both IPv4 and IPv6 packets. By specifying the ip or ip6 protocol keywords, the snoop command displays only IPv4 or IPv6 packets. The IPv6 filter option enables you to filter through all packets, both IPv4 and IPv6, displaying only the IPv6 packets. See the snoop man page for details. See How to Monitor Only IPv6 Network Traffic for a description of procedures that use this command.

Other then IPv6 traffic snoop capabilities are very similar to tcpdump and output formats are almost identical. The snoop capture file format is described in RFC 1761. Still there are some differences and for example snort can read tcpdump binary files,  but not snoop binary files. Ethereal's editcap program can be used to convert the snoop file to a tcpdump file.

Snoop has more than a dozen options:

        [ -a ]                  # Listen to packets on audio
        [ -d device ]           # Network interface to snoop (le?, ie?, bf?, tr?)
        [ -s snaplen ]          # Truncate packets
        [ -c count ]            # Quit after count packets
        [ -P ]                  # Turn OFF promiscuous mode
        [ -D ]                  # Report dropped packets
        [ -S ]                  # Report packet size
        [ -i file ]             # Read previously captured packets
        [ -o file ]             # Capture packets in file
        [ -n file ]             # Load addr-to-name table from file
        [ -N ]                  # Create addr-to-name table
        [ -t  r|a|d ]           # Time: Relative, Absolute or Delta
        [ -v ]                  # Verbose packet display
        [ -V ]                  # Show all summary lines
        [ -p first[,last] ]     # Select packet(s) to display
        [ -x offset[,length] ]  # Hex dump from offset for length
        [ -C ]                  # Print packet filter code
        [ -q ]                  # Suppress printing packet count
        [ -r ]                  # Do not resolve address to name

        [ filter expression ]

The most typical use the snoop is to observer communication between two systems. For example, if we want to observe traffic between systems alpha and beta  we can use the following command:

# snoop alpha,beta

Typical examples of snoop usage include:

Note  1: You need to press Control-C to stop the snoop utility.

Note 2:  Use the -a option to enable audible clicks, which notify you of any network traffic. Although noisy, the clicks are useful when troubleshooting, for example: snoop -a dhcp

The snoop command can only be run by superuser. In summary form, snoop only displays data pertaining to the highest-level protocol. For example, an NFS packet will only display NFS information. The underlying RPC, UDP, IP, and Ethernet frame information is suppressed but can be displayed if one of the verbose options (-v or -V) is chosen.

The snoop command has many options described in the snoop man page.

Some examples of using snoop are:


Filter expressions

Select packets either from the network or from a capture file. Only packets for which the expression is true will be selected. If no expression is provided it is assumed to be true.

Given a filter expression, snoop generates code for either the kernel packet filter or for its own internal filter. If capturing packets with the network interface, code for the kernel packet filter is generated. This filter is implemented as a streams module, upstream of the buffer module. The buffer module accumulates packets until it becomes full and passes the packets on to snoop. The kernel packet filter is very efficient, since it rejects unwanted packets in the kernel before they reach the packet buffer or snoop. The kernel packet filter has some limitations in its implementation; it is possible to construct filter expressions that it cannot handle. In this event, snoop tries to split the filter and do as much filtering in the kernel as possible. The remaining filtering is done by the packet filter for snoop. The -C flag can be used to view generated code for either the packet filter for the kernel or the packet filter for snoop. If packets are read from a capture file using the -i option, only the packet filter for snoop is used.

A filter expression consists of a series of one or more boolean primitives that may be combined with boolean operators (AND, OR, and NOT). Normal precedence rules for boolean operators apply. Order of evaluation of these operators may be controlled with parentheses. Since parentheses and other filter expression characters are known to the shell, it is often necessary to enclose the filter expression in quotes. Refer to Example 2 for information about setting up more efficient filters.

The primitives are:



Top updates

Softpanorama Switchboard
Softpanorama Search


Old News ;-)

[Aug 10, 2006] rdr rule interaction found on v4.1.13

James Huang
Tue, 01 Aug 2006 10:34:05 -0700

Recently test ipfilter v4.1.13 on Sun Solaris 8 (v240), found
interactions between rdr rules.

1. correct scenario, perfect results.
# ipnat -l
List of active MAP/Redirect filters:
rdr bge0 from any to port = 30000 ->
port = 4080 udp
rdr bge0 from any to port = 30002 ->
port = 4130 udp

# snoop udp -> UDP D=30000 S=4130 LEN=24 -> UDP D=4080 S=4130 LEN=24 -> UDP D=30002 S=4080 LEN=24 -> UDP D=4130 S=4080 LEN=24

2. interaction scenario
# ipnat -l
List of active MAP/Redirect filters:
rdr bge0 from any to port = 30002 ->
port = 4130 udp
rdr bge0 from any to port = 30000 ->
port = 4080 udp

NOTE: The rules redirect to same dest ip compare to scenario 1 that
redirects to different ip.

# snoop udp -> UDP D=30002 S=4080 LEN=24 -> UDP D=4130 S=30000 LEN=24 -> UDP D=30000 S=4130 LEN=24 -> UDP D=4080 S=30002 LEN=24

&%$@: The source ip and port of outgoing packets are accidentally changed.

Need you help to fix it, Thanks a lot.

Arguments for snoop command...

Usage: snoop
[ -a ] # Listen to packets on audio
[ -d device ] # settable to le?, ie?, bf?, tr?
[ -s snaplen ] # Truncate packets
[ -c count ] # Quit after count packets
[ -P ] # Turn OFF promiscuous mode
[ -D ] # Report dropped packets
[ -S ] # Report packet size
[ -i file ] # Read previously captured packets
[ -o file ] # Capture packets in file
[ -n file ] # Load addr-to-name table from file
[ -N ] # Create addr-to-name table
[ -t r|a|d ] # Time: Relative, Absolute or Delta
[ -v ] # Verbose packet display
[ -V ] # Show all summary lines
[ -p first[,last] ] # Select packet(s) to display
[ -x offset[,length] ] # Hex dump from offset for length
[ -C ] # Print packet filter code
[ -q ] # Suppress printing packet count
[ -r ] # Do not resolve address to name

[ filter expression ]

snoop -o saved host fred

snoop -i saved -tr -v -p1

snoop captures packets from the network and displays their
contents. snoop uses both the network packet filter and
streams buffer modules to provide efficient capture of pack-
ets from the network. Captured packets can be displayed as
they are received, or saved to a file for later inspection.

snoop can display packets in a single-line summary form or
in verbose multi-line forms. In summary form, only the data
pertaining to the highest level protocol is displayed. For
example, an NFS packet will have only NFS information
displayed. The underlying RPC, UDP, IP, and ethernet frame
information is suppressed but can be displayed if either of
the verbose options are chosen.

snoop requires an interactive interface.

The Secrets of Snoop

To capture data to a file, the command is
#snoop –o filename

This saves all the data in binary format to filename. To see data real-time, exclude the command "-o filename". Otherwise, all command syntax is the same for snoop.

The first thing we need to do is determine how many packets to capture. If no number is determined, snoop will continue to gather packets until you CRTL-C or run out of resources. To set the number, use the command.

#snoop –o filename –c 1000 .

Snoop will capture 1000 packets in about 60 seconds on a standard 10Mbps network.

Next, we want to determine what level of detail we need. Snoop comes in three flavors, summary (default), verbose summary (-V), and verbose mode (-v).

Summary gives us the least information, only the highest protocol level, layer 5,6 or 7 , and packet source/destination. Below is a single packet in summary mode. This is the 27th packet captured, it shows a Telnet connection between squirrel and my school account. 0.01743 is the time between packet 26 and 27.

27 0.01743 squirrel -> ICARUS.CC.UIC.EDU TELNET C port=45330

Verbose summary (-V) gives us all the layers of the OSI model, (layers 2,3,4, and 5, 6 or 7) but in summarized fashion, one line for each layer. Below we see an example, packet 27 again. Notice it gives us layer 2 (ETHER), layer 3 (IP), layer 4 (TCP), and layer 7 (Telnet). Note how it also gives Syn and Seq (sequence number). There is no Ack (Acknowledge number) so this is the first packet for this Telnet session.

27 0.01743 squirrel -> ICARUS.CC.UIC.EDU ETHER Type=0800 (IP), size = 58 bytes
27 0.01743 squirrel -> ICARUS.CC.UIC.EDU IP D= S= LEN=44, ID=6082
27 0.01743 squirrel -> ICARUS.CC.UIC.EDU TCP D=23 S=45330 Syn Seq=678057692 Len=0 Win=8760
27 0.01743 squirrel -> ICARUS.CC.UIC.EDU TELNET C port=45330

Verbose gives us all the gory details of each packet, all the way to the bit level on the OSI model. Below is a packet 27 in verbose mode. Here we see detailed information of each layer, layer 2 (Ethernet), layer 3 (IP), and layer 4 (TCP) header. See RFC 894 (Ether), 791 (IP), and 793 (TCP) for specific header information.

ETHER: ----- Ether Header -----
ETHER: Packet 27 arrived at 10:40:36.07
ETHER: Packet size = 58 bytes
ETHER: Destination = 8:0:20:8d:fc:d2, Sun
ETHER: Source = 8:0:20:c:df:aa, Sun
ETHER: Ethertype = 0800 (IP)
IP: ----- IP Header -----
IP: Version = 4
IP: Header length = 20 bytes
IP: Type of service = 0x00
IP: xxx. .... = 0 (precedence)
IP: ...0 .... = normal delay
IP: .... 0... = normal throughput
IP: .... .0.. = normal reliability
IP: Total length = 44 bytes
IP: Identification = 6082
IP: Flags = 0x4
IP: .1.. .... = do not fragment
IP: ..0. .... = last fragment
IP: Fragment offset = 0 bytes
IP: Time to live = 255 seconds/hops
IP: Protocol = 6 (TCP)
IP: Header checksum = 7005
IP: Source address =, squirrel
IP: Destination address =, ICARUS.CC.UIC.EDU
IP: No options
TCP: ----- TCP Header -----
TCP: Source port = 45330
TCP: Destination port = 23 (TELNET)
TCP: Sequence number = 678057692
TCP: Acknowledgement number = 0
TCP: Data offset = 24 bytes
TCP: Flags = 0x02
TCP: ..0. .... = No urgent pointer
TCP: ...0 .... = No acknowledgement
TCP: .... 0... = No push
TCP: .... .0.. = No reset
TCP: .... ..1. = Syn
TCP: .... ...0 = No Fin
TCP: Window = 8760
TCP: Checksum = 0x517a
TCP: Urgent pointer = 0
TCP: Options: (4 bytes)
TCP: - Maximum segment size = 1460 bytes
TELNET: ----- TELNET: -----

No one level of detail is "better" then the other. It depends on what type of information you are looking for. Keep in mind however that snoop can be resource intensive. In verbose mode, snoop may overwhelm the system, forcing it to drop packets depending on your network traffic. In some cases, you may have to use a dedicated server for snoop, depending on your verbose level and number of packets gathered. To capture 1000 packets in verbose summary mode:

#snoop –V –o filename –c 1000

To read a capture file, use –i filename. If you captured packets in verbose mode, you can read a capture file in summary, verbose summary, or verbose mode. I recommend you scan through the capture file in summary mode, identify what packets are interesting, then view specific packets in verbose mode. To look at a specific packet, use –ppacket#. Below is an example of looking at packets 10-32 and packet 56 in verbose mode.

snoop –i filename –v –p10-32,56

Now lets leverage the true power of snoop. Snoop has a variety of filtering tools, allowing us to focus on the type of packets we capture, be it source, destination, protocol layer, etc. Here we wi er some of the most commonly used options. However, for complete information, be sure to do a man on snoop(1).

First, we can select what systems, by either MAC (layer 2) or IP or host name, (layer 3) will be snooped. This limits what packets are captured at the interface. If you have just one node you want to snoop, include its IP address. If there are several, use the expression "and" or "or" between the nodes. You can focus the expression even more with the qualifier "from" or "to" which match the source or destination address. The "!" or "not" performs a logical NOT operation. Last, the expression "net" captures all packets that belong to a specific network. The command below captures all packets coming from zeus, going to 8:0:20:f1:b3:51, or packets belonging to the network, except Note, the host name zeus must be resolvable, be it /etc/hosts or DNS.

snoop –o filename from zeus or to 8:0:20:f1:b3:51or net not

Just as we can qualify specific hosts or networks at layer 2 or 3, we can limit packets captured at layers 4, 5, 6, and 7. At layer 4, we can qualify "tcp", "udp", or "icmp" (actually RFC 792 states icmp is 3 protocol, but I have placed it here to reflect snoop’s man page). For layers 5,6 and 7 use the qualifiers "port" and "rpc" (based on the /etc/services and /etc/rpc files). The command below captures all DNS or NFS packets

snoop –o filename –V port domain or rpc nfs

Snoop and Security

Now that we have covered the flexibility of snoop, lets apply it to your network security. With snoop, you silently sit on the network and capture data. Unlike active measures, such as network discovery using ICMP, snoop does not alert anyone to its presence. This allows you to analyze the security of your network, without notifying anyone. Also, snoop can run over a long period of time, compared to active measures that run in a single point of time. If a server is down for several minutes while you are pinging the network, you will miss it. Snoop will pick up these servers, as long as they eventually send or receive traffic.

Snoop does two critical things for security, it tells you who is on your network, and what they are doing. You need to first identify what your security concern is, then configure snoop to find that information.

Often, a security concern is having a node or gateway on your network that you do not know about. This node could be an innocent dial-up server, or a gateway a hacker set-up. I know of a company where an unknown Internet connection was recently identified with a sniffer. Active measures will tell you who is on the network, only if the machine is on. But what if a node is on only at night, or has been configured not to ICMP_REPLY, then what? Using the qualifiers we covered above, snoop could capture information on your network. With a perl or shell script, you could parse this information, identifying unknown nodes on your network.

Another security issue is what is going on your network. You may be concerned about specific websites or downloads. Perhaps you are concerned that users are downloading the latest hacker attacks. You can snoop your network, looking for FTP downloads from known websites. I know of a recent incident where an employee was identified of this during a routine network analysis.

Perhaps you have several critical servers that have been hit with denial of service attacks, such as land.c or ping of death. You can qualify snoop to look for land.c by capturing packets with source and destination the same. For ping of death, look for icmp packets with extremely large lengths.

So far we have discussed what snoop can do, now we will cover what snoop cannot do. Unlike active measures, snoop, like most sniffers, cannot operate in a switched environment. Snoop only records packets that cross the designated interface. Switches block and forward IP packets based on their MAC , layer 2, address. If you have a switch, snoop will capture only the packets in its collision domain.

Where you snoop is just as important as what you snoop. If you want to monitor all the traffic on your network, place your sniffer on the Internet router segment. This way your are capturing all Internet traffic, you are no limited to specific collision domains.

[tcpdump-workers] Linux tcpdump and Sun Solaris Snoop

Dear Tcpdump Expert,

I discovered your email in the manual page for tcpdump. Linux tcpdump and Sun Solaris snoop seem to have a common ancestor. I have been unable to discover any way to read a dump captured with Sun Solaris snoop (snoop -r -o file) using tcpdump -n -v -r file
Is there a way to accomplish this?
My goal is to assist my Linux based ISP with a trace I captured on a Sun.
I have both available.

Thank you for your time.

Bob Styma

On Thu, Nov 21, 2002 at 06:32:30PM -0700, Robert Styma wrote:
>    I discovered your email in the manual page for tcpdump.  Linux 
> tcpdump and Sun Solaris snoop seem to have a common ancestor.

It may seem that way, but if there is such an ancestor, it's Sun's
etherfind, and neither tcpdump nor snoop much resemble that - I don't
think it even *had* a save file format, as it had no option to save
captured packets in raw binary form (raw hex, yes; raw binary, no):

> I have been unable to discover any way to read a dump captured with
> Sun Solaris snoop (snoop -r -o file) using tcpdump -n -v -r file
> Is there a way to accomplish this?

1) get Ethereal, and use its editcap program to convert the snoop file
   to a tcpdump file.

2) modify libpcap to read snoop files as well as tcpdump files (which
   can't be done the same way it's done with Ethereal - Ethereal, when
   checking for types of capture files seeks backwards to the beginning
   of the file and starts re-reading it for each new file type, but
   libpcap has to be able to read from a pipe and can't seek backward).

I think I still have some code to do 2), but I don't seem to have it
here at home, so I can't supply it now (and probably won't be able to do
so until Monday at the earliest).  If people think it's a reasonable
thing to add to libpcap, I could check it in once the CVS server is
available again.

I'd suggest looking into 1) - Ethereal should run on any modern Linux
distribution, and also runs on Solaris (just as tcpdump does - tcpdump
isn't a Linux-specific program; it was originally developed for, I
think, BSD and SunOS).  See

or check whether it's installed on your ISP's Linux boxes already or
came with their Linux distribution - if not, you could download and
build it for on your Solaris boxes, although you'd have to download and
install GLib as well (and GTK+, if you want Ethereal itself).
This is the TCPDUMP workers list. It is archived at
To unsubscribe use

Sun Microsystems - BigAdmin Shell Commands

snoop -S -ta [machine]
/* Snoop for network packets and get size and time stamp entries. */

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Recommended Papers

SunService Tip Sheet for Miscellaneous Networking Programs Revision: 1.0Date: October 30, 1995

... ... ...

To see all the packets involving a certain machine:

# snoop machine-name

To see all the packets between two machines:

# snoop machine1 and machine2

To see all the packets on a network:

# snoop

Here's what a standard snoop output looks like:

Using device /dev/le (promiscuous mode)
jfn35 -> smiley-116 NFS C CREATE FH=5882 .cshrc
marlowe -> jfn35 TCP D=33237 S=48864 Ack=3354199170 Seq=2006870529 Len=0 Win=8632
smiley-116 -> jfn35 NFS R CREATE OK FH=6AD4
jfn35 -> smiley-116 NFS C WRITE FH=6AD4 at 0 for 10
smiley-116 -> jfn35 NFS R WRITE OK
sun-soft -> psi RLOGIN C port=1017
psi -> sun-soft RLOGIN R port=1017 /dev/le (promiscuous

You'll note that each line tells us the sending and the receiving machine, some information about what program is running, and some of the arguments that are being passed. For example, on the uot;.cshrc" and on the last line, we see the output being passed on by rlogin "/dev/le (promiscuous". For most packets, you'll see a message sent out (marked with a "C"), and then a reply to that message (marked with an "R").

A few things can be done to extract more information out of snoop.

To produce slightly verbose output:

# snoop -V

To produce very verbose output:

# snoop -v

The verbose output on snoop is very much so, and it's not very easy to look at in real time. For that reason, you can save snoop output to a file:

# snoop -o filename

You will just see an incrementing number as packets are saved. Hit ^C when you are down collecting information. You can then read the information back in:

# snoop -i filename

You can look at the entire snoop output in verbose mode:

# snoop -i filename -v

Alternatively, you can view individual packets in verbose mode:

# snoop -i filename -p12 -v

If you run 'snoop -i filename' and realize that packet 12 is the interesting one, you would then run the above command to see exactly what was in the twelfth packet.

snoop can give you extremely good information on exactly what each packet on the network contains. The snoop man page gives additional information on other snoop options.

snoop is only available under Solaris.

The Secrets of Snoop by Lance Spitzner 

Pretty weak and superficial paper

Sniffers have exploded in popularity over the past several years, from Network General’s Netxray and Microsoft’s Network Monitor, to public domain tools such as Etherman and Curry Sniffer. These tools are used for various reasons, including network troubleshooting, traffic analysis, node discovery, etc. We will be covering one of the most common, yet effective sniffers, snoop. Of all the sniffers, this is one standby you always have access to with Solaris. The purpose of this article is to demonstrate how to leverage snoop, with examples focusing on network security.



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: October 20, 2015