Re:The Suez Canal will be widened
by masklinn on Sunday May 16, 2021 @08:58AM
(#27173396)
> When your program OOMs, you have three options:
The issue with your analogy is that here the "program" did not OOM as part of normal operations, instead it OOM'd because of a rare condition you can't really avoid (even calling it a bug is debatable, as a bug implies misbehaviour in the canal).
In that case, increasing your safety buffer so you can recover before swapping to death or the OOM killer -9-ing programs left and right is a good idea.
> - You can make the program handle the too-large-data case better. This requires deeper systemic changes usually across multiple components (the program, your monitoring and error reporting, upstream and downstream integrations). But this also tends to have knock-on improvements across the system.
How would you make "the program" handle "the too-large case better" exactly? As in, how would the canal handle a ship getting stuck sideways after having lost propulsion save by being wider than the ship can be long?
> And a lot of times it's cheaper than the first option when you compare total rather than marginal cost.
We're talking about a 200km canal.
> Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats?
Maybe they're working on both but increasing the canal width to provide more buffer in case of rare issues is a much more complicated and thus interesting thing, and thus gets more visibility?
The issue with your analogy is that here the "program" did not OOM as part of normal operations, instead it OOM'd because of a rare condition you can't really avoid (even calling it a bug is debatable, as a bug implies misbehaviour in the canal).
In that case, increasing your safety buffer so you can recover before swapping to death or the OOM killer -9-ing programs left and right is a good idea.
> - You can make the program handle the too-large-data case better. This requires deeper systemic changes usually across multiple components (the program, your monitoring and error reporting, upstream and downstream integrations). But this also tends to have knock-on improvements across the system.
How would you make "the program" handle "the too-large case better" exactly? As in, how would the canal handle a ship getting stuck sideways after having lost propulsion save by being wider than the ship can be long?
> And a lot of times it's cheaper than the first option when you compare total rather than marginal cost.
We're talking about a 200km canal.
> Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats?
Maybe they're working on both but increasing the canal width to provide more buffer in case of rare issues is a much more complicated and thus interesting thing, and thus gets more visibility?