Earlier quoted context omitted.
[flagged]
What does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.
[deleted]
The state of the kernel Rust experiment
71–80 of 148 posts
Re: The state of the kernel Rust experiment
#72Earlier quoted context omitted.
[flagged]
> You and Greg are sorely mistaken. Greg Kroah-Hartman has been a Linux kernel developer for 25 years, responsible for large parts of the kernel. You’ve been a hacker news commenter for 1 day. Could you pipe down with these wild claims that you know better than him? Also, please don’t complain about downvotes. It’s tedious to read.
[flagged]
Re: The state of the kernel Rust experiment
#73Earlier quoted context omitted.
Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—…
IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to f…
> in C only specific language features are unsafe and not all code
Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without:
* Dereferencing pointers * Array access * Incrementing signed integers
You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from the ones that can't.
Re: The state of the kernel Rust experiment
#74Re: The state of the kernel Rust experiment
#75Earlier quoted context omitted.
I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises. One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond t…
It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
I think defining terminology here might help.
An attempt:
Language-UB (L-UB): UB according to the guarantees of the language.
Project-compiler-UB (PC-UB): The project picks compilers and compiler settings to create a stronger set of guarantees, that turns some language-UB into not being UB. Examples include turning off the strict aliasing requirement in the used compilers, or a compiler by default defining some language-UB as being defined behavior.
I do not know if such terms might catch on, though. Do they seem reasonable to you?
Re: The state of the kernel Rust experiment
#76Earlier quoted context omitted.
It is entertaining to observe that how - after the bullshit and propaganda phase - Rust now slowly enters reality and the excuses for problems that did not magically disappear are now exactly the same as what we saw before from C programmers and which Rust proponents would have completely dismissed as unacceptable in the past ("this CVE is not exploitable", "all programmers make mistakes", "unwrap should never been u…
You have a wild amount of confirmation bias going on here, though. Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises. The promise of Rust was never that it is magical. The promise is that it is significantly easier to manage these types of problems.
> Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.
The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in order to avoid UB.
Re: The state of the kernel Rust experiment
#77Earlier quoted context omitted.
I've done a bit of work with Rust, and while I did find some of the complexity frustrating, it wasn't _that_ bad. While I could sort of see some situation like you describe with a secret agenda from big tech, I think that probably requires significantly more cunning & organisation than they actually have around this stuff. It's not like Microsoft invented Rust - in fact it came from a relatively small corp in the fir…
It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design. Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft. The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. J…
>It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design.
Compared to C where it has the opinion of no fixed data types making you deal with it.
>Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.
Systemd was only opinionated in how it should break posix, because it's meant to be Linux only.
And you're then saying that there is credible evidence that Poettering was a Microsoft mole almost 15 years ago with instructions to create systemd to "disrupt" the Linux ecosystem?
Boy did Microsoft fail there, more distros than ever adopted it and it's these days almost entirely pain free.
>The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
If you have actually read the docs you would know that their strategy is not to divide and conquer as they say FUD does not work, but to instead compete with OSS.
Re: The state of the kernel Rust experiment
#78Earlier quoted context omitted.
What project has been pushed to rewrite in rust that explicitly Microsoft has been the culprit in? And not individuals who work at Microsoft does not count.
> And not individuals who work at Microsoft does not count. How in the world does this not count? People act in the interest of those who pay the bills.
>How in the world does this not count? People act in the interest of those who pay the bills.
Guilty by association?
So do you have evidence of Microsoft the company doing this or not?
Re: The state of the kernel Rust experiment
#79[flagged]
Re: The state of the kernel Rust experiment
#80Earlier quoted context omitted.
> You and Greg are sorely mistaken. Greg Kroah-Hartman has been a Linux kernel developer for 25 years, responsible for large parts of the kernel. You’ve been a hacker news commenter for 1 day. Could you pipe down with these wild claims that you know better than him? Also, please don’t complain about downvotes. It’s tedious to read.
[flagged]
Saying "appeal to authority" doesn't refute the point made above. Expertise is real. Someone with 25 years of experience with the linux kernel will know a lot more about linux and C than the average HN commenter. Almost certainly more than me.
Its possible that you might be right about whatever point you're trying to make. But if you are, I can't tell that from your comments. I can't even find a clear claim in your comments, let alone any substantive argument in support of that claim.
I'm unmoved and unimpressed.