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

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

ps command


See Also


Recommended Links Reference Controlling System Processes
pgrep kill jobs lsof    
nice top vmstat UNIX uptime command x11perf  
Unix Signals Process Scheduling Admin Horror Stories Unix History Humor Etc

In modern Unixes ps is implemented using /proc pseudo filesystem. That means it reads data from it and does not requires additional privileges. See also top command which is a simple monitoring tool for running process similar to ps but able to work in interactive mode.

In most Posix compatible Unixes ps  commonly is used with the options -ef, where "-e" selects every process and "-f" chooses the "full" output format:

The ps command by default truncates output at 80 column. To avoid this problem and full invocation like you use -w option, for example

Another useful option is option -l

Meaning of full listing columns:

ps with grep

Often ps is used with grep like in ps -ef | grep httpd There is a simple way to get rid of displaying additional line in the result of such command: make the first letter (actually any letter a class of symbols with square brackets. for example

ps | grep [h]ttpd

The essence of this trick is that brackets allow specify class of symbol which is out case contain a single symbol. But this notation prevent grep from picking up the line grep [h]ttpd as it does not contain the string httpd.  

Probably a better way to to create function to solve this problem See Unix Review Shell Corner PS-n-Grep — The Steroid Version

Actually pgrep -l  provides similar functionality.

BSD versiion of ps

Common options:

Meaning of user information columns:

How to  find zombie processes?

If you have zombie processes it means a process that has completed execution but still has an entry in the process table.  (look at PPID displayed by ps -l).  See (Zombie process - Wikipedia )

When a process ends, all of the memory and resources associated with it are deallocated so they can be used by other processes. However, the process's entry in the process table remains. The parent can read the child's exit status by executing the wait system call, at which stage the zombie is removed. The wait call may be executed in sequential code, but it is commonly executed in a handler for the SIGCHLD signal, which the parent receives whenever a child has died.

There easiest way to detect zombies is to use command top. It list number of zombies process in the header.

When a process become zombie it consumes almost no resources so generally they are not dangerous. To find out list of PIDs you can run something like:

# ps aux | awk '{ print $8 " " $2 }' | grep -w Z


Z 4104
Z 5320
Z 2945

Please note that kill -9 does not guarantee to kill a zombie process.

Top updates

Softpanorama Switchboard
Softpanorama Search


Old News ;-)

[Jun 27, 2010] WebSphere AIX Command Tips

Displaying top CPU_consuming processes:
#ps aux | head -1; ps aux | sort -rn +2 | head -10
Displaying top 10 memory-consuming processes:
#ps aux | head -1; ps aux | sort -rn +3 | head
Displaying process in order of being penalized:
#ps -eakl | head -1; ps -eakl | sort -rn +5
Displaying process in order of priority:
#ps -eakl | sort -n +6 | head
Displaying process in order of nice value
#ps -eakl | sort -n +7
Displaying the process in order of time
#ps vx | head -1;ps vx | grep -v PID | sort -rn +3 | head -10
Displaying the process in order of real memory use
#ps vx | head -1; ps vx | grep -v PID | sort -rn +6 | head -10
Displaying the process in order of I/O
#ps vx | head -1; ps vx | grep -v PID | sort -rn +4 | head -10
Displaying WLM classes
#ps -a -o pid, user, class, pcpu, pmem, args
Determinimg process ID of wait processes:
#ps vg | head -1; ps vg | grep -w wait
Wait process bound to CPU
#ps -mo THREAD -p

Show the entire line with the linux-unix ps command


One thing that always drove me crazy was not being able to get the full listing from the ps command. For example when doing ps -elf it will cut off the command column. Even dumping it to file is no help, as the command column will get cut off if it goes beyond the 80 char width.


Use the width switch:
ps -elf --width 500 | grep java.*encode
-o switch is handy too
ps -u apache --width 1000 -o "%p|%a" | grep java.*# the -u switch only shows processes with the user of apache
Here is are a list of other column descriptors that can be used with the -o switch

%C pcpu %CPU
%G group GROUP
%P ppid PPID
%U user USER %a args COMMAND
%c comm COMMAND
%g rgroup RGROUP
%n nice NI
%p pid PID
%r pgid PGID
%t etime ELAPSED
%u ruser RUSER
%x time TIME
%y tty TTY
%z vsz VSZ

Unix Review Shell Corner PS-n-Grep — The Steroid Version by Ed Schaefer

How many of us check the Unix process table using the ps command and pipe it to grep? This month, Bob Orlando presents Perl and awk scripts that add intelligence to this process.

PS-n-Grep: The Steroid Version

(or "What Is The Most Common Letter In The English Language And What Does It Have To Do With Shell Programming?")

by Bob Orlando

If you've worked in Unix for any length of time, you're probably familiar with psg or some such variant. Psg stands for "ps through grep" (essentially a ps query whose result is piped grep). It works and works well, but sometimes you need more than just a process string; sometimes you want the process string AND the process ID (PID) — separated. Oh yes, and since we're compiling a wish list here, how about the operation simply telling me how many processes match a given target string. I'll show how to do all of that — and do it without having to run multiple ps commands and filtering those results through several piped operations. To begin, let's take a quick look at psg.

Instead of typing "ps -your_options | grep", most folks simply alias psg to something like the following:

alias psg='/usr/bin/ps -eaf | grep -i'
alias psgw='/usr/ucb/ps -auxww | grep -i'
If you don't want to see the "grep" line itself in the output, then you have to do something like this:
psg()  { /usr/bin/ps -eaf   | grep -i "$@" | grep -v " grep -i" ; }
psgw() { /usr/ucb/ps -auxww | grep -i "$@" | grep -v " grep -i" ; }
In those two lines, we establish psg and psgw as functions. They behave just like aliases, but with some expanded capability. Essentially, the functions run their respective ps commands, selecting only those lines matching the string provided ("$@"). The "$@" (including the quotation marks) allows for embedded blanks as well as quotation marks themselves. The first grep -i filters out all but the desired string(s), while the second, grep -v excludes any result bearing the grep -i. Pretty basic stuff. Now for the steroids: PSWP and PSWA.

The PSWP and PSWA scripts described below (the first using Perl, the other awk) grew out of those common ps-n-grep aliases. The purpose of these scripts is to use the UCB ps -auxww command to list those processes in the process queue that match our target and to separate the result into:

  1. A list of the PIDs
  2. Full ps output strings
  3. A count of matching PIDs indicated in our return status
Here's how the Perl version works.


PSWP (PS -W via Perl) is a shell function that uses UCB ps -auxww to list processes in the process queue, displaying process lines matching our target string. Originally the function was needed for a script I was writing that needed to do the following: restart a critical process by first killing off any of the old processes that failed to terminate via the shutdown operation, call the standard startup script, and lastly, confirm that the restarted process was running by verifying that the expected processes were all found in the process queue.

UCB's ps was necessary because it provided a detailed (read "long") process string to ensure we could find exactly the target process we wanted with little chance of returning a false success (i.e., finding another process that had a similar but, therefore, less unique string). Further, when locating the target string, PSWP is careful to exclude itself, as well as any "vi" (an edit operation often responsible for falsely reporting a "found" ps string). I usually use awk for such ps interrogations (where the need is to return the PID as well as the ps string), but with the UCB ps returning 5,000+ bytes of data, awk's limited input buffer size made Perl the obvious choice — one that served me very well.

PSWP's modular design (written as a standalone function) was deliberate. I saw many potential situations where its capabilities would be helpful and allow for seamless integration into both Bourne and Korn scripts.

Sure enough, it wasn't long before I was tasked with writing yet another restart script. I was going to use PSWP, but this time the host on which the process would run was a stripped-down certification machine that lacked the space to install Perl (Dang! I hate it when that happens). It was back to awk.


PSWA (PS -W via awk) is also a shell function that uses UCB ps -auxww to list processes in the process queue and display process lines matching our target string. (Does this sound like the movie "Groundhog Day"?) Awk is still a very powerful tool, and although it lacks the superset of string manipulation capabilities available in Perl, it is capable of performing some pretty complex pattern matching and selection operations.

To work around awk's input buffer limitation, I knew I had to play with the record separator (RS). For that I used the letter "e", the most common letter in the English language. (The "e" record separator is easily changed via the function's -r option.) As the most common letter in English, using it as the record separator allows the program to ingest all the data in byte-size chunks (bypassing awk's input buffer limitations). Once it encounters a new line, the byte-size pieces are reassembled into a single line for comparison against our target ps string.

As with PSWP, writing the program as a function makes it available for use in many other scripts. For even greater portability, both scripts, and, are written using Bourne syntax so they work equally well in Korn or BASH scripts and environments. To further facilitate this, I deliberately omitted any shell invocation (the she-bang or #!/usr/bin/sh). Thus, it runs seamlessly within the invoking shell. Also, to prevent needlessly loading the script, in case it is repeatedly sourced, the script checks to see whether it is already loaded before loading itself again. It does this by determining under which shell it is running and checking accordingly. Lastly, to provide a rudimentary level of variable scoping, function variables are prefixed with _PSW_ (i.e., $_PSW_rs).

In addition to the record separator option, -r, there is also an option for ignoring case (-i), when searching for the target ps string. This is especially handy for impromptu process queries. (See Example No. 9 below for assigning PSWA or PSWP in your .profile for case-insensitive queries.)

Both functions provide a list of process IDs via stdout, and a list of matching ps strings are delivered via stderr. Fulfilling our last "wish list" requirement, both PSWA and PSWP return the actual number of processes found in the return/exit status (see "EXIT STATUS below). The caller need only redirect/capture the desired output. The following examples show how.


In the examples that follow, I call PSWA, but you need only substitute PSWP to receive identical results.

After sourcing the script to load the function (i.e., . ./ or . ./, you can run PSWA or PSWP as follows:

  1. Find jsm-ruleseng in process queue. PIDs are displayed in stdout, while the actual ps strings are displayed via stderr:
           PSWA jsm-ruleseng
  2. Find jsm-ruleseng, printing PIDs, discarding any ps line output by redirecting stderr to /dev/null:
           PSWA jsm-ruleseng 2> /dev/null
  3. Find jsm-ruleseng assigning ps output (stderr) to $pss and redirecting pids (stdout) to /dev/null:
           pss=`PSWA -- "jsm-ruleseng" 2>&1 > /dev/null`
  4. Find jsm-ruleseng assigning PID list to $pids and redirecting any ps line output to a file:
           pids=`PSWA -- "jsm-ruleseng" 2> /tmp/stderr`
  5. Return only the number of processes found (see "Returns:" below):
           PSWA -- jsm-ruleseng > /dev/null 2>&1
  6. Find -bg black -fg Green (note the "--" to end option processing before the string):
           PSWA -- -bg black -fg Green
  7. Find -bg black -fg Green ignoring case:
           PSWA -i -- -bg black -fg Green
  8. Find -bg black -fg Green using the second most frequently found letter in the English language:
           PSWA -r "t" -- -bg black -fg Green
           PSWA -r t -- -bg black -fg Green # Ditto
         | The -r option is unnecessary with PSWP and  |
         | therefore, not available therein.           |
  9. Alias PSWA function as pswa so we can search the process queue, ignoring case:
           . ./ # Source the PSWA function.
           pswa () {PSWA '-i' "$@" 2>&1 1> /dev/null ; }
    Again, calling PSWA in this fashion (as a function instead of an alias) makes alias functionality available regardless of shell.
Except for the -r, record separator option (example 8), command syntax for both PSWA and PSWP are identical.

Exit Status

PSWA and PSWP return the number of matching process lines in our status as follows:

0-253 = Actual number of processes found
254 = Indicates more than 253 processes found
255 = ERROR: Caller provided no target ps string


For testing these scripts, I wrote a simple Calling it as a background operation ( &) adds a job to the process queue that carries with it a 12,000+ byte long string you hope you'll never have to face in real life. Both PSWP and PSWA handled that process with equal ease.


Despite its expanded output capability, the Perl version still runs as quickly as the basic psg. For the dozen or so hosts on which I've run it, the timed result consistently returns in roughly half a second. Despite having four times the code, the awk function also runs very quickly — consistently in a single second. With the increasing availability of Perl, it is unlikely I'll need PSWA much longer. Still, writing the awk version was rewarding because I learned some very interesting things (such as the two most common letters in the English language).

For the past 25 years, Bob has been a Unix programmer, systems administrator, and DBA (Sybase and Oracle). In his free time, he heads the Je du-too School of Martial Arts ( in Denver, Colorado and is the author two books and three videos on martial arts.

Unix Simplicity Filtering the unix ps command

Now, suppose you are only interested in the process information
for "vi". You could do the following:
$ ps | grep vi
10ae 0535 0056 0c34 10ae (vi.exe) \unix\bin\vi.exe
1105 10ae 15cd 0000 2112 (/unix/bi)  -c ps | grep vi
The problem is that you also get the entry for the "grep" process itself.
There is a simple, elegant solution:
$ ps | grep [v]i
10ae 0535 0056 0c34 10ae (vi.exe) \unix\bin\vi.exe

In regular expressions, brackets contain either-or options. So "[sz]ys" would match "sys" or "zys". If only one character is in brackets, as in "[v]i", then the regular expression simplifies to "vi" upon execution.

Thus, in our case, "grep" is simply looking for "vi", but the "ps" entry for the "grep" contains the original "[v]i", so we prevent a match.

Hiding Passwords From UNIX ps Command

When running an sql script from unix, the unix ps (process status) command has a nasty habit of showing the Oracle userid and password of the sqlplus session. To get around this problem, you can pipe the password into sqlplus instead of putting it in as part of the sqlplus command line (which is what shows up in the ps listing). Below are examples of piping in the password (userid system, password systempw) for sqlplus, import, and export. If you put these in a unix shell command file, such as myfile.shl, be sure to do a "chmod 700 myfile.shl" so that only your userid can see your Oracle passwords in that file!

echo systempw | sqlplus -s system @myfile.sql
echo systempw | imp system file=myfile.dmp tables=mytable
echo systempw | exp system file=myfile.dmp tables=mytable

Oracle has also provided another method which pads the command line to sqlplus (or any other executable) with just enough blanks to fool the unix ps command into not displaying the actual command line. To do this, get hide.c (and os.h, if your machine doesn't have it), compile it on your system (the exact compile syntax may vary), move the original sqlplus binary to sqlplus.hide (must have a ".hide" extension), and create a link from "hide" to "sqlplus" (which will run the "hide" binary whenever "sqlplus" is entered on the command line; "hide" will then run "sqlplus.hide" with the command line padded with blanks). A sample session to do this is shown below:

cc hide.c -o hide
cp hide $ORACLE_HOME/bin
mv sqlplus sqlplus.hide
ln hide sqlplus

After doing this, any time anyone executes sqlplus with command line options, those command line options will not be visible from ps. Be aware, though, if you apply any patches to your Oracle bin directory, you must first do a "mv sqlplus.hide sqlplus" to put back the original sqlplus binary into the Oracle bin directory. Then, after applying the patches, you can once again run through those steps above to create a link from the hide binary to sqlplus. (Note: I haven't tried using hide.c, since I always use the pipe method, but, I've seen this at several places on the web and listservs, so, I'm including it here in case you want to try it out.)


Normally a zombie process means that the process has died but remains in the process table because the parent hasn’t called wait() to “reap” the process and retrieve the return code. If you kill the parent, the zombie process becomes parented by init (process 1) and init reaps it. But, the problem we were having was clearly not this. Killing the parent did nothing. And the defunct agent appeared to be holding onto resources. It was not possible to start a new agent since the defunct one continued to hold a socket open, which would never be true with the usual meaning of a defunct process. The only workaround was to reboot the system.

The key to the real answer is that the agent uses multiple threads with the POSIX threads library. Individual threads and processes under Linux are both viewed as tasks to the process management code. Threads are implemented using one task designated as “thread group leader” and a “thread group id” present in each task_struct. By default, the ps utility displays just the thread group leader, hiding the other tasks.

John Zbesko 25 Mar 2008 - 11:18
Often I’ve encountered a situation where Firefox is hanging on a web page that displays flash video. Even though I close Firefox and look for processes using “ps -ef|grep fire”, I see none. Firefox still will hang if I start again and go to the flash web page.

Only re-booting the machine seems to fix the problem. Is this a similar problem? I’ve also encountered similar problems when messing with the SystemSettings app in Kubuntu when trying to configure less-than-100%-compatible wi-fi devices. Hope this helps…

pomac says 26 Mar 2008 - 8:58
A process reading on a nfs drive can be revived, unmount the nfs filesystem with -lf or so, the key here is -f. Eventually you’ll get a io timeout and all programs will continue working.

What are you doing? I mean why are you blocking on IO in kernelspace? Can it be converted to nonblocking IO?

spinfire says; 26 Mar 2008 - 9:24
Yeah, the NFS mount case can now be fixed with -f. But in the meantime reading processes are in “D” and can’t be interrupted. There are other hardware issues which can cause things to be stuck in uninterruptible sleep perpetually.

The kernel space code used wait_for_completion() which causes uninterruptible sleep. I didn’t write that code, and I haven’t had time to look into why it chose this, except to say wait_for_completion is fairly common in driver code (there is now a timeoutable variant, but it is new, and may not always be appropriate in driver code). In this case I was working with beta drivers, beta hardware, so who knows.

[Aug 15, 2008] Tip of the Trade ps Options By Juliet Kemp

August 11, 2008 |

Admins use ps all the time to look at processes running on a system. But do you make the best use of the multitude of options this very useful tool has, or do you stick to a tiny, tested handful? Here are some ps options to check out that you may not have encountered before.

Options can be combined, but note that there are three types of option: a single dash, a double dash or no dash at all. u is different from -u. When combining options, the different option types must be grouped separately (e.g., ps Sf -u jkemp.)

Server Oriented System Tuning Info

Okay, so everyone knows about ps. But I'll just highlight one of my favorite options:

ps -eo pid,%cpu,vsz,args,wchan

Shows every process, their pid, % of cpu, memory size, name, and what syscall they are currently executing. Nifty. Home P.S.—I want to see my processes

One of the most basic tools we can use is the utility ps. ps provides a snapshot of current processes. This snapshot can range from myself as a single user (such as what active processes I have running) to all the processes on the system. The simple example of course is to run the ps command with no options, which produces output similar to:

  PID TTY          TIME CMD
 2873 pts/1    00:00:00 bash
 3002 pts/1    00:00:00 ps
Example 1. Basic output of ps

We see in Example 1, “Basic output of ps” that we get some minimal information about the processes we are running, including ps itself. ps displays the process ID (PID), the terminal associated with the process (TTY), the cumulated CPU time in [dd-]hh:mm:ss format (TIME), and the executable name (CMD). Spectacular, right? Well, ps does this and a whole lot more. I should mention at this point that the version of ps that I am using for this article is something special compared to the ps of yester-year and of your classic UNIX®. This ps, procps version 3.2.5, accepts several kinds of options: UNIX options, which may be grouped and must be preceded by a dash, BSD options, which may be grouped and must not be used with a dash, and GNU long options, which are preceded by two dashes. For the uninitiated, those who are new to Linux, or refugees from some older BSD or System V variant, this is good news. A system administrator can track down a process via several sets of options.

root      2784  2774  0 22:45 pts/2    00:00:00 su - mfrye
mfrye     2785  2784  0 22:45 pts/2    00:00:00 -bash
root      2895  1870  0 23:04 ?        00:00:00 sshd: mfrye [priv]
mfrye     2897  2895  0 23:04 ?        00:00:00 sshd: mfrye@pts/3
mfrye     2898  2897  0 23:04 pts/3    00:00:00 -bash
mfrye     3274  2785  0 23:34 pts/2    00:00:00 ps -ef
mfrye     3275  2785  0 23:34 pts/2    00:00:00 grep mfrye
Example 2. Output of ps -ef | grep mfrye
root      2784  0.0  0.0  71368  1288 pts/2    S    22:45   0:00 su - mfrye
mfrye     2785  0.0  0.0  55124  1536 pts/2    S    22:45   0:00 -bash
root      2895  0.0  0.1  38228  2660 ?        Ss   23:04   0:00 sshd: mfrye [priv]
mfrye     2897  0.0  0.1  38228  2748 ?        S    23:04   0:00 sshd: mfrye@pts/3
mfrye     2898  0.0  0.0  55124  1528 pts/3    Ss   23:04   0:00 -bash
mfrye     3272  0.0  0.0  52948   872 pts/2    R+   23:34   0:00 ps aux
mfrye     3273  0.0  0.0  51192   636 pts/2    S+   23:34   0:00 grep mfrye
Example 3. Output of ps -aux | grep mfrye

In Example 2, “Output of ps -ef | grep mfrye” and Example 3, “Output of ps -aux | grep mfrye”, we see the output of ps with different arguments. We can use this output to track a particular set of processes (owned by mfrye) via either of two sets of options (UNIX & BSD, respectively). So what's the big deal, you're thinking? OK, so bash is a pretty tame example. In cases where another process, perhaps one that consumes more memory, or some other resource, than you want, ps can be a very quick, easy, and effective way to track that process down. So now we've tracked down a particular process, but we don't know much more than some basic information about the process's CPU usage in terms of accumulated CPU time, which as you may appreciate, is not ideal. Luckily, there's more.

Killing (Numerous) Processes By S. Lee Henry

Undoubtedly, you are familiar with the kill command, which sends a signal (usually a TERM) to a running process. The default signal, if you don't specify one on the command line, will stop most processes from running. The kill command is an easy command that most Unix users learn, as well as kill -9 (also called the "sure kill"), long before they understand the exact nature of the kill command (i.e., sending a signal which a process will read and process) and its difference from simply stopping a process -- one of many options, though the most common.

When you want to kill a process using a script and need to determine the process ID, or when you want to kill a number of processes without having to use both the ps and kill command for each of them, you run into complications. This column presents a code snippet for killing a number of processes "by name". We use the Bourne shell (this will work with other shells in the Bourne shell family as well) and the xargs command to compose a kill command on the fly.

Here's the code:

------------------------------ cut here ------------------------------

procs2kill="proc1 proc2 proc3 proc4 proc5"

for proc in `echo $procs2kill`
  ps -ef | grep $proc | grep -v grep | awk '{print $2}' | xargs -i kill
  $proc killed
------------------------------ cut here ------------------------------
The procs2kill variable should define the processes to be killed as precisely as possible -- include as much of a substring as possible so that you will select the proper processes and only the proper processes. If you are overly generous in your specification (e.g., you specify a string that is too general and will match more than a single process), then you might kill more processes than you intended. Once established, the procs2kill variable is then used in the "for" loop to kill each process. The grep -v command removes any sign of the grep command in the process table; the awk command reduces the ps output to the process id column; and the xarg command then creates a kill command with each process id.

The Bourne shell "for proc in " command is very similar to the C Shell's foreach command -- foreach PROC (echo $procs2kill). The syntax is very similar and each command assigns each value, in turn, to the proc variable.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

ps - Linux Command - Unix Command

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

Suse performance tuning

Zombie process - Wikipedia, the free encyclopedia




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

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


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


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


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


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

Classic books:

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

Most popular humor pages:

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

The Last but not Least

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

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

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

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

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

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


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

Last modified: June 04, 2016