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

Solaris Packages

News See also Recommended books Recommended Links Bulk Installation
Checking Installed Packages Package Installation Uninstalling Packages Making New Packages Tips
pkgadd man pkgrm  man pkgchk  man pkgadm man admintool man
pkginfo     Humor Etc

All the software distributed as part of Solaris by Sun is released in package format. This includes all the standard shells and command sets. Packages clearly emerge as the preferred way of distributing software on Solaris specifically due to the following features:

It is possible to convert RPM to Solaris packages.

The most commonly used package management commands are:

Here is a list of typical commands used :

There are also several command that permit creation of  your own custom packages or modification of existing packages:

In addition, it is possible to use the admintool as a frontend to these commands. Installing packages using admintool has some advantages. Using admintool, you can:

Package files are text files, meaning that an editor or similar text display program can view their contents. For example, if we downloaded a package for the Apache web server, we could verify its origin by examining its headers:

$ head apache-1.3.12-sol8-sparc-local 
# PaCkAgE DaTaStReAm
SMCapache 1 5392
# end of header
VENDOR=Apache Group
[email protected]
Here, we can see that [email protected] (Steve Christiansen, the maintainer of the site), created this Apache 1.3.12 archive for the SPARC platform. Following the header material are the actual archived files themselves, packed serially by the pkgmk command.

Checking Installed Packages

The pkginfo command can be used to list all of the packages currently installed on a system:

# pkginfo | more
system IPLTadcon Administration Server Console
system IPLTadman Administration Server Documentation
system IPLTadmin Administration Server
system IPLTcons Console Client Base
system IPLTdscon Directory Server Console
system IPLTdsman Directory Server Documentation
system IPLTdsr Directory Server (root)
system IPLTdsu Directory Server (usr)
system IPLTjss Network Security Services for Java
system IPLTnls Nationalization Languages and Localization Support
system IPLTnspr Portable Runtime Interface
system IPLTnss Network Security Services
system IPLTpldap PerLDAP
application NSCPcom Netscape Communicator
application SMCbash bash
application SMCmc mc
application SMCvnc vnc
system SUNW1251f Russian 1251 fonts
system SUNW1394 Sun IEEE1394 Framework
system SUNW1394h Sun IEEE1394 Framework Header Files
ALE SUNW5xmft Traditional Chinese (BIG5) X Window

This target system has a number of system and application packages already installed, including SUNWadmap (system administration applications) and bash, the Bourne again shell (GNUbash), respectively.

Package Installation

Packages can be added easily by using the pkgadd command. Continuing with the example of the Apache file, we would use the following command to install it on a target system:

# /usr/sbin/pkgadd -d apache-1.3.6-sol7-sparc-local

Once the headers have been processed, the following message is displayed:

The following packages are available:
  1  SMCapache     apache (sparc) 1.3.12

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 

Typing Enter or 1 here will install the SMCapache package:

Processing package instance <SMCapache> from </tmp/apache-1.3.12-sol8-sparc-local>

(sparc) 1.3.12
Apache Group
Using </usr/local> as the package base directory.
## Processing package information.
## Processing system information.
   1 package pathname is already properly installed.
## Verifying disk space requirements.
## Checking for conflicts with packages already installed.
## Checking for setuid/setgid programs.

Installing apache as <SMCapache>

## Installing part 1 of 1.
[ verifying class <none> ]

Installation of <SMCapache> was successful.

This is the idealized example. Realistically, pkgadd often asks you to confirm various parameters and/or changes that it needs to install the software correctly. For example, if a directory already exists, and an attribute change needs to be made, you would encounter the following:

## Checking for conflicts with packages already installed.
The following files are already installed on the system and are being
used by another package:
* /usr/local/apache <attribute change only>

* - conflict with a file which does not belong to any package.

Do you want to install these conflicting files [y,n,?,q] 

Typing y will make the attribute change as requested, and installation will continue as normal.

After processing package and system information, and checking that the required amount of disk space is available, the pkgadd command copies all files from the archive to the local filesystem.

Uninstalling Packages

Packages can be removed from a system at any time with the pkgrm command. Before uninstalling a package, it's wise to ensure that no processes are using any of the files contained in the package, by using the ps and lsof commands. To remove the SMCapache package we installed earlier, use the following command:

bash-2.03# pkgrm SMCapache

The following package is currently installed:
   SMCapache       apache
                   (sparc) 1.3.12

Do you want to remove this package? y

## Removing installed package instance <SMCapache>
## Verifying package dependencies.
## Removing pathnames in class <none>
/usr/local/apache <non-empty directory not removed>
## Updating system information.

Removal of <SMCapache> was successful.

Making New Packages

See also solaris-pkg your own software

Making new packages is not as easy as installing or removing them. You need to create a specification for how an archive is to be built (called a prototype file), by using the pkgproto command, before using the pkgmk command to actually build the package. Reviewing the headers of the Apache package file earlier showed us some of the material that needs to be specified before building a package, such as the vendor's name, as well as the email address of the builder. This material needs to be included in a pkginfo file. Here's a list of the most commonly used parameters that can be specified in the pkginfo file:


The architecture (sparc or intel) for which the package is designed


The target directory into which the files will be unpacked


The archive type (system or application)


The contact details for the package builder


The package name


The name of the package builder


The creator of the software being archived


The release level of the software which is to be packaged

Once the pkginfo and prototype files have been created, it's very easy to build a package using pkgmk. In the following example, we're going to create an archive of the Borland Application Server 4.5 ( This step would usually occur in a production environment once all the various XML configuration files have been created and localized, and the service tested. Creating a package at this stage allows a baseline restoration to be made easy if (for example) a hard disk becomes corrupt, or a backup server needs to be bought online to meet with increased demand from users.

The pkginfo file should define all the necessary parameters (such as ARCH, BASEDIR, and CATEGORY), which were outlined previously. For the Borland Application Server, these elements would look like this:

NAME="Borland App Server"
EMAIL="[email protected]"
PSTAMP="Paul Watters"

We can interpret these entries in the following way:

Once the pkginfo file is created, we should use the following command to create the prototype file:

bash-2.03# touch prototype

Next, we need to specify the location of the pkginfo file, by inserting the following line into the prototype file:

i pkginfo=/usr/local/borland/bas45/pkginfo

In the base installation directory specified in the pkginfo file, you can use the following command to generate a list of relative pathnames and files that is then piped through the pkgproto command. The output is then appended to the prototype file:

bash-2.03# find . -print | pkgproto >> prototype 

We should then be able to examine the contents of the newly constructed prototype file:

bash-2.03# head /usr/local/borland/bas45/prototype
i pkginfo=/usr/local/borland/bas45/pkginfo
f none install.idb 0644 bas borland
d none bin 0775 bas borland
f none bin/JdsExplorer 0775 bas borland
f none bin/JdsExplorer.config 0775 bas borland
f none bin/JdsServer 0775 bas borland
f none bin/JdsServer.config 0775 bas borland
f none bin/jdbce 0775 bas borland
f none bin/jdbce.config 0775 bas borland
f none bin/jsql 0775 bas borland
f none bin/jsql.config 0775 bas borland

Every file (f) and directory (d) underneath the root directory is represented by a unique entry in the prototype file. This includes details of the user and group who own the file, as well as the permissions currently set on the file (specified in octal format).

If you wish to change some of the properties specified within the prototype file, you can use vi to search and replace entries before running the pkgmk command. For example, if we want to change the group membership of the files from borland to inprise, we use the following substitution command:


After the prototype file has been modified to your satisfaction, create the package with the following command:

bash-2.03# pkgmk -o -r /usr/local/borland/bas45
## Building pkgmap from package prototype file.
## Processing pkginfo file.
## Attempting to volumize 986 entries in pkgmap.
part  1 -- 8997 blocks, 986 entries
## Packaging one part.

The files to be packaged have been transferred to the /var/spool/pkg/BAS_LOCAL directory at this point. Next, you simply need to use the pkgtrans command to bundle the files into a single archive file:

bash-2.03# pkgtrans -s /var/spool/pkg /backup/BAS_LOCAL.pkg

The following packages are available:
  1  BAS_LOCAL    Borland Application Server
                  (sparc) 4.5

Select package(s) you wish to process (or 'all' to process
all packages). (default: all) [?,??,q]: 

After typing 1, the package file /backup/BAS_LOCAL.pkg will be created.

Top Visited
Past week
Past month


Old News ;-)

[Nov 26, 2006] BigAdmin Feature Tech Tip Introduction to Package Components for the Solaris OS

Each Solaris package is represented as a directory that has the same name as the package. The package contains many files and directories out of which only pkginfo and pkgmap are mandatory. All other items shown in the figure are optional.

The pkginfo and pkgmap files are meta-information files. The pkginfo file acts like a label on a box. It contains information such as name, identifier, build date, who to contact if there's a problem, and so on.

The pkgmap file is a packing list, where each item in the package is defined and its size and checksum are stored. The size and checksum help in determining that the package has not been tampered with. The various items in the pkgmap are recognized by their ftype entry as shown here.

ftype Entries
ftype Description
d directory
x exclusive directory (package specific)
p named pipe
c character special
b block special
s symbolic link
f executable or data file
e editable file
v volatile file (content may change)
l linked file
i meta-file

When a package is installed (using pkgadd), first directories (d), devices (c/b), and symlinks (s) are created. Then the files of type f, e, or v are copied into the file system. Hard links (ftype l) are created after all the other files have been installed. The install meta-files (ftype i) are used to direct the installation and removal of software and are not installed on the system.

A Solaris package typically contains reloc and install directories. The reloc directory contains all the files that are to be installed relative to a base directory, i.e. it contains the relocatable files. An optional root directory contains files that are to be installed relative to the root directory. Another optional directory called archive may also be present, which contains general-purpose files whose functions are defined by the package developer. The install directory contains scripts and other auxiliary files. All files of ftype i except pkginfo and pkgmap go into install.

The install directory contains a copyright file, an optional depend file, and scripts like checkinstall, preinstall, postinstall, preremove, and postremove. This directory may also contain a set of some special scripts known as Class Action Scripts. All the meta-info files are Bourne shell scripts.

The checkinstall script performs a detailed analysis of the system and gathers data; it doesn't change anything on a file system. The script may create or alter environment variables to control the installation. The script can cleanly halt the package installation, if necessary.

preinstall runs just before the actual file installation begins. This script is involved in things such as initializing the prototype and meta-files for the backout package, which will be constructed later by the postinstall script.

If a package is removed (using pkgrm), the preremove and postremove scripts, if present, run before and after the removal of the package to do some tasks like deleting the contents of some directories.

All the objects in a package fall under some class that is defined during package creation. If an object doesn't fall under any class, none class is used by default. All the classes to be installed are listed in the parameter CLASSES, which is defined in the pkginfo file. The installation occurs in the order they are listed in pkginfo. Objects with class none are always installed first. So none, if present in pkginfo, is always the first class entry. If a class isn't listed in the pkginfo, the objects in that class won't get installed even if they are defined in pkgmap.

Class Action Scripts (CAS) redefine how to add or remove an object from the package. That is, instead of a simple copy of files from the package to the appropriate file system, CAS may allow merging entries with an existing file, or saving a copy of an existing file. The Class Action Scripts work similarly during removal of a package. The install and removal Class Action Scripts are named i.<class> and r.<class>, respectively, for <class>. Files with ftype e and v are expected to have Class Action Scripts.

All the dependencies that a package might have on other packages are listed in the depend file.

As mentioned previously, pkginfo and pkgmap are the only required files in a package. One can create a package with just these two files. Such a package is perfectly acceptable, though it doesn't provide any important functionality per se.

Solaris packages can also be delivered in Package Datastream format. In this format there is a file containing one or more packages. This file is different from the directory format explained previously, which had one directory containing a package. Package datastreams are easier to distribute. We can convert from one format to another using pkgtrans.

Let's look at an example that shows how to collect information about an installed package. Here's how to find out the name of the package that contains truss utility:

# pkgchk -lp /usr/bin/truss 
Pathname: /usr/bin/truss
Type: linked file
Source of link: ../../usr/lib/isaexec
Referenced by the following packages:
Current status: installed

The output for the preceding command shows that truss is in the package SUNWtoo. Let's get some information about this package:

# pkginfo -l SUNWtoo
      NAME  :  Programming Tools
  CATEGORY:  system
      ARCH   :  sparc
   VERSION:  11.10.0,REV=2005.
   BASEDIR:  /
    VENDOR:  Sun Microsystems, Inc.
      DESC:  utilities for software development, including ld, ldd, od, and truss
    PSTAMP:  on10-patch20060622130233
  INSTDATE:  Sep 07 2006 14:10
   HOTLINE:  Please contact your local service provider
    STATUS:  completely installed
     FILES:       66 installed pathnames
                  11 shared pathnames
                   3 linked files
                  15 directories
                  30 executables
                1993 blocks used (approx)

Additional Resources

More detailed information about packages can be found in the Application Packaging Developer's Guide.

[Dec 5, 2001] Various Solaris package and patch commands


Below is a random list of commands / ways of doing things under Solaris
I've picked up while installing stuff on the Sun box.

o List patches applied:
    # patchadd -p

o To apply a patch
    Untar the patch tar.Z
    # patchadd <dir>

o To add a package
    # pkgadd -d <package file>

o To add a package in tar format
    # tar xvfz package.tar.Z
    # pkgadd -d .

  This will ask you which packages in the
  current directory you wish to install.

o To remove a package
    # pkgrm <package>

o To get info on a package
    # pkginfo -x <package>
    # pkginfo -l <package>

o To list all installed packages
    # pkginfo

o To find out which package a file is in
    # grep <file> /var/sadm/install/contents

o To find out what files are in a package
    # grep <package> /var/sadm/install/contents

o To find out what runlevel you're in
    # who -r

Recommended Links

Google matched content

Softpanorama Recommended

Top articles


Phil Brown's Solaris page Interesting Solaris scripts and advices, including the very nice pkg-get "one-shot" install script (automates download and install procedures for SVr4 packages)

Creating Solaris Packages

SUN Solaris packages Application Packaging Developer's Guide

Sys Admin Magazinev08, i12 Using Solaris Packages

Relocating Solaris packages

Converting Solaris Packages for -usr-local Use


PkgTools is a set of utilities, released under the BSD license, which can be used to aid in the development of native Solaris packages - i.e. in the pkg format.

MGMG Articles:

Solarpack Related links

How to Make A Solaris package SolarisInstallDB - Manages Solaris package information

Using Dialogs to Embed or Edit a Solaris Package

Mike Kruckenberg's Experiences and Observations New Approach to Building Solaris Packages

RPM-for-Unix HOW-TO Convert RPM to Solaris Package rpm2pkg

Downloading and Installing Packages

Carefully follow the download - uncompress - install steps below:

Download When downloading a file, make sure you are saving in binary (not text) mode. Check that the filesize matches the size listed above after downloading.

Uncompress First unzip the package file. This creates a file without the .zip extension. This is a package "datastream" file, which is suitable for installation by pkgadd. For example,

Note: If you are running an old version of Solaris (2.5.1 or earlier), you may not have unzip, download unzip for Solaris from here for SPARC or here for Intel/x86. Rename the unzip program as "unzip" and make it executable:
chmod +x unzip

Install Become root (login or su -). Change to the directory containing the package. Use /usr/sbin/pkgadd to install packages after they are uncompressed. For example,
pkgadd -d fortune-off-5.2-i86pc-solaris5.7

Use "pkginfo -l to verify the package is isntalled. For example, pkginfo -l fortune The files you installed from the package are listed at the end of file /var/sadm/install/contents to list information about the pac

Problems? If you have problems, see Steven Christensen's excellent Download and Installation Instructions and Package FAQ.

If you want to ask a question go to the Solaris On Intel mailing list or alt.solaris.x86 USENET newsgroup for Intel/x86 problems or comp.unix.solaris USENET newsgroup for Solaris (Sparc or Intel) problems.

Bulk Solaris Packages Installation

One should create a list of packages to install to the server. for example the following are a resonable subset:

The question arise how to install them with minimal hassle. there are generally three approaches to the problem:

Auto Installation of Solaris Packages

Feel free to use more recent version if they are available. To install the packages you first need to unzip them and then issue the following commands:

su root
pkgadd -d gzip-1.3.5-sol8-sparc-local
pkgadd -d tar-1.13.19-sol8-sparc-local
pkgadd -d top-3.5beta12.5-sol8-sparc-local
pkgadd -d gcc-3.0.3-sol8-sparc-local
pkgadd -d binutils-2.11.2-sol8-sparc-local
pkgadd -d zlib-1.1.4-sol8-sparc-local
pkgadd -d perl-5.8.0-sol8-sparc-local
pkgadd -d cvs-1.11.5-sol8-sparc-local

We've added a lot of software to the system and we need to ensure that the additional programs and libraries can be found. To do this we need to edit /etc/profile (System wide) or $HOME/.profile (User specific). Whichever file(s) you decide to edit you should ensure that they contain the following lines:-

export PATH

Note: Each users has there own .profile file located in their default directory. By default each of these files defines their own PATH variable with a hardcoded directory list (i.e. /usr/local/bin is not included). Your options are:- 1) To manually add /usr/local/bin to the PATH declaration in .profile, or, 2) To edit .profile and change the PATH definition so that it takes into account the existing paths.

When you issue a "su root" command the paths are reset and /usr/local/bin is no longer included. To set the default path for the su command it is necessary to edit /etc/default/su. Simply search this file for "SUPATH=" and insert /usr/local/bin immediately following the "=" Make sure you insert a Colon ":" between /usr/local/bin and any existing directories.

Note: If the "SUPATH=" declaration was commented out then simply remove the "#" character.

What I often have to do is install a whole bunch of packages onto a new machine, (or domain on an Enterprise system), and if I had to do it manually, even with the benefit of a script to unpack each package tgz file, it'd take a lot of time. (Not as much time as compiling and installing all the files on each machine, but when you have to install all the files on a lab of 20 new machines, half an hour each makes for a long tedious day This way you can rcp out the scripts and the files, fire off the install scripts in parallel and then go chat to the cute new girl/guy).

What one can do is have a simple shell script which installs all of the packages you want, plus a special file which tells pkgadd to not ask you any questions and to just install the packages as is.

Here is a shell script to install a group of packages automatically:

#!/bin/sh -x
umask 000
/usr/bin/tar -xvvf GNUzip.1.2.4.SPARC.Solaris.2.6.pkg.tar
/usr/sbin/pkgadd -d. -a noask GNUzip
rm -rf GNUzip
/usr/local/bin/gunzip -c GNUbison.1.25.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUbison
rm -rf GNUbison
/usr/local/bin/gunzip -c GNUcvs.1.9.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUcvs
rm -rf GNUcvs
/usr/local/bin/gunzip -c GNUflex.2.5.4a.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUflex
rm -rf GNUflex
/usr/local/bin/gunzip -c GNUgcc.2.8.1.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUgcc
rm -rf GNUgcc
/usr/local/bin/gunzip -c GNUgdb.4.16.SPARC.Solaris.2.6.pkg.tgz | /usr/bin/tar -xvvf -
/usr/sbin/pkgadd -d. -a noask GNUgdb
rm -rf GNUgdb

You can see the pkgadd line has a -a noask option. This tells pkgadd to refer to the noask file when it reaches a point in the package installation where it needs to ask a question. The noask file essentially tells pkgadd to skip any checks and just go ahead. Since I've made all the packages I am installing, I know how the system will look after the bulk installation, and that suits me just fine.

The noask file contains:


Below is a perl script to build another script which will do the bulk install for you. It relies on some conventions in the package name that don't always apply. For instance it will use the first word in the large package file to attempt to pkgadd the packge. E.g. when GNUbison.1.28.SPARC.Solaris.2.6.pkg.tgz is added to the system the package name to add is GNUbison. This is true for 95% of the packages. However some packages have names that won't fit into the nine character limit on package names so they have been 'crunched' up, or it made sense to call the package something else. E.g GNUghostscript installs as GNUghoscr and fvwm installs as fvwm2.

How does this affect the script below? Not too much since it automatically checks to see if the guessed at package installed. If it didn't, then it doesn't delete the files afterwards. If you don't actually want to have your big package files deleted after installation then remember to modify the script first.

Note: You need to manually add GNUzip and perl onto your system first.

Here is is:

# Program : mkbulkinstaller
# Author : Mark <[email protected]>
# Date : 27th December 1999
# Purpose : Generate package bulk installation script
open(NOASK, ">noask");
print NOASK "mail=\n";
print NOASK "instance=overwrite\npartial=nocheck\nrunlevel=nocheck\n";
print NOASK "idepend=nocheck\nrdepend=nocheck\nspace=nocheck\n";
print NOASK "setuid=nocheck\nconflict=nocheck\naction=nocheck\n";
print NOASK "basedir=default\n";

opendir(DIR, ".");
@files = readdir(DIR);

open(OUTPUT, ">bulkinstall");
print OUTPUT "#!/bin/sh -x\n";
print OUTPUT "umask 000\n";

# The pkgname is usually right 95% of the time. If the name is different then
# you will have to manually add the package.

foreach $file (@files) {
next if ($file !~ /\.pkg\.tgz$/);
print OUTPUT "/usr/local/bin/gunzip -c $file | /usr/bin/tar -xvvf -\n";
$pkgname = $file;
$pkgname =~ s/\..*//;
print OUTPUT "/usr/sbin/pkgadd -d. -a noask $pkgname\n";
print OUTPUT "if [ \$? -eq 0 ]; then\n";
print OUTPUT " /bin/rm -rf $file\n";
print OUTPUT "fi\n";
print OUTPUT "/bin/rm -rf $pkgname\n";
chmod(0755, "bulkinstall");
chmod(0644, "noask");


Get all suid files from the /var/sadm/install/contents database:

grep "[46][0-9][0-9][0-9] root" /var/sadm/install/contents | wc -l

To what package the file /usr/bin/ls belongs:

pkgchk -lp /usr/bin/ls



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