May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Solaris Snoop Packet Sniffer

Old News Sniffers Recommended Books Recommended Links Reference Options filter expressions Recommended Papers Troubleshooting Solaris Network Problems
Examples -V -v verbose mode -d -i -o -P -N Solaris IP configuration
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 extended 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 Visited
Past week
Past month


Old News ;-)

[Aug 30, 3009] Using snoop as a Troubleshooting Tool

The snoop utility can be particularly useful when troubleshooting virtually any networking problems. The traces that are produced by the snoop utility can be most helpful when attempting remote troubleshooting because an end-user (with access to the root password) can capture a snoop trace and email it or send it using ftp to a network troubleshooter for remote diagnosis.

You can use the snoop utility to display packets on the fly or to write to a file. Writing to a file using the -o switch is preferable because each packet can be interrogated later.

one# snoop -o tracefile
Using device /dev/le (promiscuous mode) 3^C

You can view the snoop file by using the -i switch and the filename in any of the standard modes, namely:

  • Terse mode - No option switch is required.
  • Summary verbose mode - Use the -V switch.
  • Verbose mode - Use the -v switch.

    Terse Mode

    one# snoop -i tracefile

    Summary Verbose Mode

    one# snoop -V -i tracefile

    Verbose is most useful when you are troubleshooting routing, network booting, Trivial File Transport Protocol (TFTP), and any network-related problems that require diagnosis at the packet level. Each layer of the packet is clearly defined by the specific headers.
    one# snoop -v -i tracefile

    Power user - View the snoop output file in terse mode and locate a packet or range of packets of interest. Use the -p switch to view these packets. For example, if packet two is of interest, type:

    one# snoop -p2,2 -v -i tracefile

    ETHER: Ether Header
    ETHER: Packet 2 arrived at 11:19:28.74
    ... ...
    TELNET: "/dev/le (promiscuous mode)\r\n\r\ 0000 "

  • [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: -----
    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 will cover 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 a layer 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 mailto:[email protected]?body=unsubscribe

    Sun Microsystems - BigAdmin Shell Commands

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

    Recommended Links

    Google matched content

    Softpanorama Recommended

    Top articles


    Network Sniffers

    SunService Tip Sheet for Miscellaneous Networking Programs

    Solaris Network Troubleshooting

    Tcpdump on Solaris

    Snort on Solaris

    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.



    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 Haters 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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

    Copyright 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. 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 to buy a cup of coffee for authors of this site


    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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. 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.

    Last modified: March 12, 2019