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

Show HN: RustyBox – a Busybox fork written in Rust

github.com

Post reply on HN
Print view View original

41–50 of 56 posts

Re: Show HN: RustyBox – a Busybox fork written in Rust

#41

Post by dataking »

comex wrote: post #2

Seems to consist mostly of a copy of Busybox’s C code auto-translated to Rust using c2rust – resulting in ubiquitous use of raw pointers and `unsafe` for mundane operations. That’s technically “written entirely in Rust”, but not in the way you’d expect… On the other hand, it could serve as a good starting point for a gradual rewrite into idiomatic Rust.

C2Rust contributor here. Yes, the conversion to unsafe is indeed only intended as a stepping stone for a rewrite into idiomatic Rust. In fact, we're hard at work on a refactoring tool that will (hopefully, one day) take some of the tedium out of that process by doing things such as identifying raw pointers that can be upgraded to proper Rust references.

Re: Show HN: RustyBox – a Busybox fork written in Rust

#42

Post by jturpin »

beatgammit wrote: post #31
arghwhat wrote: post #25

Earlier quoted context omitted.

This would be anecdotal, and caused massive stir in the community when it was realized.

And a lot of the usages were promptly fixed when people made a stink about it.

It was only fixed when a fuzzer showed a lot of vulnerabilities. Up until then the attitude was "stop demonizing unsafe, we know what we're doing."

Re: Show HN: RustyBox – a Busybox fork written in Rust

#43

Post by cogman10 »

jturpin wrote: post #42
beatgammit wrote: post #31

Earlier quoted context omitted.

And a lot of the usages were promptly fixed when people made a stink about it.

It was only fixed when a fuzzer showed a lot of vulnerabilities. Up until then the attitude was "stop demonizing unsafe, we know what we're doing."

I don't know about those particular authors. However, the vibe I get from the rust community as a whole is "unsafe is where dragons lay". Most, I'd say, treat it just like inline asm in C++. Sometimes a necessary evil, but not something you should be in the habit of using.

Re: Show HN: RustyBox – a Busybox fork written in Rust

#44

Post by skainswoo »

dataking wrote: post #41
comex wrote: post #2

Seems to consist mostly of a copy of Busybox’s C code auto-translated to Rust using c2rust – resulting in ubiquitous use of raw pointers and `unsafe` for mundane operations. That’s technically “written entirely in Rust”, but not in the way you’d expect… On the other hand, it could serve as a good starting point for a gradual rewrite into idiomatic Rust.

C2Rust contributor here. Yes, the conversion to unsafe is indeed only intended as a stepping stone for a rewrite into idiomatic Rust. In fact, we're hard at work on a refactoring tool that will (hopefully, one day) take some of the tedium out of that process by doing things such as identifying raw pointers that can be upgraded to proper Rust references.

Automatically rewriting raw pointers to Rust references would be amazing.

Re: Show HN: RustyBox – a Busybox fork written in Rust

#45

Post by nicoburns »

namewasmypw wrote: post #24
estebank wrote: post #22

Earlier quoted context omitted.

I don't think 1) unsafe will ever become prevalent in the ecosystem nor 2) that unsafe should be seen as anything other than an escape hatch that is sometimes necessary. Autotranslations from C will be seen as what they are, a transliteration from a less safe language with exactly the same bugs as the preexisting codebase. You could think of the case of calling a COM library that has a leak or a OOB error, I wouldn't…

`unsafe` is already very prevalent in the ecosystem and this is a big point of contention. https://github.com/actix/actix-web/issues/289

Actix is currently popular, but only because the rest of the ecosystem has been waiting for `async-await`, and taking a slow-and-steady approach to getting things right. I'd expect Actix's popularity to take a dramatic downturn right about when Rocket releases a async version that runs on stable Rust.

Re: Show HN: RustyBox – a Busybox fork written in Rust

#46

Post by wrs »

Given that busybox is structured as one function per command

    int COMMAND_main(int argc, char **argv)
and that it's compilable as a library already, I wonder if it would make more sense to use bindgen or the like to start with the actual busybox C code, but with a (trivial) Rust main function. You'd have the current busybox source compiling an ever-smaller library, and a Rust lib next to it. Then move things over to the Rust side one command at a time.

Re: Show HN: RustyBox – a Busybox fork written in Rust

#48

Post by Matthias247 »

dman wrote: post #13
comex wrote: post #2

Seems to consist mostly of a copy of Busybox’s C code auto-translated to Rust using c2rust – resulting in ubiquitous use of raw pointers and `unsafe` for mundane operations. That’s technically “written entirely in Rust”, but not in the way you’d expect… On the other hand, it could serve as a good starting point for a gradual rewrite into idiomatic Rust.

Rust is going to take credibility hits if more people do this. Once it becomes socially acceptable to use unsafe all over the place in the community, it might be hard to win the user trust back.

> Rust is going to take credibility hits if more people do this

I disagree on that. Rust also took a credibility hit for people advertising exactly the opposite: To rewrite things from scratch. While that approach certainly helps with getting idiomatic code right from the start, years of feature development will get lost, and the chances for introducing non memory related bugs are still there.

The ability to transfer a project to Rust in 1 step, and then to gradually improve it seems like a big plus to me. Of course it would not be great if projects are just auto-translated and then kept that way. But I don't think that is the intention of most authors who do that.

Re: Show HN: RustyBox – a Busybox fork written in Rust

#49

Post by ncmncm »

shpongled wrote: post #16
comex wrote: post #2

Seems to consist mostly of a copy of Busybox’s C code auto-translated to Rust using c2rust – resulting in ubiquitous use of raw pointers and `unsafe` for mundane operations. That’s technically “written entirely in Rust”, but not in the way you’d expect… On the other hand, it could serve as a good starting point for a gradual rewrite into idiomatic Rust.

Almost seems like it would be easier to just write it from scratch in idiomatic Rust than to try and refactor a code base of this size that makes such extensive use of unsafe blocks and pointers.

"New bugs for old! New bugs for old!"

(With apologies to to Aladdin.)

Re: Show HN: RustyBox – a Busybox fork written in Rust

#50

Post by skainswoo »

wrs wrote: post #46

Given that busybox is structured as one function per command int COMMAND_main(int argc, char **argv) and that it's compilable as a library already, I wonder if it would make more sense to use bindgen or the like to start with the actual busybox C code, but with a (trivial) Rust main function. You'd have the current busybox source compiling an ever-smaller library, and a Rust lib next to it. Then move things over to t…

I've actually thought about doing this. There are some "applets" that are just so complex or have so many gotos that I really don't want to touch the rust code any more than I want to touch the C code, so it may make sense to take this route with them in the future.
Post reply on HN