5 ms·

Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"? Migrations of this size ar

Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"? Migrations of this size aren't not done because they're technically bad ideas, but exactly because they're expensive, messy, and few people have the appetite or funding to do it. Proposing a solution to that is more interesting that just saying "switch to Rust!". Also, I don't know much Rust (still on my PL bucket list), but usually when I dive into a more detailed analysis of such a migration the most relevant parts are around how much unsafe code will be required and whether or not integrating with the existing codebase has to be fine-grained or can be done in larger modules like Rust recommends. I would naively guess that a VM would have lots of unsafe code. Are there any investigations on whether the recent vulnerabilities would have migrated to safe or unsafe code? edit: mea culpa. I didn't read the second to last-paragraph closely enough, which at least proposes a modularized way of doing this with device emulation being written in Rust in separate modules.

slim 6y ago
Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"? he made it to the front page of HN, so I guess the answer is "Yes"
- rvz 6y ago
  The answer is "Maybe" but this developer won't do it. Someone else has to make it a reality. Once again and eventually the response is still PoC||GTFO.
- nomel 6y ago
  Entertainment value is separate from practical value and feasibility.
  - adsjhdashkj 6y ago
    Maybe the practical value is traffic?
- Recursing 6y ago
  A GPT-3 written nonsensical article made it to the front page of HN[0], so I don't think it's a good measure of value [0] https://news.ycombinator.com/item?id=23893817 https://news.ycombinator.com/item?id=23893817
  - tgflynn 6y ago
    How would I go about confirming that your statement is accurate ? I see several comments on the article saying it looks like it might have been written by GPT-3, but there's no confirmation. There's also a comment on the article itself that is certainly suggestive but doesn't seem to come out and openly state that this was written by GPT-3. Finally I clicked on the author's name and see a list of several articles but no disclaimer that this author is a bot.
    - Lewton 6y ago
      https://liamp.substack.com/p/my-gpt-3-blog-got-26-thousand-visitors https://liamp.substack.com/p/my-gpt-3-blog-got-26-thousand-v... It took some digging to find this
- swsieber 6y ago
  Given the author is a long time contributor, this post is actually a bad indicator.
steveklabnik 6y ago
Given that this person has apparently worked on QEMU for ten years, I do think that it's interesting, regardless of the answer.
- jwatt 6y ago
  In addition to the author being a long term contributor, the piece seems to have been a leader for a discussion[1] on the qemu-devel mailing list (where it seems to have been positively received). [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg00800.html https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg...
- benlwalker 6y ago
  Much of this is written in the context of the new vfio-user proposal he linked at the end. This is a new, more flexible mechanism for implementing device emulation in a separate process. That emulation code can certainly be written in rust, providing a gradual path toward conversion. As background, vfio-user was at least partially born of some discussions and a proof of concept last summer for using SPDK to provide virtual NVMe devices into QEMU. These are intended to be high performance devices. Except SPDK is written in C. So maybe the title should be rewrite SPDK in Rust!
vlovich123 6y ago
Forget the last paragraph. Literally opened answering your question: > My KVM Forum 2018 presentation titled Security in QEMU: How Virtual Machines provide Isolation (pdf) (video) reviewed security bugs in QEMU and found the most common causes were C programming bugs. This includes buffer overflows, use-after-free, uninitialized memory, and more. In this post I will argue for using Rust as a safer language that prevents these classes of bugs. __found the most common causes were C programming bugs. This includes buffer overflows, use-after-free, uninitialized memory, and more__
- R0b0t1 6y ago
  Sure, but the alternative is investing in static analysis for C code, of which there are plenty of tools for. My usage of rust for now has indicated to me that for most low level tasks you are better of using C or C++. It is more suited to it. There appears to be a lot of boilerplate in rust.
  - swsieber 6y ago
    > but the alternative is investing in static analysis for C code, Yeah, the author explicitly acknowledges that: > Eliminating C programming bugs does not necessarily require switching programming languages. Other approaches to reducing bug rates in software include: > Coding style rules that forbid unsafe language features. > Building safe abstractions and prohibiting unsafe language features or library APIs. > Static checkers that scan source code for bugs. > Dynamic sanitizers that run software with instrumentation to identify bugs. > Unit testing and fuzzing. > The problem is, the QEMU community has been doing these things for years but new bugs are still introduced despite these efforts. It is certainly possible to spend more energy on these efforts but the evidence shows that bugs continue to slip through.
    - R0b0t1 6y ago
      Yes? Half of those are classes of bugs that would probably still exist with the usage of Rust, that is, they're simply a diversion from what you expected and what actually happens that the borrow checker can't save you from. You need to separate all bugs from the bugs Rust can't introduce. It's safer, in theory, to just do it in Rust first, but it is also important to consider the amount of time it actually takes to implement either. Why is this garnering downvotes...?
sudeepj 6y ago
> Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"? Could it be that he agrees in principle that Rust is the way to go but for some reasons (time, interest, etc) he does not want to do it.
dna_polymerase 6y ago
> Proposing a solution to that is more interesting that just saying "switch to Rust!". The firefox way would be more interesting, start by introducing Rust to the codebase, than write first components in it and switch it over time.

slim 6y ago

Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"? he made it to the front page of HN, so I guess the answer is "Yes"

rvz 6y ago
The answer is "Maybe" but this developer won't do it. Someone else has to make it a reality. Once again and eventually the response is still PoC||GTFO.
nomel 6y ago
Entertainment value is separate from practical value and feasibility.
- adsjhdashkj 6y ago
  Maybe the practical value is traffic?
Recursing 6y ago
A GPT-3 written nonsensical article made it to the front page of HN[0], so I don't think it's a good measure of value [0] https://news.ycombinator.com/item?id=23893817 https://news.ycombinator.com/item?id=23893817
- tgflynn 6y ago
  How would I go about confirming that your statement is accurate ? I see several comments on the article saying it looks like it might have been written by GPT-3, but there's no confirmation. There's also a comment on the article itself that is certainly suggestive but doesn't seem to come out and openly state that this was written by GPT-3. Finally I clicked on the author's name and see a list of several articles but no disclaimer that this author is a bot.
  - Lewton 6y ago
    https://liamp.substack.com/p/my-gpt-3-blog-got-26-thousand-visitors https://liamp.substack.com/p/my-gpt-3-blog-got-26-thousand-v... It took some digging to find this
swsieber 6y ago
Given the author is a long time contributor, this post is actually a bad indicator.

steveklabnik 6y ago

Given that this person has apparently worked on QEMU for ten years, I do think that it's interesting, regardless of the answer.

jwatt 6y ago
In addition to the author being a long term contributor, the piece seems to have been a leader for a discussion[1] on the qemu-devel mailing list (where it seems to have been positively received). [1] https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg00800.html https://lists.nongnu.org/archive/html/qemu-devel/2020-08/msg...
benlwalker 6y ago
Much of this is written in the context of the new vfio-user proposal he linked at the end. This is a new, more flexible mechanism for implementing device emulation in a separate process. That emulation code can certainly be written in rust, providing a gradual path toward conversion. As background, vfio-user was at least partially born of some discussions and a proof of concept last summer for using SPDK to provide virtual NVMe devices into QEMU. These are intended to be high performance devices. Except SPDK is written in C. So maybe the title should be rewrite SPDK in Rust!

vlovich123 6y ago

Forget the last paragraph. Literally opened answering your question: > My KVM Forum 2018 presentation titled Security in QEMU: How Virtual Machines provide Isolation (pdf) (video) reviewed security bugs in QEMU and found the most common causes were C programming bugs. This includes buffer overflows, use-after-free, uninitialized memory, and more. In this post I will argue for using Rust as a safer language that prevents these classes of bugs. __found the most common causes were C programming bugs. This includes buffer overflows, use-after-free, uninitialized memory, and more__

R0b0t1 6y ago
Sure, but the alternative is investing in static analysis for C code, of which there are plenty of tools for. My usage of rust for now has indicated to me that for most low level tasks you are better of using C or C++. It is more suited to it. There appears to be a lot of boilerplate in rust.
- swsieber 6y ago
  > but the alternative is investing in static analysis for C code, Yeah, the author explicitly acknowledges that: > Eliminating C programming bugs does not necessarily require switching programming languages. Other approaches to reducing bug rates in software include: > Coding style rules that forbid unsafe language features. > Building safe abstractions and prohibiting unsafe language features or library APIs. > Static checkers that scan source code for bugs. > Dynamic sanitizers that run software with instrumentation to identify bugs. > Unit testing and fuzzing. > The problem is, the QEMU community has been doing these things for years but new bugs are still introduced despite these efforts. It is certainly possible to spend more energy on these efforts but the evidence shows that bugs continue to slip through.
  - R0b0t1 6y ago
    Yes? Half of those are classes of bugs that would probably still exist with the usage of Rust, that is, they're simply a diversion from what you expected and what actually happens that the borrow checker can't save you from. You need to separate all bugs from the bugs Rust can't introduce. It's safer, in theory, to just do it in Rust first, but it is also important to consider the amount of time it actually takes to implement either. Why is this garnering downvotes...?

sudeepj 6y ago

> Is it worth the effort to write a "X should switch to Rust" post that ends with "but I personally don't have the appetite to do it"? Could it be that he agrees in principle that Rust is the way to go but for some reasons (time, interest, etc) he does not want to do it.

dna_polymerase 6y ago

> Proposing a solution to that is more interesting that just saying "switch to Rust!". The firefox way would be more interesting, start by introducing Rust to the codebase, than write first components in it and switch it over time.