Using deny directive in apache .htaccess

You can also allow or deny by domain name rather than IP address. For example

deny from .poneytelecom.eu

works for 62-210-83-26.rev.poneytelecom.eu, 62-210-142-7.rev.poneytelecom.eu and 15 62.210.91.168 62-210-91-168.rev.poneytelecom.eu

The directives provided by mod_access are used in <Directory>, <Files>, and <Location> sections as well as .htaccess files to control access to particular parts of the server. Access can be controlled based on the client hostname, IP address, or other characteristics of the client request, as captured in environment variables. The Allow and Deny directives are used to specify which clients are or are not allowed access to the server, while the Order directive sets the default access state, and configures how the Allow and Deny directives interact with each other.

Both host-based access restrictions and password-based authentication may be implemented simultaneously. In that case, the Satisfy directive is used to determine how the two sets of restrictions interact.

In general, access restriction directives apply to all access methods (GET, PUT, POST, etc). This is the desired behavior in most cases. However, it is possible to restrict some methods, while leaving other methods unrestricted, by enclosing the directives in a <Limit> section.

Allow Directive

The Allow directive affects which hosts can access an area of the server. Access can be controlled by hostname, IP address, IP address range, or by other characteristics of the client request captured in environment variables.

The first argument to this directive is always from. The subsequent arguments can take three different forms. If Allow from all is specified, then all hosts are allowed access, subject to the configuration of the Deny and Order directives as discussed below. To allow only particular hosts or groups of hosts to access the server, the host can be specified in any of the following formats:

A (partial) domain-name

Example:

Allow from apache.org
Allow from .net example.edu

Hosts whose names match, or end in, this string are allowed access. Only complete components are matched, so the above example will match foo.apache.org but it will not match fooapache.org. This configuration will cause Apache to perform a double reverse DNS lookup on the client IP address, regardless of the setting of the HostnameLookups directive. It will do a reverse DNS lookup on the IP address to find the associated hostname, and then do a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches will access be allowed.

A full IP address

Example:

Allow from 10.1.2.3
Allow from 192.168.1.104 192.168.1.205

An IP address of a host allowed access

A partial IP address

Example:

Allow from 10.1
Allow from 10 172.20 192.168.2

The first 1 to 3 bytes of an IP address, for subnet restriction.

A network/netmask pair

Example:

Allow from 10.1.0.0/255.255.0.0

A network a.b.c.d, and a netmask w.x.y.z. For more fine-grained subnet restriction.

A network/nnn CIDR specification

Example:

Allow from 10.1.0.0/16

Similar to the previous case, except the netmask consists of nnn high-order 1 bits.

Note that the last three examples above match exactly the same set of hosts.

IPv6 addresses and IPv6 subnets can be specified as shown below:

The third format of the arguments to the Allow directive allows access to the server to be controlled based on the existence of an environment variable. When Allow from env=env-variable is specified, then the request is allowed access if the environment variable env-variable exists. The server provides the ability to set environment variables in a flexible way based on characteristics of the client request using the directives provided by mod_setenvif. Therefore, this directive can be used to allow access based on such factors as the clients User-Agent (browser type), Referer, or other HTTP request header fields.

Example:

SetEnvIf User-Agent ^KnockKnock/2\.0 let_me_in
<Directory /docroot>
Order Deny,Allow
Deny from all
Allow from env=let_me_in
</Directory>

In this case, browsers with a user-agent string beginning with KnockKnock/2.0 will be allowed access, and all others will be denied.

Deny Directive

This directive allows access to the server to be restricted based on hostname, IP address, or environment variables. The arguments for the Deny directive are identical to the arguments for the Allow directive.

Order Directive

The Order directive, along with the Allow and Deny directives, controls a three-pass access control system. The first pass processes either all Allow or all Deny directives, as specified by the Order directive. The second pass parses the rest of the directives (Deny or Allow). The third pass applies to all requests which do not match either of the first two.

Note that all Allow and Deny directives are processed, unlike a typical firewall, where only the first match is used. The last match is effective (also unlike a typical firewall). Additionally, the order in which lines appear in the configuration files is not significant -- all Allow lines are processed as one group, all Deny lines are considered as another, and the default state is considered by itself.

Ordering is one of:

Allow,Deny

First, all Allow directives are evaluated; at least one must match, or the request is rejected. Next, all Deny directives are evaluated. If any matches, the request is rejected. Last, any requests which do not match an Allow or a Deny directive are denied by default.

Deny,Allow

First, all Deny directives are evaluated; if any match, the request is denied unless it also matches an Allow directive. Any requests which do not match any Allow or Deny directives are permitted.

Mutual-failure

This order has the same effect as Order Allow,Deny and is deprecated in its favor.

Keywords may only be separated by a comma; no whitespace is allowed between them.

In the following example, all hosts in the apache.org domain are allowed access; all other hosts are denied access.

In the next example, all hosts in the apache.org domain are allowed access, except for the hosts which are in the foo.apache.org subdomain, who are denied access. All hosts not in the apache.org domain are denied access because the default state is to Deny access to the server.

On the other hand, if the Order in the last example is changed to Deny,Allow, all hosts will be allowed access. This happens because, regardless of the actual ordering of the directives in the configuration file, the Allow from apache.org will be evaluated last and will override the Deny from foo.apache.org. All hosts not in the apache.org domain will also be allowed access because the default state is Allow.

The presence of an Order directive can affect access to a part of the server even in the absence of accompanying Allow and Deny directives because of its effect on the default access state. For example,

will Deny all access to the /www directory because the default access state is set to Deny.

The Order directive controls the order of access directive processing only within each phase of the server's configuration processing. This implies, for example, that an Allow or Deny directive occurring in a <Location> section will always be evaluated after an Allow or Deny directive occurring in a <Directory> section or .htaccess file, regardless of the setting of the Order directive. For details on the merging of configuration sections, see the documentation on How Directory, Location and Files sections work.

NEWS CONTENTS

• 210210 : How To Block Bots, Ban IP Addresses With .htaccess ( How To Block Bots, Ban IP Addresses With .htaccess, )
• 210210 : .Htaccess IP Banning – Block Bad Visitors ( .Htaccess IP Banning – Block Bad Visitors, )
• 210210 : Blocking IP Addresses With .htaccess ( Blocking IP Addresses With .htaccess, )
• 210210 : apache - Blocking multiple ip ranges using mod access in htaccess - Stack Overflow ( apache - Blocking multiple ip ranges using mod access in htaccess - Stack Overflow, )

Old News ;-)

How To Block Bots, Ban IP Addresses With .htaccess

Blocking bots with .htaccess

This example, and all of the following examples, can be placed at the bottom of your .htaccess file. If you don't already have a file called .htaccess in your site's root directory, you can create a new one.

   #get rid of the bad bot
   RewriteEngine on
   RewriteCond %{HTTP_USER_AGENT} ^BadBot
   RewriteRule ^(.*)$ http://go.away/

So, what does this code do? It's simple: the above lines tell your webserver to check for any bot whose user-agent string starts with "BadBot". When it sees a bot that matches, it redirects them to a non-existent site called "go.away".

Now, that's great to start with, but what if you want to block more than one bot?

   #get rid of bad bots
   RewriteEngine on
   RewriteCond %{HTTP_USER_AGENT} ^BadBot [OR]
   RewriteCond %{HTTP_USER_AGENT} ^EvilScraper [OR]
   RewriteCond %{HTTP_USER_AGENT} ^FakeUser
   RewriteRule ^(.*)$ http://go.away/

The code above shows the same thing as before, but this time I'm blocking 3 different bots. Note the "[OR]" option after the first two bot names: this lets the server know there's more in the list.

Blocking Bandwidth Leeches

Say there's a certain forum that's always hotlinking your images, and it's eating up all your bandwidth. You could replace the image with something really gross, but in some countries that might get you sued! The best way to deal with this problem is simply to block the site, like so:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://.*somebadforum\.com [NC]
RewriteRule .* - [F] 

This code will return a 403 Forbidden error to anyone trying to hotlink your images on somebadforum.com. The end result: users on that site will see a broken image, and your bandwidth is no longer being stolen.

Here's the code for blocking more than one site:

RewriteEngine on
RewriteCond %{HTTP_REFERER} ^http://.*somebadforum\.com [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://.*example\.com [NC,OR]
RewriteCond %{HTTP_REFERER} ^http://.*lastexample\.com [NC]
RewriteRule .* - [F] 

If you want to block hotlinking completely, so that no one can hotlink your files, take a look at my article on using .htaccess to block hotlinkers.

Banning An IP Address

Sometimes you just don't want a certain person (or bot) accessing your website at all. One simple way to block them is to ban their IP address:

order allow,deny
deny from 192.168.44.201
deny from 224.39.163.12
deny from 172.16.7.92
allow from all

The example above shows how to block 3 different IP addresses. Sometimes you might want to block a whole range of IP addresses:

order allow,deny
deny from 192.168.
deny from 10.0.0.
allow from all

The above code will block any IP address starting with "192.168." or "10.0.0." from accessing your site.

Finally, here's the code to block any specific ISP from getting access:

order allow,deny
deny from some-evil-isp.com
deny from subdomain.another-evil-isp.com
allow from all

Final notes on using .htaccess

As you can see, .htaccess is a very powerful tool for controlling who can do what on your website. Because it's so powerful, it's also fairly easy for things to go wrong. If you have any mistakes or typos in your .htaccess file, the server will spit out an Error 500 page instead of showing your site, so be sure to back up your .htaccess file before making any changes.

If you'd like to learn more about writing .htaccess files, I recommend checking out the Definitive Guide to Mod_Rewrite. This book covers everything you need to know about Apache's .htaccess rewrite system.

PS: If your webhost doesn't support .htaccess, it's time to get a better one! :)

.Htaccess IP Banning – Block Bad Visitors

Deny or Allow Domain Access for a Specified IP Address Range

There are several effective ways to block a range of IP addresses via htaccess. This first method blocks an IP range specified by their CIDR (Classless Inter-Domain Routing) number. This method is useful for blocking mega-spammers such as RIPE, Optinet, and many others. If, for example, you find yourself adding line after line of Apache deny directives for addresses beginning with the same first few numbers, choose one of them and try a whois lookup. Listed within the whois results will be the CIDR value representing every IP address associated with that particular network. Thus, blocking via CIDR is an effective way to eloquently prevent all IP instances of the offender from accessing your site. Here is a generalized example for blocking by CIDR (edit values to suit your needs):

# block IP range by CIDR number
<Files *>
order allow,deny
allow from all
deny from 10.1.0.0/16
deny from 80.0.0/8
</Files>

Conversely, to allow an IP range by CIDR number:

# allow IP range by CIDR number
<Files *>
order deny,allow
deny from all
allow from 10.1.0.0/16
allow from 80.0.0/8
</Files>

Blocking IP Addresses With .htaccess

Blocking IP Addresses With .htaccess

What is .htaccess

.htaccess is a file that Apache reads that allows configuration changes on a per-directory basis. One of the handy little tricks one can do with this configuration file is block visitors from viewing a web site.

The Basics – Blocking 1 IP Address
Order allow,deny
Deny from 192.168.0.101
Allow from all

This will refuse all access (GET & POST) to the web site for the IP address 192.168.0.101

The Multiple IP Approach
Order allow,deny
Deny from 192.168.0.101
Deny from 192.168.0.102
Deny from 192.168.0.103
Deny from 192.168.0.104
Allow from all

Blocking IP Ranges
Order allow,deny
Deny from 192.168.0 ßnotice there is no 101, 102, 103 (this affects a lot of users)
Allow from all

IP's range from 0 – 255 (ex -192.168.0.0 – 192.168.0.255)
You may also block ranges by way of calculating CIDR (Classless Inter-Domain Routing – pronounced "cider") IP ranges (8, 16, 24bits)
Order allow,deny
Deny from 192.168.0/16
Allow from all

Get Mean

You can also block host names instead of numeric addresses.
Order allow,deny
Deny from cox.net
Allow from all

This will block anyone in the Cox.net network. But beware; banning large isp companies such as Cox.net or Comcast.com will block all their users. Do your research when it comes to blocking hostnames. Think about who may be affected.

There are many other ways of blocking IPs, but using .htaccess is one of the more common requests we receive.

apache - Blocking multiple ip ranges using mod access in htaccess - Stack Overflow

Q: Blocking multiple ip ranges using mod access in htaccess
I read the guide from apache site but I'm a bit confused, I'm trying to ban some ranges using this syntax:
order allow,deny

deny from 127.0.55.0/127.0.75.255
deny from 127.0.235.0/127.0.255.255
allow from all

But I think it's not working properly, probably the syntax is wrong or I'm using it in the wrong way, where should I write this text in htaccess? before the other lines or after? in the same htaccess file there're some mod rewrite script too (for anti-hotlinking).

A: I've come to this answer using apache documentation. You can give an address range using ip/netmask pair :
deny from 127.0.55.0/24

However, since range 55 - 75 are not power of two, I don't see how to make a range out of them. I'd add several rules.

order allow,deny
deny from 127.0.55.0/24 // Matches 55
deny from 127.0.56.0/21 // Matches 56 to 64
deny from 127.0.64.0/21 // Matches 64 to 71
deny from 127.0.72.0/22 // Matches 72 to 75

deny from 127.0.235.0/24 // Matches 235
deny from 127.0.236.0/22 // Matches 236 to 239
deny from 127.0.240.0/21 // Matches 240 to 255
allow from all

should work.

NB: Remove the comments after // before pasting into htaccess

.htaccess IP Block Apache Web Server forum at WebmasterWorld

Hi All,
I normally block IPs or ranges of IPs like this:
deny from (IP number)

But I would like to know how to block an entire range:
##.136.0.0 - ##.191.255.255
with ## being the same number. Sorry - not sure if I'm allowed to post the full IP.

Would I simply add the line:
deny from ##.136.0.0 - ##.191.255.255

or is there another way?

These people are quite nasty and have been breaking in and planting their links on a friend's site. We're securing up the site's script by upgrading but I'd like to ban their entire IP range since they keep trying with several from this block.

Also, one other newbie question - I read somewhere online that I can ban the host these people are coming from. So if for instance, their host is "t-dialin.net" could I add
deny from t-dialin.net
and have all who come from that host blocked? I understand the ramifications of this kind of block. I am just curious if what I read is true. At this point, I only intend to ban the IP block assigned to the hackers but I have found 2 completely different IP addresses associated with these hackers and they belong to the same host.

Thanks,
Hope

jdMorgan

WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 1:43 am on Dec 22, 2005 (gmt 0)

You may use a partial IP address, a network CIDR specification, or a network/netmask specification to block ranges, depending on your needs and the actual range to be blocked.
See the examples at [httpd.apache.org...]

Jim

EarleyGirl

5+ Year Member

Msg#: 5169 posted 1:53 am on Dec 22, 2005 (gmt 0)

Thanks Jim.
I'm sorry but I've read the apache info and I guess I'm such a newbie (or a little on the simple side) that I still don't understand how to block a range. Is the follwing acceptable in .htaccess?
order allow,deny
deny from ##.136.0.0 - ##.191.255.255
allow from all
Where ## is the same number - as in 84.

jdMorgan

WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 2:14 am on Dec 22, 2005 (gmt 0)

No,
Changing your example to unroutable IP addresses for the sake of clarity in this thread, let's say you want to deny from 192.168.0.0 through 192.168.0.255

The documentation states that you may use:

deny from 192.168.0
or
deny from 192.168.0.0/24
or
deny from 192.168.0.0/255.255.255.0

All of which do the same thing.

The first example is a partial IP address. It is interpreted using 'prefix matching.' That is, any IP address that *starts with* 192.168.0 will be denied.

The second example is a network/CIDR spec, where the 'base' address is given, followed by the number of bits that must match, in this case 24. (Each 'group' of digits in an IP address is the decimal representation of an eight-bit octet, where eight bits can be used represent any decimal number from 0 through 255 [two raised to the eighth power, minus one]. Since your deny range comprises three octects, you'd use 24 bits.)

The third example is a network/netmask spec, as used in the network setting on Windoze, for example. The first part is again the 'base' IP address, and the second part is a decimal representation of a 'mask' to be applied to both the incoming IP address and the given base address before they are compared. In this case, 255.255.255.0 means that the last group of digits in the IP addresses are to be ignored.

Jim

EarleyGirl

5+ Year Member

Msg#: 5169 posted 2:26 am on Dec 22, 2005 (gmt 0)

My apologies. I guess I'm much slower than I first thought. I understand how to ban IPs from this type of IP:
deny from 192.168.0
What I can't figure out is how to deny from a range such as 192.136.0.0 - 192.191.255.255

You probably just explained it all to me but for some reason, I can't see it.
Edited to add:
Looks like I'll have to add them all in one by one such as:
deny from 192.136
deny from 192.137
deny from 192.138
all the way to
deny from 192.191

Hope

jdMorgan

WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 3:11 am on Dec 22, 2005 (gmt 0)

Yes, sorry, I can't teach you about decimal to binary radix conversion in this constrained forum format, and that's what's needed to cover complex ranges. I'd suggest a search for 'CIDR calculators' or 'Netmask calculators' unless you want to take a semester course on Boolean logic and radix conversion... :( But, since I've already done so myself...
In order to deny only the exact range you've specified, three 'pieces' are needed. This is because the range is not an exact power of two in size:

# Deny 192.136.0.0 through 192.143.255.255 (first 52,4288 addresses):
deny from 192.136.0.0/13

# Deny 192.144.0.0 through 192.159.255.255 (next 1,048,576 addresses):
deny from 192.144.0.0/12

# Deny 192.160.0.0 through 192.191.255.255
deny from 192.160.0.0/11 (last 2,097,152 addresses):

There's yet another way to do it using SetEnvIf and regular expressions, though it's just as complex in another way:

# Deny 192.136.0.0 through 192.191.255.255
SetEnvIf Remote_Addr ^192\.1(3[6-9]¦[4-8][0-9]¦9[01])\. getout
Deny from getout

If you use this latter method, remember that you are doing a string compare --a lexical compare-- and not a numeric compare. The module does not understand the code to mean 'a range of numbers'; it is only looking at characters and character ranges.

Replace all broken pipe "¦" characters above with solid pipe characters before use; Posting on this board modifies them.

And yes, the sophisticated spammers pick oddball non-aligned and non-contiguous IP ranges to make this job difficult.

Jim

jdMorgan

WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 3:18 am on Dec 22, 2005 (gmt 0)

And to top it off, I forgot the part about blocking by hostname...
Yes, you can block by hostname, as shown in the documentation I cited above.

Jim

EarleyGirl

5+ Year Member

Msg#: 5169 posted 3:24 am on Dec 22, 2005 (gmt 0)

And yes, the sophisticated spammers pick oddball non-aligned and non-contiguous IP ranges to make this job difficult.

Tricky little devils, aren't they? I just had no idea how tricky! We are having quite a time with these hackers/spammers. It's gotten to be quite a time consuming project - much I'm not getting paid for since this is my friend's site.
I do so appreciate the help and now can see why it is so complicated. You've helped me greatly. Thank you, Jim!

Hope

geekdogfl

Msg#: 5169 posted 3:37 pm on Jan 30, 2010 (gmt 0)

I know this is an old post but I'm newly-joined as a supporter of WebmasterWorld and I really need help with this topic once and for all. I read the documentation at Apache and it's a bit beyond me. I need plain English!
I'm having a serious intruder problem. The intruder's IP always starts with the same two parts: ##.###. BUT the rest of the numbers vary widely.

So if I understand this, I want to block by range -- given what I DO know for certain so far about the intruder's apparently-changing IPs?

If so, how? Would this work:

##.###./24

I would hate to block innocent people coming from ##.###.

Thanks for ANY help!

jdMorgan

WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 10:12 pm on Jan 30, 2010 (gmt 0)

You must include 4 octets, separated by periods as described in previous posts. Your post only shows two octets, and you didn't mention the size of the range to be blocked, so I don't quite know what to make of it.
Jim

geekdogfl

Msg#: 5169 posted 10:11 pm on Jan 31, 2010 (gmt 0)

Sorry, Jim! Thanks for trying to help me. I wish I knew how to better explain what I mean.
I want to block a range ##.###.333.444 through ##.###.456.789. Does that make sense? I don't think I'm supposed to pot real IPs here. I made those up. If they are real, please delete. I'm trying to show that the first two "octets" I am concerned with are always the SAME IDENTICAL NUMBERS (first one has two numerals, second has three), but the last two octets change every time and vary widely. The intruder must not have a static IP, right? I am thinking I will just have to ban ##.###. and not bother with the last two octets being narrowed or specified. That is OK, if that is what it takes to keep this jerk off the sites.

Thanks for trying! I appreciate it very much.

jdMorgan

WebmasterWorld Senior Member jdmorgan us a WebmasterWorld Top Contributor of All Time 10+ Year Member

Msg#: 5169 posted 3:38 am on Feb 1, 2010 (gmt 0)

You might want to look at the Jerk's 'total profile' -- What IP address range, what user-agent(s), what referrer(s) (if any) and what request headers he sends with each request. The additional request headers typically don't appear in standard logs, but you can access them and save them using a script if this is something you'd feel comfortable doing (also meaning that writing this script is beyond the purview of this forum).
I don't know what you typed for the ranges above since the first two octets are obscured as "x" characters, making it a bit hard to give a specific answer. But in order to block
192.168.0.0 through 192.168.255.255 --the entire valid range of the last two octets-- you could use

Deny from 192.168.0.0/16 -or-
Deny from 192.168.0.0/255.255.0.0 -or-
Deny from 192.168

All of these do exactly the same thing, and which you choose is largely a matter of "style" and consistency within your own code. Otherwise, there is no difference.

When posting IP addresses here, it is only necessary to obscure one octet. The trick is to obscure an octet that won't change the code being discussed...

Jim

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

Comprehensive guide to .htaccess- intro

• Comprehensive guide to .htaccess- Deny users by IP
• Comprehensive guide to .htaccess- Blocking users- sites by referrer

Blocking (part of) a web site for certain IP numbers

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

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