
VAXen, My Children, Just Don't Belong in Some Places - siganakis
http://www.hactrn.net/sra/vaxen.html
======
derefr
Regarding applications to modern software engineering, this parable is
basically about operations surrounding architectures that promote long-lived
processes and rare reboots (VAX) vs. ones that promote quickly-spawned,
ephemeral processes and which rely on reboots for cleanup (Unix).

The modern comparison I would make is between the design of scale-neutral
twelve-factor apps in language-platforms made for quickly spawning ephemeral
processes ("scripting" languages like PHP, Ruby, Node, Lua, or even—in
practice—Go)† and the design of "living system" VMs—and languages
thereupon—that load and unload modules over time without shutting down (JVM
app servers, Erlang, etc.)

It's okay to effectively "reboot" your Heroku instances to get them into a
sane state. Not so with your databases, stateful load balancers, or VoIP
servers. They come from two different worlds: one eschews state, while the
other owns and manages it.

† Notice how all these languages are effectively wrappers around the same
paradigm. There's a strong sense in which a "scripting" language is just a
language that models the world in the Unixine fashion, such that it can be
used to glue other Unixine programs together.

~~~
smutticus
UNIX isn't mentioned. When they say IBM I believe they are referring to
System/360 and its decendents. This is a story of two mainframe competitors.
It has nothing to do with UNIX.

~~~
ghaff
In the context of the time, the VAX is the more interactive/flexible/etc.
system relative to the 360. It certainly wasn't viewed as a mainframe then.
However, from today's vantage point, VAXen--and even the large UNIX servers
that followed--seem very mainframe-like compared to volume x86 servers.

------
teddyh
Previously discussed here:
[https://news.ycombinator.com/item?id=7278408](https://news.ycombinator.com/item?id=7278408)

~~~
guelo
Kind of sad proof of how much the comment quality has dropped on HN this year.

~~~
rdl
Labor day weekend in the US is probably the deadest time of the year.
Especially due to Burning Man.

------
ethbro
This is one of those classic internet stories. I assume originally from
Usenet. Laughed when I read it 10 years ago on Slashdot, and again today.

Here's looking at you, ten-years-from-now tech website that will be sharing
this with a whole new group of faces!

------
st3fan
_It was Monday, 19-Oct-1987. VAXen, my children, just don 't belong some
places._

[http://en.wikipedia.org/wiki/Black_Monday_(1987)](http://en.wikipedia.org/wiki/Black_Monday_\(1987\))

------
dredmorbius
Is there any support at all for the implication that this anecdote has any
more than a humorous and coincidental relationship with the 1987 stock market
crash?

I've run across this story more than once. It's amusing but also more than a
little troubling if that is in fact how fragile the global financial system
is.

~~~
jtheory
I doubt this story has any factual basis whatsoever -- it reads like a tall
tale with a moral more than anything else.

~~~
dredmorbius
Dunno. I've heard (and told) a few similar stories that do have a factual
basis.

~~~
new299
Do you have them written up anywhere? I'm a total sucker for these kind of
stories.

~~~
JacobAldridge
If you haven't already, do enjoy _The Case of the 500-mile Email_ (which I
believe is factual)

[http://www.ibiblio.org/harris/500milemail.html](http://www.ibiblio.org/harris/500milemail.html)

~~~
dredmorbius
That's a great one.

Related are the faster-than-light stock-exchange trading orders of the past
few years.

Some trades were originating out of Chicago for NY exchanges which, based on
release timing of information, would have had to travel faster than light.
Truth being that there's early access being offered some traders.

[http://www.theverge.com/2013/10/3/4798542/whats-faster-
than-...](http://www.theverge.com/2013/10/3/4798542/whats-faster-than-a-light-
speed-trade-inside-the-sketchy-world-of)

[http://arxiv.org/pdf/1302.5966v1.pdf](http://arxiv.org/pdf/1302.5966v1.pdf)

