It the opposite...

you should panic in a production environment and reset the state of the machine (which has become indeterminate).

The correctness and validity of the data >> uptime.

As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state.

If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore?

Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision.

Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing.

But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before.

To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading.

The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with.

It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work.

On some self-reflection, I come to the conclusion that I want my cake and eat it too.

There rule I work to when I design these type of systems is that if the source of the error is internal you should reset and avoid propagating the error. Conversely if you receive an error from an external source you should handle it gracefully and reject the bad message.

On the other hand, the mere act of panicking may corrupt data (by virtue of stopping processes). I learned this the hard way when my kernel panicked while I was shrinking a large ext4 volume (the panic was unrelated to the shrinking). It's not just a simple equation like you've claimed.

A panic should stop the processor dead, no data should be corrected as a result. Data in flight should not be used if you use transactional I/O and therefore will not be used if a write does not complete.

That's fine in theory, but it didn't stop my disk from being corrupted. If the computer hadn't panicked, my data would still be available.

its not theory... your system wasn't designed to be fault-tolerant in that manner.

Systems that matter, are.

The linux kernel needs to work with both tolerant and non-tolerant systems. Saying it needs to work a specific way that completely breaks real world things is completely naive, and exactly what Linus was railing against.

i use linux mainly to write latex these days, i don't want my kernel to panic, I do want my machine to stay operative and not corrupt my work.

The kernel (for my intended usage) should intentionally panic only if there is a risk of corrupting my .tex files.

Absolutely panic in a production environment.

Potential data corruption is far worse, so is a potential security compromise.

It really depends on the use case!

E.g. performing industrial control automation or airplane rudder control in a completely segregated network.

You want control over these tradeoffs, not hardcoded behaviors.

Linux is ill suited for that.

Look at seL4, minix3, eChronos instead.

Well, only that most devices never were tested over months in development kernel ... and it is not possible to do so, with all those million different devices around.