“Rust is safe” is not some kind of absolute guarantee of code safety • Hacker News Board

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#421

Post by notacoward » Sun, Oct 02, 2022, 9:05 PM UTC

yencabulator wrote: post #415

notacoward wrote: post #386

Earlier quoted context omitted.

> What about a medical procedure that WILL kill the patient if interrupted? What about life support in space? The proper answer to those is redundancy , not continuing in an unknown and quite likely harmful state.

The leap second bug would have crashed all nodes of a redundant system, at the same time...

Perhaps. On the other hand, letting a medical device continue moving an actuator or dispensing a medication when it's known to be in a bad "never happen" state could also be fatal. Ditto for the "life support in space" example. Ditto for anything reliant on position, where the system suddenly realizes it has no idea whether its position is correct. Imagine that e.g. on a warship. Limiting responses to external inputs (including time adjustments) can ameliorate such problems. So can software diversity. Many safety-critical systems require one or both, and other measures as well. Picking one black-swan event while ignoring literally every day scenarios doesn't seem very helpful. That's especially true when the thing you're advocating is what actually happened and led to its own bad outcomes.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#422

Post by lelanthran » Sun, Oct 02, 2022, 9:05 PM UTC

mynameisvlad wrote: post #58

zo1 wrote: post #50

Earlier quoted context omitted.

Then it's probably not the place for you, or people with thin skin that don't want to deal with that kind of tone/communication. If they lose out on talent because of it, that's their loss. Not every project has to be perfect and all-inclusive to the entire world of developers, and I'm okay with that.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

You're correct, it should be the default.

But why are you complaining that a group of people who don't want to work in your default environment went off and created their own?

I don't understand what you have to complain about: they have their way of working and you want to change that because it offends you?

Sounds like you're the problem, not them.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#423

Post by alias_neo » Sun, Oct 02, 2022, 9:05 PM UTC

gmueckl wrote: post #337

jmillikin wrote: post #261

Earlier quoted context omitted.

> including e.g. the monitor attached to the PC used for displaying > X-ray images Somewhat off-topic, but I used to work in a dental office. The monitors used for displaying X-rays were just normal monitors, bought from Amazon or Newegg or whatever big-box store had a clearance sale. Even the X-ray sensors themselves were (IIRC) not regulated devices, you could buy one right now on AliExpress if you wanted to.

That's not the case in the EU. I've worked for an equipment manufacturer for dental clinics. While the monitors were allowed to be off the shelf, the operator (dental clinic) is required to make sure that they work properly and display the image correctly - obey certain brightness and color resolution/calibration standards. Our display software had to refuse to work on an uncalibrated monitor.

Interesting, how does your software detect an uncalibrated monitor? Did it come with a calibration device which had to be used to scan the display output to check?

I don't suppose monitors report calibration data back to display adapters do they?

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#424

Post by krater23 » Sun, Oct 02, 2022, 9:12 PM UTC

maxbond wrote: post #392

wtallis wrote: post #389

Earlier quoted context omitted.

> But if we were operating, say, a Mars rover, and shutting down meant we would never be able to boot again, then it'd be better take kernel A and attempt to recover from whatever state we find ourselves in. That's pretty exotic, however. That you view it as exotic is partly a lack of imagination on your part; with a little more effort it's possible to identify similar use cases that are much closer to home than Mars…

> [W]ith a little more effort it's possible to identify similar use cases that are much closer to home than Mars. If you feel there are some that would add to this conversation, feel free to share them.

Your phone dies when you need to call 911. Your selfdriving car dies when you driving 120km/h on the highway. Only 2 that needed no effort to find.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#425

Post by wtallis » Sun, Oct 02, 2022, 9:12 PM UTC

notacoward wrote: post #418

wtallis wrote: post #413

Earlier quoted context omitted.

I understand why a failing drive or apparently corrupt filesystem would be reason to freeze a filesystem. But that's nowhere close to kernel panic territory. Even in a distributed, fault-tolerant multi-node system, it seems like it would be useful for the kernel to keep running long enough for userspace to notify other systems of the failure (eg. return errors to clients with pending requests so they don't have to wa…

In a system already designed to handle the sudden and possibly permanent loss of a single machine to hardware failure, those are nice to have at best. "Panic" doesn't have to mean not executing a single other instruction. Logging e.g. over the network is one of the things a system might do as part of its death throes, and definitely was for the last few such systems I worked on. What's important is that it not touch…

> "Panic" doesn't have to mean not executing a single other instruction.

We're talking specifically about the current meaning of a Linux kernel panic. That means an immediate halt to all of userspace.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#426

Post by V_Terranova_Jr » Sun, Oct 02, 2022, 9:12 PM UTC

blueflow wrote: post #104

mynameisvlad wrote: post #35

Earlier quoted context omitted.

This is also the “toned down” version of Linus. If he were any other person, he’d have been axed a long time ago for this behavior. I don’t understand how people put up with this kind of toxicity, even from him.

I bear this because in my opinion, software development has insufficient regulation and standards. I've seen enough bad software that im glad that someone is enforcing some standards regarding worst-case behavior, because this is something that is neglected too often. Its a bit sad that Linus needs to replicate individually what other engineering disciplines are mandated to by regulations. Look at car, train or aviat…

It's really more about rigor and the actual practice of engineering (e.g., tracking requirements and verification of implementation against these requirements, verifying systems & subsystems meet correctness invariants, etc.) moreso than regulation. Most software development is craftsmanship, including the Linux kernel. It's certainly possible to practice software development as engineering, but it's not common.

Source: aerospace engineer with a flight sciences background, and also software reviewer for flight systems.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#427

Post by V_Terranova_Jr » Sun, Oct 02, 2022, 9:14 PM UTC

lelanthran wrote: post #422

mynameisvlad wrote: post #58

Earlier quoted context omitted.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

You're correct, it should be the default. But why are you complaining that a group of people who don't want to work in your default environment went off and created their own? I don't understand what you have to complain about: they have their way of working and you want to change that because it offends you? Sounds like you're the problem, not them.

Sounds like he's calling them out on an internet forum that they are also free to ignore. Doesn't sound like he's the problem.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#428

Post by GauntletWizard » Sun, Oct 02, 2022, 9:15 PM UTC

alias_neo wrote: post #423

gmueckl wrote: post #337

Earlier quoted context omitted.

That's not the case in the EU. I've worked for an equipment manufacturer for dental clinics. While the monitors were allowed to be off the shelf, the operator (dental clinic) is required to make sure that they work properly and display the image correctly - obey certain brightness and color resolution/calibration standards. Our display software had to refuse to work on an uncalibrated monitor.

Interesting, how does your software detect an uncalibrated monitor? Did it come with a calibration device which had to be used to scan the display output to check? I don't suppose monitors report calibration data back to display adapters do they?

My guess is they had some heuristic based on EDIDs, which are incredibly easy to spoof.

https://smile.amazon.com/EVanlak-Passthrough-Generrtion-Elim...

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#429

Post by alerighi » Sun, Oct 02, 2022, 9:19 PM UTC

swinglock wrote: post #397

alerighi wrote: post #141

Earlier quoted context omitted.

> Aborting an operation is much better than incorrect results. Depends. Is a kernel panic better than something acting wrongly? I prefer my kernel not to panic, at the expense of some error somewhere that may or may not crash my system. If you look at the output of `dmesg` on any Linux system you often will see errors even in a perfectly working system. This is because programs of that size are by definition not perf…

> Depends. Is a kernel panic better than something acting wrongly? I prefer my kernel not to panic, at the expense of some error somewhere that may or may not crash my system. That's a false dichotomy, you don't get to choose between definitely crashing or maybe crashing. That would be nice but it's not on the menu. Crashing is just the best case scenario, so if you can make your system stop instead of being incorrec…

> That's a false dichotomy, you don't get to choose between definitely crashing or maybe crashing. That would be nice but it's not on the menu. Crashing is just the best case scenario, so if you can make your system stop instead of being incorrect, that's great.

So you prefer a system completely unusable than a system that may be used, but with some errors? If you prefer the first, you will not be able to use practically nothing. If you look at the `dmesg` output of a running Linux system you can find a lot of errors, that even if a single one of them was turned into a panic, your computer would not even be able to boot.

Nothing is perfect, and errors will appear. Ideally errors should be handled at the lowest possible level, but if unhandled to me errors should not result in a complete system crash.

> We don't all do that.

I do that. Reason is that not doing that in my use case would not only render completely unusable the product, but not even upgradable with an over the air firmware update. So better that the system will continue running than it crashing (and then rebooting).

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#430

Post by V_Terranova_Jr » Sun, Oct 02, 2022, 9:25 PM UTC

zo1 wrote: post #50

rat9988 wrote: post #4

I am the only one who would have a hard time to collaborate on a project where the "collaborators" start their message with > You need to realize that > (a) reality trumps fantasy ?

Then it's probably not the place for you, or people with thin skin that don't want to deal with that kind of tone/communication. If they lose out on talent because of it, that's their loss. Not every project has to be perfect and all-inclusive to the entire world of developers, and I'm okay with that.

It's a false dichotomy to say you either have to be "all-inclusive to the entire world of developers" or you should applaud project leaders throwing out useless condescending rants with no real technical content like:

  And the *reality* is that there are no absolute guarantees.  Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus.

What's going on here is not "woke people" trying to protect every little snowflake's feelings, rather it's noting the ranter is making himself feel good at others' expense with no other value added. His rants are completely superfluous to the substantive technical dialogue.