Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)

AIX patching


See also

Redbooks IBM Links Recommended Links  


Patching suma Hardening Security Performance tuning Log administration profile and kshrc
sudo AIX Networking mksysb Command JFS/JFS2 Useful AIX commands smit AIX Networking
aix lvm Snapshots Creating External Snapshots with chfs Command Tips Random Findings Humor Etc

Patch level and/or patches

instfix -ivq
oslevel -rn

Use the lslpp -L command to verify that the patch has been applied.

Automating TLs and service pack deployments with SUMA

The IBM Service Update Management Assistance (SUMA) allows you to automate the retrieval of TL and service pack deployments. In this section, you're going to use SUMA to retrieve TLs. SUMA was first released with AIX V5.3. More than anything, SUMA helps the system administrator automate the retrieval of AIX updates, allowing the administrator to get away from the mundane tasks of manually retrieving updates from the Web. Furthermore, it allows you to configure policies to automatically download either entire TL upgrades, service packs, or even interim fixes. The primary objective of the utility is to allow systems administrators to spend more time on proactive systems administration and less time on redundant or tedious work such as downloading updates.

So, how do SUMAs work? Essentially, they use a scheduling module that allows policies to be run at predefined intervals, which conform to your maintenance window. The policies can be configured easily without any extensive configuration. You even have the option to manually run SUMA (either from smit or the command line) to bring in whatever updates you require. To configure SUMA, you need to know the fix type. There are eight different kinds of fix types. They include APAR, PTF, Critical, Security, I/O Server, Latest (all fixes), Filesets (specific types), and Maintenance Levels. In addition, there are three types of actions you can perform on a policy. These include preview, download, and download and clean. Preview mode does not really do anything; it just generates a preview of what would be downloaded. The "download only" action downloads the actual data, while the "download and clean" action removes filesets no longer necessary after a new fix level has been brought down. This limits the size of the data that you'll need to keep.

You can run the suma command from either smit or the command line. In the first example, use smit to download an entire TL: # smit suma.

When the smit screen comes up, choose Download Updates Now (easy) and click Enter.

From this screen, scroll down to Download Maintenance Level or Technology Level and click Enter (see Figure 2).


At the window in Figure 3, click F4 and choose the appropriate TL level.

In this case, it is 6100-01, as shown in Figure 4.

Figure 4. TL level of 6100-01
Click Enter and let it run. When it completes, you'll see a summary, as shown in Figure 5.

This provides you with the following summary:

Now try it from the command line. In this case, you're going to download TL Two for AIX V6.1. Do this by running the suma -x  command

After about 30 minutes, it completes successfully

The files get installed in /usr/sys/inst.images, which is where you would also manually put them if you were to retrieve them using different processes.

Why is SUMA important? Perhaps most importantly, it helps to ensure that your systems have the latest patches that it needs. Current fixes are important. Secondly, it downloads the patches without intervention, which allows the systems administrator to focus on more important tasks.

Fix Central

This section reviews Fix Central and discusses how to use it to download TL and service pack deployments. Fix Central is the central repository for all TLs and service packs for AIX. Among other things, you'll see how to log into Fix Central and retrieve service packs. Completely revamped in October of 2007, it provides fixes and updates for all your software, hardware, and operating systems. This includes the Hardware Management Console (HMC). Using Fix Central, you can download using the following options: by APAR, Fix ID, or Test. In addition, there are three download options, IBM Download Director, HTTP, and FTP.

Download a service pack from the exact TL that you downloaded previously during the work with suma from the command line -- 6100-02. First go to Fix Central for System p®, as shown in Figure 8 (see Resources for a link to Fix Central).

From here, in the drop-down menu, choose your version. Another drop-down menu pops up, which is where you can select from one of the following: fix packs, fix recommendations, fix search, managing updates, and security advisories. Choose fix pack. Click Continue (see Figure 9).


From here, select the TL: 6100-02. At this time, you can either download the latest service pack or the entire TL. Choose the entire TL (see Figure 10).

The options for download include Download Director, bulk FTP, or CD. In this case, use Download Director. I recommend this method because it has a friendly interface and there is also flexibility to pause downloads.


The length of time is dependent on your Internet connection. For me, on broadband, this took roughly an hour.

As a systems administrator, the Fix Central URL should definitely be one of your browser favorites. Fix Central helps you keep your systems up to date and is the best method of manually retrieving data for your upgrades. You really can't be an effective AIX systems administrator without knowing how to use this tool.

Upgrading a TL

Now review the procedures to upgrade your system to the next TL.

First log in as root: # su - root. Make sure you back up your system. If you prefer, you can also use alt_disk_install or multibios; the bottom line is that you need to have a plan B if you must go back to your prior level. You should also commit them, because they can't be rejected and they also make it easier to track and reject PTFs.

Do a backup using the following command: # mksysb. When the backup is completed, you're set!


Create a .toc file. This is done by running the inutoc command (see Figure 12). You run this in the directory where your filesets reside. If you don't have the .toc file, your update will not work.

Figure 12. Running the inutoc command
Running the inutoc command

When this is completed, you are ready to start the upgrade. Move to the directory where your .toc file resides. If you do this, you will not have to specify a path name during your upgrade: # smit update_all.

On the screen in Figure 13, you will be making several changes.

Figure 13. Update software screen
Update software screen

For Input device/directory for software, put in the dot (.). If you remembered to cd to the directory that has the .toc file, you don't need to specify the full path name. In this case, you did not commit the software, though as a practical matter because you can't back out of a TL upgrade, you really should say yes to limit the amount of filesets stored on your system -- a real disk hog. In this case, you first previewed the data to ensure that there would not be any problems. This is the third option on this smit menu (shown in Figure 13). The preview option does nothing except validate whether something might be missing as a prerequisite of the upgrade. This is good to do to avoid surprises. You don't want to find out something is missing during your two-hour maintenance window of the month. You can run a preview at any time without any impact to the system.

In our case, as you can see in Figure 14, the preview is successful and there are no failures. So you are ready to move on.

Figure 14. Output of the preview
Output of the preview

When you are ready to run the upgrade, change the preview to no. You will also have to change the default field that relates to << Accept new license agreement >>. For some reason, AIX defaults to no. Change it to yes.

After you click Enter, it will prompt you to make sure you want to do this. Click Enter to continue to start the process (see Figure 15).

Figure 15. Start the upgrade process
Start the upgrade process

This can run for up to an hour, depending on the speed of your system and the type of upgrade you are performing. When the process is complete, you can scroll down to the summary section to see if you've been successful, which in this case is yes. (see Figure 16).

Figure 16. Success

Your final step is to reboot the box. Make sure you perform this step before bringing your applications back and going live. After I rebooted the box, I ran the oslevel command to confirm the new system level (see Listing 1).

Listing 1. Confirming the new system level
lpar46ml16fd_pub > # oslevel -s


What does this information signify? It tells that you are running AIX V6 TL2, service pack 1, released in 2008 in the 47th week. The forth field, 0847, indicates the year and week. Finally, it is highly recommended that you apply the latest service pack when moving to the new TL. In our case we did not have to, because the latest pack was already a part of the TL upgrade.

TL upgrade deployment schedule

When should you actually perform a TL upgrade? There are generally three scenarios where you will make this choice:

The short answer is that there really is no right or wrong time to perform an upgrade. Some clients need an environment that requires maximum uptime and stability. These clients typically wait until new TLs are out for at least six months to a year before applying them. Other folks will wait for several TL's to be put into place prior to upgrading to ensure maximum reliability. For clients that like to take advantage of new features and ensure that they have the latest security patches, they typically install new service packs shortly after they come out. From a vendor-support perspective, IBM would prefer if you upgraded your TLs (and service packs, for that matter) as soon as they come out. The reason is that it's just easier to support systems that are always at current levels. I like to upgrade at least once a year to a new TL. In doing so, I will also usually wait until at least service pack number two has been released. If you really want to err on the side of caution, wait until service pack number three. That way, you will know that your release is really rock solid.

IBM - How to check or upgrade AIX firmware level


Old News ;-)

IBM - Service and support strategy best practices for Power systems

patches AIX vs Solaris installation method - Unix Linux Forum -

MJB wrote:

> Hi all,

> I'm looking for some help/advice on patching AIX. We are in the
> process of moving from Sun/Solaris to IBM/AIX. We have a few p5
> servers running 5.3 and I want to make sure the OS stays up to date.
> On Solaris you could just download the latest recommended patch cluster
> from Sunsolve, unzip it and install it.

> How does it work with AIX? I've been to:



You might want to start at .

Maintenance Levels (MLs) were renamed to Technology Levels (TLs). Service Packs (SPs) are fixes on a specific TL. You can download these from the website, order them on CD or use the SUMA tool in AIX.

IBM has a best practices guide for software maintenance

IBM - Service and support strategy best practices for Power systems

Look into SUMA. I don't know how many machines you have to maintain or how you do your provisioning or what not. But we use SUMA on our 520s and it's great. Every night it downloads the latest patches. We have
a set schedule. We install new patches in the applied state, test them, and just run them as applied until testing is complete and it is time to apply a new round of patches. Then we commit all and apply the
new ones. That's an important step.

So give smitty suma a look and see if it helps you out. You will have to do a little work to configure it, but nothing terribly sophisticated. The only information you should need with respect to maintenance levels etc. is your output from oslevel -r.

You may need to use the -c option to suma to add a HTTP_PROXY if you use one. man suma gives good details on this.

IBM Support Fix Central 5300-06 Service Pack 12 for AIX 5.3 operating system

July, 2009

ServiceReport This file is used by the AIX command compare_report to create reports listing filesets on the system that are at a lower level than the latest levels, and those that are at a lower level than the last technology level.

New Security APARs Security updates are initially released as interim fixes to expedite availability. The updates are later repackaged in the same format as generally available AIX updates.

IZ48496 Potential security issue.
IZ50500 Potential security issue.
IZ50503 Potential security issue.
New High Impact for Highly Pervasive APARs

IBM classifies some APARS as HIPER. Installation of packages containing these APARs is highly recommended.

New APARs resolving PEs APARs in the list below are included in this package and resolve problems marked as PE in previous service packs. IZ52944 "GETGRENT_R" ROUTINE CAUSES HEAP CORRUPTION .

All Other New APARs

IZ50510 chdev -a pv=clear causes RDAC disks to become Defined
IZ50511 Cannot read SAS address of SAS DC using AIX command
IZ50512 uelpent CORE dump - Initialization stages
IZ50601 Loss of path if target controller goes offline
IZ50604 Hang in mkuser command
IZ51076 Fixdata for new service pack

AIX Maintenance Strategies

Between regular technology levels, IBM will release service packs, PTFs that are grouped together for easier identification. These fixes will be for highly pervasive, critical, or security related issues and will be released ever 4-6 weeks between technology levels.

Applying the latest level of available updates will move the system to the latest service pack. To see which service pack is currently installed, we have a new command switch: "oslevel -s" . The output for a server/LPAR with AIX 5.3, technology level 4, service pack 2 installed would be:

# oslevel -s

Like maintenance levels, service packs are cumulative, so if service pack 4 is installed, all of the previous critical fixes from service packs 1 through 3 will also be installed.

As you might have guessed, this also means the end of "critical fix packs".

Something completely new is the concluding service pack, which will identify the last service pack on a technology level The CSP will contain fixes for highly pervasive, critical, or security related issues, just like an SP, but it may also contain fixes from the newly released technology level that are highly pervasive, critical, or security related.

The CSP will be available shortly after a new technology level is released. As an example, if technology level 5300-04 is released, the CSP for 5300-03, will be available 4-6 weeks later.

It will have a specific level identifier of "CSP", so the "oslevel -s" command output would be:

# oslevel -s
5300-03-CSP -- patch report in version 5.3I

IBM Support Fix Central Fix packs for AIX 5.3 operating system

AIX updates are provided as Technology Level packages or Service Packs. These generally available updates have been tested to operate best when all updates in a fix pack are installed. IBM recommends installing the complete fix pack. A fix pack is a combination of many single fixes for product components that are dependent on or related on each other. It can include new features, functions, or enhancements.

Service life of AIX 5.3 Technology Levels

Beginning with AIX 5300-06, Technology Levels are supported for approximately two years. End Of Service dates are estimates only. A two year life for a TL is an objective only. All statements regarding

Recommended Links


U.S. DOE-CIAC Bulletins IBM Corp.® -- list of DOE patches

patch level and/or patches

instfix -ivq
oslevel -r

Use the lslpp -L command to verify that this patch has been applied.

emgr Command


Starts the interim fix (interim fix) manager, which installs, removes, lists, and checks system interim fixes.


To list interim fix; data:

emgr -l [ -L Label | -n interim fixNumber | -u VUID ] [-v{1|2|3} ] [ -X ]

To install an interim fix package:

emgr -e interim fixPackage | -f ListFile [-w Directory ] [ -b ] [ -k ] [ -p ] [ -I ] [ -q ] [ -m ] [ -X ]

To remove an installed interim fix:

emgr -r -L Label | -n interim fixNumber | -u VUID | -f ListFile [-w Directory ] [-b ] [ -k ] [ -p ] [ -I ] [ -q ] [ -X ]

To check an installed interim fix:

emgr -c [ -L Label | -n interim fixNumber | -u VUID | -f ListFile ] [ -w Directory ] [-v{1|2|3} ] [ -X ]

To mount or unmount an installed interim fix:

emgr -M | -U [ -L Label | -n interim fixNumber | -u VUID | -f ListFile ] [ -w Directory ] [ -X ]

To force removal of an installed interim fix:

emgr -R interim fixLabel [ -w Directory ] [ -X ]

To view packages locked by interim fix manager:

emgr -P [ Package ] [ -X ]


The emgr (interim fix manager) command can be used to install and manage system interim fixes. The interim fix manager installs packages created with the epkg command and maintains a database containing interim fix information. The emgr command performs the following operations:

Referencing an Efix

The ways to reference an interim fix are as follows:

Reference by Label
Each interim fix that is installed on a given system will have a unique interim fix label. This is the unique key that binds all of the different database objects. To reference an interim fix by label, pass the label as a parameter to the -L flag. For example, to run a check operation on an interim fix with label ABC123, type:
emgr -cL ABC123
Reference by Efix ID
Each interim fix that is installed on a given system has an interim fix ID. The interim fix ID is simply the order number in which the interim fix is listed in the interim fix database. Using this option may be convenient if you are performing operations on interim fixes based on interim fix listings. The emgr command will convert the interim fix ID into an interim fix label before performing the given operation. To reference an interim fix by ID, pass the ID as an parameter to the -n flag.


Efix IDs can change as interim fixes are removed and added. Always verify the current interim fix ID number by using the -l flag to list the specific interim fix or all interim fixes.

For example, to run a check operation on the first interim fix with ID equal to 1, type:

emgr -cn1
Reference by VUID
Because interim fix packages are not formally tracked by any entity, it is possible that the same interim fix label could be used for more than one interim fix package. However, the emgr command does not accept the installation of more than one interim fix with the same interim fix label at the same time. The VUID (Virtually Unique ID) can be used to differentiate packages with the same interim fix label. The emgr command converts the VUID into an interim fix label before performing the given operation. For example, to list an installed interim fix with VUID equal to 000775364C00020316020703, type:
emgr -l -u 000775364C00020316020703

The VUID is displayed in the preview phase of interim fix installation and removal. The VUID is also displayed when listing with verbosity level set to 2 or higher with the -v flag.

Efix Logging

The following operations are logged to the emgr command log file, /var/adm/ras/emgr.log:


-b Causes the emgr command to skip the usual AIX bosboot process for interim fixes that require rebooting.
-c Specifies the check operation. Instructs the emgr command to run a check operation on the specified interim fix or interim fixes.
-e interim fixPackage Specifies the path of the interim fix package file. The interim fix package file must be created with the epkg command and must end with the 16-bit compression extension, .Z.
-f ListFile Specifies a file that contains one of the following:
  • A list of package locations for the installation operation (one per line)
  • A list of interim fix labels for the remove, mount, unmount, and check operations (one per line)

The emgr command ignores any blank lines or lines where the first non-white-space character is the # character.

-I Runs the low-level debugger for AIX bosboot by using the bosboot command's -I flag.
-k Loads the low-level debugger during AIX bosboot using the bosboot command's -D flag.
-l Instructs the emgr command to run the list operation on the specified interim fix or interim fixes.
-L Label Selects the interim fix for this operation by interim fix label.
-m Instructs the emgr command to perform a mount installation. When and interim fix is mount-installed, the interim fix files are mounted over the target files.
-M Instructs the emgr command to mount an interim fix or interim fixes that have been mount-installed by using the -m flag. The -M flag can be used to mount an interim fix that was installed using the -m flag and has been unmounted by the -U flag or by some other means, such as rebooting the system.
-n interim fixID Selects the interim fix for this operation by specifying the interim fix ID.
-p Instructs the emgr command to perform a preview for either installation or removal. The preview runs all of the check operations, but does not make any changes.
-P [ Package ] Specifies the package-view operation, which displays all packages that are locked by the interim fix manager, their installer, and the locking label or labels.
-q Suppresses all output other than errors and strong warnings.
-r Instructs the emgr command to run a remove operation on the specified interim fix or interim fixes.
-R Label Instructs the emgr command to run a force-remove operation. This option removes interim fix data and package locks associated with the interim fix label without actually removing interim fix files, running any remove scripts, or boot processing. This option can be used for only one interim fix at a time. The interim fix label is required to identify the target interim fix.

Attention: This method of interim fix removal should be considered an emergency procedure. Because this method can create inconsistencies on the target system, the force remove method should be used only if all other methods of removing the interim fix are unsuccessful.

-u VUID Selects the interim fix for this operation by specifying the VUID.
-U Instructs the emgr command to unmount an interim fix or interim fixes that have been mount-installed by using the -m flag.
-v{1|2|3} Specifies the verbosity level for the listing operation or the verification level for the check operation. Valid levels are 1, 2, and 3.
-w Directory Instructs the emgr command to use the specified working directory instead of the default /tmp directory.
-X Attempts to expand any file systems where there is insufficient space to perform the requested emgr operation. This option expands file systems based on available space and size estimates that are provided by the interim fix package and the emgr command.


  1. It is possible to exhaust available disk space during an installation even if the -X flag is used. This is more likely if other files are being created or expanded in the same file systems during an installation.
  2. Remote file systems cannot be expanded by the emgr command.

Exit Status

All of the emgr command operations completed successfully.
An error occurred.


Only the root user can run the emgr command. Efix data, saved files, and temporary files are accessible only by the root user.

The emgr command looks for a supported MD5 generating command on the system. If one is located, the emgr command displays the MD5 checksum to the user. The user can then cross check this MD5 sum with a secured source. If an MD5 generating command is not located, the emgr command takes no further action.

The user can force set the path to an MD5 command by exporting the EMGR_MD5_CMD shell variable. This variable should contain the absolute path to the MD5 generating command.


This feature is not supported in the original release of interim fix management. It is recommended that the user updates to the latest level of interim fix management by updating bos.rte.install to the latest level.


  1. To preview the installation of an interim fix package called games.020303.epkg.Z, type:
    emgr -p -e games.020303.epkg.Z
  2. To install the interim fix package called games.020303.epkg.Z and automatically expand file systems if additional space is needed, type:
    emgr -X -e games.020303.epkg.Z
  3. To list all interim fixes on the system, type:
    emgr -l
  4. To do a level 3 listing of interim fix label games, type:
    emgr -lv3 -L games
  5. To remove the interim fix with label games, type:
    emgr -r -L games
  6. To preview the removal of the interim fix labels in file /tmp/myfixes, type:
    emgr -rp -f /tmp/myfixes
  7. To check all interim fixes with verification level 2, type:
    emgr -cv2
  8. To check interim fix ID number 3 with verification level 1 (the default verification level), type:
    emgr -c -n3
  9. To check interim fix with VUID of 000775364C00020316020703 and verification level 3, type:
    emgr -u 000775364C00020316020703 -c -v3
  10. To list all locked packages and their interim fix labels, type:
    emgr -P
  11. To list all interim fix labels that have locked the installp package bos.rte.lvm, type:
    emgr -P bos.rte.lvm
  12. To mount-install the interim fix package called games.020303.epkg.Z and suppress AIX bosboot, type:
    emgr -e games.020303.epkg.Z -mb
  13. To mount all interim fix files that have been mount-installed on the system by using the -m option, type:
    emgr -M
  14. To unmount all interim fix files associated with interim fix label games, type:
    emgr -U -L games


/usr/sbin/emgr Contains the emgr command
/usr/emgrdata/DBS/efix.db Contains the interim fix header database
/usr/emgrdata/DBS/files.db Contains the interim fix files database
/usr/emgrdata/DBS/pkglck.db Contains the package locks database
/usr/emgrdata/DBS/prereq.db Contains the prerequisite database

Related Information

The bosboot command, epkg command.

Interim fix Management in AIX 5L Version 5.3 Installation Guide and Reference.

WSG Resources Unix Security Superglue

Superglue is a tool developed by the CITES Workstation Services Group that helps automate the patching of Solaris and AIX machines.

Although patching is a crucial step in maintaining system security, it can be slow and tedious work, particularly if you maintain several machines. Superglue was designed to take the burden of patching off of the system administrator, making it more likely that patches will be applied regularly. To use Superglue, all you need to do is mount the Superglue directory on your machine and run the program. Superglue takes care of the rest.

OS Superglue mount point

As root:

  1. /sbin/mount -o (mount point) /mnt
  2. /mnt/superglue --this step can take a while depending on number of patches, machine speed, and network speed
  3. /sbin/umount /mnt

Please note that the scheduled maintenance period for the Solaris Superglue server is Tuesdays from 1730-1900 (5:30pm - 7:00pm). We strongly recommend that you plan your system patching activities accordingly.

Superglue is provided on an as-is basis and is not officially supported by CITES. Comments on the service may be sent to

Random Findings

Re: Keeping any up-to-date?

Ciaran Deignan (Ciaran.Deignan@BULL.NET)
Fri, 15 Jan 1999 10:24:03 +0100

On Thu, 14 Jan 1999, Randolf-Heiko Skerka wrote:

> On Mon, Jan 11, 1999 at 09:46:02AM +0000, John RIddoch wrote:
> > To carry on the thread of keeping Solaris patched, I wrote a script to
> > automatically update a systems patches overnight via cron.
> Great work. But are things like that available for other OSes (I´m thinking
> of AIX, HP-UX, CISCO IOS[?] and so on)?

For AIX, Bull has a check tool that verifies that PTFs corresponding to security problems have been installed. The tool is called "bull_check", and is available from (click on "download").

By default it checks for Year2000 PTFs, give it the option "security" to check for security things.

I have a script to automatically download the missing PTFs from the Bull PTF server, if anybody's interested.

Bye Ciaran

Ciaran Deignan Tel: (France) 04 76 29 79 92
BULL XS-BU ( Internet Support Project Leader

Office: C1/012 Bullcom: 229 79 92
Mail to: C1/023 or Fax: 229 76 89

This archive was generated by hypermail 2.0b3 on Fri Jan 15 1999 - 09:48:18 PST



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


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


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


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

Classic books:

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

Most popular humor pages:

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

The Last but not Least

Copyright © 1996-2018 by Dr. Nikolai Bezroukov. was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and 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 make a contribution, supporting development of this site and speed up access. In case is down you can use the at


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

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