

* is Unix - jacobian
http://jacobian.org/writing/star-is-unix/

======
antonovka
This meme is a silly amateur-hour wheel re-invention and ignorance of history.

The fact is, pre-forking a pool of processes without implementing a per-
process multiple-connection event mechanism is going to be grossly inefficient
in terms of memory utilization (ie, you need to use select, poll, kqeueue,
etc.).

You can claim otherwise (COW pages et al), but history is not on your side
(look at the scalability of existing pre-fork/connection-per-process network
daemons). Think about it -- how much of the runtime can truly be shared across
connection handlers?

The fact that this model doesn't scale is not news. It doesn't require
rediscovery. It shouldn't be surprising. Anyone who has run Apache, sendmail,
or any 80s/90s networking software -- much less authored something similar --
will know better.

Moreover, there's _nothing wrong with threads_ \-- threads are a low-level
tool that can be used to implement high-level concurrent systems. They're
cheaper than processes because they _do_ support mutable state where it's
useful, but _you don't have to use fork() to avoid avoid mutable state_.

If you don't want shared mutable state (and you don't), then _don't use it_.

~~~
jacobian
_This meme is a silly amateur-hour wheel re-invention and ignorance of
history._

Yeah, well fuck you too.

As it turns out, I _am_ an amateur, at least when it comes to POSIX, but more
importantly _I find this stuff fun._ I hadn't realized that having fun and
learning about new topics was such an offensive thing to do.

Maybe this is just frivolity, but it's surely a better way to spend a few
minutes than crapping all over somebody else's fun.

~~~
antonovka
My intention was to elucidate why the fork(2) non-event-based "mini-meme" is
known dead-end.

~~~
omouse
Off-topic but...we need a proper computer science/programming collection of
papers, books, etc. built up so that people can go off and learn things from
the past instead of learning about them independently and then spawning blog
posts about it.

~~~
silentbicycle
For learning this side of Unix, I've found the following very helpful (note
that this is a bit BSD-centric):

1\. _The Unix Programming Environment_ by Kernighan and Pike. The best overall
intro to the pipes, shebangs, and other assorted command line stuff in Unix.
Very old school, but still very relevant - those are the root of many of
Unix's strengths. (K&P's _The Practice of Programming_ is also excellent,
though not as specific to Unix.)

2\. _Advanced Programming in the UNIX Environment_, 2nd ed., by (the late) W.
Richard Stevens. This and man pages will go a long way.

3\. The man pages themselves. It's generally understood that OpenBSD's man
pages are particularly well written, but if you're using Linux and the GNU
userland, there will be lots of differences in the details.

4\. The 4.4BSD "Programmer's Supplementary Documents" (PSD) - This is a
collection of papers and man pages. While some are out of date, and some are
mainly of historical interest, the introductions to tools such as make, lex,
yacc, gdb, etc. are quite good, and often a tenth the length of the
corresponding O'Reilly book. (These papers may be installed with your distro.
OpenBSD has them in /usr/share/doc . I bought the book used for a couple
bucks.) There are also "User's Supplementary Documents" (USD) and System
Manager's Manual (SMM) collections, with papers on configuring sendmail, using
vi, etc.

5\. _The Art of Unix Programming_ by Eric S. Raymond - I recommend this one in
spite of finding ESR _incredibly_ irritating. It's a very good conceptual
overview of the big design ideas in Unix and their ramifications, albeit one
interspersed with narcissistic soapboxing by the author.

In general, using a Linux distro with a strong emphasis on having a friendly
GUI layer can keep you at arms length from really learning Unix. Dig around in
/etc. Learn to use cron and ed. (No, really.) Get your hands dirty.

I would also highly recommend learning a scripting language that integrates
well with C (some people like Perl, Python, or Ruby, I prefer Lua), because
really using Unix well is going to involve some C. Working with C isn't scary
unless you're trying to build a large system in C - try instead to break it up
into a suite of smaller programs, rather than one monolithic one. Take
advantage of pipes and all the other existing Unix infrastructure. It's there
to help keep complexity at bay.

Mostly, though, tinker and explore.

~~~
antonovka
For Unix systems-level/network programming, I'd also add to the list:

1\. UNIX Network Programming: Networking APIs: Sockets and XTI; Volume 1 (W.
Richard Stevens) - the books is considered the bible of the BSD networking
APIs, and if you're interested in writing network software at any scale, in
any language, you should start with this book -- everything else builds from
here.

2\. Write Great Code: Volume 1: Understanding the Machine (Randall Hyde) - At
the end of the day you're writing code that will execute on a machine.
Understanding how the machine works will help you understand your code.

3\. The Design and Implementation of the FreeBSD Operating System (Marshall
Kirk McKusick, George V. Neville-Neil) - If you've ever wondered how copy-on-
write pages work (some of the magic behind the fork(2) model), or how your
processes get scheduled, this is a good place to start -- even if you aren't
using a BSD, the tenants hold.

------
claymation
I love an in-depth, technical blog post as much as anyone, and kudos to Ryan
for dissecting Unicorn, but I didn't know whether to laugh or cry when I read
that Unicorn has, "teh Unix turned up to 11". zOMG! fork!

This series of blog posts underscores my point that the Rails community,
perhaps the Web 2.0 community at large, is just now learning things the rest
of us have known for years. accept(2)-based pre-forking socket servers are not
news.

~~~
silentbicycle
> "teh Unix turned up to 11". zOMG!

Yeah. Ruby people suddenly feeling all hardcore after touching Unix syscalls
for the first time. Ick.

------
wooby
The alternative to preforking is select(2), which lets you get away with a
single-process server and avoid IPC in certain scenarios:
<http://www.lowtek.com/sockets/select.html>

I think Boa and thttpd use select instead of forking for clients.

~~~
silentbicycle
You might want to look at libevent (<http://www.monkey.org/~provos/libevent/>)
and libev (<http://software.schmorp.de/pkg/libev.html>). They're wrappers to
kqueue (on BSD) and epoll (on Linux), both of which improve upon select
([http://www.monkey.org/~provos/libevent/libevent-
benchmark.jp...](http://www.monkey.org/~provos/libevent/libevent-
benchmark.jpg)).

~~~
mace
Libevent is great for multiplatform code. PyEvent is the Python wrapper module
for libevent also written by dugsong.

------
ilyak
nginx is Unix

It's obviously designed by Unix orthdoxes and it shows

No dynamic linking! No threads! Not much of mem alloc, either!

------
iuguy
No. * is most definitely not Unix. Unix is Unix. Anything else is not Unix.

~~~
jrockway
Sometimes it pays to click through to the article before commenting.

