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


Old News See also Recommeded Links Reference Etc

With my many years experience with virus-protection integrity checkers (Adinf) I can attest that integrity checkers are generally pretty tricky to write and use and return on the investment is usually less than one expects. In virus world databases and binaries were successfully attacked, therefore encrypting them is nice but read-only media is better.

Tripwire is the most popular, but rather primitive and architecturally outdated integrity checker for Unix (now NT versions are also available). Originally released in 1992 by Gene Kim (Tripwire's CTO) and Dr. Eugene Spafford (from the COAST Laboratory at Purdue University) it was archaic even in its first version. Neither of the authors understood the regex approach. They also chose wrong implementation language (C). And to add insult to injury they invented very bad "ad hoc" language for specifying files to check. The language is not only unique in its primitiveness, but also pretty annoying. It can be considered to be a classic example of YASAP (yet another stupid application macrolanguage).

In short they did everything wrong but despite this the program succeeded, because the need for any integrity checker in Unix were so great... :-). They were just in the right place at the right time. Still it's success is very superficial, it is success of hype. Productive use of Tripwire is a very difficult and challenging task. Most installations that I know use Tripwire just for cosmetics, to demonstrate that they care about security. On very static, appliance type server Tripwire definitely makes sense and creation of a realistic security policy is relatively easy. In other cases your mileage may vary.

First of all creating of a realistic attribute checking scheme for a production Unix environment with many applications installed is a very challenging task in itself. The Tripwire scripting language is extremely primitive and many assertions about, say, permissions are simply non-expressible in it. That fact alone makes creating of realistic policies really tricky and very time-consuming. Generally you would be better off wring you own macro generator for policies.

Paradoxically Tripwire established itself as the most popular integrity checker for Unix and despite being extremely weak software can be considered to be a classic Unix security tool :-(.

If you're interested in Tripwire then let me be the first to welcome you to the world of paranoid system admins. Tripwire is marginally useful in detecting a compromise of your system.

Tripwire generates a database of the most common files and directories on your system. Once it is generated, you can then check the current state of your system against the original database and get a report of all the files that have been modified, deleted or added.

This comes in handy if you allow other people access to your machine and even if you don't, if someone else does get access, you'll know if they tried to modify files such as /bin/login etc.

So lets install Tripwire. First you need to download it from At the time of this update the current version is 2.3.1-2.

Once you've downloaded it move the tarball to /usr/local/src (I like to store all my source code there) and untar it by running the following command:

tar -zxvf tripwire-2.3.1-2.tar.gz

Change into the newly created directory and edit the install.cfg with your favorite text editor (nano, pico, joe vi etc). script. You'll want to edit the following:

# The root of the TSS directory tree.

Change this to TWROOT="/usr/local/src/tripwire-2.3.1-2"

# This sets the default text editor for Tripwire.

You can change this to whatever editor you prefer.

Once you have those changed, save the file and exit. Then run the ./ script. It will list the OSes that Tripwire supports and will ask you if you want to continue with installation. Next up is the License Agreement. Read it and if you accept, type accept.

It will then list all the settings and ask you if you would like to continue, answer yes. Then it installs the files and prompts you for a passphrase to password protect the database. Choose it wisely. It will now generate your keyfile and then prompt you for a local passphrase and a site passphrase.

Once that is done, tripwire will be installed and you're ready to customize the format of the database and finally create it. To customize the database, you will need to edit the /usr/local/src/tripwire-2.3.1-2/policy/twpol.txt file. Make sure you back it upbefore you start changing things in it.

What I would recommend doing is first generating the database using the default policy file. Once the database is generated, use tripwire to check against it and you will get a report of what is missing on your system, for example it checks for /lib/modules/preferred and if you don't have that file it will let you know in the report. If you don't remove useless items from the policy file, you're report will be long and full of garbage that you don't need to look at everyday and you will probably miss the things you should be looking for.

So to generate the database, run:

/usr/local/src/tripwire-2.3.1-2/bin/tripwire --init

It will ask you for your passphrase and once you enter it, it will start to generate the database. This will vary in time depending on how big your installation is, how fast your CPU is etc. Once the database is generated, you will want to check it to find out what you can remove from the policy file. To check the database and have it output to a file, run:

/usr/local/src/tripwire-2.3.1-2/bin/tripwire --check > /tmp/report.txt

It will then proceed to check your filesystem against the database and will create a file called report.txt in /tmp which will contain information on what Tripwire discovered.

Open up this file and look for anything that it said it couldn't find. Log into another terminal and open up the twpol.txt policy file. Compare the two and remove anything not found one by one. Once you are done editing, you have to recreate the policy file, to do this run:

/usr/local/src/tripwire-2.3.1-2/bin/twadmin --create-polfile ../policy/twpol.txt

It will ask you for your passphrase, once you enter it, tripwire should create a new policy file. You can then go ahead and update and then check your filesystem once more to see if you got everything. If you install alot of things, you will probably want to update the database on a regular basis.

You can also set up a cronjob to check the filesystem every night or whenever you feel like it and it will email you the report. For example:

03 2 * * * /usr/local/bin/tripwire --check | /usr/bin/mail root -s "Tripwire Check" 2>&1
Top Visited
Past week
Past month


Old News ;-)

Intrusion Detection Systems Tripwire or alternative

We're currently running the educational version of tripwire... no one is
really administering it and the reports are just being ignored.
As I see
it, the short fall of this free version is the inability to centralize the
databases/reports and the granularity/control of the reports. From what I
saw it's quite cryptic as well. My company's a non profit and qualifies for
tripwire's commercial product with a discount. We're considering going to
it, but want to see if there are viable alternatives. Has any one put
together something that can be used with the existing freeware version of
tripwire as far as centralizing information and creating reports? Are there
any other free or commercial products that may better/easier? How does
Flight Recorder fit into the scheme of things. Obviously these are pretty
green questions, but we had to get attacked for someone to get off their
duffs and now they want to know everything yesterday. At least the check
books are coming out :-)

Any direction would be greatly appreciated.


Roy Harrison

Linux magazine Tripwire Part3 2001 Regular review paper. Nothing special.

[osiris-devel] random seed - openssh use helper program. Butssh is _much more_ sensitive - if you can listen to the session, that'si t.

Alexei_Roudnev Alexei_Roudnev at
Tue Nov 4 13:24:02 MST 2003

> hi,
> I disagree that osirisd must be installable as a completely
> standalone application. I agree that it _should_ be. However,
> if installing additional software or patches works towards
> the project goals, software should be installed/upgraded. The
> primary goal of security overrides ease of system administration.
I 80% disagree. I works in this area more than 10 years (not all the time,
but as NOC head in Moscow, Ru-Cert expert, hacking investigator for a few
serious cases, and network designer and administrator now), and I can say,
that in 90% cases, ease to use are the main factor - it is better to have
100% coverage with _easy to use_ system, even if it is not 100% perfect but
allows to monitor, verify and confirm changes for 100 systems every day,
than to install _heavy to use_ system and then do not use it, because it
requires patches, manual analyze etc...

Else, no one use Tripwire - INTACT is much better IDS system. But - it is
not easy to manage, and is not easy to install (btw, no one system require
installing random patch to Solaris - no openssl, apache + ssl module,
commercial ssl, tripwire, proactivenetwork agent in ssl mode, intact...).

I have a good example. One company had enough licenses for tripwire to
install it on all systems. It was installed, but used on a 3 systems only.
reason - administration problems make impossible to manage it on 50 systems
around. If system was simple, it been used on all 50 servers, which means
much better security, even if every single system was little less secure.

Don't mix _security_ with _paranoya_. American airlines and american plane
passangers are a very good example of paranoya (which have nothing with
_real_ security). We do not need network paranoya, we need a security. In
case of osiris IDS, it means _watch ALL systems and ALL data_.

Anyway. Here it is more theoretical question, and we have a good resolution
for this problem, which satisfy to the both requirements.

Distributed Systems Group (DSG)Ed Arnold

put this in your root crontab:

0 0 * * * find / -mtime -1 -print | mail rootlocalhost

or something similar(i tested that syntax on linux since i don't have any direct access to a solaris box, but i had something like that running with solaris)

This will mail you every night at midnight with the files that have changed in the last 24 hours. This is not just for logfiles, but for all files. If it changed and you don't know why, check it out.

(you could always create a perl wrapper to something liek this so that you only pick up pertinent changed files, or you can block things liek the /dev directory if you feel you must).

-mount should take care of it walking past local FS's. There's another
switch for that also, but I think it's deprecated as of now.

Anyone tinkered with the fingerprint DB that Sun has out now? I haven't
had a chance yet....too many other things left to do, like upgrade BIND,
chroot it and so on....

NETSYS.COM - The Intelligent Hacker's Choice! - Focus Sun Mailing List Archives

All the 2.x versions (current is 2.4.0) support encrypted policy
and database. So all a cracker can do is delete them ... unless
you typed your public and private passwords over a cleartext link ...

TW-1.3 can be made "pretty safe" if you put your tripwire tree on
a switchable ro/rw disk. Making most external disks switchable
is a simple hardware mod. I have a software utility for switching
between ro and rw mode while the system (solaris 7 and up) is up and
running, if anyone wants it.

The Trouble With Tripwire: Making a Valuable Security Tool More Efficient
by Edward R. Arnold
last updated June 6, 2001


Even with the protection that a security perimeter may provide, the fact remains that firewalls aren't foolproof and that potential attackers are hard at work, 24 hours a day. No networks are entirely secure. Furthermore, some organizations must allow remote logins to machines from sites outside their perimeter, meaning they must maintain a certain number of semi-exposed hosts that are vulnerable to attack. It is not enough to know that a system has been scanned or probed. If an attack is detected, how can it be determined that a system has actually been compromised and important files removed or altered? One answer is to always run Tripwire, or one of its free-ware cousins, in order to detect changes in critical system files.

Unfortunately, this is not always an efficient solution. The author, who works for a well-known research institution in the USA, has experimented with Tripwire since the mid-nineties. The institution had experienced a series of hacks, as well as a number of mishaps stemming from incorrect machine configuration changes that led to internal, and external, embarrassment. These problems led them to try Tripwire to detect if any important files on their systems had been changed. Unfortunately, due to the volume and frequency of reports that it generated, it quickly became clear that Tripwire was a labor time-sink!

Given that running Tripwire may be a security necessity, it would be beneficial to do so as efficiently as possible. This paper will focus on ways to reduce the time and labor required to effectively operate run the Tripwire security and configuration monitoring tool.

Tripwire: Boon or Bust?

Tripwire is much like the fabled elephant and the blind men: how you feel about it depends on the perspective from which you approach it. A person who has successfully used Tripwire to detect cracked binaries and/or system misconfigurations will have nothing but praise for it. On the other hand, someone who has been "stuck in the trenches" reading through endless reports in an attempt to find problems, will think that it's a labor-intensive waste of time. Minimizing the labor required dictates that reports be as brief, and as infrequent, as they possibly can be made. Using Tripwire on a day-to-day basis can be an uncreative and essentially boring activity. On the other hand, if one can reduce the torrent of data that Tripwire provides, and thus make it simpler to use, then running it can become bearable (if not necessarily palatable.) Fortunately, it is possible to reduce the time and effort required to administer Tripwire, primarily by reducing the time required to process reports.

The Time Sinks

More than a year of experience in running Tripwire has made it pretty clear where the inefficiencies within the product lie, as of commercial version 2.2.1 (Linux) or 2.2.1A (Solaris). The following are some of the areas that the author believes contributes to time and labor inefficiency of Tripwire.

History Mechanism

The single most important time efficiency issue with Tripwire is the lack of a report history mechanism, which would drastically reduce the number of reports. For instance, a dozen systems being checked three times per day can result in over 1000 reports per month, any one of which could contain the critical information the tool is supposed to detect. Even the most careful tuning cannot prevent this; for instance, the installation or modification of a large software package may suddenly result in a large report that will continue until the administrator has time to do a database update. This is especially true if an administrator cannot make policy tuning and database update his first priority.

Policy Tuning

Tripwire does not have the capability to automatically tailor rules in the policy file (to minimize report volume) by watching a system over a period of time in order to recommend rule changes. At install time, the distributed policy file per processor/OS type is just a static file that comes with the distribution. The install procedure does not customize the file based on simple criteria, such as the presence of certain files or filesystem structures revealed by the mount table. Furthermore, it excludes some important files (e.g. the root crontab). Since the same template policy file per processor/OS type results upon install, a lengthy tuning process is required with each machine in order to minimize useless report output. Currently, there is no way around this problem other than to try to make the tuning process as quick as possible until most noise is tuned out. In the meantime, a history mechanism would significantly lessen the urgency of tuning.

Report Formats

Although the commercial Tripwire product has five report formats, none of them offers a maximally-abbreviated single-line format that provides violation type, filename, and changed attribute keys in a single line. (Tripwire's closest format is level 1, which provides only violation type and filename.) The default (level 3) format is a multiple-line format that is time-consuming to use. In many cases, the signature associated with a changed attribute isn't even of interest (for example, who wants to stare at an MD5 signature?) and, in many cases, the signature associated with a file attribute could change frequently and defeat history. So it is ultimately up to the system administrator to inspect the attribute or file in question before doing database or policy update. We parse the default Tripwire format into a single-line-per-file, 3-field format which looks like:

a /etc/inet/core
m /etc/passwd smCM
r /local/etc/named.foobar 

Although file attribute values are currently not included in the report, file content signatures may be added at a later time if automated diffs are implemented (see "Automated File Diffs" below).

Ease of Maintenance

Tripwire database and policy file maintenance are made easier if the Tripwire admin does not have to remember argument switches and long filenames. Maintenance time is also a good time to enforce security issues that the harried or newbie administrator might forget, such as making sure Tripwire passwords are protected by doing an update on the system console or via a secure shell link.

Lack of Regular Expressions

The Tripwire policy file allows complete exclusion or lower security policies on directory trees. However, it does not allow exclusion or changed security policies on regular expressions for filenames. Directories in which pseudo-random filenames are created by utilities that are not always under the Tripwire administrator's control - other than places like /tmp where they are expected - create "noise" in report output.

Another aspect of the regular expression problems is that it is not possible to instruct Tripwire to report on the addition of filenames that have historically been associated with cracking activity, for example: "/tmp/\..*".

E-Mail Report Minimization

Tripwire now allows e-mail reporting to go to different addresses for different portions of a machine's filesystems. Unfortunately, smaller organizations don't have the staff to assign responsibility for a system to several people. The best approach for such small organizations is to have no more than one report per Tripwire check run, and to have one primary person responsible per system.

Reducing the Time Sinks of Tripwire

Despite the numerous shortcomings listed above, it is possible reduce the labor and anxiety required to use the base Tripwire product, Tripwire for Servers, by taking the following steps:

  • Implement two wrappers, one for routine checking, and one for database or policy update;
  • Enforce security in the database and policy update wrapper, e.g. require ssh or console use, and provide reminders about ro/rw disk use. Allow checking to be done as a side-effect of database update so that a new report baseline can be established in a single step;
  • Provide labor-saving convenience features in the update wrapper. For instance, policy update (which is CPU intensive) can be easily re-entered so previous changes aren't lost if the administrator has to terminate prematurely;
  • In the checking wrapper, parse the default report format into a single-line-per-file compact format at time of checking;
  • In the checking wrapper, implement a simple history mechanism and file exclusions to reduce duplicate reporting. A simple (diff-based) mechanism proved to be as good as an earlier, more complex mechanism that considered more than two previous reports. We have chosen to disregard the complexity that would be introduced by using the capability to specify severity level or rulename at check time, which we haven't found useful in our environment.

Further Improvements

While the simple steps discussed so far will reduce the labor required to use Tripwire, a further reduction is possible within the structure/limitations imposed by program's architecture. It is also apparent that further gains in efficiency are necessary before Tripwire is quick and easy enough to use that people will not mind using it. In order to further improve the efficiency of operating Tripwire, the author suggests that the developers incorporate the following improvements into the next commercial version.

Abbreviated Reporting - On machines that are used for software development, an update of a software package (located in an area subject to Tripwire monitoring) that resides under its own root location can result in a large e-mail report. In such a case, very little information is provided by listing every changed file. This can be dealt with by generalizing the exclusions file to a check-time configuration file that contains exclusions and abbreviations. Abbreviations are filename wild-cards that cause a head directory name to be reported just once with a count of the number of files affected, if abbreviation mode is turned on at check time.

Read-Only Disk on Redhat Linux Hosts - Use of a switchable read-write/read-only SCSI disk requires that a SCSI reset be done when the protection switch is changed. Part of the author's development effort included writing a "remount" command that uses the SCSI reset capability available in user-level as of Solaris-7. (This feature had previously been used on IRIX-6 machines; IRIX-6 provides a canned user-level command for SCSI reset.) The author is currently investigating to what extent a ro/rw disk can function under Linux.

Speedier Database Update - Database update and re-check requires excessive elapsed time because the default update method requires an interactive editing step. Developers should investigate approaches that could place all of this activity in the background without unacceptable security risk, e.g. without Tripwire passwords visible in the process table.

Automated File Diffs - A change to an ASCII text file, e.g. "/etc/passwd", creates an obligation on the part of the Tripwire administrator to determine if changes are benign or not. The obvious way to do this is to diff the file against a copy of the same file taken from a backup prior to the file's last mod date. Unfortunately, this procedure is very time-consuming and so administrators tend to skip it except in unusual cases. Since some sites have automated backup systems from which files can be retrieved by name, Tripwire Inc. should look at development of an API for interfacing with these systems. If this proves to be feasible, it would probably be implemented only for files specified in the check-time configuration file, and file content signatures could be added to the abbreviated report format to support this.

Re restricting tripwire update to subdirs

martin f krafft <[email protected]> [2002-09-15 20:16:19 +0200]:
> [...preventing noise about directory changes...]
> How does one do that with tripwire 2.x? tripwire --update -I -R /etc
> doesn't work.

I stopped using Tripwire at version 1.2. After that they wigged out.
I converted to AIDE and have not looked back. But back in those days
there was an option -loosedir which would prevent tripwire from
complaining about directory modification time updates. Don't know if
that will help you or not.

  • SECURITY: SunWorld: Tripwire: The next generation of security tools [review]

    (Mar 3, 2000, 18:56) (Posted by john) (2 talkbacks posted) (575 reads)
    "Tripwire is an integrity assessment software package that maintains a database of file attributes and sends alerts when any of those attributes change. Essentially, it tells you if

    [Feb 23, 2000] Tripwire Setup Guide

    Tripwire Setup Guide
    by lyte, [email protected]
    Created on February 22nd, 2000.
    Last updated on February 23rd, 2000.

    If you're interested in Tripwire then let me be the first to welcome you to the world of the paranoid system admins. Tripwire can be a vital tool in detecting a compromise of your system.

    Tripwire generates a database of the most common files and directories on your system. Once it is generated, you can then check the current state of your system against the original database and get a report of all the files that have been modified, deleted or added.

    This comes in handy if you allow other people access to your machine and even if you don't, if someone else does get access, you'll know if they try to modify files such as /bin/login etc.

    SECURITY: Net Imperative: Linux suppliers integrate Tripwire security

    (Mar 3, 2000, 18:58) (Posted by dwj) (0 talkbacks posted) (469 reads)
    "The aim of the integration is to provide Linux applications with greater security and make Linux a more robust OS for e-business."

  • Recommended Links

    Google matched content

    Softpanorama Recommended

    Top articles

    Sites - Downloads -- outdated. Use rpmfind instead.

  • Click on one of the binaries below - we have presented 3 different formats - 2 Red Hat RPMs and a tarball.

  • Commercial versions of Tripwire are available for all major platforms including Solaris, Windows NT, HP-UX, and IBM AIX operating systems. To find out more, visit Tripwire Security Systems, Inc. -- company site. Bad thing about the product is that they do not post the price of the Web site. You need to request quotation. But approximate price is

  • RPMs for Red Hat Linux:

  • Project Tripwire - you can get 80% of functionality of the commercial version for free. Implementing Tripwire (v1.3) -- very basic document. Hardly better then nothing.

    Getting Started with Tripwire (Open Source Linux Edition)

    A crude yet effective intrusion detection system such as Tripwire can alert systems administrators to possible intrusion attempts by periodically verifying the integrity of a server's file systems. Systems intruders will often use trojan binaries for login, su, ps, and ls, etc. to cover their tracks and keep a low profile on the system. Under normal circumstances even astute systems administrators may not observe the intrusion because the trojan binaries mimic the system binaries so well.

    One tried and true method to alert systems administrators of unexpected file system alterations is to use a software package such as Tripwire to keep a database of checksums on the file sizes of critical system files. Depending on the configuration, Tripwire can notify appropriate personnel if a critical file or directory is modified or deleted.




    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.

    Created: May 16, 1997; Last modified: March 12, 2019