Unix System Calls Links

Reference

Linux Syscall Reference

fxr.watson.org sys-kern-syscalls.master

Linux System Call Table

Wikipedia

System call - Wikipedia, the free encyclopedia

• Fork (operating system) - Wikipedia, the free encyclopedia
• stat (Unix) - Wikipedia, the free encyclopedia

System Calls -- slides

• System call is to invoke system provided functions.
• System calls deals with sytem level resources, such as memory allocation, setting time, create new process, etc.
• Real system calls are done in the form of interrupts. Assembly level coding. Inconvenient to use.
• What we normally use are the system library functions which put wraps over the system calls, so we can use the familiar function call interfaces.
• The system library functions are often at too low a level, you may want to wrap it in your own routines.
• Many functions can be made accessible through #include <.h>
• man page of functions always tell you what include file to use.
• Allocating memory dynamically, e.g. buiding a linked list.

mail() {

struct rec { char name[20];

int number;

struct rec *next; }

struct rec *a; /* declare the pointer */

a = (struct rec *) malloc(sizeof(struct rec)); /* get the memory */

a-> = (struct rec *) malloc(sizeof(struct rec)); /*get another one*/

scanf("%s %d", a->, &(a->));

….

free(a); /* release the fist node and loose the second */

}

-->

• Use system() . ( #include <.h> )
• Example: the list of current directory and print it.

mail( ) {

FILE *fp, *fopen(); char c;

system("ls -l > tmp"); /* invoking bourne shell */

fp = fopen("tmp", "r");

while ( (c = getc(fp)) != EOF)) putchar(c);

fclose(fp);

}

-->

Use pipe

• Use pipe to read the results of a shell command or provide input to a shell command.

main( ) {

FILE *infp, *outfp, *popen( ); int c;

infp = popen("ls -l", "r"); /* equivelant to ls -l | thisprogram */

outfp = popen("mail qli", "w");

while ( ( c = getc(infp)) != EOF) fprintf(outfp, "%c", c);

pclose(infp);

pclose(outfp);

}

-->

Process Control (cont.)

• Process creation/termination
  • fork( ) exit( )
  • execl( ) excelc( ) exclv( ) execv( ) execve( ) execvp( )
• Communication/synchronization
  • wait( ) pipe( ) sleep( ) alarm( ) signal( ) kill( )
  • setjmp( ) longjmp( )
  • The System V IPC:
  • msgget( ) msgsnd( ) msgrcv( ) msgctl( )
  • semget( ) semop( ) semctl( )
  • shmget( ) shmat( ) shmdt( ) shmctl( )

fork( )

• int fork( )
  • creates a new (child) process which is identical to the caller (the parent process).
  • the child process inherits:
    • the code
    • the environment
    • all signal setting
    • set user and group ids
    • time left one the alarm clock
    • current working directory
    • all open file descriptors (copies)
  • fork() returns -1 if a child cannot be created. Otherwise it returns: 0 -- if the process is the child the process id of the child -- if the processs is the parent.

Example:

….

if ( (pid == fork( )) != 0 ) {
printf("I am the parent process\n");
… other stuff
wait(&status);
}
else {
printf("I am the child process\n");
…. other child process code
}

• How many new processes will be greated if the following sequence is executed: fork( ); fork( );

Event Detection (Signal)

• Signals (interrupts) can be sent to processes. You can ignore a signal, take default action on a signal, or catch the signal.
• During the execution of a process an interrupt (singal) can be sent to the process by "kill" command, by kill( ) system call, and alarm( ) system call.
• If you program does not specify anything about signal, the default action will be taken by the system, normally termination.
• You can set up traps to catch the signals and invoke your own signal handler routines.
• Set a trap (calling signal() function):

  #include <.h>
  
  main( ) {
  ….
  signal(SIGINT, handler(SIGINT));
  /* call hander() if SIGINT arrives */

Signal (cont.)

• The handler is a function that you define as handler(int signal) { … check the signal type; … take action accordingly }
• Upon return from the handler, the execution continues from the interrupted point.
• You can use signal(SIG???, SIG_IGN) to ignore the signal SIG???. In this case your program is not disturbed.
• signal(SIG???, SIG_DFL) : take default action. Normally terminate.
• There are about 30 signals. Look at "man 5 signal". E.g., HUP, INT, KILL, STOP, ALRM, etc.
• Example:

kill -HUP pid Many system daemons catch this signal and reinitialize themselves.

Signal (cont.)

• User may generate a signal by using kill() and alarm() system call
• int kill(int process_id, int signal_name);
  • kill() function can generate any signal and send to the processs specified.
• unsigned alarm(int seconds);
  • wait the specified number of seconds and send ALRM signal to the process who called this function.
• Example: set timeout for a process

  …..
  
  signal(SIGALRM, handletimeout());
  …..
  alarm(20);
  ….
  void handletimeout() { …. }

setjmp & longjmp (<.h>)

• allow inter-fcuntion goto and bypass the usual return sequence
• int setjmp(jump_buf buf);
  • save the current state of the caller in the argument and then return 0
• void longjmp(jump_buf buf, int val);
  • Pass control to the return address stored in the first argument which was set by an earlier setjmp() call.
  • The result will appear to be a return from the last setjmp() call with the save buf.
  • The second paramemter will be the return val of setjmp(). If val is 0, setjmp() will return 1.
• Example:

#include <.h>

#include <.h>

#include </signal.h>

#define TIMEOUT 10

static jmp_buf jbuf;

main(int argc, char argv[ ]) {

FILE *fp;

int ecode;

if ( ( fp = fopen( argv[1], "r") == NULL){

perror("ca't open file"); exit(1); }

while (1) {

if (setjmp(jbuf)) == TIMEOUT ) {

printf("Timeout\n"); ecode=0; break;}

else {

signal(SIGALRM, wentoff);

alarm(10);

printf(Enter ID number:");

• 
  

if (scanf("%d%*c", &id) == EOF) {

ecode = 0; break; }

alarm(0); /* cancel alarm */

if (fseek(fp,id*sizeof(cust), 0)

==NULL) {

perror("can't seek");ecode=1;break;

} else if ( fread((char *) &cust,

sizeof(cust), 1, fp) ! = 1) {

perror("can't read");ecode=1;break;}

print_info(cust);

}} /* if, while */

} /* main() */

wentoff(int signal) {

printf("Timeout has occured\n");

longjmp(jbuf, TIMEOUT);

}

exec () family

• exce family overlay the calling process by the give program. This is the way to create a process and run a program different to the parent process.
  int execl(path, arg0 [ , arg1,... , argn ] (char *)0) char *path, *arg0, *arg1, ..., *argn;
  int execv(path, argv) char *path, *argv[ ];
• The calling process is overload by the program or interpreter (e.g. /bin/sh) specified by path (the complete path).
• The new program is executed with the given arguments.
• arg0 must be the program file name (convention).
• Use execl when the arguments are know. (char*)0 is to terminate the argument list.
• Use execv when the arguments are constructed dynamically (unknow at programming time).
• Adding on a list of environment vars
  int execle(path, arg0 [ , arg1,... , argn ] (char *)0, envp) char *path, *arg0, *arg1, ..., *argn, *envp[ ];
• Use the PATH env var. Search for the prog file in PATH dirs.
  int execlp(file, arg0 [ , arg1,... , argn ] (char *)0) char *file, *arg0, *arg1, ..., *argn;
  int execvp(file, argv) char *file, *argv[ ];
• All exec() family is the frontend of
  int execv(file, argv, envp) char *file, *argv[ ], *envp[ ];
• Example:

Program one.c :

• 
  

char *argv[ ]={"two", "abc", "123", '\0'};

char *env[]={"X=100", "Y=200", '\0'};

mail() {

printf("Running one\n");

if (execve("/usr/home/qli/two", argv, env) <= 0 ) {

perror("Can't execl"); }

}

Program two.c :

main(argv, argv)

int argc; char *argv[]; {

char *getenv( ); int i;

printf("Running two\n");

for (I=0; I< I++) printf("%s\n", argv[i]);

printf("%s, %s, %s, %s\n", getenv("X") getenv("Y"), getenv("HOME"), getenv("PWD")); }

%two # running two from shell

Running two

two

(null), (null), /usr/home/qli, /usr/home/qli

%one # running one from shell

Running one

Running two

two

abc

123

100, 200, (null), (null)

dup(int filedesc) duplicates the file descriptor to the lowest unused file descriptor number.

• Example:

#define Read 0

#define Write 1

#define STDIN 0

#define STDOUT 1

main ( ) {

FILE *fpt, *fpw;

int pfd[2]; /* pipe */

pipe(pfd);

if ((pid=fork()) != 0) { /* parent proc */

• 
  

close(STDOUT);

dup(pfd([Write]);

close(pfd[Write]);

close(pfd[Read]);

….. some code, maybe execl();

} else { /* child process */

close(STDIN);

dup(pfd([Read]);

close(ptd[Read]);

close(pfd[Write]);

…. some code, maybe execl();

} /* if */

} /* main */

pipe (conti.)

• Use fdopen with pipe

#include <.h>

#define ERROR -1

main() {

FILE *fdopen(), *fr, *fw;

int pid, pfd[2];

int i, n;

pipe(pfd);

if ((pid=fork()) == ERROR) {

printf("Can't fork\n"); exit(1); }

else if (pid != 0) { /* dad process */

fw = fdopen(pfd[1], "w");

for (i=1; i<=10; i++)

fprintf(fw, "%d\n", i);

fclose(fw);

exit(0);

} else

{ /* son process */

• 
  

fr = fdopen(pfd[0], "r");

for (i=10; i? i++) {

fscanf(fr, "%d", &n);

printf("In son process: %d\n", n);

}

fclose(fr);

exit(0);

} /* if … else */

} /* main */

-->

[Aug 20, 2004] Manipulating Files And Directories In Unix Copyright (c) 1998-2002 by guy keren.

The following tutorial describes various common methods for reading and writing files and directories on a Unix system. Part of the information is common C knowledge, and is repeated here for completeness. Other information is Unix-specific, although DOS programmers will find some of it similar to what they saw in various DOS compilers. If you are a proficient C programmer, and know everything about the standard I/O functions, its buffering operations, and know functions such as fseek() or fread(), you may skip the standard C library I/O functions section. If in doubt, at least skim through this section, to catch up on things you might not be familiar with, and at least look at the standard C library examples.

This document is copyright (c) 1998-2002 by guy keren.

The material in this document is provided AS IS, without any expressed or implied warranty, or claim of fitness for a particular purpose. Neither the author nor any contributers shell be liable for any damages incured directly or indirectly by using the material contained in this document.

permission to copy this document (electronically or on paper, for personal or organization internal use) or publish it on-line is hereby granted, provided that the document is copied as-is, this copyright notice is preserved, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

Permission to make translations of this document is also granted, under these terms - assuming the translation preserves the meaning of the text, the copyright notice is preserved as-is, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

For any questions about the document and its license, please contact the author.

Advanced Programming in the UNIX(R) Environment

A rarity - a great computer book., April 24, 2001   Reviewer: Bowen Simmons (see more about me) from Sunnyvale, CA USA The computer industry is notable for the huge quantity of really bad books it engenders. This, however, is not one of those books - this is a great book. Before explaining why it is great, I'd like to get the table of contents out of the way, so that you will know what it covers: Preface 1. Introduction (a "whirlwind tour of Unix") 2. Unix Standardization and Implementations 3. File I/O 4. Files and Directories 5. Standard I/O Library 6. System Data Files and Information 7. The Environment of a Unix Process 8. Process Control 9. Process Relationships 10. Signals 11. Terminal I/O 12. Advanced I/O 13. Daemon Processes 14. Interprocess Communication 15. Advanced Interprocess Communication 16. A Database Library 17. Communicating with a PostScript Printer 18. A Modem Dialer 19. Pseudo Terminals Appendices A. Function Prototypes B. Miscellaneous Source Code (all source code is available for download) C. Solutions to Selected Exercises Bibliography Index The first thing to understand about the book is that while it can be used as just a reference work (the index is wonderful), it really is a book you can and should read. Even if you think you know a lot of this stuff, you can be surprised at what you can still learn. What makes the book so much more useful than just a collection of man-page print-outs (that dreary and painfully common form of UNIX "book") is the method of presentation. Stevens' basic atom of organization is the function call. For each call (or minor variations on a single call), he provides the C prototype, and then, in text, explains what the function does, what it's arguments are for, and then typically provides a small C program that demonstrates it in action, which he then explains. These function-level building blocks are arranged into related sets, each of which is a chapter in the book. Each chapter has a wrapper that consists of an introduction explaining some basic concepts and history of the functions described in that chapter, and some review exercises at the end. The chapters themselves are arranged so that the earlier chapters describe the basic functions, and the later chapters describe the more difficult functions. Every chapter both teaches the reader something of immediate use in writing code (even the introduction has sample programs), as well as preparing him for the more difficult subjects that lie ahead. Now for the caveats. Stevens absolutely assumes that you know how to program in C and that you know how to use Unix development tools (or at least that you have some other source from which to learn them). This is not the book to learn how to use C or particular shells, editors, compilers, linkers, or debuggers. Similarly, new Unix variants, such as Linux and MacOS X, receive no specific mention here at all (though the book is invaluable for both). Also, there is no discussion of the various GUI interfaces offered on many current Unix systems - for those, some other book will necessary. One other thing worth mentioning is the cost of the book. Don't be put off by it - Stevens' book has been justifying that cost for a lot of readers for a lot of years. In closing, I've been a developer for many years and have owned many computer books. I recommend very few of them, but can't recommend this one highly enough. It is one of the few books I've had that routinely lies open beside me when I work. In addition to my personal recommendation, you might look not only at all the positive reviews for this book, but also at the reviews for "competitive" books and notice how often they refer you back to this one. This book is the standard by which other UNIX programming books are measured, and so far, it has not been surpassed

Using Unix System Calls by M. Rochkind, W.Toomey

• Using the C Compiler and Debugger
• An Introduction to the C Language
• Introduction to Unix System Calls
• Processes
• File I/O
• Memory Management
• Unix Signals
• More File I/O
• Pipes
• Semaphores and Shared Memory
• Security

Programming in C  --    David Marshall 1994 Contains a lot of useful info on system calls 

UNIX and C

• Advantages of using UNIX with C
• Using UNIX System Calls and Library Functions
• File and Directory Manipulation
  • Directory handling functions
  • File Manipulation Routines
  • errno
• Process Control and Management
  • Running UNIX Commands from C
    • execl()
    • fork()
    • wait()
    • exit()
  • Piping in a C program
    • popen() - Formatted Piping
    • pipe() - Low level Piping
  • Interrupts and Signals
    • Sending Signals - kill()
    • Receiving signals - signal()
• Times Up!!
• Exercises

BSD Sockets: A Quick & Dirty Primer
 

``As you delve into the mysteries of UNIX, you find more and more things that are difficult to understand immediately. One of these things, at least for most people, is the BSD socket concept. This is a short tutorial that explains what they are, how they work, and gives sample code showing how to use them.'' --Jim Frost
 

UNIX Signals and Process Groups
 

``This document describes the four common UNIX signalling environments, including their interfaces, and contrasts each. In addition, it describes the concepts and interfaces behind both BSD and POSIX process groups.'' --Jim Frost
 

Berkeley UNIX^® System Calls and Interprocess Communication
 

The purpose of this paper is to discuss interprocess communication in the context of Berkeley UNIX. Special emphasis will be given to those system calls concerned with the creation, management, and use of sockets. --Lawrence Besaw

 

Papers from the 4.4BSD PSD Manual ( Copyright Notice .)

Introductory 4.4BSD IPC (HTML)
An Advanced 4.4BSD IPC Tutorial (HTML)
 

Unix FAQ

ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/

 

UNIX Referance Desk

http://www.geek-girl.com/unix.html

Unix Seventh Edition Manual This is a classic. See vol1/man2.bun - system calls for historical information that may help to understand Unix kernel evolution.

Syscall specifications of Linux - Table of Contents by Louis-Dominique Dubeau.

[Beej's Guide] A fork() primer   -- From Beej's Guide to Unix Interprocess Communication

[Dubeau] Syscall specifications of Linux - Table of Contents by Louis-Dominique Dub

Syscall specifications of Linux - Table of Contents by Louis-Dominique Dubeau.

• Introduction
  • Conventions
• File system subsystem
  • access
  • chdir and fchdir
  • chmod and fchmod
  • chown and fchown
  • chroot
  • close
  • creat and open
  • dup and dup2
  • fcntl
  • fstat, stat and lstat
  • fstatfs and statfs
  • fsync
  • ftruncate and truncate
  • ioctl
  • link
  • lseek
  • mkdir
  • mknod
  • mount and umount
  • pipe
  • read
  • readdir
  • readlink
  • rename
  • rmdir
  • select
  • symlink
  • sync
  • umask
  • unlink
  • utime
  • write
• Virtual memory subsystem
  • brk
  • getpagesize
  • mmap and munmap
• Network subsystem
  • accept
  • bind
  • connect
  • getdomainname and setdomainname
  • gethostid and sethostid
  • gethostname and sethostname
  • getpeername
  • getsockname
  • getsockopt
  • listen
  • recv, recvfrom and recvmsg
  • send, sendmsg and sendto
  • shutdown
  • socket
  • socketpair
• Processus control subsystem
  • _exit
  • execve
  • template
  • getegid and getgid
  • geteuid and getuid

[Beej's Guide] A fork() primer   -- From Beej's Guide to Unix Interprocess Communication

• exit()
• fork()
• ps
• signal()
• signal listing
• wait()
• waitpid()

UNIX Kernel Source Tour

Tour of the Linux kernel source

The Linux Kernel -- free book by David A Rusling. One of the best source of information about Linux kernel

• Title Page
• Preface
• Hardware Basics
• Software Basics
• Memory Management
• Processes
• Interprocess Communication Mechanisms
• PCI
• Interrupts and Interrupt Handling
• Device Drivers
• The File System
• Networks
• Kernel Mechanisms
• Modules
• The Linux Kernel Sources
• Linux Data Structures
• The Alpha Processor
• Useful Web and FTP Sites
• The GNU General Public License
• Glossary

Berkeley UNIX System Calls and Interprocess Communication

The Linux Programmer's Guide, version 0.4 by B. Scott Burkett, Sven Goldt, John D. Harper, Sven van der Meer and Matt Welsh, is available in HTML, HTML (tared and gziped), LaTeX source, PDF and PostScript.

• Contents
• 1 The Linux operating system
• 2 The Linux kernel
• 3 The Linux libc package
• 4 System calls
• 5 The ``swiss army knife'' ioctl
• 6 Linux Interprocess Communications
  • 6.1 Introduction
  • 6.2 Half-duplex UNIX Pipes
    • 6.2.1 Basic Concepts
    • 6.2.2 Creating Pipes in C
    • 6.2.3 Pipes the Easy Way!
    • 6.2.4 Atomic Operations with Pipes
    • 6.2.5 Notes on half-duplex pipes:
  • 6.3 Named Pipes (FIFOs - First In First Out)
    • 6.3.1 Basic Concepts
    • 6.3.2 Creating a FIFO
    • 6.3.3 FIFO Operations
    • 6.3.4 Blocking Actions on a FIFO
    • 6.3.5 The Infamous SIGPIPE Signal
  • 6.4 System V IPC
    • 6.4.1 Fundamental Concepts
      • IPC Identifiers
      • IPC Keys
      • The ipcs Command
      • The ipcrm Command
    • 6.4.2 Message Queues
      • Basic Concepts
      • Internal and User Data Structures
      • SYSTEM CALL: msgget()
      • SYSTEM CALL: msgsnd()
      • SYSTEM CALL: msgctl()
      • msgtool: An interactive message queue manipulator
    • 6.4.3 Semaphores
      • Basic Concepts
      • Internal Data Structures
      • SYSTEM CALL: semget()
      • SYSTEM CALL: semop()
      • SYSTEM CALL: semctl()
      • semtool: An interactive semaphore manipulator
      • semstat: A semtool companion program
    • 6.4.4 Shared Memory
      • Basic Concepts
      • Internal and User Data Structures
      • SYSTEM CALL: shmget()
      • SYSTEM CALL: shmat()
      • SYSTEM CALL: shmctl()
      • SYSTEM CALL: shmdt()
      • shmtool: An interactive shared memory manipulator
• 7 Sound Programming
  • 7.1 Programming the internal speaker
  • 7.2 Programming a sound card
• 8 Character Cell Graphics
  • 8.1 I/O Function in libc
    • 8.1.1 Formatted Output
    • 8.1.2 Formatted Input
  • 8.2 The Termcap Library
    • 8.2.1 Introduction
    • 8.2.2 Find a Terminal Description
    • 8.2.3 Look at a Terminal Description
    • 8.2.4 Termcap Capabilities
      • Boolean Capabilities
      • Numeric Capabilities
      • String Capabilities
  • 8.3 Ncurses - Introduction
  • 8.4 Initializing
  • 8.5 Windows
  • 8.6 Output
    • 8.6.1 Formatted Output
    • 8.6.2 Insert Characters/Lines
    • 8.6.3 Delete Characters/Lines
    • 8.6.4 Boxes and Lines
    • 8.6.5 Background Character
  • 8.7 Input
    • 8.7.1 Formated Input
  • 8.8 Options
    • Output Options
    • 8.8.1 Input Options
    • 8.8.2 Terminal Attributes
    • 8.8.3 Use Options
  • 8.9 Clear Window and Lines
  • 8.10 Updating the Terminal
  • 8.11 Video Attributes and Color
  • 8.12 Cursor and Window Coordinates
  • 8.13 Scrolling
  • 8.14 Pads
  • 8.15 Soft-labels
  • 8.16 Miscellaneous
  • 8.17 Low-level Access
  • 8.18 Screen Dump
  • 8.19 Termcap Emulation
  • 8.20 Terminfo Functions
  • 8.21 Debug Function
  • 8.22 Terminfo Capabilities
    • 8.22.1 Boolean Capabilities
    • 8.22.2 Numbers
    • 8.22.3 Strings
  • 8.23 [N]Curses Function Overview
• 9 Programming I/O ports
  • 9.1 Mouse Programming
  • 9.2 Modem Programming
  • 9.3 Printer Programming
  • 9.4 Joystick Programming
• 10 Porting Applications to Linux
  • 10.1 Introduction
  • 10.2 Signal handling
    • 10.2.1 Signals under SVR4, BSD, and POSIX.1
    • 10.2.2 Linux signal options
    • 10.2.3 signal under Linux
    • 10.2.4 Signals supported by Linux
  • 10.3 Terminal I/O
  • 10.4 Process information and control
    • 10.4.1 kvm routines
    • 10.4.2 ptrace and the /proc filesystem
    • 10.4.3 Process control under Linux
  • 10.5 Portable conditional compilation
  • 10.6 Additional Comments
• 11 Systemcalls in alphabetical order
• 12 Abbreviations
• About this document ...

Open Group Search Engine

http://www.opengroup.org/onlinepubs/7908799/

GNU C Library

libc -- GNU C Library - GNU Project - Free Software Foundation (FSF)

Any Unix-like operating system needs a C library: the library which defines the ``system calls'' and other basic facilities such as malloc.

The history of Unix and various standards determine much of the interface of the C library. In general the GNU C library supports the ISO C and POSIX standards. We also try to support the features of popular Unix variants (including BSD and System V) when those do not conflict with the standards. Different compatibility modes (selectable when you compile an application) allow the peaceful coexistence of compatibility support for different varieties of Unix.

Random Findings

FreeCode Free Programming Source Code

Socket Programming Guide

UNIX Socket Programming in C -- Programming UNIX Sockets in C - Frequently Asked Questions Created by Vic Metcalfe, Andrew Gierth and other contributers May 21, 1998

W. Richard Stevens home page

• Source code from Advanced Programming in the UNIX Environment
• Here is an updated version of the Linux source code, supplied by a reader, that supposedly works under RedHat 5.0 and 5.1.

FreeCode

UKUUG Home Page

• UK Linux Links

Etc

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

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

Most popular humor pages:

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

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

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

Last modified: March 12, 2019