Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells

Yum's repository system

News YUM Recommended Links Reference Yum's repository system How to add a new yum repository  
EPEL repository How to Enable EPEL Repository Yum Plugins How to download RPMs with yum Download Dependencies for a RPM Red Hat RPM hell
Smart Pirut Yast Horror Stories Unix History Humor Etc

Yum's repositories a standard way of working with performing updates and install of new packages in RPM-based Linux distributions. Red Hat, CentOs, Academic Linux, Fedora and OpenSuse supports Yum repositories.

Yum  consists of two tools; yum-arch, which is used to construct an (ftp or http) repository on a suitable server, and yum, the general-purpose client. Once a yum repository is prepared  any client permitted to access the repository can install, update, or remove one or more rpm-based packages from the repository.

For a particular commercial distribution registration is needed to get access to repositories. Only such distributions as CentOS, Academic Linux, Fedora and OpenSuse provide free access to yum repositories. For example for CentOS:

CentOS has quite a large number of official repositories. This is to ensure that administrators can maintain their servers in a known state. By using the default repositories, only packages that are updated upstream are made available. This ensures binary compatibility with Red Hat Enterprise Linux.

For some people, this may be very important, especially if they are running software that is certified for Red Hat Enterprise Linux. But what if you just want the CentOS core but want to be able to use software that isn't available upstream? What if you want to try a newer version of a piece of software? Chances are you will find what you're looking for in one of the CentOS repositories, but if not, you can always add a third-party repository.

Official CentOS Repositories

The following are the official CentOS repositories.


This repository contains the RPM packages as they are supplied on the related ISO images. This repository is enabled by default, although the contents of this repository don't update after a given release.


This repository, which is also enabled by default, is where all the security, bug fix, and enhancement updates for the [base]  repositories are placed. All of the other repositories contain their own updates.


This repository (enabled by default) does not contain packages that are released upstream. Instead, it contains additional packages that are needed to build software from the source RPMs (SRPMs). Using this repository doesn't cause CentOS to lose binary compatibility with upstream versions and should remain enabled.


This repository is not enabled by default and contains additional software packages that have been contributed by the CentOS community. The important distinction with this repository is that none of the software will conflict with software in the base distribution. This means that it is generally safe to use these packages and that they won't break binary compatibility with upstream versions. However, they are not tested by the CentOS developers and may not necessarily follow upstream versions of the software all that closely.


This repository is similar to the [contrib]  repository in that it contains contributed software. Like [contrib], these packages are contributed by CentOS users, but packages are also supplied by CentOS developers. The major difference, though, is that the software that this repository provides may very well replace or upgrade packages that are included in the base distribution. This means that use of this repository could break binary compatibility with upstream versions.

Before using this repository, you should be fully aware of what this means to you. If you have no interest in maintaining compatibility with upstream versions or your project desperately needs the software included in [centosplus], then by all means feel free to use it. If you are more conservative and would rather keep your system as close to upstream versions as possible, you'd be better off not enabling this repository.


This repository is enabled by default and contains packages that add functionality to the distribution. It's written by the CentOS developers and has undergone reasonable testing. Software versions should track upstream versions fairly closely, and these packages will never conflict or interfere with [base]  packages.


The testing repository contains packages that are currently being tested and debugged. Unless you have a specific reason for doing so, this repository should not be enabled on a production server.

Third-Party Repositories

Now that you've seen the official repository list, you should also be aware that there are many third-party repositories that you can use. These are not approved by the CentOS Project but often contain many useful packages. For more information on third-party repositories and how to use them, check out the CentOS wiki at

Assessing repositories behind proxies

If there is a proxy between client and server you need to configure client configuration file so that it knows about the proxy, in /etc/yum.conf file You do not need quotes around the URL.


In case proxy requires authentication you need to provide those details too:

# The account details for yum connections

YUM also understands standard environment variable http_proxy.

In this case you need to provide those variable either in /etc/profile or in particular user .bash_profile. The settings below enable yum to use the proxy server, connecting to port 8080.

# The Web proxy server used by this account
export http_proxy
Or with authentication:

The alternative way to provide access to YUM repositories on a local network is to use NFS.  You can  export  (rw,no_root_squash) /var/cache/yum to all the LAN clients. This will speed up operations with the remote repositories as NFS is faster then HTTP protocol.  Best of all, there is no setup.

In a typical repository, there are several thousand packages, with a lot of headers. About 700 packages are actually installed on a typical linux system. However, the archive component of each package, which contains the actual binaries and libraries and documentation installed, is much larger -- the complete rpm is thus generally two to four orders of magnitude larger than the header. For example, the header for Open Office (a fairly large package) total about 100 kilobytes in size. The rpm itself, on the other hand, is about 30 megabytes in size. The header can be reliably delivered in a tiny fraction of a second over most networks; the rpm itself requires seconds to be delivered over 100Mbit/sec LAN.  Early automated update tools either required a locally mounted repository directory in order to be able to access all of the headers quickly (local disk access even from a relatively slow CD-ROM drive, being fast enough to deliver the rpm's in a timely way so that their headers could be extracted and parsed) or required that each linked rpm be sent in its entirety over a network to an updating client from the repository just so it could read the header. One was locally fast but required a large commitment of local disk resources (in addition to creating a new problem, that of keeping all the local copies of a master repository synchronized). The other was very slow. Both were also network resource intensive.

This is the fundamental problem that yum solves for you. Yum splits off the headers on the repository side (which is the job of its only repository-side tool, yum-arch). The headers themselves are thus available to be downloaded separately, and quickly, to the yum client, where they are typically cached semi-permanently in a small footprint in /var/cache/yum/serverid (recall that serverid is a label for a single repository that might be mirrored on several servers and available on a fallback basis from several URL's). Yum clients also cache (space permitting or according to the requirements and invocation schema selected by the system's administrator) rpm's when they are downloaded for an actual install or update, giving a yum client the best of both the options above -- a local disk image of (just the relevant part of) the repository that is automatically and transparently managed and rapid access to just the headers.

An actual download of all the headers associated with packages found on your system occurs the first time a yum client is invoked and thereafter it adds to or updates the cached headers (and downloads and caches the required rpm's) only if the repository has more recent versions or if the user has deliberately invoke yum's "clean" command to empty all its caches. All of yum's dependency resolution then proceeds from these cached header files, and if for any reason the install or update requires an rpm already in the cache to be reinstalled, it is immediately available.

However, it is probably better in many cases to use rsync or other tools to provide a local mirror of the repository in question and use yum's fallback capability to accomplish the same thing. This gives one a much better capability of standing alone should update access go away on the "server" of the yum cache NFS exported across a LAN.

With the header information (only) handy on high-speed local media, the standard tools used to maintain rpm's are invoked by yum and can quickly proceed to resolve all dependencies, determine if it is safe to proceed, what additional packages need to be installed, and so forth. Note well that yum is designed (by a highly experienced systems administrator, Seth Vidal, with the help of all the other highly experienced systems administrators on the yum list) to be safe. It will generally not proceed if it encounters a dependency loop, a package conflict, or a revision number conflict.

If yum finds that everything is good and the package can be safely installed, removed, or updated, it can either be invoked in such a way that it does so automatically with no further prompts so it can run automagically from cron, or (the general default when invoked from a command line) it can issue a user a single prompt indicating what it is about to do and requesting permission to proceed. If it finds that the requested action is in fact not safe, it will exit with as informative an error message as it can generate, permitting the system's administrator to attempt to resolve the situation by hand before proceeding (which may, for example, involve removing certain conflicting packages from the client system or fixing the repository itself).

From the overview given above, it should be apparent that yum is potentially a powerful tool indeed, using a single clever idea (the splitting off of the rpm headers) to achieve a singular degree of efficiency. One can immediately imagine all sorts of ways to exploit the information now so readily available to a client and wrap them all up in a single interface to eliminate the incredibly arcane and complex commands otherwise required to learn anything about the installed package base on a system and what is still available. The yum developers have been doing just that on the yum list - dreaming up features and literally overnight implementing the most attractive ones in new code. At this point yum is very nearly the last thing you'll ever need to manage packages on any rpm based system once it has gotten past its original, distribution vendor based, install.

rpm doesn't permit one to tell it to "install package X and anything else that it needs, after YOU figure out what that might be". Yum, of course, does.

Even yum, though, can't "fix" a dependency loop, or cope with all the arcane revision numbering schemes or dependency specifications that appear in all the rpm's one might find and rebuild or develop locally for inclusion in a central repository. When one is encountered, a Real Human has to apply a considerable amount of systems expertise to resolve the problem. This suggests that building rpm's from sources in such a way that they "play nice" in a distribution repository, while a critical component of said repository, is not a trivial process. So much so that many rpm developers simply do not succeed.

Also, yum achieves its greatest degree of scalability and efficiency if only rpm-based installation is permitted on all the systems using yum to keep up to date.

Consequently, repository maintainers must willy-nilly become rpm builders to at least some extent. If SuSE releases a lovely new tool in source rpm form that isn't in your current Red Hat based repository, of course you would like to rebuild it and add it. If your University has a site license for e.g. Mathematica and you would like to install it via the (properly secured and license controlling) repository you will need to turn it into an rpm. If nothing else, you'll need to repackage yum itself for client installations so that its configuration files point to your repositories and not the default repositories provided in the installation rpm's /etc/yum.conf.

Creating private Yum repositories

There are three steps to creating a yum repository:

If you have a special repository which you really like, but which does not support yum, you can use a trick: make a local mirror of the files via rsync or similar utility and then create a local YUM repository. To convert directory with RPMs into YUM repository you need to run a special utility createrepo

yum install createrepo

To create a repository you need to run it with a single parameter, the root of  RPM directory tree (you can use subdirectories for various groups of RPMs):

createrepo /var/cache/myrepo

After running the utility you can notice that in the directory /var/cache/yum/myrepo there is a new directory called repodata with data describing RPMs in it. 

The last step is to create the file with extension repo, for example, my.repo  in /etc/yum.repos.d/:

name=my cool repo

At this point you should be able to install RPM from local repository using yum. You can  use wget and cron-jobs for synchronizing of the local repository.  After each synchronization you need to update the repodata directory using createrepo

Setting up a remote yum repository

Once the repository is constructed, it must be made available by http, ftp, or rsync. If the repository is made in the root document tree of your web server, e.g., /var/www/html/, the following entry should be added to /etc/httpd/conf/httpd.conf:

<Directory /var/www/>
Options +Indexes

in order to allow the directories to be listed. Reload the httpd configuration file with

# /sbin/service httpd reload 


# /sbin/service apache2 reload 

depending of the flavour of Linux you are using and the type of Web server you have.

Repo files

On invocation yum first checks its configuration file /etc/yum.conf which store all information about the repositories in /etc/yum.repos.d/.

The files in this directory should have an extension repo and format like this:

name=SUSE LINUX 10.0 - Base

The first option shows the name - this must be unique because yum uses it to identify the repository and the cached data about it.

The second option, the name field, is for the user to know what he has configured.

baseurl gives the server and the directory where yum can find the packages.

You can use mirrorlists instead. The url to the mirrorlist is part of the field mirrorlist - due to the fact the no server provides them, we have to make our own.

Top Visited
Past week
Past month


Old News ;-)

[Feb 08, 2017]

Feb 08, 2017 |

Sometimes it can be handy to set up your own repository to prevent from downloading the remote repository over and over again. This tutorial shows how to create a CentOS mirror for your local network. If you have to install multiple systems in your local network then all needed packages can be downloaded over the fast LAN connection, thus saving your internet bandwidth.

Create the Directories:

mkdir -pv /var/www/html/centos/4/{os,updates}/i386

Replacing 4 and i386 with your major version and architecture.
Additionally you'll need some deeper directories. This is the correct location to copy the CD/DVD rpms.

mkdir -pv /var/www/html/centos/4/os/i386/CentOS/RPMS/
The Base Repository

Copy the RPMs from the CDs/DVD to /var/www/html/centos/base .

Create the base repository headers:

createrepo /var/www/html/centos/4/os/i386/

The Updates Repository

Select an rsync mirror for updates: check out this list of aviable mirrors: Centos OS Mirror list and these are identified with rsync .

For example: rsync://

The mirrors share a common structure for updates. Simply append /updates/<d version>/<base arch> .

Rsync to create the updates-released repository:

/usr/bin/rsync -avrt rsync:// --exclude=debug/ /var/www/html/centos/4/updates/

This will create a complete update repository at /var/www/html/centos/4/updates/i386 . The repodata directory will be created with all of the headers.

You can additionally pipe this into mail to receive an email when updates are available.

/usr/bin/rsync -avrt rsync:// --exclude=debug /var/www/html/centos/4/updates/ | /bin/mail -s "New Repo Updates"

Next I would advise to setup a cron job to run the rsync (above). In this manner your repository is kept updated and only new updates and headers will be downloaded to your repository.

Yum Configuration

Edit yum.conf :

vi /etc/yum.repos.d/CentOS-Base.repo

name=CentOS-$releasever - Base
#released updates
name=CentOS-$releasever - Updates

That's it.

SPECIAL THANKS TO kylehase (for sending me corrections)

[Feb 08, 2017] Create your own private yum repository.

Notable quotes:
"... /var/ftp/repo/Fedora/10/i386 ..."
"... /var/ftp/repo/Fedora/10/x86_64 ..."
"... /var/ftp/repo/Fedora/10/SRPMS ..."
"... /var/ftp/repo/Fedora/10/i386 ..."
"... /var/ftp/repo/Fedora/10/x86_64 ..."
"... ..."
"... /etc/yum.repos.d/my.repo ..."
Feb 08, 2017 |

Sometimes, especially when you create your own RPMs, it is extremely useful to keep them in a local YUM repository . The advantage of this is that, when you install a package, YUM automatically resolves any dependencies, not only by downloading the necessary packages from the other repositories you might have in you list, but also by using your local repo as a resource for potential dependencies.

So, when installing a package (eg my_package.rpm ) with YUM, you are supposed to have already created RPM packages for all of the my_package.rpm 's dependencies and to have updated the repository's metadata, so that yum is able to resolve all the dependencies. If these dependencies do not exist in any of the repositories in your list, then, in short, you cannot install your package with yum.

So, in order to install an RPM package and all the other packages that it depends on, you only need to run:

# yum install my_package.rpm

How to create a local YUM repo ?

You will need an utility, named createrepo . Its RPM package exists in Fedora Extras. To install it, just run as root:

# yum install createrepo

Then, put all your custom RPM packages in a directory. Assuming that this directory is /path/to/repository , you can create all the necessary metadata for your local repository by running the following command as root or as the user that owns the directory:

# createrepo -v /path/to/directory

That's it! Your local YUM repository is ready.

Keep in mind that every time you put any new RPMs in that directory or remove any old RPMs, you will need to run the above command again, so that the repository metadata gets updated.

Add your local repo to the list

The next thing you need to do is to add your local repository to your list of repos, so that yum knows where to find it. This info is kept in the /etc/yum.repos.d/ directory. As root, create a new text file in this directory, name it fedora-local.repo (you can use any name you like, but remember to add the extension .repo ), and add the following info in it:

[]# cat /etc/yum.repos.d/fedora-local.repo
name=[give any name you like without the square brackets ofcourse]
baseurl=[file:| ftp | http |<path to the repository>]

In Order to access the repository over ftp or http the urls should be modified as follows

As you can see, we used the protocol file:/// in the baseurl option. This assumes that the local repo exists in the local machine. If it exists in another machine of your internal network, feel free to use any other protocol in order to tell yum where to find your local repository, For example you can use http:// , ftp:// , smb:// etc.

In the above example, the GPG key check is disabled ( gpgcheck=0 ). If you sign your packages, you can set this to " 1 " and uncomment the following line ( gpgkey=... ). This contains the path to your public key, so that YUM can verify the package signatures.

You can have as many local YUM repositories as you like.

Other uses of a local repository

Using a local repository does not only serve as a place for your custom RPMs. You can perfectly save some bandwidth by downloading all the released fedora updates in that repo and use this to update all the systems of your internal network. This will save bandwidth and time.

The Procedure is the same for all RPM based systems, using YUM Package Manager. So this can be applied to Fedora, Redhat and CentOS systems

Create your own yum repository - TechRepublic

The standard RPM package management tool in Fedora, Red Hat Enterprise Linux, and CentOS is the yum package manager. Yum works quite well, if a little bit slower than other RPM package managers like apt4rpm and urpmi, but it is solid and handles dependencies extremely well. Using it with official and third-party repositories is a breeze to set up, but what if you want to use your own repository? Perhaps you manage a large computer lab or network and need to have - or want to have - certain packages available to these systems that you maintain in-house. Or perhaps you simply want to set up your own repository to share a few RPM packages with the world or just your friends.

Creating your own yum repository is very simple, and very straightforward. In order to do it, you need the createrepo tool, which can be found in the createrepo package, so to install it, execute as root:

# yum install createrepo

Once the package is installed, you can begin creating your repository. You will also need some RPM packages to create the repository with. Decide where you want to store your repository; let's say, /var/ftp/repo will be the base directory.

Depending on how particular you want to get, you can dump everything to a single repository or keep things organized. I'm a big fan of organization, so let's assume you will be creating a repository for Fedora 10 and have both i386 and x86_64 packages you want to be made available with it. I would create an appropriate directory tree using the following commands:

# mkdir -p /var/ftp/repo/Fedora/10/{SRPMS,i386,x86_64}

Now copy your i386 packages to /var/ftp/repo/Fedora/10/i386 , your x86_64 packages to /var/ftp/repo/Fedora/10/x86_64 , and the SRPMS you have (if wanted) to /var/ftp/repo/Fedora/10/SRPMS . To easily automate the creation of the repository metadata, create a shell script called create-my-repo and place it somewhere in your PATH:

for arch in i386 x86_64
    pushd ${destdir}/${arch} >/dev/null 2>&1
        createrepo .
    popd >/dev/null 2>&1

Make the script executable and whenever you run it, it will call the createrepo tool on the two directories: /var/ftp/repo/Fedora/10/i386 and /var/ftp/repo/Fedora/10/x86_64 . Once this is done, your repository is ready for use.

If /var/ftp is the available FTP root, then would be the download URL for the i386 packages. To make this available to the other client systems, create a yum repository configuration file called /etc/yum.repos.d/my.repo with the following contents:

name=My Repository

This file can be used on both i386 and x86_64 clients due to the "$basearch" specifier. It will be enabled the next time "yum update" is run.

Creating your own yum repository is very easy and very straightforward, and is a great way for administrators to distribute specialized packages within an organization.

Creating a yum repository (repo) and Creating a yum group to install

02 May 2007 |
Creating a yum repository is fairly easy, the only command you need is createrepo and some rpms. This is a quick guide to making a repo, I have a more complete example in my howto make an install server.

Make a directory to contain your rpms, it's nice to name the directory the same as the repo name. Even better, segregate the rpms by architecture, i386, i686, noarch, SRPMS, etc. Copy the rpms into the appropriate directories and run create repo on that directory. Ensure you sign your rpms with your gpg key.

[user@machine] mkdir -p MyRepo/i386 MyRepo/noarch MyRepo/i686 MyRepo/SRPMS
[user@machine] mv myrpm.noarch.rpm MyRepo/noarch
[user@machine] mv myrpm.src.rpm MyRepo/SRPMS
[user@machine] mv mybinrpm.i386.rpm MyRepo/i386
[user@machine] createrepo MyRepo

Groups File (comps.xml)

Now, if you want to install all the rpms in your repo, or a specific subset, you'll need to create a groups file otherwise known as comps.xml. For our example, if we wanted myrpm.noarch.rpm to be installed by default and mybinrpm.i386.rpm to be an optional install, we would create a comps.xml file like this:
<!--  <meta> -->
<!-- Meta information will go here eventually -->
<!--  </meta> -->
    <description>Default RPMS from MyRepo</description>
      <packagereq type="default">myrpm</packagereq>
      <packagereq type="optional">mybinrpm</packagereq>
Now we need to rerun createrepo so that clients will know our group assignments.
[user@machine] createrepo -g comps.xml MyRepo


Now, if we want to install this group on a machine, we create a .repo file in /etc/yum.repos.d like this:
name=My Repository
If you didn't sign your rpms and do not wish to verify signatures, set gpgcheck=0 in your .repo file. If you did sign your rpms, then you'll need to export your gpg key into a file so yum can import the file into the rpm database.

Exporting your GPG-Key for RPM/YUM

First, find the name of your key if you don't already know it.
[thomas@host ~] gpg --list-keys
pub   1024D/79E7E0DB 2007-10-08
uid                  Repository Owner <>
sub   2048g/04F5FDBA 2007-10-08
Then export the key into a file:
[thomas@host ~]$ gpg --export -a "Repository Owner <>" >
[thomas@host ~]$ cat 
Version: GnuPG v1.4.5 (GNU/Linux)
... ... ... 
Then move this file to the location specified in the .repo file. Yum will install the key into the rpm database for you. To install the key manually, you can do the following:
[root@host thomas]# rpm --import
[root@host thomas]# rpm -q gpg-pubkey
We can see that our key (gpg-pubkey-79e7e0db-470a4258) was installed into the rpm database).

Now, to install this group.

[user@machine] yum groupinstall mygroup
This will install any default or mandatory rpms as listed in comps.xml, any optional rpms will not be installed.


To install our packages via kickstart, we'll need to add the repo to our kickstart file
repo --name=MyRepo --baseurl=http://path/to/MyRepo

Red Hat Enterprise Linux 6.x yum Repository (POWER me up) by DanielJMartin

Dec 1 2011 |

So you have Redhat 6.x* Enterprise installed, but now you need to set-up some local repositories from the DVD which the system was created. So here is a quick guide on how to do it -

First install the createrepo command, else we can't create our yum repository.

# rpm -ivh --aid /mnt/Packages/deltarpm-3.5-0.5.20090913git.el6.ppc64.rpm

# rpm -ivh --aid /mnt/Packages/python-deltarpm-3.5-0.5.20090913git.el6.ppc64.rpm

# rpm -ivh --aid /mnt/Packages/createrepo-0.9.8-4.el6.noarch.rpm

Mount the installation DVD.

# mount /dev/dvd /mnt

Copy over the packages to a folder.

# mkdir /etc/yum.repos.d/rhel6.x

# cp /mnt/Packages/* /etc/yum.repos.d/rhel6.x

When you copy over the files you will also find a *.xml library file, either in the same dir as the source or in a sub that needs to be copied over for the next command.

# cp /mnt/repodata/repomd.xml /etc/yum.repos.d/rhel6.x

Create the repo with the createrepo command.

# createrepo -g repomd.xml /etc/yum.repos.d/rhel6.x

Create the repo file.

vi /etc/yum.repos.d/rhel6x.repo

name=RHEL 6.x

Update yum's repo list.

# yum clean all

Loaded plugins: product-id, subscription-manager
Updating Red Hat repositories.
RHEL-Repository | 1.3 kB 00:00 ...
RHEL-Repository/primary | 1.5 MB 00:00 ...
RHEL-Repository 3210/3210
repo id repo name status
RHEL-Repository RHEL 6.x 3,210
repolist: 3,210

Then test.

# yum search httpd
Loaded plugins: product-id, subscription-manager
Updating Red Hat repositories.
======================== N/S Matched: httpd =======================================
httpd.ppc64 : Apache HTTP Server

httpd-devel.ppc : Development interfaces for the Apache HTTP server
httpd-devel.ppc64 : Development interfaces for the Apache HTTP server
httpd-manual.noarch : Documentation for the Apache HTTP server
httpd-tools.ppc64 : Tools for use with the Apache HTTP Server
mod_dav_svn.ppc64 : Apache httpd module for Subversion server
mod_dnssd.ppc64 : An Apache HTTPD module which adds Zeroconf support

Name and summary matches only, use "search all" for everything.

* be sure to replace the 'x' with your version of RHEL.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles




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-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: October, 09, 2018