“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

#191

Post by WastingMyTime89 » Sun, Oct 02, 2022, 4:16 PM UTC

titzer wrote: post #148

jmillikin wrote: post #137

Earlier quoted context omitted.

I think Linus's response would be that those failable tasks are called "processes", and the low-level supervisor that starts + monitors them is the kernel. If you have code that might fail and restart, it belongs in userspace. If you want to run an Erlang-style distributed system in the kernel then that's an interesting research project, but it isn't where Linux is today. You'd be better off starting with SeL4 or Fuc…

40 years of microkernels, of which I know Linus is aware of, beg to differ. Maybe Linus's extreme opposition to microkernels, ostensibly because they have historically a little lower performance--I dunno--but my comment should not be read as "yes, you must have a microkernel". There are cheaper fault isolation mechanisms than full-blown separate processes. Just having basic stack unwinding and failing a task would be…

Sorry it’s hard to take you seriously after that.

Linux isn’t a microkernel. If you want to work on a microkernel, go work on Fuchsia. It’s interesting research but utterly irrelevant to the point at hand.

Anyway, the microkernel discussion has been happening for three decades now. They haven’t historically had a little lower performance. They had garbage performance, to the point of being unsuitable in the 90s.

Plenty of kernel code can’t be written as to be unwindable. That’s the issue at hand. In a fantasy world, it might have been written as such but it’s not the world will live in which is what matters to Linus.

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

#192

Post by pca006132 » Sun, Oct 02, 2022, 4:17 PM UTC

EdSchouten wrote: post #138

jmillikin wrote: post #81

As usual HN comments react to the headline, without reading the content. A lot of modern userspace code, including Rust code in the standard library, thinks that invariant failures (AKA "programmer errors") should cause some sort of assertion failure or crash (Rust or Go `panic`, C/C++ `assert`, etc). In the kernel, claims Linus, failing loudly is worse than trying to keep going because failing would also kill the fa…

The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…

Probably not very linux, but consider the case where a device is controlling a motor speed by setting its current, computed by getting its current speed and do a simple PID control. If your device crashed (due to failure of something else, for example some LED display) while the current output is pretty large, you may cause some serious damage to whatever that motor is connected to. The thing the system should be able to do is notify such error and gracefully shutdown, for example sending commands to shutdown everything else.

Although I think this can be better done by some special panic handler that performs a sjlj and notify other systems about the failure, without continuing running with the wrong output...

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

#193

Post by jjnoakes » Sun, Oct 02, 2022, 4:18 PM UTC

alerighi wrote: post #141

swinglock wrote: post #121

Earlier quoted context omitted.

At least in user space, aborting an operation is much better than incorrect results. But the kernel being incorrect makes user space incorrect as well. First of all, making a problem both obvious and easier to solve is better. Nothing "only" about it - it's better. Better both for the programmers and for the users. For the programmer the benefit is obvious, for the user problems will simply be more rare, because the…

> 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…

> for a customer a system that crashes completely is worse than a system that has some bugs somewhere

This entirely depends on the industry and the customer. My team leaves asserts on in production code because our customers want aborts over silent misbehavior.

It is an order of magnitude cheaper for them if things fail loudly and they get a fix when compared to them tracking down quiet issues hours, days, or even months after the fact.

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

#194

Post by [deleted] » Sun, Oct 02, 2022, 4:18 PM UTC

PragmaticPulp wrote: post #49

I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…

[deleted]

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

#195

Post by zo1 » Sun, Oct 02, 2022, 4:19 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 .

I am a nice person and consider myself fair to everyone I work with, everyone gets a fair shot and a clean slate with me. But having to jump through verbal hoops to make my interactions "inclusive" and what these people would call non-hostile is downright hellish for me and way more effort than I think is reasonable. It's not inclusive towards me and is downright hostile towards me.

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

#196

Post by krater23 » Sun, Oct 02, 2022, 4:19 PM UTC

mynameisvlad wrote: post #144

aaaaaaaaaaab wrote: post #117

Earlier quoted context omitted.

>work environments It’s not a “work environment”. You can’t report Linus to HR. If you have a problem with him, you can fork the kernel and convince others to follow you. Then you’ll have a mailing list where you can ban Linus for his style. Good luck!

Yes because if he were at any company, he’d have been fired. Decades ago. Just because it’s not an official “work environment” per your definition does not mean it isn’t hostile or intolerable were it actually one. But actually countering that point is a lot harder, isn’t it?

Ok, it's intolerable for you how he communicates on the Linux Kernel Mailing List. Are you anyway subscribed to the LKML? Are you kernel developer? Are you developer anyway? Who you are that you want to tell a community how they have to communicate? Why your opinion should matter for this community?

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

#197

Post by throw827474737 » Sun, Oct 02, 2022, 4:19 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 .

Nope, imo this extreme also excludes many average folks are not so overly poliically correct. I have the feeling we have overshot peak inclusion and are excluding the not so well behaved folks (or simple people who have other problems, or who want to play these games).

Personally I find that Linus here not toxic at all, at most a borderline strong opinion, but come on, as well as we all need to be more empathic, we should also be able to take some harsher critique and make not such a toxicity thing out of an more open and direct opinionated response...

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

#198

Post by mynameisvlad » Sun, Oct 02, 2022, 4:19 PM UTC

LunaSea wrote: post #170

mynameisvlad wrote: post #161

Earlier quoted context omitted.

Would it make it more ok if people were? How many people are joining? How many people are joining because or in lieu of Linus? How many people are joining just because it’s Linux/Git/whatever (although granted that is in part due to Linus making them such big things)? How many people would have joined/wouldn’t have left if he wasn’t there?

That doesn't matter. It is his project and people are free ton join or start their own.

Of course it matters. There are many reasons why people might join one of his projects, many of which don’t involve him but instead the project itself. His presence might have stifled or grown involvement in those projects.

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

#199

Post by layer8 » Sun, Oct 02, 2022, 4:20 PM UTC

pornel wrote: post #122

layer8 wrote: post #99

Earlier quoted context omitted.

Please correct me if I’m wrong, but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, and thus with regards to Linux kernel requirements isn’t safer in that aspect than C. To the contrary, Rust is arguably less safe in that aspect than C, due to the general Rust practice of panicking upon unexpected conditions.

Lack of a non-hacky no-panic guarantee is a pain. That would be like a no-segfault guarantee in C. But Rust's situation is still safer, because Rust can typically prevent more errors from ever becoming a run-time issue, e.g. you may not even need to use array indexing at all if you use iterators. You have a guarantee that references are never NULL, so you don't risk nullptr crash, etc. Rust panics are safer, because…

One has to be careful about words. When Rust (or Linux) is used in (say) a vehicle or in a nuclear power plant, panicking certainly has immediate safety implications.

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

#200

Post by Someone1234 » Sun, Oct 02, 2022, 4:21 PM UTC

bobajeff wrote: post #92

As a layman who hasn't done any kernel programming. Linus sounds pretty reasonable here. We can't have the kernel crashing because of a panic.

A kernel crash IS a panic. They're one and the same.

The discussion is a little more nuanced than just that. It is "we've entered an invalid/undefined/corrupt state, now what?" And in essence saying "We ONLY panic as a matter of last resort, we'll just spit out a bunch of loggable errors and soft fail from the kernel call until then."