Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust in QEMU Roadmap

lore.kernel.org

Post reply on HN
Print view View original

81–90 of 184 posts

Re: Rust in QEMU Roadmap

#81

Post by lvass »

sureglymop wrote: post #40
jdefr89 wrote: post #29

[flagged]

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well. I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In m…

Clangd just works, and quite nicely, for me in Emacs, didn't even need to install any external package besides clang-tools from my distro's repository. I don't get this argument at all. The dependency management advantage is probably cool until you realize you can basically only trust distro maintainers to provide long term support for dependencies and crates makes it much harder for them, and makes programs less likely to remain secure in the long run. Who's going to fix a heap of Rust abandonware when an exploit is found in their transient dependencies?

Re: Rust in QEMU Roadmap

#82

Post by 0x457 »

vlovich123 wrote: post #35

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

Because QEMU wants their thing to be packaged in various distros. Those distros don't allow packages to bring their own tool chain (for good reasons).

Re: Rust in QEMU Roadmap

#83

Post by 0x457 »

ronsor wrote: post #68
vlovich123 wrote: post #63

Earlier quoted context omitted.

You’re answering a slightly different question but to me that’s a Debian packaging problem to solve. It’s weird to me that QEMU devs take this problem seriously enough to be putting in all sorts of workarounds to support old versions of the toolchain in the tip of tree just to privilege Debian support. This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo tha…

> As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. Most toolchains don't have as much churn as Rust.

> Most toolchains don't have as much churn as Rust.

What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code.

Now compare rust releases to this: https://gcc.gnu.org/releases.html

Re: Rust in QEMU Roadmap

#84

Post by capitainenemo »

vlovich123 wrote: post #35

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

Well, at least a couple of years ago, one surprising thing I discovered with rustup was that unlike distros that have a clean install/uninstall, rustup was rm -rf * ing everything in the place it was installed. There was an open bug on it and multiple complaints. I, who needed it for various system builds, had innocently rustup'd to /usr/local. On uninstall, it wiped all of /usr/local. I had backups on that machine, but it was still an unpleasant experience and I did lose a few not-too-important scripts.

I don't know if others have run into the same thing, but it's why I'd trust Gentoo's packaging more.

Re: Rust in QEMU Roadmap

#85

Post by jeroenhd »

vlovich123 wrote: post #35

Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.

The goal of non-rolling release distros is to have a predefined set of dependencies, which the distro maintains and fixes if necessary.

If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture, Debian must fix that for their users. That leaves the curl2bash installers that are popular with fast moving tools and languages useless for long term stability. The same goes for crates, which can be pulled at any time for almost any reason and break compiles.

Then there are other setups distros can choose to support, like having update servers/package repositories for updating servers that aren't allowed to connect to the internet or are even air gapped. You can't save rustup to a DVD, but you can take a copy of the Debian repository and update air gapped servers in a way that leaves a permanent trace (as long as you archive the disks).

Not all distros have this problem. In theory the Rust people could set up an apt/repository Debian users can add to get the best features of a package manager and the latest version, and distros like Arch/Gentoo don't bother with the stability guarantees most distros have.

Qemu can ignore these requirements and opt into not being packaged into distros like Debian or Ubuntu or Fedora or RHEL or Oracle Linux. That'd cost them a lot of contributions from those platforms, though, and may cause a risk of the project being forked (or even worse, end up in the ffmpeg/avconv situation).

Re: Rust in QEMU Roadmap

#86

Post by 0x457 »

jdefr89 wrote: post #42
sureglymop wrote: post #40

Earlier quoted context omitted.

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well. I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In m…

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.

I'm current working on an embedded project in rust. The most annoying part is when the project is shared with a non-embedded part, but otherwise it's a breeze to work on.

Had no issues using DMA or anything else.

Re: Rust in QEMU Roadmap

#87

Post by jdefr89 »

jujube3 wrote: post #74
sureglymop wrote: post #40

Earlier quoted context omitted.

Even if you took the whole safety aspect away, why should I start a new project in Rust as opposed to C or C++? Rust has modern tooling, great IDE support and a language server, nice dependency management, cargo and I could go on. Writing rust makes it imo much easier to structure your code and project as well. I just recently had to build a medium sized C project. The Makefile alone was at least 700 lines long. In m…

Read his comment. This guy literally writes exploits for C/C++ software. Of course he wants you to keep using memory-unsafe languages, otherwise his business dries up!

LMAO. Alright you made me laugh you got me there. My secret plot fam…

Re: Rust in QEMU Roadmap

#88

Post by jdefr89 »

dralley wrote: post #60
jdefr89 wrote: post #42

Earlier quoted context omitted.

Say you have to develop an embedded project. Try dealing with Rust and its dependency hell as everything you do requires a million different packages.. Or, develop me a driver that needs DMA.. How about a kernel allocator? Want to do that? Sure just wrap everything in "Unsafe"... So what is the point? Furthermore Rust programs link to libc ironically.

All of that HAS been done in Rust. It's not that bad. It's actually quite good in many ways. #[no_std] is fairly unique to Rust.

Yes it has and can be done with rust. But usually by writing “unsafe” code so what the hell is the point if the majority of the code isn’t gonna have the Rust memory guarantees it would normally have? Furthermore, not all MCUs have a Rust compiler or tool chain to use. C is the defacto standard. Not saying it cannot be done, just that I am not sure it’s worth the extra effort and overhead.

Re: Rust in QEMU Roadmap

#89

Post by kstrauser »

jdefr89 wrote: post #29

[flagged]

> Binary exploitation is my field of expertise.

> Creating an entire language to prevent such bugs is excessive, especially given the current state of software security.

I'm having a hard time reconciling those 2 statements. I can imagine any 1 person having one or the other of those opinions, but not both at the same time.

> Meanwhile, the vast majority of security issues (around 98%) come from basic human errors, such as reusing passwords or falling for phishing, not sophisticated zero-days exploiting memory corruption.

We're not limited to doing just one thing, you know. Some people are working on improving the authentication space. Others are working on making it easier for developers to write safe code. Both of those can progress at the same time.

Re: Rust in QEMU Roadmap

#90

Post by jdefr89 »

Novosell wrote: post #58
jdefr89 wrote: post #44

Earlier quoted context omitted.

What are the other advantages exactly besides tool chain? A lot of people using Rust where the could have just used Go or another language that is memory safe and actually productive. Maybe I am just being a hater because I grew up on C/C++ but I know for a fact "Rustaceans" are getting out of control. Approaching zealot territory for sure. The time people spend fighting the Rust compiler for a project, they could ha…

The US government, Linux, Google, Mozilla and many more see value in memory safe languages, yet I see so many people, like you, saying "No, they're all wrong. Get good.". I just don't get it. What insights do you have that makes you more qualified than all these organizations combined? What are they all missing?

I have been doing government work for a while and understand why they respond that way. Nation states can in fact develop very powerful kill chains. My entire start up was created and sold based on a vehicle kill chain but that took us a year and a half to do… Mean while some kid in his moms basement uses leaked credentials and sprays a network or phishes and boom. Major breach…
Post reply on HN