Softpanorama

May the source be with you, but remember the KISS principle ;-)
Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

nice command

News

See Also

Books

Recommended Links Performance tuning time x11perf
nohup top vmstat Horror Stories Unix History Humor Etc

In Unix no process can monopolize all system resources (CPU, memory, disk access, and so on). The kernel’s primary function is to manage the system resources equitably. It does this by assigning a priority to each process so that some processes get better access to system resources and some processes might have to wait longer until their turn arrives. Changing priority of the task can be useful in a situation in which CPU and RAM use must be reserved or allocated for a specific task. That's what  nice  and renice  commands allow you to do. 

The operating system's task switcher, also known as the scheduler, is designed to do the following:

  1. Load the context of a task into the Central Processing Unit (CPU) registers.
  2. Let the task run for a short period of time.
  3. Save that context before loading the context of the next task.

The scheduler maintains a number of internal tables to manage the context of every running task in the system. It also manages resources using a pair of queues known as the run queue and the sleep queue. The run queue is where tasks that have all of their resources available are held. The sleep queue is for tasks that are waiting for one or more resources to be available. In general, the scheduler makes sure that the system runs in an orderly, responsive manner.

Many things make up the context of a running task. When a task runs, there is a CPU register called the instruction pointer (IP) that contains the memory address of the current machine code instruction being executed. When a task is switched out, the task switcher must save the value of that IP register to be able to reload it again later when the task is switched back in. Therefore, part of the context of a task is the current IP value.

Another important value that makes up the context of a task is the stack pointer (SP). The stack is a last-in-first-out (LIFO) queue that holds subroutine return addresses, items of data, pointers, and so on. The meaning of each item held on the stack is determined by the instructions that operate on them, according to the programmer's detailed design.

The IP and SP, along with all of the other important CPU registers that make up the context of the running task, are the low-level details that the task switcher uses to switch contexts and run different tasks. The task switcher also works with higher-level details. One of those higher-level details is the priority of the task.

Priority

 In the UNIX scheme of things, this priority is indicated by a number that can vary from a -20 to a +19 and is known as the nice number of the task. The programs with the highest priority have the lowest nice value, so a value of -20 makes a task important in the UNIX scheme. Contrary to that, a task with a nice value of +19 is a nice, unselfish task that allows all other tasks to have a greater share of the CPU's precious time to run on than itself.

The nice  command is used with its -n  option, along with an argument in the range of -20  to 19, in order from highest to lowest priority (the lower the number, the higher the priority). For example, to run the gzip  with a low priority, use the nice  command like this:

$ nice -n 12 gzip /proxylogs/* &

UNIX provides several tools for detailed viewing of what is running on the computer at any time. Among them  the ps command and top. Based on the ps  command, the top  command provides a convinient text-based display of constantly updated console-based output showing the most CPU-intensive processes currently running. It can be started like this:

# top

The renice  command can be used to reset the priority of running processes or control the priority and scheduling of all processes owned by a user. Regular users can only numerically increase process priorities (that is, make tasks less important) with this command, but the root operator can use the full nice  range of scheduling (-20  to 19).

System administrators can also use the time  command to get an idea of how much time and what proportion of a system’s resources are required for a task, such as a shell script. (Here, time  is used to measure the duration of elapsed time; the command that deals with civil and sidereal time is the date  command.) This command is used with the name of another command (or script) as an argument like this:

# time -p find / -name core -print
/dev/core
/proc/sys/net/core

real 1.20
user 0.14
sys 0.71

Output of the command displays the time from start to finish, along with the user and system time required. Other factors you can query include memory, CPU use, and file system input/output (I/O) statistics. See the time  command’s man page for more details.

Nearly all graphical process-monitoring tools include some form of process control or management. Many of the early tools ported to Linux were clones of legacy UNIX utilities. One familiar monitoring (and control) program is top.

NEWS CONTENTS

Old News ;-)

[Mar 31, 2011] Learn Linux, 101 Process execution priorities

In addition to the top command, you can also display niceness values using the ps command. You can either customize the output as you saw in the article "Learn Linux 101: Create, monitor, and kill processes," or you can just use the -l option to get a long listing. The output of ps -l is shown in Listing 2. As with top, look for the niceness value in the NI column.


Listing 2. Using ps to find niceness
                    
ian@attic4:~$ ps -l
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 S  1000 26502 26501  0  80   0 -  5368 wait   pts/4    00:00:00 bash
0 R  1000 27046 26502  0  80   0 -  1684 -      pts/4    00:00:00 ps


Default niceness

You may have guessed from Listing 1 or Listing 2 that the default niceness, at least for processes started by regular users, is 0. This is usually the case on current Linux systems. You can verify the value for your shell and system by running the nice command with no parameters as shown in Listing 3.


Listing 3. Checking default niceness
                    
ian@attic4:~$ nice
0

Setting priorities

Before we look at how to set or change niceness values, let's build a little CPU-intensive script that will show how niceness really works.

A CPU-intensive script

We'll create a small script that just uses CPU and does little else. The script takes two inputs, a count and a label. It prints the label and the current date and time, then spins, decrementing the count till it reaches 0, and finally prints the label and the date again. This script shown in Listing 4 has no error checking and is not very robust, but it illustrates our point.


Listing 4. CPU-intensive script
                    
ian@attic4:~$ echo 'x="$1"'>count1.sh
ian@attic4:~$ echo 'echo "$2" $(date)'>>count1.sh
ian@attic4:~$ echo 'while [ $x -gt 0 ]; do x=$(( x-1 ));done'>>count1.sh
ian@attic4:~$ echo 'echo "$2" $(date)'>>count1.sh
ian@attic4:~$ cat count1.sh
x="$1"
echo "$2" $(date)
while [ $x -gt 0 ]; do x=$(( x-1 ));done
echo "$2" $(date)

If you run this on your own system, you might see output similar to Listing 5. Depending on the speed of your system, you may have to increase the count value to even see a difference in the times. This script uses lots of CPU, as we'll see in a moment. If your default shell is not Bash, and if the script does not work for you, then use the second form of calling shown below. If you are not using your own workstation, make sure that it is okay to use lots of CPU before you run the script.


Listing 5. Running count1.sh
                    
ian@attic4:~$ sh count1.sh 10000 A
A Wed Jan 20 08:34:16 EST 2010
A Wed Jan 20 08:34:16 EST 2010
ian@attic4:~$ bash count1.sh 99000 A
A Wed Jan 20 08:34:20 EST 2010
A Wed Jan 20 08:34:22 EST 2010

So far, so good. Now let's create a command list to run the script in background and launch the top command to see how much CPU the script is using. (See the previous article "Learn Linux 101: The Linux command line" for a refresher on command lists.) The command list is shown in Listing 6 and the output from top in Listing 7.


Listing 6. Running count1.sh and top
                    
ian@attic4:~$ (sh count1.sh 5000000 A&);top

Listing 7. Using lots of CPU
                    
top - 15:41:15 up 1 day, 17:59,  6 users,  load average: 0.20, 0.06, 0.02
Tasks: 169 total,   2 running, 167 sleeping,   0 stopped,   0 zombie
Cpu(s): 52.1%us,  0.7%sy,  0.0%ni, 47.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   4057976k total,  1393772k used,  2664204k free,   235596k buffers
Swap: 10241428k total,        0k used, 10241428k free,   662592k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
26756 ian       20   0  4004  588  496 R  100  0.0   0:03.53 sh
11220 ian       20   0  555m 101m  27m S    5  2.6  57:58.07 firefox
26757 ian       20   0 19132 1364  980 R    0  0.0   0:00.03 top
    1 root      20   0 19584 1888 1196 S    0  0.0   0:00.89 init
    2 root      15  -5     0    0    0 S    0  0.0   0:00.01 kthreadd

Not bad. We are using 100% of one of the CPUs on this system with just a simple script. If you want to stress multiple CPUs, you can add an extra invocation of count1.sh to the command list. If we had a long running job such as this, we might find that it interfered with our ability (or the ability of other users) to do other work on our system.

Using nice to set priorities

Now that we can keep a CPU busy for a while, we'll see how to set a priority for a process. To summarize what we've learned so far:

The nice command can also be used to start a process with a different priority. You use the -n or (--adjustment) option with a positive value to increase the priority value and a negative value to decrease it. Remember that processes with the lowest priority value run at highest scheduling priority, so think of increasing the priority value as being nice to other processes. Note that you usually need to be the superuser (root) to specify negative priority adjustments. In other words, regular users can usually only make their processes nicer.

To demonstrate the use of nice to set priorities, let's start two copies of the count1.sh script in different subshells at the same time, but give one the maximum niceness of 19. After a second we'll use ps -l to display the process status, including niceness. Finally, we'll add an arbitrary 30-second sleep to ensure the command sequence finishes after the two subshells do. That way, we won't get a new prompt while we're still waiting for output. The result is shown in Listing 8.


Listing 8. Using nice to set priorities for a pair of processes
                   
ian@attic4:~$ (sh count1.sh 2000000 A&);(nice -n 19 sh count1.sh 2000000 B&);\
> sleep 1;ps -l;sleep 10
A Thu Jan 21 14:38:39 EST 2010
B Thu Jan 21 14:38:39 EST 2010
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 R  1000   946     1 99  80   0 -  1001 -      pts/3    00:00:01 sh
0 R  1000   948     1 99  99  19 -  1001 -      pts/3    00:00:01 sh
0 R  1000   952 32408  0  80   0 -  1684 -      pts/3    00:00:00 ps
0 S  1000 32408 32407  0  80   0 -  5368 wait   pts/3    00:00:02 bash
A Thu Jan 21 14:38:45 EST 2010
B Thu Jan 21 14:38:45 EST 2010

Are you surprised that the two jobs finished at the same time? What happened to our priority setting? Remember that the script occupied one of our CPUs. This particular system runs on an AMD Athlon™ 7750 dual-core processor, which is very lightly loaded, so each core ran one process, and there wasn't any need to prioritize them.

So let's try starting four processes at four different niceness levels (0, 6, 12, and18) and see what happens. We'll increase the busy count parameter for each so they run a little longer. Before you look at Listing 9, think about what you might expect, given what you've already seen.


Listing 9. Using nice to set priorities for four of processes
                   
ian@attic4:~$ (sh count1.sh 5000000 A&);(nice -n 6 sh count1.sh 5000000 B&);\
> (nice -n 12 sh count1.sh 5000000 C&);(nice -n 18 sh count1.sh 5000000 D&);\
> sleep 1;ps -l;sleep 30
A Thu Jan 21 16:06:00 EST 2010
C Thu Jan 21 16:06:00 EST 2010
D Thu Jan 21 16:06:00 EST 2010
B Thu Jan 21 16:06:00 EST 2010
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
0 R  1000  1422     1 94  80   0 -  1001 -      pts/3    00:00:00 sh
0 R  1000  1424     1 42  86   6 -  1001 -      pts/3    00:00:00 sh
0 R  1000  1427     1 56  92  12 -  1001 -      pts/3    00:00:00 sh
0 R  1000  1431     1 14  98  18 -  1001 -      pts/3    00:00:00 sh
0 R  1000  1435 32408  0  80   0 -  1684 -      pts/3    00:00:00 ps
0 S  1000 32408 32407  0  80   0 -  5368 wait   pts/3    00:00:02 bash
A Thu Jan 21 16:06:14 EST 2010
B Thu Jan 21 16:06:17 EST 2010
C Thu Jan 21 16:06:26 EST 2010
D Thu Jan 21 16:06:30 EST 2010

With four different priorities, we see the effect of the different niceness values as each job finishes in priority order. Try experimenting with different nice values to demonstrate the different possibilities for yourself.

A final note on starting processes with nice; as with the nohup command, you cannot use a command list or a pipeline as the argument of nice.

Changing priorities

renice

If you happen to start a process and realize that it should run at a different priority, there is a way to change it after it has started, using the renice command. You specify an absolute priority (and not an adjustment) for the process or processes to be changed as shown in Listing 10.


Listing 10. Using renice to change priorities
                    
ian@attic4:~$ sh count1.sh 10000000 A&
[1] 1537
ian@attic4:~$ A Thu Jan 21 16:17:16 EST 2010
sh count1.sh 1renice 1 1537;ps -l 1537
1537: old priority 0, new priority 1
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY        TIME CMD
0 R  1000  1537 32408 99  81   1 -  1001 -      pts/3      0:13 sh count1.sh 100
ian@attic4:~$ renice +3 1537;ps -l 1537
1537: old priority 1, new priority 3
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY        TIME CMD
0 R  1000  1537 32408 99  83   3 -  1001 -      pts/3      0:18 sh count1.sh 100

Remember that you have to be the superuser to give your processes higher scheduling priority and make them less nice.

You can find more information on nice and renice in the man pages.

[Apr 04, 2006] Performance tuning UNIX systems by William B. Zimmerly

"If you carefully tune the processes that run on your workstations and servers, including setting the appropriate task priorities and removing tasks that waste resources, your computers will continue to be the good and faithful servants that they're meant to be."
Apr 04, 2006 | Developerworks

... The operating system's task switcher, also known as the scheduler, is designed to do the following:

  1. Load the context of a task into the Central Processing Unit (CPU) registers.
  2. Let the task run for a short period of time.
  3. Save that context before loading the context of the next task.

The scheduler maintains a number of internal tables to manage the context of every running task in the system. It also manages resources using a pair of queues known as the run queue and the sleep queue. The run queue is where tasks that have all of their resources available are held. The sleep queue is for tasks that are waiting for one or more resources to be available. In general, the scheduler makes sure that the system runs in an orderly, responsive manner.

It's all in the context

Many things make up the context of a running task. When a task runs, there is a CPU register called the instruction pointer (IP) that contains the memory address of the current machine code instruction being executed. When a task is switched out, the task switcher must save the value of that IP register to be able to reload it again later when the task is switched back in. Therefore, part of the context of a task is the current IP value.

Another important value that makes up the context of a task is the stack pointer (SP). The stack is a last-in-first-out (LIFO) queue that holds subroutine return addresses, items of data, pointers, and so on. The meaning of each item held on the stack is determined by the instructions that operate on them, according to the programmer's detailed design.

The IP and SP, along with all of the other important CPU registers that make up the context of the running task, are the low-level details that the task switcher uses to switch contexts and run different tasks. The task switcher also works with higher-level details. One of those higher-level details is the priority of the task.

Priority

All programs are not created equal. Some programs that are critical to the operation of the computer itself must have a higher priority than others that are not so critical. In the UNIX scheme of things, this priority is indicated by a number that can vary from a -20 to a +19 and is known as the nice number of the task. The programs with the highest priority have the lowest nice value, so a value of -20 makes a task important in the UNIX scheme. Contrary to that, a task with a nice value of +19 is a nice, unselfish task that allows all other tasks to have a greater share of the CPU's precious time to run on than itself.

UNIX provides many powerful tools for detailed viewing of what is running on the computer at any time, and the ps command was designed to give you those details. Start an xterm and enter the following command to see how nice the programs are:

$ ps -eo pid,state,nice,args | less -S

The command produces output, as shown in Listing 1 below.


Listing 1. Output
  PID S  NI COMMAND
    1 S   0 init [5]
    2 S  19 [ksoftirqd/0]
    3 S -10 [events/0]
    4 S -10 [khelper]
    5 S -10 [kblockd/0]
   28 S   0 [kapmd]
   30 S   0 [pdflush]
   31 S   0 [pdflush]
   33 S -10 [aio/0]
   32 S   0 [kswapd0]
  138 S   0 [kseriod]
  176 S   0 [kjournald]
 1080 S   0 [kjournald]
 1081 S   0 [kjournald]
 1082 S   0 [kjournald]
 1564 S   0 /sbin/dhclient -1 -q -lf /var/lib/dhcp/dhclient-eth0...
 1610 S   0 syslogd -m 0
 1614 S   0 klogd -x
 1632 S   0 portmap
 1651 S   0 rpc.statd
 1729 S   0 /usr/sbin/sshd
 1744 S   0 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
 1760 S   0 ntpd -U ntp
  .
  .
  .
 2364 S   0 konsole
 2373 S   0 /bin/bash
 2563 R   0 ps -eo pid,state,nice,args

On my workstation, 84 lines were generated. This means that at the time the ps task was running, it was only one of 84 different tasks that were competing for time to run on the CPU. Now examine the parts of this command to better understand what the system is telling you. The -eo pid,state,nice,args switch tells the ps task to list the following information for each task running on the system:

The less command with the -S switch creates a clean, good-looking list by limiting each line in the list to the width of the xterm.

The majority of the tasks have a nice value of "0," putting them right in the middle of the priority range. There are few tasks running with nice numbers that make them high (-10) or low (19) priority. Most of the tasks are also sleeping; that is, they are waiting for some resource to become available. In fact, only the ps command was running when I generated this list. Most tasks are designed to do what they need to do quickly and then exit or sleep.

Nice and renice

The nice command executes a command specified within its argument list with the given nice number. The renice command is used to change the nice number of the task. For command switch details, see the man pages for each command.

renice command

The renice command enables you to alter the priority of currently running processes. The new priority number (the nice number) and the process ID (the PID) are the primary input for the renice command of the program to be changed.

You can renice any of the processes that you own; however, you can only monotonically increase their priority within the range of 0 to 20, whereas only the superuser can renice any currently running process over the full range of nice values.

Two main classes of UNIX computers dominate the horizon: workstations and servers. Each requires careful attention to the processes that run on the machines to ensure their limited resources aren't wasted by repetitively performing tasks that aren't important to their designated purposes.

Workstations

Because workstations can be used for many varied tasks, there are no fixed rules for tuning every workstation. Some workstations are used for programming, graphic artistry, heavy number crunching, and for data mining. In every case, it helps to see what processes are running while you are doing your preferred activity, and then tune your workstation accordingly.

For example, on a programmer's workstation, compiling and linking some programs can take many hours. A programmer who wants to speed it up -- at the expense of everything else -- can become a superuser and then start the compile with the following commands:

$ su
Password:

# nice -n -15 make

The -n -15 parameter lowers the nice number of the make task by 15 -- this increases the priority so much that you can actually feel it when you move the mouse around the screen. On most systems, only the superuser account can make this type of priority change to a task. Nonetheless, for a workstation running a long process, it can be worthwhile.

The administrator of a system can use the configuration file associated with the Linux Pluggable Authentication Modules (PAM) in order to impose resource limits, including a default nice value, on users. This file is known as the limits.conf file and can be found in the /etc/limits or /etc/security directories. Although it is beyond the scope of this article to describe this file in detail, many articles can be found on the Internet describing it.

Briefly, the line ...

@lusers hard priority 5

is the same as running...
nice -n 5

on all processes that the user runs.

There are several other parameters for resource limiting to be found in the limits.conf file, but this covers the default nice value that user processes run with.

Another important way to tune a workstation's performance is to identify features and functions you don't use that might be running on your workstation. For example, many Linux® systems have a file called /etc/cron.daily/slocate.cron that runs the disk-intensive dbupdate program on a daily basis. This program enables you to use the locate command, rather than the find command, to find files. If you never use the locate command, you can edit the /etc/cron.daily/slocate.cron file so the dbupdate program doesn't run by becoming a superuser, starting your favorite editor, and commenting out the instructions, as shown in Listing 2 below.


Listing 2. /etc/cron.daily/slocate.cron file
$ su
Password:

# cd /etc/cron.daily

# vi slocate.cron

Listing 3 indicates how the /etc/cron.daily/slocate.cron file should look after you put the comment character (#) before each line, to prevent it from being executed.

Note: Commenting out each line in this tiny script is a better way to prevent it from running than simply deleting the file. After all, you might change your mind at some future date and want to begin using the slocate command. This will necessitate, allowing the cron task to run the updated program. All you need to do then is delete the comment characters before each line in the file.

Listing 3. File results
#!/bin/sh
# renice +19 -p $$ >/dev/null 2>&1
# /usr/bin/updatedb -f "nfs,proc,devpts" -e "/tmp,/var/tmp,/usr/tmp,/afs,/net"

Remember, this is an issue of personal preference too. If your machine belongs to your employer, I do not suggest making such changes without supervisory permission. After all, the system administrators might want to use the locate command when you're not there.

Servers

Unlike workstations, servers usually have precisely defined purposes and, therefore, are easier to tune. For example, the primary responsibility of a Web server is to receive and satisfy browser requests from the Internet. Similarly, a file server must quickly and accurately dispense the files being requested. In both cases, the server shouldn't have tasks that are normally assigned to workstations.

If a server is dedicated to one primary function, such as a Web server, edit out any other services from the configuration files. Often, a Web server runs the ftp, nfs, dhcp, dns, and other daemons that aren't necessary. The less that a machine must share, the more responsive its primary tasks are. As a bonus, there is also greater security, because there are fewer holes available to hack.

This article provides some general guidelines for tuning server performance. For more specific information, check out the links in the Resources section.

Conclusion

If you carefully tune the processes that run on your workstations and servers, including setting the appropriate task priorities and removing tasks that waste resources, your computers will continue to be the good and faithful servants that they're meant to be.

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Top articles

Sites



Etc

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.  

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 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. www.softpanorama.org 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 softpanorama.org is down you can use the at softpanorama.info

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 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: September 12, 2017