Introduction to Sudo (superuser do)

• Introduction
• Minimal usage of sudo and possible alternatives

• Main advantages

• Main components

• Problem of escape to shell

• Sudo vs ACL: overlaying account based permissions using sudo

• Providing wheel group access to root via sudo

• See also

Introduction

One problem with Unix security is not that root is all-powerful, but that regular accounts are not powerful enough to be useful for many common tasks.  One way to solve this Unix problem was sudo, the utility that can grant to non-root account root access on "per-command" basis.  Essentially sudo is a rudimentarily implementation of RBAC (see, for example Solaris RBAC) in a completely portable Unix-flavor independent way.  All problem related to proper structuring of roles are present in sudo, as soon as it is used for anything else then access of root account by non-root but privileged (typically members of Wheel Group) users.

Sudo (superuser do) is an extension of the classic Unix command su (introduced in BSD). It allows a system administrator to work using his own account and switch to root or other user identity available on the system only for commands that need it. In most cases it is used to as "one command switch to root". It also protect system administrators from horrible mistakes that can happen when you work as root all the time. In case you are tired you can do a lot of damage with just one "subconscious" mistake. For example, if you accidentally type rm /etc* instead of rm etc*. See Admin Horror Stories for a overview of typical "horrors" of this time. In other words working in your own account all the time and using sudo prefix when you need to execute commands as root is much safer way of working for sysadmins. Here the value of sudo is undisputable. 

In addition sudo provides logging of commands which you submitted. That also has value when, say, two people administer the same server. Otherwise  to understand what was done by your partner is not easy, as sysadmin typically are in a hurry and seldom completely document their actions. Sometimes people lie and try to hide their mistakes. Here you have some chances to recreate the set of actions of your partner.

Sudo is useful on all version and flavors of Unix, with possible exception of Solaris 10 were native OS mechanisms (RBAC) are superior. For a brief history of Sudo see history section

Sudo is integrated in OpenBSD and Ubuntu and pre-installed on enterprise linux distributions (RHEL and Suse). It is not installed on AIX and HP-UX but it is available in "vendor-precompiled", "vendor-unsupported" form. See

• Sudo on AIX
• Sudo for HP-UX

The great advantage of sudo is that it can (and should) be deployed on all Unix systems under administration (it's pretty simple to deploy if via SSH).  This universal availability is a huge advantage over other similar packages.

The current version as of April 2013 is 1.8.6p8, but most linux distros provide only much older (but adequate) version 1.7.6p2 (called Maintenance release on sudo site).  It's now pretty complex product which is the major deficiency. Security vulnerabilities are periodically discovered and for open source program of such complexity its presence in the system is essentially a free backdoor to root as it is reasonable to assume that for any version there is at lease one unknown zero-day exploit.  There is a great need for simpler and more secure "sudo-light"...

In some organizations and flavors on Linux (such as Ubuntu) root account has password disabled and the only way to access root is via sudo.  This concept is called Rootsudo in Ubuntu

Minimal usage of sudo and possible alternatives

Minimal usage of sudo involves execution of a command as root by prefixing it with the name of program (sudo). For example:

sudo passwd root

The simplest alternative to this functionality is a copy of shell renamed as sudo, set the SUID  attribute  and make it owned by wheel group with the execute permission for group enabled. For example:

cp /usr/bin/bash /root/bin/sudo
chown root:wheel /root/bin /root/bin/sudo
chmod 750 /root/bin
chmod 4710 /root/bin/sudo

In this case you get basic passwordless sudo functionality for wheel group members using standard Unix facilities which is important for "strange" flavors of Unix such as HP-UX where sudo port behaves somewhat strange (AIX, another "strange" Unix has a usable sudo port).

Another rarely used but viable alternative to sudo is ssh. You can try to use ssh with a public key, which provides passwordless login like:

alias sdo='ssh root@localhost '
sdo your_command 

To do this, you must create a public/private key pair for the user who should be allowed to ssh into the root account and then put the public key into root's authorized_keys file. You may restrict this key to execute only by writing

command="yourcommand"

PermitRootLogin yes

Disadvantage (which you may consider to be an advantage as well) is that this passwordless connection to the local host will reinitializes your environment each time you use the command .

Main advantages

Sudo popularity emerged not accidentally. It has several advantages, representing, in essence, a minimal implementation of RBAC for Unix. Among them:

• The simplification of delegation of root. In large enterprises one of the important (and time consuming) services that Unix group usually provides is to set a temp root password on one or several boxes so that application administrator can perform some operations which require root access. Unless those temp passwords are random, communication of temp root password creates a vulnerability due to which an intelligent person can access root account on other systems that were converted for temp root. For example, this is the case if temp password is created using some formula that contains as a part server name (for example prefix) and a random string (as a suffix). In case of sudo you can use automatic remote enrollment of user into particular group (wheel or sysadmin, depending on flavor of Unix used) and do not even need to communicate anything to the user; he/she get the ability to become root from his account using the command sudo su -  or by prefixing commands by sudo. In the latter case commands are written to syslog which simplify troubleshooting.

  SSH, OpenView or Tivoli TCM permit changing of group membership for the wheel group on selected servers with a single command. That means that instead of time consuming operation you enroll the person who need temporary root access to a group of servers in no time. What is very important you can automatically provide deenrollement after the requested period is over: just schedule at command that remove the person from the group at the end of agreed period. This eliminates another important vulnerability when temporary passwords became new permanent as administrator does not keep track of the servers with temp password and expiration periods. Deletion is done automatically when the period expires by the command scheduled beforehand. Otherwise this operation requires human action of resetting password back, and this the operation that more often then is performed later then in due time.
   

• Audit trail for all attempts to switch to root both successful and unsuccessful. That tremendously help in troubleshooting, especially as is typical for large enterprise environment when there are multiple cooks (aka sysadmins ;-) in the kitchen and typically the left hand does not know what right hand is doing.
   
• Logging of commands, prefixed by sudo, providing a clear audit trail of "who did what." When used in tandem with remote syslogd, sudo can log all commands to a central loghost (as well as on the local host). Please note the for AIX you need to enable syslog first.
   
• Simplification of switching to root for administrators. Sudo can be configured in such a way that members of wheel group do not need additional authentication to became the root. Especially if regular logins have two factor authentication (via SecurID or Smartcards). That saves time and troubles of remembering multiple root passwords, if you need to administer multiple systems (or a creation of a security vulnerability if such password are constructed using a pre-defined formula; intelligent users can soon get this "secret" and use it to their own advantage to cut red tape).

  Ubuntu goes one step further. By default, the root account password is locked in Ubuntu. This means that you cannot login as root directly. However, since the root account physically exists it is still possible to sudo to root and to run programs with root-level privileges.
  

• Prevention of costly mistakes. The main value of sudo for sysadmins is that it helps to prevent some really horrible things that often happen when you work as root and do something in a hurry. With sudo you can try to execute command as a regular user but if permissions are inadequate and command fails repeat it as root using shortcut sudo !!. And that's probably the best part of its usefulness. In most cases that all administrator needs so long (and dangerous) sessions of using root account for trivial operations can be eliminated. If passwords for regular accounts are one time (e.g. reasonably secure as is the case if SecurID or similar one-time password system is used) this is a very attractive solution. Please remember that a lot of systems were destroyed by administrators using some badly though out command as root without proper testing. See Admin Horror Stories
  
• Possibility to grant "read-only" access to certain files. From this point of view this capability of granting command access is most useful for providing a "read-only" and "re-write" assess to some root owned files by granting usage of explicit cat (or cp in case of re-write access) commands for selected files, or other simple commands with explicit arguments (not vi or other commands with the possibility escaping to command shell). But even this is dangerous and this privilege can be abused. If cp command granted, the wrapper can be provided in which to modification of the first copy it to user own  own directory, then editing proceed without privileges and then another cp command puts the file back. With ACLs this implementation of capability is simpler and more transparent.
  
• Possibility to grant only selected commands executed with extended privileges to certain users. Suse is definitely not RBAC, but some functionality similar to RBAC can be imitated by granting access to several command (for example the ability to start and stop particular application server). The command should be unable to escape to shell and be simple enough to exclude this possibility (it is a bad idea to grant the ability to execute find command as root for obvious reasons) Compete specification of arguments usually is required to prevent attempts to use the command as a "universal root opener". While definitely useful for restarting daemons and some similar actions this is not a RBAC and you should keep such assignments simple. Excessive zeal here really hurts. The alternative is using one command accounts like shutdown and restart, where the logging with password executes the required command. This might be more convenient for operators.
   
• "Time ticketing" system. When a user invokes sudo and enters their password, they are granted a ticket for 5 minutes (this timeout is configurable at compile-time). Each subsequent sudo command updates the ticket for another 5 minutes. This gives some level of protection in situation where there is a danger of accidentally leaving a root shell where others can physically get to your keyboard. While certainly annoying for everyday use, this is a useful facility for critical boxes.

Main components

Conceptually sudo is a really simple package that unfortunately grow too complex with time. It consist of just three utilities (sudo, visudo and sudoreplay) and a single configuration file /etc/sudoers. I would recommend to pay a special attention to  sudoreplay as it provides the functionality of automatic logging of your commands and then converting them into a script the can be replayed on other servers.

1. sudo(8) command: setuid root wrapper that users invoke to execute commands as root (or other privileged account).
   
2. /etc/sudoers. This is a key configuration file which can also be located in /etc/sudo or /usr/local/etc directory. It is sudo's roles definition file specifying who may run what commands as which user. It is fully documented in sudoers(5). See also a good into in Gentoo Sudo(ers) Guide
   
3. visudo(8) command allows administrators to edit the sudoers file without risking locking themselves out of the system.
   
4. sudoreplay  plays back or lists the session logs created by sudo. When replaying, sudoreplay  can play the session back in real-time, or the playback speed may be adjusted (faster or slower) based on the command line options.

   List sessions run by user millert:

    sudoreplay -l user millert

   List sessions run by user bob with a command containing the string vi:

    sudoreplay -l user bob command vi

   List sessions run by user jeff that match a regular expression:

    sudoreplay -l user jeff command '/bin/[a-z]*sh'

   List sessions run by jeff or bob on the console:

    sudoreplay -l ( user jeff or user bob ) tty console

Sudo is distributed under a BSD-style license and currently maintained by Todd Miller. The current homepage is http://www.courtesan.com/sudo/

Problem of escape to shell

Like in any complex security program the security record of sudo itself is questionable and there were several exploitable vulnerabilities in different versions; also like with many other open source programs, it looks like there is not much development discipline: capability of the program grows non-stop without much architectural vision, evaluation of the return on the investment and general security of code. As a result the current version is far from being a simple elegant tool it used to be. It has just too many options, keys etc. Some recent enhancements probably were not necessary and mainly increased the complexity of the codebase. Contrary to common perception sudo does not really provide for a role structuring facility similar to RBAC: any assignment of a capability to execute a complex command capable of executing other commands (or invoke shell) without envelope that checks and fixes arguments (for example find or ex) essentially means conversion of this "restricted" account into backdoor for the root, if this command is executed as root. Some of those escapes to shell can be blocked via Sudo noexec  option.

Sudo vs ACL: overlaying account based permissions using sudo

Sometimes sudo is used to accomplish tasks related to access to specific command and files which also can be  accomplished via ACLs. For example ACLs is preferable for granting read or write access to specific set of files for particular user. But sudo can restrict command to specific arguments, which ACLs can't do.

In both case you essentially create additional hidden infrastructure on top of regular Unix permissions. With sudo this infrastructure is even less visible then in case of ACLs.  As such those capabilities should be deployed only as "the last option" when Unix groups facilities can't help.

Still, if we are talking about fixed, static commands such an approach is permissible. But granting a "read-only" and "re-write" assess to some root owned files by granting usage of explicit cat (or cp in case of re-write access) commands for selected files is a bad solution. This problem should be solved using either standard Unix groups or, if standard Unix groups are insufficient with ACLs.

Also you need to remember that even static commands can represent a security hole if they can escape to shell and usage of noexec option is a much in all such cases.  But even this is dangerous and this protection can be broken and the privilege can be abused.

Sudo is great when cases of usage are simple and limited to few users. As soon as sudoer file become complex this complexity sooner or later  can byte you unless it is structures as a repetition of the same relatively simple grants for different users. 

One needs clearly understand that granting a user the right to run any command with shell escapes like "vi" or "find" as root is equivalent to granting root access. Actually granting to users, who are not system administroars the ability to execute any command with root privileges without strict control of arguments is dangerous and prome to abuse.

Restricting execution capabilities of regular user account is mostly useless: the problem is not excessive capabilities of regular account, but the lack of thereof. But it does make sense for applications. Applications are a different beast and here sudo can and should be useful if you cannot use restricted shell, chroot or similar things:

Defaults syslog_goodpri=alert

# Cmnd alias specification
Cmnd_Alias DNS = /var/dss/vinamed.boot, /var/dss/vidb.root, /usr/bin/kill - HUP *
Cmnd_Alias MAILCMDS = /usr/local/bin/aliases, /usr/local/bin/qlist, /usr/local/bin/qlist2, /usr/local/bin/qreport, /usr/local/bin/qreport2, /usr/local/bin/qdelete, /usr/local/bin/qdelete2, /etc/rc3.d/S88sendmail
Cmnd_Alias MONITORCMDS = /etc/rc3.d/S88sendmail, /usr/bin/su - pmx4 *

MAIL ALL= MAILCMDS
monitor ALL=(ALL) NOPASSWD: MONITORCMDS

Providing wheel group access to root via sudo

As I mentioned before the first really elegant sudoer configuration is as simple as:

%wheel ALL = (ALL) ALL 

where the wheel group consist of all administrators. In this case anytime sysadmins need to execute command as root he/she just prefix it with sudo. This is actually an imitation of the BSD wheel group functionality and what is really nice that it can be accomplished on any flavor of Unix although a PAM-based implementation is better on those systems were it is available (Solaris, Linux).

In Solaris this is useful only for compatibility in multi-Unix enterprise environment and the group used probably should be not the wheel group but sysadmin group. The latter has additional capabilities not dissimilar to BSD wheel group (in Solaris this is the ability to change attributes of files via Admintool).

%sysadmin ALL = (ALL) ALL

%operator ALL = NOPASSWD: /usr/bin/su operator

Actually this part of sudo functionality can be easily implemented without sudo using additional copy of /bin/sh (sudo can used as the name of the copy) with permissions 4550 and owned by root:wheel or in Solaris root:sysadmin. It provides probably 80% of sudo usefulness in preventing root role "overstaying" for administrators with access to the root role (assuming that all of them are members of the group wheel or sysadmin). This solution lacks logging and other nice features provided by sudo, but it does avoid sudo overcomplexity. In certain cases when adding software to the server is prohibited, it can serve as a "poor man sudo" and it might help to avoid risks connected with root role "overstaying" as well as potential security holes inherent in the current version of sudo with all its complexity.

Here are some additional examples from the sudo manual:

Since the sudoers file is parsed in a single pass, order is important. In general, you should structure sudoers such that the Host_Alias, User_Alias, and Cmnd_Alias specifications come first, followed by any Default_Entry lines, and finally the Runas_Alias and user specifications. The basic rule of thumb is you cannot reference an Alias that has not already been defined.

Below are example sudoers entries. Admittedly, some of these are a bit contrived. First, we define our aliases:

 User_Alias     FULLTIMERS = millert, mikef, dowdy
 User_Alias     PARTTIMERS = bostley, jwfox, crawl
 User_Alias     WEBMASTERS = will, wendy, wim

 Runas_Alias    OP = root, operator
 Runas_Alias    DB = oracle, sybase

 Host_Alias     SPARC = bigtime, eclipse, moet, anchor :\
                SGI = grolsch, dandelion, black :\
                ALPHA = widget, thalamus, foobar :\
                HPPA = boa, nag, python
 Host_Alias     CUNETS = 128.138.0.0/255.255.0.0
 Host_Alias     CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0
 Host_Alias     SERVERS = master, mail, www, ns
 Host_Alias     CDROM = orion, perseus, hercules

 Cmnd_Alias     DUMPS = /usr/bin/mt, /usr/sbin/dump, /usr/sbin/rdump,\
                        /usr/sbin/restore, /usr/sbin/rrestore
 Cmnd_Alias     KILL = /usr/bin/kill
 Cmnd_Alias     PRINTING = /usr/sbin/lpc, /usr/bin/lprm
 Cmnd_Alias     SHUTDOWN = /usr/sbin/shutdown
 Cmnd_Alias     HALT = /usr/sbin/halt
 Cmnd_Alias     REBOOT = /usr/sbin/reboot
 Cmnd_Alias     SHELLS = /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
                         /usr/local/bin/tcsh, /usr/bin/rsh, \
                         /usr/local/bin/zsh
 Cmnd_Alias     SU = /usr/bin/su
 Cmnd_Alias     PAGERS = /usr/bin/more, /usr/bin/pg, /usr/bin/less

Here we override some of the compiled in default values. We want sudo to log via syslog(3) using the auth facility in all cases. We don't want to subject the full time staff to the sudo lecture, user millert need not give a password, and we don't want to reset the LOGNAME, USER or USERNAME environment variables when running commands as root. Additionally, on the machines in the SERVERS Host_Alias, we keep an additional local log file and make sure we log the year in each log line since the log entries will be kept around for several years. Lastly, we disable shell escapes for the commands in the PAGERS Cmnd_Alias (/usr/bin/more, /usr/bin/pg and /usr/bin/less).

 Defaults               syslog=auth
 Defaults>root          !set_logname
 Defaults:FULLTIMERS    !lecture
 Defaults:millert       !authenticate
 Defaults@SERVERS       log_year, logfile=/var/log/sudo.log
 Defaults!PAGERS        noexec

The User specification is the part that actually determines who may run what.

 root           ALL = (ALL) ALL
 %wheel         ALL = (ALL) ALL

We let root and any user in group wheel run any command on any host as any user.

 FULLTIMERS     ALL = NOPASSWD: ALL

Full time sysadmins (millert, mikef, and dowdy) may run any command on any host without authenticating themselves.

 PARTTIMERS     ALL = ALL

Part time sysadmins (bostley, jwfox, and crawl) may run any command on any host but they must authenticate themselves first (since the entry lacks the NOPASSWD tag).

 jack           CSNETS = ALL

The user jack may run any command on the machines in the CSNETS alias (the networks 128.138.243.0, 128.138.204.0, and 128.138.242.0). Of those networks, only 128.138.204.0 has an explicit netmask (in CIDR notation) indicating it is a class C network. For the other networks in CSNETS, the local machine's netmask will be used during matching.

 lisa           CUNETS = ALL

The user lisa may run any command on any host in the CUNETS alias (the class B network 128.138.0.0).

 operator       ALL = DUMPS, KILL, SHUTDOWN, HALT, REBOOT, PRINTING,\
                sudoedit /etc/printcap, /usr/oper/bin/

The operator user may run commands limited to simple maintenance. Here, those are commands related to backups, killing processes, the printing system, shutting down the system, and any commands in the directory /usr/oper/bin.

 joe            ALL = /usr/bin/su operator

The user joe may only su(1) to operator.

 pete           HPPA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

The user pete is allowed to change anyone's password except for root on the HPPA machines. Note that this assumes passwd(1) does not take multiple usernames on the command line.

 bob            SPARC = (OP) ALL : SGI = (OP) ALL

The user bob may run anything on the SPARC and SGI machines as any user listed in the OP Runas_Alias (root and operator).

 jim            +biglab = ALL

The user jim may run any command on machines in the biglab netgroup. sudo knows that ``biglab'' is a netgroup due to the '+' prefix.

 +secretaries   ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser

Users in the secretaries netgroup need to help manage the printers as well as add and remove users, so they are allowed to run those commands on all machines.

 fred           ALL = (DB) NOPASSWD: ALL

The user fred can run commands as any user in the DB Runas_Alias (oracle or sybase) without giving a password.

 john           ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*

On the ALPHA machines, user john may su to anyone except root but he is not allowed to give su(1) any flags.

 jen            ALL, !SERVERS = ALL

The user jen may run any command on any machine except for those in the SERVERS Host_Alias (master, mail, www and ns).

 jill           SERVERS = /usr/bin/, !SU, !SHELLS

For any machine in the SERVERS Host_Alias, jill may run any commands in the directory /usr/bin except for those commands belonging to the SU and SHELLS Cmnd_Aliases.

 steve          CSNETS = (operator) /usr/local/op_commands/

The user steve may run any command in the directory /usr/local/op_commands/ but only as user operator.

 matt           valkyrie = KILL

On his personal workstation, valkyrie, matt needs to be able to kill hung processes.

 WEBMASTERS     www = (www) ALL, (root) /usr/bin/su www

On the host www, any user in the WEBMASTERS User_Alias (will, wendy, and wim), may run any command as user www (which owns the web pages) or simply su(1) to www.

 ALL            CDROM = NOPASSWD: /sbin/umount /CDROM,\
                /sbin/mount -o nosuid\,nodev /dev/cd0a /CDROM

Any user may mount or unmount a CD-ROM on the machines in the CDROM Host_Alias (orion, perseus, hercules) without entering a password. This is a bit tedious for users to type, so it is a prime candidate for encapsulating in a shell script.

Some points for the large enterprise environment the advantages of deploying SUDO (based on article: Sudo at a VERY LARGE site) are as following:

• Unlike RBAC, sudo is portable (RBAC now is implemented in Solaris and AIX 6.1) and supports just about every UNIX flavor out there. Compiles pretty much out of the box (but read the docs!)
• rdist can be used used to push executables and /etc/sudoers configuration file across all servers
• SCCS or CVS can used to track changes to sudoers
• Access to root account without need to know root password
• NOPASSWD option is useful for batch processes and applications.
• Better logging is real help. Logs on each machine ... and then send to central log. Modify your syslog.conf as appropriate. Sudo audit logs quite handy (who/what happened/changed?).
• Several audit/analysis tools available from sudo community
• Some stats:
  • 18,916 sudo (root type) actions in DOMAIN for the month of March/1997
  • 2,813 on HOST1, 1,226 on HOST2, 594 on HOST3, etc.
  • 1,250 for SA1, 1080 for SA2, 892 for Alek, etc.
  • 261 "su root`s" ... necessary at times, but still too many IMHO (What did they do?)
• To get a good idea of what sudo can do, you really need to take a look at a sample sudoers file.

See also

• News
• Recommended Links
• Sudo on AIX
• Sudo for HP-UX

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