5 ms·

VAXen, My Children, Just Don't Belong in Some Places

117 points by siganakis 12y ago

derefr 12y ago
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.
- bitwize 12y ago
  ones that promote quickly-spawned, ephemeral processes and which rely on reboots for cleanup (Unix). The only modern OS I know of that "relies on reboots for cleanup" is, ironically enough, the one famously descended from VMS (I am of course talking about NT-kernel-family Windows). And this is not a VAX vs. Unix story; it's a story about by-the-numbers IBMers who dress in the Right Clothes and say the Right Things being completely feckless in the face of a VAX, development and maintenance of which has quite a different tradition and culture, mainly consisting of scruffy guys who Get Shit Done. Of which there is not a lack in the Unix tradition either.
  - derefr 12y ago
    > And this is not a VAX vs. Unix story A parable communicates a lesson, and the lesson "don't let ops people who have never run an architecture resembling yours near your machines" is kind of vacuous/trivial. Like I said, I'm looking for a piece of wisdom can be extracted from this story that's relevant for modern devops people. I think the lesson is basically: some systems evolved around doing discrete batch-processing tasks that throw away their arenas when they're done, and have very few and discrete connection points; while other systems are "about" living object graphs that can't be disentangled, only upgraded as an entire system, and which maintain themselves rather than having maintenance done upon them from outside. Rebooting solves problems with the former, since you're cleaning up all your temp files, cached intermediary results, etc. and then scheduling fresh new tasks. Rebooting the latter just makes it struggle to put itself back together exactly the way it was before. Think of power-cycling an LAMP "app-tier" server (Unixine) vs. a database server (Vaxine.)
    - mwcampbell 12y ago
      I read the story. In what case would it be that disastrous to reboot a database server?
      - lutusp 12y ago
        > In what case would it be that disastrous to reboot a database server? To assure data integrity, an interactive database system has to log off all its users and shut down open databases before rebooting. If the reboot can't be orchestrated that way, if users can't be logged off in an orderly way, there will be data loss.
        jmalicki 12y ago
        If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. That's the entire point of transactions...
        lutusp 12y ago
        > If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. Yes -- all except the ongoing transactions at the users' workstations. That by itself could represent a serious synchronization problem. For a serious business, an emergency power system might represent a better choice.
        dllthomas 12y ago
        If you've not pulled the plug on your users' workstations, the clients should be perfectly capable of retrying the broken transactions when the database comes back up. There can, of course, be constraints that make this impossible, but sloppy coding making it impossible is more common.
        newman314 12y ago
        If your DB is ACID AND your underlying storage has not lied to you about committing the write...
- smutticus 12y ago
  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 12y ago
    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.
    - deleted 12y ago
      [deleted]
  - jpatokal 12y ago
    A VAX is actually a "minicomputer" in the lingo of the time -- because it's only the size of a washing machine, not the entire room! https://en.wikipedia.org/wiki/Minicomputer https://en.wikipedia.org/wiki/Minicomputer
- dredmorbius 12y ago
  Did you even read the story? It's about IBM mainframes (not Unix systems) on an uninterruptable ("immortal") power supply, a VAX which wasn't, but which could survive reboots in pretty good shape. Except when handling world-changing financial transactions.
- newman314 12y ago
  I'm not sure where you are coming from that Unix reboots are frequent but please stay away from any that I have to interact with. Windows on the other hand still require reboots fairly regularly.
  - gizmo686 12y ago
    In this context, "reboot" means the program exiting and being started again.
    - lutusp 12y ago
      That's not the common meaning of reboot, in fact, it's not even an alternative meaning. http://www.learnersdictionary.com/definition/reboot http://www.learnersdictionary.com/definition/reboot
- jleader 12y ago
  Where did you get the idea that the story had anything to do with Unix? Or that Unix relies on reboots for cleanups? Note that around the time of this story, one of the most popular hardware platforms for running Unix (especially in academic environments) was ... the VAX (and its predecessor, the PDP-11). So in fact of the 2 "sides" in the story (IBM mainframes vs. VAXen running VMS), Unix would be on the scruffy VAX side (if anything, at that time Unix folks were scruffier than VMS folks).
teddyh 12y ago
Previously discussed here: https://news.ycombinator.com/item?id=7278408 https://news.ycombinator.com/item?id=7278408
- guelo 12y ago
  Kind of sad proof of how much the comment quality has dropped on HN this year.
  - rdl 12y ago
    Labor day weekend in the US is probably the deadest time of the year. Especially due to Burning Man.
ethbro 12y ago
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 12y ago
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 12y ago
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 12y ago
  I doubt this story has any factual basis whatsoever -- it reads like a tall tale with a moral more than anything else.
  - dredmorbius 12y ago
    Dunno. I've heard (and told) a few similar stories that do have a factual basis.
    - new299 12y ago
      Do you have them written up anywhere? I'm a total sucker for these kind of stories.
      - dredmorbius 12y ago
        Nothing of quite this scope.
        jtheory 12y ago
        There are huge disasters that come of software mistakes -- but look at the story of the Therac-25 vs. this kind of story. Factual stories don't normally have punchlines. If however many billions of dollars were actually lost due to a server rebooting at the wrong time, would it actually be possible that it remained a secret, only documented in this one humorous and totally un-sourced account? Also note the exaggerations of the incompetence of the IBM datacenter operators. It's an entertaining read, because it's written to be an entertaining read ("a former gnome of Zurich"?). Maybe there's some kernel of truth in there; maybe not -- but there's no way to tell now (without other, better sources) what that may be.

117 points by siganakis 12y ago

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.

bitwize 12y ago
ones that promote quickly-spawned, ephemeral processes and which rely on reboots for cleanup (Unix). The only modern OS I know of that "relies on reboots for cleanup" is, ironically enough, the one famously descended from VMS (I am of course talking about NT-kernel-family Windows). And this is not a VAX vs. Unix story; it's a story about by-the-numbers IBMers who dress in the Right Clothes and say the Right Things being completely feckless in the face of a VAX, development and maintenance of which has quite a different tradition and culture, mainly consisting of scruffy guys who Get Shit Done. Of which there is not a lack in the Unix tradition either.
- derefr 12y ago
  > And this is not a VAX vs. Unix story A parable communicates a lesson, and the lesson "don't let ops people who have never run an architecture resembling yours near your machines" is kind of vacuous/trivial. Like I said, I'm looking for a piece of wisdom can be extracted from this story that's relevant for modern devops people. I think the lesson is basically: some systems evolved around doing discrete batch-processing tasks that throw away their arenas when they're done, and have very few and discrete connection points; while other systems are "about" living object graphs that can't be disentangled, only upgraded as an entire system, and which maintain themselves rather than having maintenance done upon them from outside. Rebooting solves problems with the former, since you're cleaning up all your temp files, cached intermediary results, etc. and then scheduling fresh new tasks. Rebooting the latter just makes it struggle to put itself back together exactly the way it was before. Think of power-cycling an LAMP "app-tier" server (Unixine) vs. a database server (Vaxine.)
  - mwcampbell 12y ago
    I read the story. In what case would it be that disastrous to reboot a database server?
    - lutusp 12y ago
      > In what case would it be that disastrous to reboot a database server? To assure data integrity, an interactive database system has to log off all its users and shut down open databases before rebooting. If the reboot can't be orchestrated that way, if users can't be logged off in an orderly way, there will be data loss.
      - jmalicki 12y ago
        If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. That's the entire point of transactions...
        lutusp 12y ago
        > If your database is ACID, you can pull the power on the server from the wall and have it instantly turn off w/o data loss. Yes -- all except the ongoing transactions at the users' workstations. That by itself could represent a serious synchronization problem. For a serious business, an emergency power system might represent a better choice.
        dllthomas 12y ago
        If you've not pulled the plug on your users' workstations, the clients should be perfectly capable of retrying the broken transactions when the database comes back up. There can, of course, be constraints that make this impossible, but sloppy coding making it impossible is more common.
        newman314 12y ago
        If your DB is ACID AND your underlying storage has not lied to you about committing the write...
smutticus 12y ago
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 12y ago
  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.
  - deleted 12y ago
    [deleted]
- jpatokal 12y ago
  A VAX is actually a "minicomputer" in the lingo of the time -- because it's only the size of a washing machine, not the entire room! https://en.wikipedia.org/wiki/Minicomputer https://en.wikipedia.org/wiki/Minicomputer
dredmorbius 12y ago
Did you even read the story? It's about IBM mainframes (not Unix systems) on an uninterruptable ("immortal") power supply, a VAX which wasn't, but which could survive reboots in pretty good shape. Except when handling world-changing financial transactions.
newman314 12y ago
I'm not sure where you are coming from that Unix reboots are frequent but please stay away from any that I have to interact with. Windows on the other hand still require reboots fairly regularly.
- gizmo686 12y ago
  In this context, "reboot" means the program exiting and being started again.
  - lutusp 12y ago
    That's not the common meaning of reboot, in fact, it's not even an alternative meaning. http://www.learnersdictionary.com/definition/reboot http://www.learnersdictionary.com/definition/reboot
jleader 12y ago
Where did you get the idea that the story had anything to do with Unix? Or that Unix relies on reboots for cleanups? Note that around the time of this story, one of the most popular hardware platforms for running Unix (especially in academic environments) was ... the VAX (and its predecessor, the PDP-11). So in fact of the 2 "sides" in the story (IBM mainframes vs. VAXen running VMS), Unix would be on the scruffy VAX side (if anything, at that time Unix folks were scruffier than VMS folks).

teddyh 12y ago

Previously discussed here: https://news.ycombinator.com/item?id=7278408 https://news.ycombinator.com/item?id=7278408

guelo 12y ago
Kind of sad proof of how much the comment quality has dropped on HN this year.
- rdl 12y ago
  Labor day weekend in the US is probably the deadest time of the year. Especially due to Burning Man.

ethbro 12y ago

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 12y ago

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 12y ago

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 12y ago
I doubt this story has any factual basis whatsoever -- it reads like a tall tale with a moral more than anything else.
- dredmorbius 12y ago
  Dunno. I've heard (and told) a few similar stories that do have a factual basis.
  - new299 12y ago
    Do you have them written up anywhere? I'm a total sucker for these kind of stories.
    - dredmorbius 12y ago
      Nothing of quite this scope.
      - jtheory 12y ago
        There are huge disasters that come of software mistakes -- but look at the story of the Therac-25 vs. this kind of story. Factual stories don't normally have punchlines. If however many billions of dollars were actually lost due to a server rebooting at the wrong time, would it actually be possible that it remained a secret, only documented in this one humorous and totally un-sourced account? Also note the exaggerations of the incompetence of the IBM datacenter operators. It's an entertaining read, because it's written to be an entertaining read ("a former gnome of Zurich"?). Maybe there's some kernel of truth in there; maybe not -- but there's no way to tell now (without other, better sources) what that may be.