posix has been rendered useless, isn't it?

[Roland Smith]

On Sun, Dec 21, 2014 at 09:26:37PM +0530, Mayuresh Kathe wrote:
> hello,
> 
> there's a question which i have not been able to
> find an answer to yet, hence venture to pose here.
> 
> i have been studying the unix way of doing things,
> i.e. tool-chaining to combine small programs for
> accomplishing a solution.

Simple chaining is only *one* possible connection mechanism.  One
that is perfectly suitable for “filters”; programs that read from
standard input and write to standard output.  But it is not always
suitable for other types of programs.

The UNIX phylosophy is much larger than that.  Therefore I would
recommend that you read “The Art of Unix Programming” by Eric
Raymond.  You can read the first edition online here:
http://www.catb.org/esr/writings/taoup/html/ The section “Basics
of the Unix Philosophy”
http://www.catb.org/esr/writings/taoup/html/ch01s06.html is a good
overview.

> but, almost none of today's servers built for any
> of today's unix-like systems adhere to the unix
> philosophy. most of them instead, are large
> applications.

Not always.  Look e.g. at the nginx webserver or the postfix mail server.

> i couldn't find a way to write a c-shell script
> to create a workable mail server in minimal time.

That is because a mail server isn't really suitable for the “chaining”
model.

The postfix mail server consists of several cooperating programs
instead of one monolithic program like sendmail.  They cooperate
by reading/writing mail queues.  Look at
http://www.postfix.org/OVERVIEW.html for an overview of the
architecture of postfix.

Another example is the nginx webserver.  This is a relatively small
program; the stripped binary on my FreeBSD 10 amd64 machine is
594656 bytes.  It has approximately 150.000 lines of code.  It uses
multiple “worker” processes to make use of modern multi-core machines.
Thw workers use an event-driven architcture to achieve a high degree
of concurrency (handling many requests at one time) with a low
memory usage.  Splitting the handling of a HTTP request into many
small pieces that can individually be executed quickly allows the
program to keep being responsive to new incoming requests while
many other requests are in different stages of being handled.


Roland
-- 
R.F.Smith                                   http://rsmith.home.xs4all.nl/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated]
pgp: 5753 3324 1661 B0FE 8D93  FCED 40F6 D5DC A38A 33E0 (keyID: A38A33E0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20141224/6e477742/attachment.sig>