Building RPMs

RPM concept is somewhat similar to self-installable archive popular in DOS world and available in all major archivers, such a RAR.  It is more structured and more tunes to software installation. Every RPM package has a package label, which contains the following pieces of information:

• the software name
• the software version (the version taken from original "upstream" source of the software)
• the package release (the number of times the package has been rebuilt using the same version of the software). This field is also often used for indicating the specific distribution for example "fc4" (Fedora Core 4), "rhl9" (Red Hat Linux 9), "suse100" (SUSE Linux 10.0) etc.
• the architecture the package was built for (i386, i686, athlon, ppc, etc.). RPM files with the noarch.rpm extension refer to files which do not depend on a certain computer's architecture. These files usually include graphics and text for another program to use, and sometimes programs written in an interpreted programming language, such as Python programs and shell scripts.

RPM file names normally have the following format:

<name>-<version>-<release>.<architecture>.rpm

For example:

nano-0.98-2.i386.rpm

A package label is contained within the file and does not necessarily need to match the name of the file. Source code may also be distributed in RPM packages. Such package labels do not have an architecture part and replace it with "src", e.g.:

libgnomeuimm-2.0-2.0.0-3.src.rpm

Additionally, libraries are distributed in two separate packages for each version. One contains the precompiled code, while the second one contains the development files such as headers, static library files, etc. for the library in question. Those packages have "-devel" appended to their name field.

RPM can also make a so-called source RPM package which contains all the stuff needed to build the binary RPM package, that is, source tarballs, patch files, and the specfile. Thus, everything you need to rebuild the package is bundled together conveniently.

RPM Setup

The following hints assume that you have a system with installed RPM, which is true for RPM-based Linux distributions of course.

• If you are new to RPM, make sure that you have a suitable optflags setting in your /etc/rpmrc  or elsewhere. You can check the result with the command

  rpm --eval '%{optflags}'
  

  Some people like highest optimization levels, but I think that GCC's -O2 is enough and can protect you from quite a few optimizer bugs.

• you may want to prepare a /usr/share/config.site  file that contains your default settings for GNU configure. This is useful even without RPM. Check the autoconf documentation for details.
• Find out where RPM expects to find source tarballs and specs, where RPM would do its building, where it would place resulting packages etc. Typically, this is done in subdirectories of %{_topdir}, so you can get an answer by issuing the command

  rpm --eval '%{_topdir}'
  

  Normally, the subdirectories of %{_topdir} are world-writable, so that regular users can build packages. If you prefer to work in your own home directory, prepare a ~/.rpmmacros  file with contents like

  # Use the home directory for building.
  # Needed dirs (or symlinks): BUILD RPMS/i386 SOURCES SPECS SRPMS
  %home           /home/chris
  %_topdir        %{home}
  %_tmppath       %{_builddir}
  %buildroot      %{_tmppath}/%{name}-root
  

RPM Usage Examples

Assume that you want to build the package foo  from sources in foo-1.0.tar.gz  using RPM. Assume further that you have (prepared or got) a specfile and perhaps some patches for foo-1.0.

1. Move the source tarball and the patch files into the directory where RPM expects to find sources, e.g. /usr/src/packages/SOURCES/. You may also want to place the specfile to the corresponding SPECS  directory.
2. Issue the command rpm -ba foo.spec, where foo.spec is the pathname of the specfile. (Include directory components if necessary.) If everything goes well, this builds (-b) both source and binary RPM packages (-a) and stores these in e.g. /usr/src/packages/SRPMS/  and /usr/src/packages/RPMS/i386/, respectively. The actual building happens in a subdirectory of /usr/src/packages/BUILD/, and the buildroot for the installation may be a subdirectory of /var/tmp/.

   I recommend that you capture the screen output into a logfile by refining the above command to

   rpm -ba foo.spec 2>&1 | tee foo-1.0.log
   

   The logfile can help you in case of errors, and of course it should always be scanned for warnings and other strange things.

3. Get root permissions and (really) install the package with

   rpm -Uvh /usr/src/packages/RPMS/i386/foo-1.0-1.i386.rpm   # or whatever
   

   Now the package is properly integrated in your system. (Note: -U means upgrade package, the -vh just prints a progress bar.)

4. Once you are satisfied with the package, you may remove the build tree in /usr/src/packages/BUILD/. This can either be done directly or via the command

   rpm --clean foo.spec
   

   (Note that this --clean option is not related to the specfile's %clean section which undoes the pseudo-installation. When building binary RPMs, the %clean commands are executed automatically in case of success, but the build tree remains unless the --clean option is given.)

5. Similarly, you can remove the source tarball and the patch files from /usr/src/packages/SOURCES/  because you have a source RPM now. (Have you?) RPM can do this for you if you give the command

   rpm --rmsource foo.spec
   

   Note that this still leaves the specfile, though it is also contained in the source RPM. You can remove the specfile manually or with the option --rmspec.

6. Note also that the options --clean and --rmsource can as well be given in the rpm -b command. That is, you can build the RPM packages with subsequent proper cleanup by giving the single command

   rpm -ba --clean --rmsource foo.spec 2>&1 | tee foo-1.0.log
   

7. Should you ever need the sources and the specfile again, you can unpack the source RPM package by telling RPM to install it:

   rpm -i /usr/src/packages/SRPMS/foo-1.0-1.src.rpm
   

   In contrast to the installation of a binary RPM, the installation of a source RPM does not require extra privileges as long as the SOURCES  and SPECS  directories are writable.

8. In the special case where you just want to unpack the source RPM, build the binary RPM from its contents, and clean up, a single command suffices:

   rpm --rebuild /usr/src/packages/SRPMS/foo-1.0-1.src.rpm 2>&1 | tee foo-1.0.log
   

Recommendations

• Before you use the specfile, glance through it. I sometimes comment out some applicable parts, e.g. patches for experimental features, or time-consuming make check commands, which you may want to try. Or you may want to comment out certain Require directives that demand packages you have actually installed, but with a different name. And of course, the specfile comments may contain helpful usage information.
• Note that most patches are specific to a particular package version. Later versions may be fixed already, in the same or another way than the one suggested by the patches, or may not be fixed, but the patches could then be incomplete or inappropriate or could fail to apply for some reasons.

  If you update a specfile for a newer version, you should disable all previous patches. You could try to find out whether the old patches would still apply and, by careful inspection of the source code, whether they should be applied and what further adaptation could be necessary. The best result would be an updated patch file that fits properly to the new version.

• RPM appends a release number to every version number. Let the version number mirror the official version of the package you downloaded, and count your own modifications of that package with the release number. If you modify the package without upgrading to a new official tarball, simply increment the release number in the specfile. If you build a new official version, update the version number in the specfile. Then you can reset the release number to 0 or 1.
• Once you have built some RPMs, you may want to share them with the community. Binary RPMs are ready for installation and thus can be very convenient, but they carry a lot of dependencies specific to the build system. There is the machine type, of course, plus specific dynamic library versions required for the executables, and some other things which make binary RPMs less portable. RPM detects most of these cases and (by default) refuses to install RPMs with unsatisfied dependencies. Such a binary RPM package is rather useless. It won't even help a user if he decides to build the package himself, because the specfile is elsewhere, in the source RPM. These restrictions are encountered again when it comes to upgrades.

  The specfile can often be used with very few modifications to build later versions of the package. That's why I post specfiles and patches only. The other sources can be downloaded from the offical sites, and when you are there, you can check for the newest versions as well.

• Report your patches to the package authors so that you don't have to do the patching again when upgrading next time.
• If you found the specfile at my website, report specfile changes to me, if you like.

RPM packages are created from RPM spec files using the rpmbuild tool. When building an RPM pachge you need to create the directory with the name of the package and several predefined subdirectories

• SOURCES  — Contains the original sources, patches, and icon files.
• SPECS  — Contains the spec files used to control the build process.
• BUILD  — The directory in which the sources are unpacked, and the software is built.
• RPMS  — Contains the binary package files created by the build process.
• SRPMS  — Contains the source package files created by the build process.

The key component of the RPM package is SPECS section which contains so called spec files which are very similar to makefile.  It contains information required by RPM to build the package, as well as instructions telling RPM how to build it.  The spec files also specify what files are a part of the package, and where they should be installed. They have the ".spec" suffix and are distributed within source packages (SRPM)

It has multiple sections. Among them:

• The Preamble. The preamble contains information that will be displayed when users request information about the package. This would include a description of the package's function, the version number of the software, and so on. Also contained in the preamble are lines identifying sources, patches, and even an icon to be used if the package is manipulated by graphical interface.
• The Prep Section. The prep section is where the actual work of building a package starts.  Usually it contains instructions for unpacking the sources. It can be done via shell script of macros:

  %prep
  rm -rf $RPM_BUILD_DIR/cdplayer-1.0
  zcat $RPM_SOURCE_DIR/cdplayer-1.0.tgz | tar -xvf -

  Or using macros

  %prep
  %setup

  However, RPM does provide two macros to make life easier. One macro can unpack a compressed tar file and cd into the source directory. The other macro easily applies patches to the unpacked sources.
   

• The Build Section. Like the prep section, the build section consists of a shell script with the commands are required to actually compile the sources. Often this section could consist of a single make command.
• The Install Section. Also containing a shell script, the install section is used to perform the commands required to actually install the software. Typically it consist of a make install command. Otherwise, you'll need to add the usual assortment of cp, mv, or install commands to get the job done.
• The File List. The last section consists of a list of files that will comprise the package. Additionally, a number of macros can be used to control file attributes when installed, as well as to denote which files are documentation, and which contain configuration information. The file list is very important — if it is missing, no package will be built.

There are also several optional section

• Install and Uninstall Scripts. This is an optional section. While the previous sections contained either information required by RPM to build the package, or the actual commands to do the deed, this section is different. It consists of scripts that will be run, on the user's system, when the package is actually installed or removed. RPM can execute a script:
  • Prior to the package being installed.
  • After the package has been installed.
  • Prior to the package being erased.
  • After the package has been erased.

  One example of when this capability would be required is when a package contains shared libraries. In this case, ldconfig would need to be run after the package is installed or erased. As another example, if a package contains a shell, the file /etc/shells  would need to be updated appropriately when the package was installed or erased.

• The Verify Script. This is another script that is executed on the user's system. It is executed when RPM verifies the package's proper installation. While RPM does most of the work verifying packages, this script can be used to verify aspects of the package that are beyond RPM's capabilities.
• The Clean Section. This is an optional section. Another script that can be present is a script that can clean things up after the build. This script is rarely used, since RPM normally does a good job of clean-up in most build environments.

The RPM package is a binary format and consists of four sections:^[1]

• The lead identifies the file as an RPM file and contains some obsolete headers.
• The signature which can be used to ensure integrity and/or authenticity
• The header contains metadata including package name, version, architecture, file list, etc..
• A file archive, which usually is cpio compressed with gzip. In more recent versions of RPM, star can also be used for archive and bzip2, lzma or xz for compression. RPM 5.0 format supports using xar for archiving.

Working behind the scenes of the package manager is the RPM database, stored in /var/lib/rpm. It uses Berkeley DB as its back-end. It consists of a single database (Packages) containing all of the meta information of the installed rpms. Multiple databases are created for indexing purposes, replicating data to speed up queries. The database is used to keep track of all files that are changed and created when a user (using RPM) installs a package, thus enabling the user (via RPM) to reverse the changes and remove the package later. If the database gets corrupted, the index databases can be recreated with the rpm --rebuilddb  command.

To build RPMs your system should have the rpmbuild  command. (If the command "which rpmbuild" does not display anything, you don't have rpmbuild.). On Red Hat and Fedora systems, the rpmbuild  command is provided by the rpm-build  package. (You can give the command "rpm -q rpm-build" to check if it is installed.) .

It is better to use some close example (prototype RPM), especially in the source form then to build your RPM from scratch.

In this case you need first to install "prototype" RPM to your home directory. To placing the package files under $HOME/MyRPM and the rpm database in the $HOME/MyRPM/var/rpm directory use the command:

rpm -ivh --nodeps --relocate /=$HOME/MyRPM --root=/$HOME/MyRPM package.rpm

To study RPM you can also unpack it  You can do it using Midnight commander, or rom2cpio (in the latter case only content of cpio archi will be unpackaed.

# rpm2cpio emacs-common-21.4-20.el5.x86_64.rpm | cpio -idmv

The rpm2cpio command extracts a cpio archive from an RPM file, and cpio command extract files from the cpio archive.

The options used with the cpio command are described as follows.

• -i: extract files
• -d: make directories
• -m: preserve modification time
• -v: verbose

All source packages of SUSE LINUX carry a .src.rpm  extension (source RPM).

The following directories must be available for rpm and rpmbuild in /usr/src/packages  (unless you specified custom settings in a file like /etc/rpmrc):

SOURCES

for the original sources (.tar.gz  files, etc.) and for distribution-specific adjustments (.dif  files)

SPECS

for the .spec files, similar to a meta Makefile, which control the build process

BUILD

all the sources are unpacked, patched, and compiled in this directory

RPMS

where the completed binary packages are stored

SRPMS

here are the source RPMs

When you install a source package all the necessary components will be installed in /usr/src/packages: the sources and the adjustments in SOURCES  and the relevant .spec  file in SPECS.

The following example uses the wget.src.rpm  package. After installing the package with YaST, you should have the following files:

/usr/src/packages/SPECS/wget.spec
/usr/src/packages/SOURCES/wget-1.4.5.dif
/usr/src/packages/SOURCES/wget-1.4.5.tar.gz

rpmbuild -b X /usr/src/packages/SPECS/wget.spec starts the compilation. X is a wild card for various stages of the build process (see the output of --help  or the RPM documentation for details). The following is merely a brief explanation:

-bp

Prepare sources in /usr/src/packages/BUILD: unpack and patch.

-bc

Do the same as -bp, but with additional compilation.

-bi

Do the same as -bp, but with additional installation of the built software. Caution: if the package does not support the BuildRoot feature, you might overwrite configuration files.

-bb

Do the same as -bi, but with the additional creation of the binary package. If the compile was successful, the binary should be in /usr/src/packages/RPMS.

-ba

Do the same as -bb, but with the additional creation of the source RPM. If the compilation was successful, the binary should be in /usr/src/packages/SRPMS.

--short-circuit

Skip some steps.

The binary RPM created can now be installed with rpm -i or, preferably, with rpm -U. Installation with rpm makes it appear in the RPM database.

The danger with many packages is that unwanted files are added to the running system during the build process. To prevent this, use build, which creates a defined environment in which the package is built. To establish this chroot environment, the build script must be provided with a complete package tree. This tree can be made available on the hard disk, via NFS, or from DVD. The respective position is specified with build --rpms <path>. Unlike rpm, the build command looks for the SPEC file in the source directory. To build wget anew (like in the above example) with the DVD mounted in the system under /media/dvd, use the following commands as root:

cd /usr/src/packages/SOURCES/
mv ../SPECS/wget.spec .
build --rpms /media/dvd/suse/ wget.spec

Subsequently, a minimum environment is established at /var/tmp/build-root. The package is built in this environment. Upon completion, the resulting packages are located in /var/tmp/build-root/usr/src/packages/RPMS.

The build script offers a number of additional options. For example, cause the script to prefer your own RPMs, omit the initialization of the build environment, or limit the rpm command to one of the above-mentioned stages. Access additional information with build --help and man build.

Midnight Commander (mc) can display the contents of RPM archives and copy parts of them. It represents archives as virtual file systems, offering all usual menu options of Midnight Commander. Display the HEADER  with F3. View the archive structure with the cursor keys and Enter. Copy archive components with F5.

A front-end for rpm is also available for Emacs. KDE™ offers the kpackage tool. GNOME™ offers gnorpm.

Using the Alien (alien) Perl script, it is possible to convert or install an alien binary package. This tries to convert old TGZ archives to RPM before installing. This way, the RPM database can keep track of such a package after it has been installed. Beware: alien is still alpha software, according to its author — even if it already has a high version number.

NEWS CONTENTS

• 20040810 : Linux Magazine August 2004 GURU GUIDANCE Creating Custom RPMs, Part One ( Linux Magazine August 2004 GURU GUIDANCE Creating Custom RPMs, Part One, Aug 10, 2004 )
• 20040810 : This months column covers the files and file formats involved in creating RPMs. Next months column will present practical examples, including how to build both binary and architecture-independent RPMs. ( )
• 20040810 : Building RPMS from SOURCE or SRPMS ( Building RPMS from SOURCE or SRPMS, )
• 20040810 : Building RPM packages as user ( Building RPM packages as user, )
• 200102 : Building RPMs Yourself ( Building RPMs Yourself, )
• 200102 : RPM Building Crash Course by Pierre Sarrazin ( May 9, 2007 )

Old News ;-)

[Aug 10, 2004] Linux Magazine August 2004 GURU GUIDANCE Creating Custom RPMs, Part One

RPMs can be a great way to manage the packages you install on your system. Unfortunately, not everything you might want to install is available in RPM form. Perhaps you need a more recent version of a program than the one that ships with your distribution; or maybe it's a program you wrote yourself; or perhaps it's just something that's very obscure. Similar dilemmas can occur with non-program packages, such as font or clip art collections.

Whatever the case, if you're installing a program for a single computer, chances are you'll just install it the old-fashioned way, by typing make && make install (or some similar set of commands) in the source directory. make gets the job done, but it means you're giving up the benefits of the RPM system. What's more, if you're maintaining several computers, running around installing the same package on all of them can be tedious.

Life would be much easier if you could create your own RPM, giving you the ability to easily install the package on many systems and the benefits of its package tracking. Fortunately, RPM includes tools that enable you to do just that. Creating an RPM isn't as easy as creating a tarball, but the task isn't insurmountable.

This month's column covers the files and file formats involved in creating RPMs. Next month's column will present practical examples, including how to build both binary and architecture-independent RPMs.

Building RPMS from SOURCE or SRPMS

Never build RPMS as root.

1. Log into your machine as a regular user.
2. create a mirror image of the main RPM directory structure in your $HOME and
3. tell RPM to use these directories instead of the original ones.

Building RPM packages as user

This document explains how to build packages without root-access. This might be useful in case you have a build environment where different users need to build packages without interfering each other.

Customizing your RPM build environment

To make RPM use your environment definitions, you need to override the default macros RPM uses. The only one that is crucial for this is %_topdir (which by default would point to /usr/src/redhat).

You can do this by adding the following to ~/.rpmmacros.

	%_topdir /home/dag/redhat/

As a consequence, RPM will need the default directory structure underneath. So you can do as user:

	mkdir -p ~/redhat/{BUILD,RPMS/{i386,i686,noarch},SOURCES,SPECS,SRPMS}

And now you're set to go.

The obvious catch

Beware that you don't have the same permissions as root, which means you can't chown files to other users. So if the default Makefile uses chown or install to change ownership, this will obviously fail. As a workaround, you can't use %makeinstall, and instead use install yourself without changing owners. Ownerships should be in the %files section.

Customize even more !

Since you now can build packages yourself, you can also customize the default packager, vendor and other information by defining more macros.

	%packager Dag Wieers <[email protected]>
	%vendor Dag Wieers <[email protected]>
	%_tmppath /home/dag/tmp/
	%_topdir /home/dag/redhat/
	%prefix /usr/local/

There are much more macros for changing default paths, programs or even function-macros. See our links for more specific information.

Building RPMs Yourself

If you are familiar with the make-based way to build and install software packages in Unix systems, this page should enable you to step to a higher level, using RedHat's Package Manager (RPM).

RPM Building Crash Course By Pierre Sarrazin

May 9, 2007

(See French version.)

Getting the rpmbuild command

Your system may currently have the rpm command but not the rpmbuild command. (If the command "which rpmbuild" does not display anything, you don't have rpmbuild.) On Red Hat and Fedora systems, the rpmbuild command is provided by the rpm-build RPM package. (You can give the command "rpm -q rpm-build" to check if it is installed.) Avoiding root

By default, one needs to be root to build RPM packages under the /usr/src/redhat directory. To avoid that, give the following command under root:

chown -fR someuser /usr/src/redhat

This step is only needed once. However, you can build RPM packages in any directory owned by someuser by writing an appropriate ~/.rpmmacros file. For example, put the following line in that file:

By default, RPM packages are built in the /usr/src/redhat directory, which is only writable by root. You can have the rpmbuild command use another directory (e.g., /home/your_userid/rpm) by putting this line in a file called .rpmmacros in your home directory:

%_topdir /home/your_userid/rpm

You must then create the following subdirectories in that directory:

cd /home/your_userid/rpm
mkdir SOURCES SPECS BUILD SRPMS
mkdir -p RPMS/i386 RPMS/athlon RPMS/i486 RPMS/i586 RPMS/i686 RPMS/noarch

See the RPM reference documentation for details.

Building from a source RPM (SRPM)

Install the .src.rpm file this way:

rpm -i somepackage-1.0-1.src.rpm

This will create files in the SOURCES directory of your RPM building directory tree, and a .spec file in the SPECS directory.

Then go the SPECS directory and give the command to build the RPM:

cd /home/your_userid/rpm/SPECS
rpmbuild -bb somepackage.spec

Give the -ba option instead if you also want to build the SRPM. The binary RPM packages will typically be created in the RPMS/i386 directory (on a PC-based system).

Building from a source archive

When a source archive (e.g., somepackage-1.0.tar.gz) contains a .spec file, one can give the following command to build the RPM without having to deploy the archive:

rpmbuild -tb somepackage-1.0.tar.gz

Give the -ta option instead if you also want to build the SRPM.

(The source archives that I publish are supposed to contain a functional .spec file. If I omitted this, please complain to me.)

Recommended Links

Softpanorama Recommended

Top articles

Sites

Top articles

Sites

...

• Maximum RPM A book written by Ed Bailey. It is available in hardback (442 pages), and has recently been re-printed by Sams in soft-cover (450 pages - ISBN: 0672311054). The hardcover edition includes a quick reference card. An on-line version of the original book is also available, and a more up to date, work in progress version can be found here.
• The RPM home page.
• Red Hat RPM Guide A more recent book by Eric Foster-Johnson, this has recently been released under the Open Publication License and a draft close to the published version is available on-line as Fedora RPM Guide. This book covers everything from basic usage to advanced tricks, package creation and API programming. Participation in updating the Guide can be done via the Fedora Documentation Project. Discussions about moving this content and work upstream to rpm.org can occur on fedora-docs-list.

rpm - Trac

AAA Development-Tasks-Packaging-Tools-RPM-Howto - Mandriva Community Wiki a very good tutorial

Red Hat Package Manager 4 information

RPM Tutorial

[freshrpms.net] - The fight

Packaging software with RPM by Martin Streicher,

• Packaging software with RPM, Part 1
• Packaging software with RPM, Part 2
• Packaging software with RPM, Part 3

RPM HOWTO (Red Hat 1999)

Better Living Through RPM, Part 2

• Ark linux howto
• IBM article on rpm building
• A redhat magazine article on rpm building
• Pdf tutorial on rpm building made by GuruLabs
• Red Hat RPM Guide

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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

Most popular humor pages:

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

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019