Softpanorama

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

SYN Flooding

News DoS Attacks Recommended Links Oracle kernel parameters tuning on Linux  SYN cookies 
Possible SYN flooding on port 25. Sending cookies TCP handshake Network Troubleshooting Tools Humor Etc

A SYN flood is a form of denial-of-service attack in which an attacker sends a succession of SYN requests to a target's system in an attempt to consume enough server resources to make the system unresponsive to legitimate traffic. Some versions of Linux kernel report fake attacks:

Feb 22 10:52:23 susehost kernel: [1874019.797638] possible SYN flooding on port 25. Sending cookies.

 See discussion of Fedora developers (Bug 734991 – Large numbers of TCP Possible SYN flooding on port X. Dropping request). One simple measure to protect against this error is to use settings recommended by Oracle (see Oracle kernel parameters tuning on Linux): 

kernel.sem = 250 256000 100 1024
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 262144
net.ipv4.tcp_wmem = 262144 262144 262144
net.ipv4.tcp_rmem = 4194304 4194304 4194304

It is based on the unique structure of TCP/IP handshake which requires response from the client in order to complete handshake.  See TCP handshake.

Normally when a client attempts to start a TCP connection to a server, the client and server exchange a series of messages which normally runs like this:

  1. The client requests a connection by sending a SYN (synchronize) message to the server.
  2. The server acknowledges this request by sending SYN-ACK back to the client. 
  3.  The client responds with an ACK, and the connection is established.

This is called the TCP three-way handshake, and is the foundation for every connection established using the TCP protocol.

A SYN flood attack works by not responding to the server with the expected ACK code. The malicious client can either simply not send the expected ACK, or by spoofing the source IP address in the SYN, causing the server to send the SYN-ACK to a falsified IP address - which will not send an ACK because it "knows" that it never sent a SYN.

The server will wait for the acknowledgement for some time, as simple network congestion could also be the cause of the missing ACK, but in an attack increasingly large numbers of half-open connections will bind resources on the server until no new connections can be made, resulting in a denial of service to legitimate traffic. Some systems may also malfunction badly or even crash if other operating system functions are starved of resources in this way.

This is the html version of the Power point presentation  http://www.thefengs.com/wuchang/work/courses/cs510_fall2005/summaries/09.ppt.  which unfortunately disappeared from the WEB.

TCP handshake

TCP SYN  flooding

TCP SYN  flooding

169.237.5.23

168.150.241.155

169.237.7.114

TCP Buffers

Half-open connection;  Waiting for ACK

Completed handshake;  connection open

empty

buffer

SYN-flood

128.120.254.1

128.120.254.2

128.120.254.3

128.120.254.4

128.120.254.5

128.120.254.6

128.120.254.7

128.120.254.8

128.120.254.9

128.120.254.10

128.120.254.11

128.120.254.12

128.120.254.13

128.120.254.14

169.237.7.114

128.120.254.15

TCP Buffers

Half-open connection;  Waiting for ACK

Completed handshake;  connection open

empty

buffer

TCP SYN  flooding counter-measures

TCP SYN  flooding counter-measures

TCP SYN  flooding counter-measures

TCP SYN  cookies

TCP SYN  cookie

SYN-Cookies

Spoofed  packets will not consume  TCP buffers

SYN

ack-number

SYN-ACK

seq-number as SYN-cookie,

ack-number

NO  BUFFER ALLOCATED

ACK

seq_number

ack-number+data

SYN-ACK

seq-number, ack-number

TCP  BUFFER ALLOCATED

Status?

Cookies  for the “bad guy”

Top Visited
 Switchboard
Latest
Past week
Past month
...

NEWS CONTENTS

Old News ;-)

Bug 734991 – Large numbers of TCP Possible SYN flooding on port X. Dropping request

2011-09-01

Naoki 

Description of problem:
High volume of "kernel: [6289924.871236] TCP: Possible SYN flooding on port 8080. Dropping request" messages being logged on a high traffic server however syn cookies is supposedly disabled:

# cat /proc/sys/net/ipv4/tcp_syncookies 
0
# cat /proc/sys/net/ipv4/tcp_max_syn_backlog
65536


As with this thread it's the same issue (different server software): http://squid-web-proxy-cache.1019090.n4.nabble.com/possible-SYN-flooding-on-port-3128-Sending-cookies-td2242687.html

Version-Release number of selected component (if applicable):
2.6.38.8-32.fc15.x86_64 & 2.6.40.3-0.fc15.x86_64 (probably others)

How reproducible:
Reliably when sessions exceed ~2000. This is _not_ deemed to be a DoS of any kind.

Steps to Reproduce:
1. Install apache,squid,tomcat,etc
2. Send a large amount of traffic.

  
Actual results:
Dopped connections due to SYN flood protection (incorrectly?) activating.

Expected results:
Connections handled as normal.
Comment 1 Dave Jones 2011-09-01 11:54:02 EDT 
If syncookies were enabled, you should also be seeing "sending cookies" messages.
Comment 2 Chuck Ebbert 2011-09-06 07:58:28 EDT 
Was the max syn backlog set before starting the network daemon, or afterward?
Comment 3 Naoki 2011-09-11 23:21:59 EDT 
With cookies enabled we see "Sending cookies", the proposed solution to this as read in various forums is to set cookies=0. After doing so the message simply changes to "dropping" which results in the same thing, namely failed network connections and an unreliable service. My traffic is valid and I'd really prefer to just turn off this protection as it does me more harm than good.

Here are the relevant sysctl sections:

net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_syn_retries = 5
net.ipv6.conf.all.max_desync_factor = 600
net.ipv6.conf.default.max_desync_factor = 600
net.ipv6.conf.dummy0.max_desync_factor = 600
net.ipv6.conf.em1/203.max_desync_factor = 600
net.ipv6.conf.em1.max_desync_factor = 600
net.ipv6.conf.em2.max_desync_factor = 600
net.ipv6.conf.lo.max_desync_factor = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120

net.netfilter.nf_conntrack_acct = 0
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_count = 10442
net.netfilter.nf_conntrack_events = 1
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_expect_max = 256
net.netfilter.nf_conntrack_frag6_high_thresh = 262144
net.netfilter.nf_conntrack_frag6_low_thresh = 196608
net.netfilter.nf_conntrack_frag6_timeout = 60
net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_icmpv6_timeout = 30
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_timestamp = 0
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.nf_conntrack_max = 262144

Dead end threads on the subject of TCP sessions being affected by this include;
- https://bbs.archlinux.org/viewtopic.php?id=123807
- http://www.spinics.net/lists/squid/msg54852.html
Comment 4 Naoki 2011-09-11 23:24:20 EDT 
Ah sorry Chuck I missed the comment - we've restarted the daemon but I think not the entire network service (assuming "service network restart"). We will try that and report back.
Comment 5 Naoki 2011-09-12 02:58:09 EDT 
I get the feeling this isn't a syn_cookie issue at all but rather a conntrack issue which would mean the kernel message is perhaps misleading. I cannot see a variable limit that we might be hitting that would result in "Dropping request" errors though so it's all a bit of a guess.
Comment 6 Chuck Ebbert 2011-09-12 10:35:43 EDT 
Before 2.6.40, connections would be silently dropped due to a bug in the code. That was fixed, so maybe the connections were always being dropped and you just weren't aware of it until now.
Comment 7 Naoki 2011-09-12 21:54:56 EDT 
That's possible but we did not previously have iptables (and therefore conntrack even loaded) so we wouldn't have run into any old bugs. We certainly are now though. 

The question is why am I (and seemingly others) overloading conntrack to the point of dropping connections due to a false positive SYN flood attack response with 300-400Mbps of legitimate traffic.

Load is nominal:
# uptime
 10:46:10 up 19:23,  2 users,  load average: 0.41, 0.46, 0.43

SYNs aren't even particularly high:
# netstat -tan | grep ':8080 ' | awk '{print $6}' | sort | uniq -c
      2 CLOSE_WAIT
   1175 ESTABLISHED
      2 FIN_WAIT1
     55 LAST_ACK
      1 LISTEN
     41 SYN_RECV
    125 TIME_WAIT

Yet we have an obvious degradation of service (resulting in monitoring checks timing out and fail-over responses) especially at higher traffic times of day:
# for i in `seq -w 0 23`; do echo -en "Hour $i:\t"; grep " $i:" /var/log/messages| grep -c "Possible SYN "; done
Hour 00:	7197
Hour 01:	242
Hour 02:	0
Hour 03:	0
Hour 04:	0
Hour 05:	0
Hour 06:	0
Hour 07:	0
Hour 08:	0
Hour 09:	0
Hour 10:	56
Hour 11:	19
Hour 12:	192
Hour 13:	10
Hour 14:	0
Hour 15:	100
Hour 16:	1281
Hour 17:	1390
Hour 18:	355
Hour 19:	151
Hour 20:	1375
Hour 21:	9108
Hour 22:	11933
Hour 23:	9306
(this matches like our normal traffic distribution).

Our next step is to test a system without iptables loaded - but I do not see that as a long term solution because a) it's poor security form for and b) doesn't help resolve the issue for anybody else seeing it.
Comment 8 Naoki 2011-09-12 22:33:53 EDT 
Oh dear. I see this is actually part of ipv{4,6}/tcp_ipv{4,6}.c and not conntrack which means we're stuck with it.
Comment 9 Naoki 2011-09-12 22:43:40 EDT 
So I think you are totally correct that we were hitting it before, however the layout of the older service was many servers on 100Mbit the new setup is fewer servers on 1Gbit and so these boxes are much more prone to hit it. Sadly of course they all hit this wall the same time.
Comment 10 Naoki 2011-09-13 00:35:38 EDT 
Some relevant code sections in tcp_ipv4.c: 

        /* TW buckets are converted to open requests without
         * limitations, they conserve resources and peer is
         * evidently real one.
         */
        if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
                if (net_ratelimit())
                        syn_flood_warning(skb);
#ifdef CONFIG_SYN_COOKIES
                if (sysctl_tcp_syncookies) {
                        want_cookie = 1;
                } else
#endif
                goto drop;
        }


Our TW buckets are set to = net.ipv4.tcp_max_tw_buckets = 262144 which I had assumed would be high enough. What other parameters come into play when deciding on dropping or not?
Comment 11 Chuck Ebbert 2011-09-14 07:07:30 EDT 
(In reply to comment #10)
> Our TW buckets are set to = net.ipv4.tcp_max_tw_buckets = 262144 which I had
> assumed would be high enough. What other parameters come into play when
> deciding on dropping or not?

/proc/sys/net/core/somaxconn ?

The application should also have settings for that, but it seems to be capped by the sysctl value.
Comment 12 Naoki 2011-09-14 21:15:53 EDT 
Hi Chuck, I'd not even come across somaxconn before, and it's at the default 128. Looking this up I see recommendations up to 3000 which makes 128 seem incredibly low. I've pushed it up to 1024 and will give it 24 hours for comparison and shall report back. 

I get the feeling from all of this that the tcp stack defaults in Fedora (RHEL6) are too low for even half gig speeds, unless it's just our particular brand of short-lived low-packet count traffic that's throwing it out of course.

You help is much appreciated by the way.
Comment 13 Naoki 2011-09-15 02:21:52 EDT 
Note I changed the bug subject to hopefully better reflect the issue. Also still had "Dropping" at somaxconn 1024 to pushed up to 3000. See how we go.
Comment 14 Naoki 2011-09-15 21:52:24 EDT 
Sadly no improvement. I have the same number of drops recorded in messages on a 'tuned' machine with somaxconn=3000 as an untuned one of the same spec set to default 128.

srv1
# cat /proc/sys/net/core/somaxconn
3000
# for i in `seq -w 10 23`; do echo -en "Hour $i:\t"; grep "Sep 15 $i:" /var/log/messages| grep -c "Possible SYN "; done
Hour 10:	10
Hour 11:	94
Hour 12:	0
Hour 13:	0
Hour 14:	0
Hour 15:	0
Hour 16:	0
Hour 17:	0
Hour 18:	20
Hour 19:	208
Hour 20:	3570
Hour 21:	6711
Hour 22:	7000
Hour 23:	6452


srv2
# cat /proc/sys/net/core/somaxconn
128
# for i in `seq -w 10 23`; do echo -en "Hour $i:\t"; grep "Sep 15 $i:" /var/log/messages| grep -c "Possible SYN "; done
Hour 10:	44
Hour 11:	80
Hour 12:	0
Hour 13:	0
Hour 14:	0
Hour 15:	0
Hour 16:	0
Hour 17:	0
Hour 18:	53
Hour 19:	188
Hour 20:	3708
Hour 21:	6940
Hour 22:	7027
Hour 23:	6778

(I am aware these aren't total numbers due to ratelimit consolidation but it's indicative of pattern)

A rundown of the parameters thus far;

net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_retrans_collapse = 1
net.ipv4.ip_default_ttl = 64
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.ip_nonlocal_bind = 0
net.ipv4.tcp_syn_retries = 5
net.ipv4.tcp_synack_retries = 5
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_intvl = 75
net.ipv4.tcp_retries1 = 3
net.ipv4.tcp_retries2 = 15
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_syncookies = 0
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.ip_local_port_range = 32768    61000
net.ipv4.tcp_mem = 144888       193186  289776
net.ipv4.tcp_wmem = 4096        16384   4194304
net.ipv4.tcp_rmem = 4096        87380   4194304
net.nf_conntrack_max = 262144


Additionally there are no errors on the Ethernet sides (peak 17MB/s) and packets  are around 6k/second at peak. 

The application server running is Tomcat with;
        connectionTimeout="60000" 
        maxThreads="1024" 
        socket.directBuffer="true"      
        socket.appReadBufSize="1024" 
        socket.appWriteBufSize="1024" 
And using APR. 

I wouldn't mind just disabling SYN flood protection entirely and comparing the results.
Comment 15 Naoki 2011-09-26 21:50:05 EDT 
After all the kernel tuning what we found that actually worked was altering "acceptCount" in Tomcat. Now obviously not a kernel bug so we can probably just close this bz. However I must note that a generic kernel warning about being unable to handle traffic volumes -which could be due to any number of things- probably should reflect this in the log message instead of "Possible SYN flood". Well yes, but if we listed all the things it "possibly" could be we'd quickly run out of log space.
Comment 16 Neil Horman 2011-09-27 06:41:07 EDT 
Thats exactly what you should do.  This isn't a problem at all, its a reflection of the backlog parameter passed to the listen call in an application, and the rate at which the application then accepts connections on that socket.  That backlog parameter defines how many outstanding requests can be queued on a listening socket before they start to get dropped.  All thats happening here is that the application, Tomcat in this case, is saying I want to have no more than X outstanding connection requests on my listening socket at any one time, but its calling accept on that socket at a sufficiently slow rate that the queue is overflowing and dropping subsequent requests.  The fix is to increase the queue length (as you've done with the acceptCount parameter), or to make tomcat accept requests more quickly.
Comment 17 Naoki 2011-09-28 00:53:26 EDT 
Hello Neil yes that's exactly right, we've come to the end

linux - A lot of TCP time wait bucket table overflow in CentOS 6 - Server Fault

we have the following output from dmesg:
__ratelimit: 33491 callbacks suppressed
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow
TCP: time wait bucket table overflow

Also we have the following setting:

cat /proc/sys/net/ipv4/tcp_max_tw_buckets
524288

We are under some kind of attack, but we could not detect what cause this problem?

asked Nov 17 '12 at 17:59

divaka
132 We increased /proc/sys/net/ipv4/tcp_max_tw_buckets to 720000 but with no luck – divaka Nov 17 '12 at 18:12

Is there any reasonable limit of the above setting? We increased it to 1000000 and now the things look very well by now? – divaka Nov 17 '12 at 19:13

If you increase it, the attack will do more harm since you are allowing it to consume more memory. Is there some good reason you are increasing it? (Do you have plenty of memory to spare?) – David Schwartz Nov 18 '12 at 1:05

Try the following commands to determine if you have a lot of connections coming from one address or if you are under a distributed attack. 

netstat -nt | cut -c 40- | cut -d: -f1 | sort | uniq -c | sort -n
netstat -nt | cut -d: -f2 | sort | uniq -c | sort -n

If you have high numbers from a few IP addresses it will be easier to limit the connections. You can then add deny rules or rate-limit rules to iptables to limit access from these addresses.

If you are under attack you may want to get your ISP involved as they can limit connections before they reach you.

Tricky net.ipv4 variables in sysctl.conf

Hello everybody,

This question is probably for tcp/linux kernel experts.

I am in process of installing mail server which potentially will serve for 10000 of users, so every aspect of kernel tuning is quite important for me, I have 2 cpu (Opteron) server running on CentOS 5.2 64bit with 16GB of RAM. I will have mysql database and spamassassin running on this server.

So I am trying to tune some net.ipv4 and kernel variables to handle a high load.

I must say that I familiarised myself with documentation about every variable which I am trying to tune and I know what it's trying to change:
I was reading this manual.
http://ipsysctl-tutorial.frozentux.n...-tutorial.html

I am interested only in this list of variables:

What do you think should you turn this on in my case?

net.ipv4.tcp_syncookies = 1
Are those numbers look right for my case?
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_keepalive_time = 3600

On some websites it's written that you shouldn't turn on those parameters when tcp_syncookies are on.
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_fack = 1

Should be this enabled in my case?
net.ipv4.tcp_timestamps = 1

Are those numbers right for my amount of ram?

net.ipv4.tcp_max_syn_backlog = 1024
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.ip_local_port_range = 32768 61000 - is it the right amount of local ports for 10000 clients?

Are there any formulas that are helping you to calculate those numbers.(I wasn't able to find this information).

net.ipv4.tcp_rmem = 4096 25165824 25165824
net.core.rmem_max = 25165824
net.core.rmem_default = 25165824
net.ipv4.tcp_wmem = 4096 65536 25165824
net.core.wmem_max = 25165824
net.core.wmem_default = 65536

Maybe you know any other variables which I should tune in my case?

For ex.
kernel.shmmax = 1073741824 - will it be enough for me?

Re SYN Flood

On Sun, Mar 07, 1999 at 11:16:04PM -0500, Russell D. Weiss wrote:
: Anyone know what this means?  I saw it in my messages log file.  I didn't
: know what it meant.
: 
: (IPs changed to protect the innocent or not-so-innocent)
: 
: Mar  7 17:01:31 MyMachineName Kernel: Warning: possible SYN flood from
: 128.97.XX.X on My.Ip.Address:111.  Sending cookies.

You were being RPC scanned.  You should talk with your site administrator
about some proper router filters.  Additionally, if you don't need any
RPC services (NFS, yp, etc), stop running the portmapper.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

CERT Advisory CA-1996-21 TCP SYN Flooding and IP Spoofing Attacks

SYN flood - Wikipedia, the free encyclopedia

SYN cookies by D. J. Bernstein

SYN cookies - Wikipedia, the free encyclopedia

Etc

Society

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

Quotes

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 quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

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

History:

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 DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting 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-Month :  How 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 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. www.softpanorama.org 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

Disclaimer:

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