May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Wheel Group

/ home / Authentication


Groups administration

Recommended Books

Recommended Links

Root account controls






Suse Security

Red Hat security

Solaris 10  (RBAC) SecurID



BSD Unix invented wheel group as a special system group for users who can assume the role of root (switch to root using su or sudo). AIX has similar notion of sugroups.  Solaris has sysadmin group (group 14) that is allowed to change permissions of files that user does no own. Generally Solaris 10  RBAC permits much flexible arrangement then wheel group and can be considered as a generalization of this concept.  

Two PAM modules pam_require and  pam_wheel  can provide functionally for establishing the role of wheel group similar to BSD.  It can include ability to su to root without authentication without using sudo. 

Ssh usually made exempt from SecurID, but telnet, ftp and r-services (if they are installed) can benefit form being able to limit the userspace for this protocol.

Similar role can be played by several other linux PAM modules, for example pam_listfile ( authenticate users based on the contents of a specified file  or ) but this is less elegant as you need to create and maintain the list, which  duplicates wheel group. At the same time it is very valuable for control of certain protocols, like ftp.

Examples below are based on Suse 10. Please note that this module is not used by default in SLEC but is available in OpenSuse 10.2 and can copied to SLES. 

In Linux it is usually located at /lib/security/ or /lib64/security/

The PAM file that needs to be modified is /etc/pam.d/su

auth sufficient
auth required
auth include common-auth
account include common-account
password include common-password
session include common-session
session optional

For example:

auth     sufficient
auth     required root_only
auth     include        common-auth
account  include        common-account
password include        common-password
session  include        common-session
session  optional


Top Visited
Past week
Past month


Old News ;-)

[Oct 31, 2007] Darwish Unix Thoughts ... June 2007

03- Let only users set on /etc/security/access.conf be able to login (assuming they already passed the above stacked rules).
In /etc/security/access.conf:
# Accept `root' and `ahmed' logins only (till the system go mainstream)
In /etc/pam.d/common-account:
account required

[Oct 31, 2007] pam_wheel question

Under RH 6.2 (pam 0.72) I was able to set up su such that only users in the wheel group were able to su to root, but anyone could su to other unprivledged accounts. Now on my 7.1 (pam 0.75) box, if I enable pam_wheel in su, it prevents everyone from using su unless they are in the wheel group instead of just allowing su to root by wheel group
members. Here is my su config for the 7.1 box:

auth sufficient /lib/security/
# Uncomment the following line to implicitly trust users in the "wheel"
#auth sufficient /lib/security/ trust use_uid debug
# Uncomment the following line to require a user to be in the "wheel"
auth required /lib/security/ use_uid debug
auth required /lib/security/ service=system-auth
account required /lib/security/ service=system-auth
password required /lib/security/ service=system-auth
session required /lib/security/ service=system-auth
session optional /lib/security/

And here is the config from my 6.2 box where it works as I want it to:

# The next two lines require a user to be in group "wheel" in order to
su to root.
auth sufficient /lib/security/ debug
auth required /lib/security/ group=wheel
auth required /lib/security/ shadow nullok
account required /lib/security/
password required /lib/security/
password required /lib/security/ shadow use_authtok
session required /lib/security/
session optional /lib/security/

My question is, how do I get the same funtionality under 7.1?



[Oct 31, 2007] The Answer Guy 55 Remote Login as 'root' Don't do it! (Except using SSH or ...)

From michael.rees on Wed, 07 Jun 2000

Hi, Sorry to bother you but could you help me with the following??

i am running red hat linux 6.1 and am encountering some problems i can login as root from the console but not from anywhere else

i have to login as webmaster on all other machines on ntwk

from nowhere, including the console, can i su once logged in as webmaster

any help would be appreciated

Regards, Michael

Your system is enforcing a very reasonable policy by preventing direct 'root' logins from over the network.
The best way to circumvent this policy is to use one of the implementations of SSH (the original SSH by Tatu Ylonen, now owned and commmercially available from DataFellows Inc, or OpenSSH --- which is ironically at a .com rather than a .org domain, or the GPL'd lsh at
Any of these should allow you to access your system through cryptographically secured authentication and session protocols that protect you from a variety of sniffing, spoofing, TCP hijacking and other vulnerabilties that are common using other forms of remote shell access (such as telnet, and the infamous rsh and rlogin packages).
If you really insist on eliminating these policies from your system you can edit files under /etc/pam.d that are used to configure the options and restrictions of the programs that are compiled against the PAM (pluggable authentication modules) model and libraries. Here's an example of one of them (/etc/pam.d/login which is used by the in.telnetd service):
# The PAM configuration file for the Shadow `login' service
# NOTE: If you use a session module (such as kerberos or NIS+)
# that retains persistent credentials (like key caches, etc), you
# need to enable the `CLOSE_SESSIONS' option in /etc/login.defs
# in order for login to stay around until after logout to call
# pam_close_session() and cleanup.

# Outputs an issue file prior to each login prompt (Replaces the
# ISSUE_FILE option from login.defs). Uncomment for use
# auth       required issue=/etc/issue

# Disallows root logins except on tty's listed in /etc/securetty
# (Replaces the `CONSOLE' setting from login.defs)
auth       requisite

# Disallows other than root logins when /etc/nologin exists
# (Replaces the `NOLOGINS_FILE' option from login.defs)
auth       required

# This module parses /etc/environment (the standard for setting
# environ vars) and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# (Replaces the `ENVIRON_FILE' setting from login.defs)
auth       required

# Standard Un*x authentication. The "nullok" line allows passwordless
# accounts.
auth       required nullok

# This allows certain extra groups to be granted to a user
# based on things like time of day, tty, service, and user.
# Please uncomment and edit /etc/security/group.conf if you
# wish to use this.
# (Replaces the `CONSOLE_GROUPS' option in login.defs)
# auth       optional

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on logins.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account    requisite

# Uncomment and edit /etc/security/access.conf if you need to
# set access limits.
# (Replaces /etc/login.access file)
# account  required

# Standard Un*x account and session
account    required
session    required

# Sets up user limits, please uncomment and read /etc/security/limits.conf
# to enable this functionality.
# (Replaces the use of /etc/limits in old login)
# session    required

# Prints the last login info upon succesful login
# (Replaces the `LASTLOG_ENAB' option from login.defs)
session    optional

# Prints the motd upon succesful login
# (Replaces the `MOTD_FILE' option in login.defs)
session    optional

# Prints the status of the user's mailbox upon succesful login
# (Replaces the `MAIL_CHECK_ENAB' option from login.defs). You
# can also enable a MAIL environment variable from here, but it
# is better handled by /etc/login.defs, since userdel also uses
# it to make sure that removing a user, also removes their mail
# spool file.
session    optional standard noenv

# The standard Unix authentication modules, used with NIS (man nsswitch) as
# well as normal /etc/passwd and /etc/shadow entries. For the login service,
# this is only used when the password expires and must be changed, so make
# sure this one and the one in /etc/pam.d/passwd are the same. The "nullok"
# option allows users to change an empty password, else empty passwords are
# treated as locked accounts.
# (Add `md5' after the module name to enable MD5 passwords the same way that
# `MD5_CRYPT_ENAB' would do under login.defs).
# The "obscure" option replaces the old `OBSCURE_CHECKS_ENAB' option in
# login.defs. Also the "min" and "max" options enforce the length of the
# new password.

password   required nullok obscure min=4 max=8

# Alternate strength checking for password. Note that this
# requires the libpam-cracklib package to be installed.
# You will need to comment out the password line above and
# uncomment the next two in order to use this.
# password required retry=3 minlen=6 difok=3
# password required use_authtok nullok md5
This is from my Debian laptop ( and thus has far more comments (all those lines starting with "#" hash marks) than those that Red Hat installs. It's good that Debian comments these files so verbosely, since that's practically the only source of documentation for PAM files and modules.
In this case the entry that you really care about is the one for '' This module checks the file /etc/securetty which is classically a list of those terminals on which your system will allow direct root logins.
You could comment out this line in /etc/pam.d/login to disable this check for those services which call the /bin/login command. You can look for similar lines in the various other /etc/pam.d files so see which other services are enforcing this policy.
This leads us to the question of why your version of 'su' is not working. Red Hat's version of 'su' is probably also "PAMified" (almost certainly, in fact). So there should be a /etc/pam.d/su file that controls the list of policies that your copy of 'su' is checking. You should look through that to see why 'su' isn't allowing your 'webmaster' account to become 'root'.
It seems quite likely that your version of Red Hat contains a line something like:
# Uncomment this to force users to be a member of group root
# before than can use `su'. You can also add "group=foo" to
# to the end of this line if you want to use a group other
# than the default "root".
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
auth       required
Classically the 'su' commands on most versions of UNIX required that a user be in the "wheel" group in order to attain 'root' The traditional GNU implementation did not enforce this restriction (since rms found it distasteful).
On my system this line was commented out (which is presumably the Debian default policy, since I never fussed with that file on my laptop). I've uncommented here for this example.
Note that one of the features of PAM is that it allows you to specify any group using a command line option. It defaults to "wheel" because that is an historical convention. You can also use the module on any of the PAMified services --- so you could have programs like 'ftpd' or 'xdm' enforce a policy that restricted their use to members of arbitrary groups.
Finally note that most recent versions of SSH have PAM support enabled when they are compiled for Linux systems. Thus you may find, after you install any version of SSH, that you have an /etc/pam.d/ssh file. You may have to edit that to set some of your preferred SSH policies. There is also an sshd_config file (mine's in /etc/ssh/sshd_config) that will allow you to control other ssh options).
In generall the process of using ssh works something like this:
  1. Install the sshd (daemon) package on your servers (the systems that you want to access)
  2. Install the ssh client package on your clients (the systems from which you'd like to initiate your connections).
  3. Generate Host keys on all of these systems (normally done for you by the installation).
.... you could stop at this point, and just start using the ssh and slogin commands to access your remote accounts using their passwords. However, for more effective and convenient use you'd also:
  1. Generate personal key pairs for your accounts.
  2. Copy/append the (public) keys from each of your client accounts into the ~/.ssh/authorized_keys files on each of the servers.
This allows you to access those remote accounts without using your passwords on them. (Actually sshd can be configured to require the passwords AND/OR the identity keys, but the default is to allow access without a password if the keys work).
Another element you should be aware of is the "passphrases" and the ssh-agent. Basically it is normal to protect your private key with a passphrase. This is sort of like a password --- but it is used to decrypt or "unlock" your private key. Obviously there isn't much added convenience if you protect your private key with a passphrase so that you have to type that every time you use an ssh/slogin or scp (secure remote copy) command.
ssh-agent allows you to start a shell or other program, unlock your identity key (or keys), and have all of the ssh commands you run from any of the descendents of that shell or program automatically use any of those unlocked keys. (The advantage of this is that the agent automatically dies when you exit the shell program that you started. That automatically "locks" the identity --- sort of.
There are alot of other aspects to ssh. It can be used to create tunnels, through which one can use all sorts of traffic. People have created PPP/TCP/IP tunnels that run through ssh tunnels to support custom VPNs (virtual private networks). When run under X, ssh automatically performs "X11 forwarding" through one of the these tunnels. This is particularly handy for running X clients on remote systems beyond a NAT (IP Masquerading) router or through a proxying firewall.
In other words ssh is a very useful package quite apart from its support for cryptographic authentication and encryption.
In fairness I should point out that there are a number of alternatives to ssh. Kerberos is a complex and mature suite of protocols for performing authentication and encryption. STEL is a simple daemon/client package which functions just like telnetd/telnet --- but with support for encrypted sessions. And there are SSL enabled versions telnet and ftp daemons and clients.
Another issue where I talked a bit about crypto software available for Linux:
Another issue where I answer questions about remote root logins:

[Oct 31, 2007] msg00007 pam_wheel

Subject: pam_wheel
List-id: Pluggable Authentication Modules <>
Hey all, I have users that need root access to their workstations. Reading the pam documentation for the pam_wheel module it sounds like I can allow them to 'su -' without entering a password. This is ideal because I don't want to give them that root password, i'd rather keep that to myself. Problem is, it doesn't work. I'm using red hat 7.2. Here is the contents of /etc/pam.d/su:
auth       sufficient   /lib/security/
# Uncomment the following line to implicitly trust users in the "wheel" group.
auth       sufficient   /lib/security/ trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth       required     /lib/security/ use_uid
auth       required     /lib/security/ service=system-auth
account    required     /lib/security/ service=system-auth
password   required     /lib/security/ service=system-auth
session    required     /lib/security/ service=system-auth
session    optional     /lib/security/
Here is output from the id command as a user:
uid=976(jabagley) gid=100(users) groups=100(users),0(root),98(ident)
when 'su -' is entered, i am prompted for a password. Did I missunderstand the pam documentation? what is wrong?

James Bagley                    |           CDI Innovantage
james_bagley@xxxxxxxxxxxxxxx    | Technical Computing UNIX Admin Support
   DON'T PANIC                  |       Agilent Technologies 

[Oct 31, 2007] zSeries_EPA_STD_CONFIG

You MUST restrict authentication to services that are explicitly specified. The 'other' fallback
MUST be disabled by specifying the module for each module-type in the 'other'
configuration. This ensures that access decisions within the PAM system are handled only by the
service specific PAM configuration.

You MUST add the module to the 'auth' module type configuration for the 'su'
service and specify the 'trusted' group.

Sample /etc/pam.d/su File
File: /etc/pam.d/su
auth sufficient
auth required use_uid group=trusted
auth required
auth required onerr=fail no_magic_root
account required
account required no_magic_root # deny=5 reset
password required
session required

Forcing the root user to change the root password is not desired here, therefore the
module is absent.

Novell SUSE LINUX 10.1 pam

-rwxr-xr-x 1 root root 7088 Apr 23 03:03 /lib64/security/

eric's extremeboredom " Blog Archive " wheel group in linux

" RainBeware of the garbage can "wheel group in linux
So I was wondering if I could set "su" to only allow users in the "wheel" group to su to root like with BSD. I never thought I'd be lucky enough to find another reason why Richard Stallman (the hippy who started the FSF) is an idiot in the process.

The man page pointed me to the info page, which had a very, um, intresting bit of text at the bottom..

Why GNU `su' does not support the `wheel' group

(This section is by Richard Stallman.)

Sometimes a few of the users try to hold total power over all the
rest. For example, in 1984, a few users at the MIT AI lab decided to
seize power by changing the operator password on the Twenex system and
keeping it secret from everyone else. (I was able to thwart this coup
and give power back to the users by patching the kernel, but I wouldn't
know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual
`su' mechanism, once someone learns the root password who sympathizes
with the ordinary users, he or she can tell the rest. The "wheel
group" feature would make this impossible, and thus cement the power of
the rulers.

I'm on the side of the masses, not that of the rulers. If you are
used to supporting the bosses and sysadmins in whatever they do, you
might find this idea strange at first.
So this is how I understand what he is saying:

We have bob, mary, and joe all as members of the "wheel" group, all who have the root password.
Bob gets pissed off because someone symlinked vim to emacs and changes the root password, not telling anyone else what it is.
Jack (standard user, not in wheel group) somehow finds the password from bob, but is unable to do anything because he is not in the wheel group
Everyone is screwed
So lets see, if a non-admin user somehow gets the root password we dont WANT him logging into root. If they dont understand how to administer a unix box they'll most likely end up running 'rm -rf /'. Assuming bob removed all users but himself from the wheel group, if the require-wheel feature was disabled then Jack could supposedly tell one of the legitamate administrators what the password is so they could regain control of the system, but how likely is it that Mr. pissed off Bob would tell Jack the password unles he had good reason, which would most likely imply that he trusted him not to turn against him. And if bob added Jack himself to the wheel group Jack could just log into his account, and call over an admin to su to root and take care of the situation. I just dont see how this weighs up.

Addionally, he totally ignores the fact that this command is now used on many production buisness servers. In these situations you are much more worried about your users (or intruders) gaining root access than a discruntle employee. I would accept the feature being turned off by default, but not including it for this reason? Come on.

Fortunetly, I found theres a PAM module written by one of the friendly RedHat folks that adds wheel checking support.

Add the following lines to /etc/pam.d/su:

auth required /lib/security/ use_uid

The readme for the pam_wheel module is avaliable here.

And if you're REALLY parinoid, check out the new SELinux features in Kernel 2.6 which allows you to get rid of the whole concept of a superuser alltogether.

This entry was posted on Friday, April 30th, 2004 at 8:29 pm and is filed under Rants, Computers & Technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.


Kdzhao03-15-02, 10:51
Hi, From a book, I see it mentioned that we can use the "wheel" group to
restrict those users who can su to root.(as below). However, is that for
Solaris? I tried to add the "wheel" group but seems no use. By the way, I also
did not see the /etc/ttytab file on my system (what is this file about?). Anyone
has any idea on this?

My current way to limit people who can su to root is to modify the
"/usr/bin/su" so that only group member can exec it, others can not. Is there
any better way on it?



Limit who can become root by using the "wheel" group in the /etc/group
file. If the wheel group is empty, anyone can switch user (su) to root if they know
the password. However, if there are any entries in the wheel group, only those
users listed can su to root. This stops an unauthorised user who happens to learn
the root password from becoming root. However, if someone does know the root
password, they still will be able to log in directly as root if the /etc/ttytab
file is not configured correctly. In the /etc/ttytab file, change the field
"secure" to "unsecure" for all entries. This forces all
users to login as an ordinary user then su to root and /etc/ttytab can now work in
conjunction with the wheel group to control access to root. Another advantage of
forcing users to su to root is it leaves a better audit trail of who has performed
system administrator actions.


John D Groenveld03-15-02, 10:51
In article <[email protected]>, kdzhao
<[email protected]> wrote:
> My current way to limit people who can su to root is to modify the "/usr/bin/su"
> so that only group member can exec it, others can not. Is there any better way
> on it?

As you discovered, the wheel group does not exist in Solaris 2. group:comp.unix.solaris su wheel

The best way to limit su access is not to give the root password away. If you need to
delegate sys admin functions, read about sudo and RBAC. John [email protected]


Greg Andrews03-15-02, 10:51
[email protected] (kdzhao) writes:
> From a book, I see it mentioned that we can use the "wheel" group to restrict
> those users who can su to root.(as below). However, is that for Solaris?

No. The book was written for a BSD type of Unix operating system. SunOS 4.x (commonly
called "SunOS", though Sun included it in Solaris 1.1 and 1.2) was a BSD Unix, but
it's quite old now.

SunOS 5.x is what people usually call "Solaris". It is an SVR4 type Unix, which does
not use the wheel group.

+++++ Greg Andrews +++ [email protected] +++++ I have a map of the United States that's
actual size -- Steven Wright


Simon Burr03-15-02, 10:51
In <[email protected]> [email protected]
(kdzhao) writes:
> From a book, I see it mentioned that we can use the "wheel" group to restrict
> those users who can su to root.(as below)

This is fairly standard on BSD stuff; however Solaris is mainly based around SVR4
(System V, Release 4) so the stuff isn't going to work exactly as described below. If
you do want to implement this then you can do the following:

o Add the wheel group to the system:
# groupadd wheel

o Change the permissions of su so that only root and people in the wheel group can
execute it:
# chown root:wheel /usr/bin/su chmod 4550

o Add allowed users to the wheel group by adding the usernames to the end of the
wheel entry in /etc/group, ie: Original entry (where GID is the numeric group id):
wheel::GID: With users foo, bar and baz added to the wheel group:

You can also use a PAM module to enforce this; you can get the code for the PAM
module from:

Simon the stressed [email protected] "Our company name changes
so often we have to use plain mugs and PostIt notes"


Alan Coopersmith03-15-02, 14:02
[email protected] (kdzhao) writes in alt.solaris.x86:
| From a book, I see it mentioned that we can use the "wheel" group
|to restrict those users who can su to root.(as below). However, is |that for
Solaris? I tried to add the "wheel" group but seems no use. |By the way, I also did
not see the /etc/ttytab file on my system (what |is this file about?). Anyone has any
idea on this?

Sounds like your book covers BSD and not Solaris. If you want to implement group
wheel on Solaris, search on for pointers in comp.unix.solaris to
Casper Dik's PAM module for doing this.

The CONSOLE field in /etc/default/login is the Solaris equivalent to the ttytab
functionality you described.

04-01-2002, 12:10 AM
Note: this document is written in reference to Red Hat Linux 6.2+

PAM (Pluggable authentication module) is very diverse in the types of modules it provides. One could accomplish many authentication tasks using PAM. However PAM expands itself beyond typical authentication programs, as it allows an admin to employ other system-critical features such as resource limiting, su protection, and TTY restrictions. Much of PAM's features are not within the scope of this document, but for further reading you can refer to the links at the bottom of this document.

Firstly we must enable the pam_limits module, inside /etc/pam.d/login. Add the following to the end of the file:

session required /lib/security/

After adding the line above, the /etc/pam.d/login file should look something like this:

auth required /lib/security/
auth required /lib/security/ service=system-auth
auth required /lib/security/
account required /lib/security/ service=system-auth
password required /lib/security/ service=system-auth
session required /lib/security/ service=system-auth
session optional /lib/security/
session required /lib/security/

The limits.conf file located under the /etc/security directory can be used to control and set resource policies. limits.conf is well commented and easy to use - so do take the time to skim over its contents. It is important to set resource limits on all your users so they can't perform denial of service attacks with such things as fork bombs, amongst other things it can also stop 'stray' server processes from taking the system down with it.

It is also a good idea to separate rules for users, admins, and other (other being everything else). This is important, cause take for instance a scenario where a user fork bombs the system - it could in effect disable an administrator's ability to login to the system and take proper actions, or worse crash the server.

Below is the default policy used on a server iv configured:

# For everyone (users and other)
* hard core 0
* - maxlogins 12
* hard nproc 50
* hard rss 20000

# For group wheel (admins)
@wheel - maxlogins 5
@wheel hard nproc 80
@wheel hard rss 75000

#End of file

The first set of rules say to prohibit the creation of core files - core 0 , restrict the number of processes to 50 - nproc 50, restrict logins to 12 - maxlogins 12, and restrict memory usage to 20MB - rss 20000 for everyone except the super user. The the later rules for admins, say to restrict logins to 5 - maxlogins 5, restrict the number of processes to 80 - nproc 80, and restrict the memory usage to 75MB - rss 75000.

All the above only concerns users who have entered via the login prompt on your system. The asterisk (*) defines all users and at wheel (@wheel) defines only users in group wheel. Make sure to add your administrative users into the wheel group (this can be done in /etc/group).

Finally edit the /etc/profile file and change the following line:

ulimit -c 1000000

to read:

ulimit -S -c 1000000 > /dev/null 2<&1

This modification is used to avoid getting error messages like 'Unable to reach limit' during login. On newer editions of Red Hat Linux, the later ulimit setting is default.

Further reading is available in The Linux-PAM System Administrators' Guide located at:

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites Knowledgebase

The Answer Guy 55 Remote Login as 'root' Don't do it! (Except using SSH or ...)




The pam_wheel PAM module limits the users who can become the root user based on the original users' group memberships. Groups of users can be implicitly trusted or explicitly distrusted based on the combination of options (described below) that are specified when pam_wheel is configured.

The following options are supported:


su auth sufficient
su auth required
su auth required



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 Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

Copyright © 1996-2021 by Softpanorama Society. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

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

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

You can use PayPal to to buy a cup of coffee for authors of this site


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