Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Solaris Inetd Services

News

Lecture Notes OSI Protocol Layers Recommended Books Recommended Links TCP Wrappers Xinetd Humor   Etc

Lecture Notes


Introduction

Originally, BSD Unix set a different server program running for every network service. As the number of services grew in the mid 1980s, Unix systems started having more and more server programs sleeping in the background, waiting for network connections. Although the servers were sleeping, they nevertheless consumed valuable system resources such as process table entries and swap space. Perhaps more importantly, configuring these servers was somewhat difficult, as each server was started up in a different way and had a different syntax for defining which port they should bind to and which UID they should use when running.

Today most Unix systems use the Internet daemon, inetd (or xinetd), to centralize the handling of lightweight Internet services. The inetd daemon listens and accepts connections on many network ports at the same time. When a connection is received, inetd starts up the appropriate TCP-based or UDP-based server running under the appropriate UID. The Internet daemon also simplifies the writing of application-specific daemons themselves, as each daemon can be written so that it reads from the network on standard input and writes back to the network on standard output—no special calls from the Berkeley socket library are required.

Note: Linux use an alternative Internet daemon called xinetd. Instead of locating all of its configuration in a single inetd.conf file, xinetd typically requires a separate configuration file for each service in the directory /etc/xinetd.d.

inetd uses the bind( ) call to attach itself to many network ports and then uses the select( ) call to determine which of these ports is the one that has received a connection.

The inetd daemon is run at boot time as part of the startup procedure. When inetd starts executing, it examines the contents of the /etc/inetd.conf file to determine which network services it is supposed to manage. The program will reread its configuration file if it is sent a HUP signal

A sample inetd.conf file
# Internet server configuration database
#
ftp       stream tcp nowait root    /usr/sbin/ftpd ftpd
#telnet   stream tcp nowait root    /usr/sbin/telnetd telnetd
#shell    stream tcp nowait root    /usr/sbin/rshd rshd
#login    stream tcp nowait root    /usr/sbin/rlogind rlogind
#exec     stream tcp nowait root    /usr/sbin/rexecd rexecd
#uucp     stream tcp nowait uucp    /usr/sbin/uucpd uucpd
#finger   stream tcp nowait nobody  /usr/sbin/fingerd fingerd
#tftp     dgram  udp wait   nobody  /usr/sbin/tftpd tftpd
#comsat   dgram  udp wait   root    /usr/sbin/comsat comsat
talk      dgram  udp wait   root    /usr/sbin/talkd talkd
ntalk     dgram  udp wait   root    /usr/sbin/ntalkd ntalkd
#echo     stream tcp nowait root    internal
#discard  stream tcp nowait root    internal
#chargen  stream tcp nowait root    internal
#daytime  stream tcp nowait root    internal
#time     stream tcp nowait root    internal
#echo     dgram  udp wait   root    internal
#discard  dgram  udp wait   root    internal
#chargen  dgram  udp wait   root    internal
#daytime  dgram  udp wait   root    internal
#time     dgram  udp wait   root    internal

Each line of the inetd.conf file contains at least six fields, separated by spaces or tabs:

Service name

Specifies the service name that appears in the /etc/services file. inetd uses this name to determine which port number it should listen to. If you are testing a new service or developing your own daemon, you may wish to put that daemon on a nonstandard port. Unfortunately, inetd requires that the service name be a symbolic value such as smtp, rather than a numeric value such as 25.

Socket type

Indicates whether the service expects to communicate via a stream or on a datagram basis.

Protocol type

Indicates whether the service expects to use TCP- or UDP-based communications. TCP is used with stream sockets, while UDP is used with dgram, or datagrams.

Wait/nowait

If the entry is "wait," the server is expected to process all subsequent connections received on the socket. If "nowait" is specified, inetd will fork( ) and exec( ) a new server process for each additional datagram or connection request received. Most UDP services are "wait," while most TCP services are "nowait," although this is not a firm rule. Although some manpages indicate that this field is used only with datagram sockets, the field is actually interpreted for all services.

User

Specifies the UID that the server process will be run as. This can be root (UID 0), daemon (UID 1), nobody (often UID -2 or 65534), or any other user of your system. This field allows server processes to be run with fewer permissions than root to minimize the damage that could be done if a security hole is discovered in a server program.

Command name and arguments

The remaining arguments specify the command name to execute and the arguments passed to the command, starting with argv[0].

Some services, like echo, time, and discard, are listed as "internal." These services are so trivial that they are handled internally by inetd rather than requiring a special program to be run. Although these services are useful for testing, they can also be used for denial of service attacks. You should therefore disable them.

You should routinely check the entries in the /etc/inetd.conf file and verify that you understand why each of the services in the file is being offered to the Internet. Sometimes, when attackers break into systems, they create new services to make future break-ins easier. If you cannot explain why a service is being offered at your site, you may wish to disable it until you know what purpose it serves. In many circumstances, it is better to disable a service that you are not sure about than it is to leave it enabled in an effort to find out who is using it at a later point in time: if somebody is using the service, they are sure to let you know! One easy way to list all of the services that are enabled is:

% grep -v "^#" /etc/inetd.conf
talk    dgram   udp     wait    root    /usr/sbin/tcpd  in.talkd
ntalk   dgram   udp     wait    root    /usr/sbin/tcpd  in.ntalkd
pop-3   stream  tcp     nowait  root    /usr/sbin/tcpd popper -c -C -p 2
auth    stream  tcp     nowait  nobody  /usr/sbin/tcpd identd -o -E -i

Because of the importance of the /etc/inetd.conf file, you may wish to track changes to this file using a source code control system such as RCS or CVS. You may also wish to use a consistency-checking tool such as Tripwire or detached PGP signatures to verify that all changes to the file are authorized and properly recorded.

The client-server model describes network services and the client programs of those services. One example of the client-server relationship is the name server and resolver model of the DNS. Another example of the client and server relationship is the NFS.

Starting and stopping services

To start services for server processes, you must know which files to use for automatic service configuration. You must also know how to manually start the services.

There are two ways of starting services: via inetd and via RC files

 Internet Service Daemon (inetd)

The inetd daemon is a special network process that runs on each system and starts server processes that do not automatically start at boot time. The inetd daemon is the server process for both the standard Internet services and Sun Remote Procedure Call (Sun RPC) services. The inetd daemon starts at boot time using the /etc/rc2.d/S72inetsvc script. A configuration file lists the services that the inetd daemon will listen for and start in response to network requests. If you do not specify a configuration file, the inetd daemon uses the default /etc/inet/inetd.conf file.

  1. To get the list of services that the inetd daemon listens for,  perform the command:

    # cat /etc/inet/inetd.conf
    .
    .(output truncated)
    .
    # TELNETD - telnet server daemon
    telnet stream tcp6 nowait root /usr/sbin/in.telnetd in.telnetd
    # smserverd to support removable media devices
    100155/1 tli rpc/ticotsord wait root
    /usr/lib/smedia/rpc.smserverd rpc.smserverd
    # REXD - rexd server provides only minimal authentication
    #rexd/1 tli rpc/tcp wait root /usr/sbin/rpc.rexd rpc.rexd
    # FTPD - FTP server daemon
    ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -a
    .
    .(output truncated)
    .

  2. When the inetd daemon receives a network request, it runs the associated command in the inetd.conf file.
     
  3. Structure of inetd.conf file Each entry is a single line in the following form:

    service-name endpoint-type protocol wait-status uid server-program \ server-arguments

Notes

The inetd daemon starts a server process when it receives an appropriate service request. The in.ftpd server process can be invoked by the inetd daemon each time a connection to the File Transfer Protocol (FTP) service is requested as shown in the following example:

# grep ftp /etc/inet/inetd.conf
ftp stream tcp6 nowait root /usr/sbin/in.ftpd in.ftpd -a

When changing the /etc/inet/inetd.conf file, send a hang-up (HUP) signal to the inetd process to force it to reread the configuration file:

# pkill -HUP inetd

Note – To turn off a service, add a # symbol to the beginning of the line corresponding to that service in the /etc/inetd.conf file, and send a HUP request.

Services Network Ports: Well known and Ephemeral Ports

Network ports help transport protocols distinguish between multiple service requests arriving at a given host computer. The TCP and UDP transport protocols identify ports using a positive integer between 1 and 65535, which is called a port number.

Network ports can be divided into two categories:

Port Numbers There are two fundamental approaches to port assignments:

Starting Services for Well-known Ports

Each network service uses a port that represents an address space reserved for that service. If a port number is not pre-assigned, the operating system allows an application to choose an unused port number. A client often communicates with a server through a well-known port.  The list of services that use a well-known port includes:

Starting Well-Known Port Services Startup Scripts

One of the well-known port services that starts at boot time is the sendmail process. The sendmail process uses well-known port 25 to perform network services for email using the Simple Mail Transport Protocol (SMTP). You can confirm that the name has been translated to the port number by searching for the mail entry in the /etc/inet/services file. To confirm the translation, perform the command: 

# grep mail /etc/inet/services
smtp 25/tcp mail

The sendmail process is initialized by the startup script /etc/rc2.d/S88sendmail when you boot the Solaris. Because the sendmail process uses port 25, the sendmail process starts listening at  port 25 for incoming mail activity soon after start up. There is no need for the inetd daemon to listen at port 25 for incoming sendmail requests or to start sendmail, because the sendmail process is already running.

Starting Well-Known Port Services on Demand using Inetd

The telnet service is a well-known port service that does not automatically start at boot time. For example the telnet service uses port 23. At the same time this services is used only episodically and it makes sense to run it only when there is a request to save memory. The inetd daemon can listen for telnet requests, so that the telnet service does not have to continually run on the system. When the inetd daemon  receives a network request at a port, it uses the information listed in the /etc/inet/service file to determine which service to start and if this is a telnet connection starts telnet daemon.

Here is a typical scenario that involves two system alisa and bill with alisa trying to connect to bill using telnet service:

  1. The initiating host alisa executes telnet bill command.
  2. The telnet service is a well-known service. The port for this service is port 23.
  3. The telnet packet requesting a connection goes to port 23 on the host bill.
  4. Initially, the inetd daemon listens at port 23 for the telnet service. The telnet bill command on alisa  generates a request to port 23 that inetd recognizes as a telnet request because of the configuration entry in the /etc/inet/services file (it associates ports and services for inetd).
  5. The telnet service does not continuously run on a system waiting for a connection. The inetd daemon must start the telnet service dynamically on demand.
  6. The inetd daemon consults the /etc/inetd.conf file to find a matching entry for the requested service. The inetd daemon  identifies the telnet service line.
  7. The inetd daemon executes the in.telnetd process from the /etc/inetd.conf file. The in.telnetd daemon takes control of the current telnet session’s communication.
  8. The in.telnetd daemon receives this session’s traffic and runs on port 23 until this telnet session ends.

Note – The inetd daemon continues to listen for new service requests.

Inetd Enhancements and Replacements

One typical enhancement of indet that provides better security is TCP Wrappers. the idea of TCP Warappers is realy simple: to screen the connection based on the rules contained in certain files (hosts.allow, host.deny) and based onthis screening to grant of deny request.  If the request is allowed, then the the corresponding server process (e.g ftp) can be started. This mechanism is also referred to as tcp_wrapper. Solaris 9 can be installed with TCP wrappers in the default installation. And TCP Wrappers are standard in Solaris 10.

There is also a  replacement for inetd, called xinetd that includes built-in TCP wrapper functionality. Like combination of  inetd+tcpd, it enables the configuration of the access rights for a given machine, but it can do more:

 It is often used in Linux distributions, but not in Solaris.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

A Simple Socket Server Using 'inetd'

Perl code for simple server and client.

24.9. When to use or not to use inetd

The decision to add or move a service into or out of inetd(8) is usually based on server load. As an example, on most systems the telnet daemon does not require as many new connections as say a mail server. Most of the time the administrator has to feel out if a service should be moved.

A good example I have seen is mail services such as smtp and pop. I had setup a mail server in which pop3 was in inetd(8) and exim was running in standalone, I mistakenly assumed it would run fine since there was a low amount of users, namely myself and a diagnostic account. The server was also setup to act as a backup MX and relay in case another heavily used one went down. When I ran some tests I discovered a huge time lag for pop connections remotely. This was because of my steady fetching of mail and the diagnostic user constantly mailing diagnostics back and forth. In the end I had to move the pop3 service out of inetd(8).

The reason for moving the service is actually quite interesting. When a particular service becomes heavily used, of course, it causes a load on the system. In the case of a service that runs within the inetd(8) meta daemon the effects of a heavily loaded service can also harm other services that use inetd(8). If the multiplexor is getting too many requests for one particular service, it will begin to affect the performance of other services that use inetd(8). The fix, in a situation like that, is to make the offending service run outside of inetd(8) so the response time of both the service and inetd(8) will increase.

Chapter 24. The Internet Super Server inetd

Another reason to use inetd is that you can use TCP-wrappers with it. Mail daemons are usually complied with TCP-wrappers library support but this is not true for other daemons.

24.9. When to use or not to use inetd

The decision to add or move a service into or out of inetd(8) is usually based on server load. As an example, on most systems the telnet daemon does not require as many new connections as say a mail server. Most of the time the administrator has to feel out if a service should be moved.

A good example I have seen is mail services such as smtp and pop. I had setup a mail server in which pop3 was in inetd(8) and exim was running in standalone, I mistakenly assumed it would run fine since there was a low amount of users, namely myself and a diagnostic account. The server was also setup to act as a backup MX and relay in case another heavily used one went down. When I ran some tests I discovered a huge time lag for pop connections remotely. This was because of my steady fetching of mail and the diagnostic user constantly mailing diagnostics back and forth. In the end I had to move the pop3 service out of inetd(8).

The reason for moving the service is actually quite interesting. When a particular service becomes heavily used, of course, it causes a load on the system. In the case of a service that runs within the inetd(8) meta daemon the effects of a heavily loaded service can also harm other services that use inetd(8). If the multiplexor is getting too many requests for one particular service, it will begin to affect the performance of other services that use inetd(8). The fix, in a situation like that, is to make the offending service run outside of inetd(8) so the response time of both the service and inetd(8) will increase.

The inetd - -etc-inetd.conf file from Securing and Optimizing Linux by Gerhard Mourani

Old Red Hat inetd configuration is like Solaris.

inetd, called also the super server, will load a network program based upon a request from the network. The inetd.conf file tells inetd which ports to listen to and what server to start for each port.

The first thing to look at as soon as you put your Linux system on ANY network is what services you need to offer. Services that you do not need to offer should be disabled and uninstalled so that you have one less thing to worry about, and attackers have one less place to look for a hole. Look at your /etc/inetd.conf file to see what services are being offered by your inetd program. Disable what you do not need by commenting them out by adding a # at the beginning of the line, and then sending your inetd process a SIGHUP command to update it to the current inetd.conf file.

  1. Change the permissions on this file to 600.
                 [root@deep] /#chmod 600  /etc/inetd.conf
                 
  2. Ensure that the owner is root.
                 [root@deep] /# stat /etc/inetd.conf
                 
    
                 File: "/etc/inetd.conf"
                 Size: 2869         Filetype: Regular File
                 Mode: (0600/-rw-------)         Uid: (    0/    root)  Gid: (    0/    root)
                 Device:  8,6   Inode: 18219     Links: 1    
                 Access:	Wed	Sep	22	16:24:16	1999(00000.00:10:44)
                 Modify:	Mon	Sep	20	10:22:44	1999(00002.06:12:16)
                 Change:	Mon	Sep	20	10:22:44	1999(00002.06:12:16)
                 

  3. Edit the inetd.conf file vi /etc/inetd.conf and disable services like: ftp, telnet, shell, login, exec, talk, ntalk, imap, pop-2, pop-3, finger, auth, etc. unless you plan to use it. If it's turned off, it's much less of a risk.
                 # To re-read this file after changes, just do a 'killall -HUP inetd'
                 #
                 #echo	stream	tcp	nowait	root	internal
                 #echo	dgram	udp	wait	root	internal
                 #discard	stream	tcp	nowait	root	internal
                 #discard	dgram	udp	wait	root	internal
                 #daytime	stream	tcp	nowait	root	internal
                 #daytime	dgram	udp	wait	root	internal
                 #chargen	stream	tcp	nowait	root	internal
                 #chargen	dgram	udp	wait	root	internal
                 #time	stream	tcp	nowait	root	internal
                 #time	dgram	udp	wait	root	internal
                 #
                 # These are standard services.
                 #
                 #ftp	stream	tcp	nowait	root	/usr/sbin/tcpd	in.ftpd -l -a
                 #telnet 	stream	tcp	nowait	root	/usr/sbin/tcpd	in.telnetd
                 #
                 # Shell, login, exec, comsat and talk are BSD protocols.
                 #
                 #shell	stream	tcp	nowait	root	/usr/sbin/tcpd	in.rshd
                 #login	stream	tcp	nowait	root	/usr/sbin/tcpd	in.rlogind
                 #exec	stream	tcp	nowait	root	/usr/sbin/tcpd	in.rexecd
                 #comsat	dgram	udp	wait	root	/usr/sbin/tcpd	in.comsat
                 #talk	dgram	udp	wait	root	/usr/sbin/tcpd	in.talkd
                 #ntalk	dgram	udp	wait	root	/usr/sbin/tcpd	in.ntalkd
                 #dtalk 	stream	tcp	wait	nobody	/usr/sbin/tcpd	in.dtalkd
                 #
                 # Pop and imap mail services et al
                 #
                 #pop-2	stream	tcp	nowait	root	/usr/sbin/tcpd	ipop2d
                 #pop-3	stream	tcp	nowait	root	/usr/sbin/tcpd	ipop3d
                 #imap	stream	tcp	nowait	root	/usr/sbin/tcpd	imapd
                 #
                 # The Internet UUCP service.
                 #
                 #uucp	stream	tcp	nowait	uucp	/usr/sbin/tcpd  /usr/lib/uucp/uucico    -l
                 #
                 # Tftp service is provided primarily for booting.  Most sites
                 # run this only on machines acting as "boot servers." Do not uncomment
                 # this unless you *need* it.  
                 #
                 #tftp	dgram	udp	wait	root	/usr/sbin/tcpd	in.tftpd
                 #bootps	dgram	udp	wait	root	/usr/sbin/tcpd	bootpd
                 #
                 # Finger, systat and netstat give out user information which may be
                 # valuable to potential "system crackers."  Many sites choose to disable 
                 # some or all of these services to improve security.
                 #
                 #finger	stream	tcp	nowait	root	/usr/sbin/tcpd	in.fingerd
                 #cfinger	stream	tcp	nowait	root	/usr/sbin/tcpd	in.cfingerd
                 #systat	stream	tcp	nowait	guest	/usr/sbin/tcpd	/bin/ps -auwwx
                 #netstat	stream	tcp	nowait	guest	/usr/sbin/tcpd	/bin/netstat    -f inet
                 #
                 # Authentication
                 #
                 #auth	stream	tcp	nowait	nobody	/usr/sbin/in.identd    in.identd -l -e -o
                 #
                 # End of inetd.conf
                 

  4.              [root@deep] /# killall  -HUP inetd
               

  5. One more security measure you can take to secure the inetd.conf file is to set it immutable, using the chattr command. To set the file immutable simply, execute the following command:
                 [root@deep] /# chattr  +i /etc/inetd.conf
                 
    This will prevent any changes accidental or otherwise to the inetd.conf file. A file with the immutable attribute set i cannot be modified, deleted or renamed, no link can be created to this file and no data can be written to it. The only person that can set or clear this attribute is the super-user root. If you wish later to modify the inetd.conf file you will need to unset the immutable flag: To unset the immutable flag, simply execute the following command:
                 [root@deep] /# chattr -i /etc/inetd.conf
                 

Note: Don't forget to send your inetd process a SIGHUP signal killall -HUP inetd after making change to your inetd.conf file. The services you enable on a selected host depend on the functions you want the host to provide. Functions could support the selected network service, other services hosted on this computer, or development and maintenance of the operating system and applications.

Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

inetd - Wikipedia, the free encyclopedia

The inetd Super-Server FreeBSD page where the idea originated. BTW daytime, time, echo, discard, chargen, and auth are all internally provided services of inetd.

inetd Daemon

inetd Daemon

inetd.conf File Format for TCP/IP

Chapter 24. The Internet Super Server inetd

Chapter 11: inetd: the Internet super server

Configuring the Internet Daemon, inetd

The inetd Super-Server

Understanding inetd

xinetd



Etc

Society

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

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related 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 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. www.softpanorama.org 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

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 Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March, 12, 2019