The murmur of the snarkmatrix…

Tim Maly § Sooo / 2014-08-27 01:35:19
Matt § Sooo / 2014-08-25 02:10:30
Tim § Sooo / 2014-08-25 00:49:38
Robin § Sooo / 2014-08-21 20:47:35
Doug § Sooo / 2014-08-21 20:40:50
Tim § Sooo / 2014-08-21 18:23:13
Gavin § Sooo / 2014-08-21 18:10:44
Robin § Sooo / 2014-08-21 18:06:14
Bob Stepno § The structure of journalism today / 2014-03-10 18:42:32
Anne Field § The booster pack / 2014-02-15 16:15:39

Only crash

Sometimes you run across an idea so counter-intuitive and brain-bending that you immediately want to splice it into every domain you can think of. Sort of like trying a novel chemical compound against a bunch of cancers: does it work here? How about here? Or here?

That’s how I feel about crash-only software (link goes to a PDF in Google’s viewer). Don’t pay too much attention to the technical details; just check out the high-level description:

Crash-only programs crash safely and recover quickly. There is only one way to stop such software—by crashing it—and only one way to bring it up—by initiating recovery.

Wow. The only way to stop it is by crashing it. The normal shutdown process is the crash.

Let’s go a little deeper. You can imagine that commands and events follow “code paths” through software. For instance, when you summoned up this text, your browser followed a particular code path. And people who use browsers do this a lot, right? So you can bet your browser’s “load and render text” code path is fast, stable and bug-free.

But what about a much rarer code path? One that goes: “load and render text, but uh-oh, it looks like the data for the font outlines got corrupted halfway through the rendering process”? That basically never happens; it’s possible that that code path has never been followed. So it’s more likely that there’s a bug lurking there. That part of the browser hasn’t been tested much. It’s soft and uncertain.

One strategy to avoid these soft spots is to follow your worst-case code paths as often as your best-case code paths (without waiting for, you know, the worst case)—or even to make both code paths the same. And crash-only software is sort of the most extreme extension of that idea.

Maybe there are biological systems that already follow this practice, at least loosely. I’m thinking of seeds that are activated by the heat of a forest fire. It’s like: “Oh no! Worst-case scenario! Fiery apocalypse! … Exactly what we were designed for.” And I’m thinking of bears hibernating—a sort of controlled system crash every winter.

What else could we apply crash-only thinking to? Imagine a crash-only government, where the transition between administrations is always a small revolution. In a system like that, you’d optimize for revolution—build buffers around it—and as a result, when a “real” revolution finally came, it’d be no big deal.

Or imagine a crash-only business that goes bankrupt every four years as part of its business plan. Every part of the enterprise is designed to scatter and re-form, so the business can withstand even an existential crisis. It’s a ferocious competitor because it fears nothing.

Those are both fanciful examples, I know, but I’m having fun just turning the idea around in my head. What does crash-only thinking connect to in your brain?


Tim (and Gavin?) are probably the experts here, but isn’t this how toddlers work?

More seriously, aren’t a lot of parliamentary democracies likes this? You’re in power until you can’t hold the coalition, and the only way to start again is to hold a new election?

I assume you’re resisting analogies to a certain Culture novel until all the Snarketeers have read it.

Wait, you mean PoG? That actuallyhadn’t occurred to me… (cogitating on it now…)

Saheli says…

I was thinking about fire, which has now come up again.

> Or imag­ine a crash-only busi­ness that goes bank­rupt every four years as part of its busi­ness plan. Every part of the enter­prise is designed to scat­ter and re-form, so the busi­ness can with­stand even an exis­ten­tial cri­sis. It’s a fero­cious com­peti­tor because it fears nothing.

What a terrifying notion. But I imagine one BP wishes it had right about now.

Two questions about extending this idea to business models:

1) wouldn’t turning “hey, we can always go bankrupt” into a get out of jail free card just encourage businesses to engage in LESS responsible practices? Much of what ails us now stems from businesses’ ability to externalize the full costs of what they do (e.g. we STILL don’t have a carbon tax). Seems to me like a crash-only business model would just encourage more of that and less of what we actually need in this world, which is long-term thinking baked into the DNA of corporate entities.

2) How do you know this isn’t happening already?

Whoah! You’re totally right. “Plan to crash” suddenly sounds awfully familiar.

Steve says…

I’ve seen many business recover with a different name and continue to rip-off customers and pilfer money from the Government purse through a lack of proper monitoring of grants. So in effect this method already occurs.

Here’s a little analogy.

Powered aircraft pilots practice engine-out scenarios as part of emergency training. A checklist is brought out that usually sets a good glide angle and starts the pilot thinking about a place to land.

However, glider pilots perform that skill every flight. From the moment of release and throughout the flight, they’re constantly planning ahead, thinking of where the landing spot will be (and some alternates) and what flight path will get them there.

That’s terrific! Yep, perfect analogy.

Crash-only romantic entanglements.

Speaking of politics, this reminds me of something Ezra Klein said back during HCR debate, although I can’t find the link. Political parties like to try to engineer “permanent majorities.” And all the structural incentives, from politicians to staffers to lobbyists and fundraisers, push you in that direction. But if you look at history, every party that has a majority loses it, and loses it pretty quickly. The idea he pushed is that majorities aren’t to be kept, but to be gained, used in the service of long-term goals of your party, and then lost. You lose seats, maybe you even lose power for a while, but you get health-care reform.

ajuc says…

if you can easily recover from crash, why show the user, that crash even happened?

We can just crash and recover in background.

And then it turns out, that some conditions (for example some server not responding) triggers crash and recover infinite loops .

Then we have to add many kinds of recovery code, and our code paths become less integrated, and there are more and more almost never used code, and we are where we started :0

At least that’s what happened with app i work on in my job.

I suppose the analog is science is following a radical theory to its furthest conclusions and working hard to test it under the most adverse of conditions. Many theories are abandoned and ignored long before they have been exhaustively investigated or tested. Scientists are sometimes afraid to pursue speculative new ideas because it may be difficult to publish if you’re off in your own little corner of thoughtspace. Instead, scientists often retreat to the comfort of established lines of thinking, where they can more easily crank out mediocre papers on mildly interesting results.

“Crash-only” science would encourage embracing radical new ideas and pursuing them to their logical and experimental conclusions.

And all the struc­tural incen­tives, from politi­cians to staffers to lob­by­ists and fundrais­ers, push you in that direc­tion.

We can just crash and recover in background.

Marv says…

Isn’t this what lock free transaction systems do?
They allow every thread to run until a collision is detected. In that case, one of the colliding threads is rolled back (“crashed”) with the potential loss of some work. It is then restarted try again.

chuck says…

At risk of sounding like a dorky neo-Darwinist – the seeds which germinate in forest fires aren’t crashing. Before human forest management, forest fires were regular, almost predictable events. The seeds exploit the nutrient-rich, competition-free environments which come along regularly. For them it’s not a worst case scenario by any means. And they weren’t designed, they evolved. It’s a big difference.

Good point re: the regularity of forest fires. I don’t think the design/evolve distinction matters in this case, though; in fact, if evolution pushed some organism towards a crash-only model, I’d consider that a solid endorsement of the strategy.

As a 1-man shop, I develop web-based applications for a client who prefers “make it fast & cheap with few specs”. I often code the most likely scenarios with lots of parameter- & logic-checks along the way that fail with a “red screen of oops”. These crash-only paths make up for “few specs”: if I get a call or message about a red screen, then I get to ask, “Why were you doing that?” Then, I either improve the checks that allowed that error, or I get to code another, now-better-defined, useful scenario. If a crash-only path never happens, then I saved the time fulfilling it. Not “standard methodology”, but we’ve survived in an economy-challenged industry for six years now.

In The Matrix, the Architect explains that the system (of human society) is unstable and has to crash on occasion so it can be rebuilt.

Since this blog is called The Snarkmatrix I assume this is what motivates this post.

Quotes from the Architect:

You are here because Zion is about to be destroyed. Its every living inhabitant terminated, its entire existence eradicated.

… Rest assured, this will be the sixth time we have destroyed it, and we have become exceedingly efficient at it.

… stumbled upon a solution whereby nearly ninety-nine percent of the test subjects accepted the program provided they were given a choice – even if they were only aware of it at a near-unconscious level. While this solution worked, it was fundamentally flawed, creating the otherwise contradictory systemic anomaly, that, if left unchecked, might threaten the system itself. Ergo, those who refused the program, while a minority, would constitute an escalating probability of disaster.

Your life is the sum of a remainder of an unbalanced equation inherent to the programming of the matrix. You are the eventuality of an anomaly, which despite my sincerest efforts I have been unable to eliminate from what is otherwise a harmony of mathematical precision. While it remains a burden assiduously avoided, it is not unexpected, and thus not beyond a measure of control. Which has led you, inexorably, here.

Which brings us at last to the moment of truth, wherein the fundamental flaw is ultimately expressed, and the Anomaly revealed as both beginning… and end.

Tim Maly says…

Coming back to think, I’ve been thinking about it for governments again or other institutions that have a tendency to accumulate over time. Some of that accumulation is good to be sure but much of it isn’t or could be better designed or what have you.

But now I’m not really talking about crash only. I’m talking about sunset clauses and constant decay as well as renewal.

The snarkmatrix awaits you

Below, you can use basic HTML tags and/or Markdown syntax.