Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Solaris System Logs

News Recommended Links Reference Pipes in syslog Log rotation is Solaris Syslog daemon

/var/adm/messages

/var/log/sulog

loginlog

/var/cron/log Lastlog How to rotate wtmpx in solaris
Perl Log Tools http logs Remote Syslog syslog-ng    
Event correlation Tips Horror Stories Random Findings Humor Etc

A system log is a recording of certain events. The kind of events found in a system log is determined by the nature of the particular log and any configurations used to control those events that are logged. System logs are usually text files containing a timestamp and other information specific to the message or subsystem.

One issue with log files is the difference between how Windows and UNIX each maintain open files. In UNIX, although it is not possible to remove a file that is currently open, it is possible to rename that file. In Windows, it is necessary to manipulate the access control list (ACL) of the file before renaming the file; a simple rename fails.

Both Windows and UNIX do share the behavior, if the file is open, and it is renamed, the process continues to write to that renamed file. In order for a process that keeps a file open to write to the original name, it must be restarted. Upon restart, the process creates a new file with the original name.

This is in contrast with processes, which open a file, write to it, and then close it. If the file was open at the time of the rename, the process continues to finish the write operation before closing the file descriptor. When the process is ready to write again, it writes to the original name, thus creating a new file.

Logs are rotated using logadm -- a special utility introduced in Solaris 9.


Top updates

Softpanorama Switchboard
Softpanorama Search


NEWS CONTENTS

Old News ;-)

Re Solaris log files

I vote for /var/log/cron.19990220, /var/log/ftp.19990220, /var/log/authlog.199902, etc. Do you have so many logs online that they need more than one flat directory? Then go one more level down, but not 4. Also, putting the timestamp in the filename makes restores and greps of the files less confusing.

But I think the problem is even bigger than that.

Some log files grow VERY RAPIDLY -- many megabytes per day. Some grow very slowly. authlog comes to mind. It's best to keep individual log files under some certain size. 1MB is great. 10MB is OK. 50MB is getting kinda big.

But with these different growth rates, the tendency is to age some of them daily, others weekly, others yearly(!).

Then there's the annoying ones like wtmp that are binary.

And let's not forget that some processes need to be restarted after a logfile move, while others don't.

And some programs follow the paradigm "my logfile must exist and be writable by me or else I will silently log nothing".

I've always considered writing some tool that would allow you to manage and age all your log files from one config file. Maybe the config file would be a table that lists the base logfile name, the interval at which it gets aged, the number of logs or amount of space to keep online before deleting them, etc.

Anybody know of any such program? It might be too much work for too little gain.

The ultimate would be an ADAPTIVE process that keeps fewer old logs online if space is getting tight, etc. Personally I think an adaptive news expire program would be nice, too.

I'll get right on these, as soon as I get this other stuff done for my boss... :-)

Todd Williams Manager, Computer and Communication Systems
MacNeal-Schwendler Corp. ("MSC"), 815 Colorado Blvd., Los Angeles, CA 90041
todd.williams@macsch.com (323)259-4973 http://www.macsch.com/
geek n. : a carnival performer often billed as a wild man whose act usu.
includes biting the head off a live chicken or snake -Webster's New Collegiate

CERT/Understanding system log files on a Solaris

Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.

All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.

Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.

[PDF] Solaris™ Operating Environment Security

Log Files

Log file are used by the system and applications to record actions, errors, warnings, and problems. They are often quite useful for investigating system quirks, for discovering the root causes of tricky problems, and for watching attackers. There are typically two types of log files in the Solaris Operating Environment: system log files which are typically managed by the syslog daemon and application logs which are created by the application.

set sys:coredumpsize = 0

Log Files Managed by syslog

The syslog daemon receives log messages from several sources and directs them to the appropriate location based on the configured facility and priority. There is a programmer interface, syslog(), and a system command, logger, for creating log messages. The facility (or application type) and the priority are configured in the /etc/syslog.conf file to direct the log messages. The directed location can be a log file, a network host, specific users, or all users logged into the system. By default, the Solaris Operating Environment defines two log files in the /etc/syslog.conf file. The /var/adm/messages log files contains a majority of the system messages. The /var/log/syslog file contains mail system messages. A third log file is defined but commented out by default. It logs important authentication log messages to the /var/log/authlog file. Uncomment the following line in /etc/syslog.conf to enable logging these messages: Save the file and use the following command to force syslogd to re-read its configuration file:

All of these files should be examined regularly for errors, warnings, and signs of an attack. This task can be automated by using log analysis tools or a simple grep command.

Application Log Files

Application log files are created and maintained by commands and tools without using the syslog system. The Solaris Operating Environment includes several commands that maintain their own log files. Here is a list of some of the Solaris Operating Environment log files:

/var/adm/sulog messages from /usr/bin/su

/var/adm/vold.log messages from /usr/sbin/vold

/var/adm/wtmpx user information from /usr/bin/login

/var/cron/log messages from /usr/sbin/cron

The /var/adm/wtmpx file should be viewed with the last command.

#auth.notice ifdef(`LOGHOST’, /var/log/authlog, @loghost)

# kill -HUP `cat /etc/syslog.pid`

The /var/adm/loginlog file does not exist in the default of the Solaris Operating Environment installation, but it should be created. If this file exists, the login program records failed login attempts. All of these logs should also be monitored for problems.

Recommended Links

Softpanorama Top Visited

Softpanorama Recommended

CERT/Understanding system log files on a Solaris

Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.

All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.

Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.

 

Reference

Man Pages

adm/messages

This file is a catch-all log file for a number of messages from the UNIX kernel as well as for other logging applications such as syslogd. The file is formatted as an ASCII text file and entries are usually one record per line with new entries appended to the end of the file.

The following is a sample excerpt from a messages file. Each pair of lines shown below appears as one line in the file:

Oct 31 04:05:01 unix.fghij.net syslogd:restart
Oct 31 04:05:02 unix.fghij.net named[112]: unapproved query
from  [10.10.0.1].32768 for "loghost.local.net"
Oct 31 04:05:02 unix.fghij.net named[112]: unapproved 
query from [10.10.0.1].32768 for "loghost.local.net"
Oct 31 04:05:42 unix.fghij.net printd[207]: send_job failed job 203
(lw_land@lw.fghij.net)check status
Oct 31 04:06:00 unix.fghij.net sendmail[14602]: EAA14602: from=ih_cron, 
size=456, class=0, pri=30456, ...
Oct 31 04:06:01 unix.fghij.net sendmail[14604]: EAA14602: to=ih_cron, 
delay=00:00:01, xdelay=00:00:00, ...
Oct 31 04:06:42 unix.fghij.net printd[207]: send_job failed job 203 
(lw_land@lw.fghij.net) check status
Oct 31 04:07:42 unix.fghij.net printd[207]: send_job failed job 203
(lw_port@lw.jghij.net)check status

Note that the messages file can get very large quickly and should be rotated regularly to ensure that it does not consume too much local disk space. Refer to "Using newsyslog to rotate files containing logging messages on systems running Solaris " for more information.

/var/log/sulog

The sulog file, /var/adm/sulog, is a log containing all attempts (whether successful or not) of the su command. An entry is added to the sulog file every time the su command is executed. The fields in sulog are: date, time, successful (+) or unsuccessful (-), port, user executing the su command, and user being switched to. In the preceding example, all su attempts were successful, except for the attempt on 2/23 at 20:51, when user pete unsuccessfully attempted to su to user root.

Look for entries where an unauthorized user has used the command inappropriately. The following entry shows a successful (indicated by +) su from user userid to root.

SU 03/31 12:52 + pts/0 <userid>-root

Look for failed su attempts.

SU 03/31 12:52 - pts/0 <userid>-root

Look for su occurring at unusual times during the day (e.g., after hours, very early in the morning).

SU 03/31 02:12 + pts/0 <userid>-root

SU 11/04 09:43 + ??? root-uucp
SU 11/06 10:24 + pts/5 mcevoyg-root
SU 11/06 10:44 + pts/6 mcevoyg-root
SU 11/06 11:30 + pts/2 mcevoyg-root
SU 11/07 14:07 + pts/2 mcevoyg-root
SU 11/07 14:24 + pts/5 mcevoyg-root
SU 11/07 14:43 + pts/2 mcevoyg-root
SU 11/07 14:46 + pts/1 mcevoyg-root
SU 11/12 10:41 + pts/1 mcevoyg-root
SU 11/12 15:59 + pts/2 mcevoyg-root
SU 11/12 16:24 + pts/2 mcevoyg-root
SU 11/13 09:20 + pts/2 mcevoyg-root
SU 11/17 10:37 + pts/2 mcevoyg-root
SU 11/17 14:54 + pts/2 mcevoyg-root
SU 11/17 16:26 + pts/3 hilgarj-root
SU 11/17 22:22 + pts/3 hilgarj-root
SU 11/18 09:13 - pts/2 mcevoyg-root
SU 11/18 09:14 - pts/2 mcevoyg-root
SU 11/18 09:14 - pts/2 mcevoyg-root
SU 11/18 09:14 - pts/2 mcevoyg-root
SU 11/18 09:14 + pts/2 mcevoyg-root
SU 11/18 11:45 + pts/2 mcevoyg-root
SU 11/30 14:43 - pts/3 mcevoyg-root

loginlog

Unsuccessful login attempts after five consecutive failures are logged in the file /var/adm/loginlog, only if the file /var/adm/loginlog exists and is owned by root, group sys, and has read and write permissions only for root. Follow this procedure to create and configure the file /var/adm/loginlog for unsuccessful login attempt logging:

  1. Log in (or su) as root.

  2. Enter the command touch /var/adm/loginlog.

  3. Enter the command chown root /var/adm/loginlog.

  4. Enter the command chgrp sys /var/adm/loginlog.

  5. Enter the command chmod 600 /var/adm/loginlog.

The following is an example entry written into /var/adm/loginlog.

adm:/dev/pts/9:Tue May  5 21:07:49 1998

This entry indicates that a user attempted to log in as user adm on port /dev/pts/9 on May 5 at 9:07 P.M.

 

Last Log

The last command displays login/logout and system boot information in time sequence order. last reads the binary file /var/adm/wtmpx, which is written to every time a user logs in or out and when the system is rebooted. An example last command output is

pete      console      :0               Wed Apr  1 20:52   still logged in
pete      console      :0               Wed Apr  1 20:40 - 20:51  (00:10)
pete      console      :0               Mon Feb 23 21:31 - 20:39 (36+23:08)
reboot    system boot                   Mon Feb 23 21:13
pete      console      :0               Sun Feb 15 20:03 - 21:11 (8+01:07)
reboot    system boot                   Sun Feb 15 20:02
pete      console      :0               Sat Feb  7 16:05 - 20:00 (8+03:55)
reboot    system boot                   Sat Feb  7 15:44
pete      console      :0               Tue Feb  3 22:50 - 15:42 (3+16:51)
root      console      :0               Tue Feb  3 21:04 - 22:50  (01:46)
pete      console      :0               Tue Feb  3 20:59 - 21:03  (00:04)
root      console      :0               Tue Feb  3 20:52 - 20:59  (00:06)
pete      console      :0               Tue Feb  3 20:38 - 20:52  (00:13)
root      console      :0               Tue Feb  3 20:35 - 20:38  (00:02)
pete      console      :0               Tue Feb  3 20:19 - 20:35  (00:15)
pete      console      :0               Tue Feb  3 20:18 - 20:19  (00:00)
pete      console      :0               Tue Feb  3 20:18 - 20:18  (00:00)
root      console      :0               Tue Feb  3 20:12 - 20:18  (00:05)
reboot    system boot                   Tue Feb  3 20:11
reboot    system boot                   Tue Feb  3 18:56
root      console      :0               Fri Jan 30 09:11 - 09:12  (00:00)
reboot    system boot                   Wed Jan 28 11:26
root      console      :0               Fri Jan 23 15:00 - 11:25 (4+20:25)
reboot    system boot                   Thu Jan 22 15:14
wtmp begins Thu Jan 22 15:14

See also How to rotate wtmpx in solaris

Install Log

The system install log, found in /var/sadm/system/logs/install_log, is generated when Solaris is installed on the system. The install log contains all of the character output generated throughout Solaris installation. The log contains information such as disk partitioning and formatting, software module installation status, and mount points.

Volume Manager Log

The volume manager log, /var/adm/vold.log, is used by the Solaris Volume Manager (the software that manages the CD-ROM and diskette drives and automates the user-system interaction when using those drives).

 

sysidtool Log

The sysidtool log, found in /var/sadm/system/logs/sysidtool.log, is generated by the sysidtool tool suite, itself run automatically at system installation time or when the system is unconfigured with sys-unconfig. This log can be useful for double-checking the configuration of a newly installed or reinstalled system to see what, if any, changes have occurred.

Solaris systems use the /var directory to store logs and other local files so that the operating system can support other directories being mounted as read only, sometimes from file servers elsewhere on the network. The /var directory is thus often on a partition that is local to the system.

The generic Solaris  installation includes a syslog file that sends most logging information to the /var/adm/messages file; only mail.debug information is sent to the /var/adm/syslog file. One particular shortcoming of the Solaris default installation is that auth.notice messages aren't logged anywhere.

All of the log files described below can be found in subdirectories under /var. There may be other application-specific log files that you will also need to inspect. However, it is beyond the scope of this implementation to describe all of the log files that you might want to inspect for your specific Solaris installation.

Because log files often provide the only indication of an intrusion, intruders often attempt to erase any evidence of their activities by removing or modifying the log files. For this reason, it is very important that your log files be adequately protected to make it as difficult as possible for intruders to change or remove then. See the practice "Managing logging and other data collection mechanisms" for more information on this topic.

adm/utmp, adm/utmpx, /adm/wtmp, and adm/wtmpx

These files contain user and accounting information that is recorded when a user logs in, logs out, or starts a new shell process with an application such as xterm or screen.Records written to these log files by the managing application contain account activity for the system.

The data in these files are written as binary data so they must be read by a tool specifically designed to do so, such as last(1) and who(1). See the system man pages for last(1) and who(1) for additional information on the data and display formats available with these tools.

adm/lastlog

This binary log file stores information about a user who has logged into the system. It is kept up to date by utilities such as login(1) and in.uucpd(1M). The data are viewable with tools such as last(1), who(1), and finger(1). Refer to the system man pages for more information.

adm/sulog

The sulog file is a record of all attempts by users on the system to execute the su(1M) command. Each time su(1M) is executed, an entry is added to the sulog file.

The format of this human-readable text file includes date, time, success/failure (+/-), and both the current and requested account. The following is a sample excerpt from a sulog file:

 
SU 08/28 11:41 - pts/1 jxk-root
SU 08/28 11:41 + pts/1 jxk-root
SU 09/14 13:05 + pts/0 thimbl-root
SU 09/14 14:58 + pts/0 thimbl-root
SU 09/16 13:52 + pts/0 thimbl-root
SU 09/16 15:16 + pts/2 thimbl-guest
SU 10/19 14:17 - pts/2 marchok-root
SU 10/19 14:17 + pts/2 marchok-root


/var/log This log directory is sometimes used to store miscellaneous log files, including log files ceated by syslog for messages that are not written to /usr/adm/messages or to the system console.

Syslog files

Often a number of miscellaneous syslog files are written to /var/log for logging events that are not logged elsewhere such as main, news, and user events. You can view which of these events are written to this directory (or any other log files) by reviewing the syslog config file /etc/syslog.conf. For example, the following syslog.conf file writes several specific log files to the /var/log directory:

#
syslog configuration file (loghost)
#
#output to console
*.err;mail,kern.notice;daemon,auth.debug;user.info    /dev/console
#output to local file "messages" for automatic log file analysis
*.err;auth,daemon,mark,kern.debug;mail,user.notice    var/adm/messages
#output to local files for archiving messages of potential interest
auth.debug /var/log/auth.log
daemon.debug /var/log/daemon.log
lpr.debug   /var/log/lpr.log
mail.debug  /var/log/mail.log
news.debug  /var/log/news.log
uucp.debug  /var/log/uucp.log
user.debug  /var/log/user.log
#
#end of /etc/syslog.conf
#

log/sysidconfig.log

This log file is created by the sysidconfig(1M) command, which executes system configuration applications or defines a set of system configuration applications. Specific information about this and other related system configuration tools can be found in the system man pages for sysidconfig.


/var/cron This directory contains the files that you would find associated with the system's cron(1M) and at(1) functions.

cron/log

This file contain log entries for cron(1M) and at(1) jobs that have been run on the local machine. This file is a text file that lists the command that was run, at what time, and as what user. The following example log file contains both a cron and at job entry:

> CMD: /usr/lib/uucp/uudemon.hour
> uucp 14572 c Mon Nov 9 19:11:00 1998
< uucp 14572 c Mon Nov 9 19:11:00 1998
> CMD: 910656780.a
> root 14592 a Mon Nov 9 19:13:00 1998
< root 14592 a Mon Nov 9 19:13:01 1998

Random Findings

/var/log/utmp; /var/log/utmpx

These logs keep track of users currently logged into the system. Using the who command, check the users logged in at the current time:

<userid> pts/1 Mar 31 08:40 (origination hostname)

Look for user logins that are unexpected (e.g., for staff on vacation), occur at unusual times during the day, or originate from unusual locations.

/var/log/wtmp; /var/log/wtmpx

These logs keep track of logins and logouts. Using the last command, do the following:

Look for user logins occurring at unusual times.

<userid> pts/4 <hostname> Sat Mar 22 03:14 - 06:02 (02:47)

Look for user logins originating from unusual places (locations, addresses, and devices).

<userid> pts/12 <strange hostname> Fri Mar 21 08:59 - 13:30 (04:31)

Look for unusual reboots of the system.

reboot system boot Sun Mar 23 05:36

/var/log/syslog

By default, the syslog file will contain only messages from mail (as defined in the /etc/syslog.conf file). Look for anything that looks unusual.

/var/adm/messages

This log records system console output and syslog messages. Look for unexpected system halts.

Look for unexpected system reboots.

Mar 31 12:48:41 ahost.domain.com unix: rebooting...

Look for failed su and login commands.

Mar 30 09:14:00 <hostname> login: 4 LOGIN FAILURES ON 0, <userid>

Mar 31 12:37:43 <hostname> su: 'su root' failed for <userid> on /dev/pts/??

Look for unexpected successful su commands.

Mar 28 14:31:11 <hostname> su: 'su root' succeeded for <userid> on /dev/console

/var/adm/pacct

This log records the commands run by all users. Process accounting must be turned on before this file is generated. You may want to use the lastcomm command to audit commands run by a specific user during a specified time period.

compile <userid> ttyp1 0.35 secs Mon Mar 31 12:59

/var/adm/aculog

This log keeps track of dial-out modems. Look for records of dialing out that conflict with your policy for use of dial-out modems. Also look for unauthorized use of the dial-out modems

Other log files   Solaris  includes Basic Security Module (BSM), but it is not turned on by default. If you have configured this service, review all the files and reports associated with BSM for the various kinds of entries that have been described in the practice "Inspect your system and network logs."

 If your site has large networks of systems with many log files to inspect, consider using tools that collect and collate log file information. As you learn what is normal and abnormal for your site, integrate that knowledge into your specific procedures for inspecting log files.




Etc

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 in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes.   If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner. 

ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.  

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 quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard 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 DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

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

Most popular humor pages:

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

The Last but not Least


Copyright © 1996-2015 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.

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.

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 softpanorama.org is down currently there are two functional mirrors: softpanorama.info (the fastest) and softpanorama.net.

Disclaimer:

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.

Last modified: June 04, 2016