4 ms·

ps is used for monitoring. I make sure I write processes that don't fail. This is done with tooling (valgrind, cachegrind, unit tests, integration tests) and t

ps is used for monitoring. I make sure I write processes that don't fail. This is done with tooling (valgrind, cachegrind, unit tests, integration tests) and testing (automated testing, experienced testers). The whole process restart mechanism is a combination of string and sticky tape to abstract away the problem of half-arsed poorly written bits of functionality that crap themselves every few minutes. I can and have written processes that stay alive for years (5 years 122 days pegged at 100% CPU being the record after which a reboot was required as the Sun Ultra 2 hosting it was replaced).

octo_t 13y ago
you have clearly never written a distributed system or similar. Fail Fast, Fail Often.
- harrytuttle 13y ago
  That mantra is simply bullshit. I have written massively distributed systems which have an insanely high reliability requirement and it is really not the answer. I've been doing this for 25 years. A more appropriate statement is: Fail early and gracefully, recover always, expect failure. Fail early - assertions up front. Prevention is better than cure. Fail gracefully - don't allow assertions to take the entire process out. Don't allow the language to crash the process out. Recover always - design your system for recovery and understand recovery conditions. Expect failure - know where and when something is going to fail and handle it. Fail fast, fail often results in nasty shit like processes hung in restart cycles etc.
  - tel 13y ago
    This is much closer to the actual Erlang philosophy that gets misquoted so often.
deleted 13y ago
[deleted]
jacques_chester 13y ago
> I make sure I write processes that don't fail. Please name one major, non-trivial network system software that has gone for 5 years, 122 days without a fault in production anywhere. Engineers in other disciplines make best efforts not to fuck up. And then they accept that they, or others, will fuck up anyhow and they plan for that. So do we. And so we should. Betting it all on Red 19 is a strategy of roulette, not serious work.
- harrytuttle 13y ago
  We don't bet on that, we aim for that.
  - jacques_chester 13y ago
    I can sense we're about to have a circular argument based on where to draw the boundaries of responsibility. My point is that betting entirely on one strategy for mitigating faults is unnecessarily risky. Especially when additional levels of mitigation are easily installed and configured. In your other post you even point out a series of things that you do. I don't see why process management is of a different kind. Edit: removed unnecessary grandstanding.

octo_t 13y ago

you have clearly never written a distributed system or similar. Fail Fast, Fail Often.

harrytuttle 13y ago
That mantra is simply bullshit. I have written massively distributed systems which have an insanely high reliability requirement and it is really not the answer. I've been doing this for 25 years. A more appropriate statement is: Fail early and gracefully, recover always, expect failure. Fail early - assertions up front. Prevention is better than cure. Fail gracefully - don't allow assertions to take the entire process out. Don't allow the language to crash the process out. Recover always - design your system for recovery and understand recovery conditions. Expect failure - know where and when something is going to fail and handle it. Fail fast, fail often results in nasty shit like processes hung in restart cycles etc.
- tel 13y ago
  This is much closer to the actual Erlang philosophy that gets misquoted so often.

deleted 13y ago

[deleted]

jacques_chester 13y ago

> I make sure I write processes that don't fail. Please name one major, non-trivial network system software that has gone for 5 years, 122 days without a fault in production anywhere. Engineers in other disciplines make best efforts not to fuck up. And then they accept that they, or others, will fuck up anyhow and they plan for that. So do we. And so we should. Betting it all on Red 19 is a strategy of roulette, not serious work.

harrytuttle 13y ago
We don't bet on that, we aim for that.
- jacques_chester 13y ago
  I can sense we're about to have a circular argument based on where to draw the boundaries of responsibility. My point is that betting entirely on one strategy for mitigating faults is unnecessarily risky. Especially when additional levels of mitigation are easily installed and configured. In your other post you even point out a series of things that you do. I don't see why process management is of a different kind. Edit: removed unnecessary grandstanding.