
Show HN: RustyBox – a Busybox fork written in Rust - skainswoo
https://github.com/samuela/rustybox
======
comex
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.

~~~
dman
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.

~~~
estebank
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 blame the language doing the calling for the bug.

Having said that, these translations are still useful as a starting point, not
a destination. Think of a case where the external C API is retained, but all
the innards are gradually converted to a more idiomatic codebase.

~~~
namewasmypw
`unsafe` is already very prevalent in the ecosystem and this is a big point of
contention.

[https://github.com/actix/actix-
web/issues/289](https://github.com/actix/actix-web/issues/289)

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

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

~~~
jturpin
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."

~~~
cogman10
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.

------
viraptor
For coreutils actually written from scratch, see a more interesting project:
[https://github.com/uutils/coreutils](https://github.com/uutils/coreutils)

~~~
skainswoo
Yeah, I'm a fan of the uutils project but I haven't tested it out myself yet!
It would be neat to start incorporating some of those commands into rustybox
in place of the old implementations.

------
ggm
Is C2R (and the precursor I know of F2C) strictly speaking "without a line of
C" in it?

Yes, literally. But figuratively, No, because you used the C as a higher order
definition language and did translation not re-implementation.

So this might (in some cases) be bug for bug compatible (a good thing?) if the
bug is a logic bug, not a C boundary error or a type cast effect or something
not strictly defined. It isn't an "independently implemented suite" if you
wanted to e.g. use it for conformance testing to a spec.

------
sstangl
If this started with BusyBox translated from C to Rust, is this code also
under the GPL, as is BusyBox?

I don't see any LICENSE or COPYING files in the repo.

~~~
SwellJoe
Seems like it would have to be the same license as BusyBox, since it is a
"compiled" artifact of BusyBox (just compiled to another high level language).

------
pornel
"Written in Rust" is overselling it.

It's somewhat impressive that c2rust is can translate so much code, but
without following it up with refactoring into more idiomatic Rust (which is a
lot of work), this is merely replacing gcc with rustc.

------
gorgoiler
Wow, I did not know Busybox shipped with a webserver. Here’s the Busybox code:

[https://git.busybox.net/busybox/tree/networking/httpd.c](https://git.busybox.net/busybox/tree/networking/httpd.c)

Shame the rustybox version strips all the comments:

[https://github.com/samuela/rustybox/blob/master/networking/h...](https://github.com/samuela/rustybox/blob/master/networking/httpd.rs)

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

~~~
skainswoo
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.

------
harikb
If a GPL code is auto-translated to another language, shouldn't the fork have
the same GPL license? Or does the new author get to put a new license?

~~~
rwmj
It should be GPL.

------
alexhutcheson
If you're looking for an alternative to BusyBox, a former BusyBox maintainer
has written ToyBox[1], which has a similar collection of command-line
utilities, but with a BSD license. It's still in C, though.

[1] [https://github.com/landley/toybox](https://github.com/landley/toybox)

------
_bxg1
Making this code more idiomatic seems like a really cool opportunity to get
some Rust experience. I imagine there's a ton of low-hanging fruit in here,
especially given how minimal and modular the different utilities tend to be.
And at the same time, you're touring idioms and optimizations copied from some
of the most refined C code out there.

------
KuiN
I've always been interested in busybox and other similar tool sets - I even
wrote a very simple set of coreutils clones at one point; but I've never
really understood the use case. I like Rust & I like using modern tools when
there's a benefit. But whatever coreutils Apple ship or come with a reasonable
Linux distro seem to work 99% of the time for my work. Simpler & smaller I get
for restricted embedded, I'm sure I've used them doing embedded work with
small ARM boards & a custom tiny Linux - but the payoffs have never seemed too
enticing.

~~~
saagarjha
Busybox is quite literally “POSIX in a box”. It’s useful to have on systems
where you’d like a shell and some utilities but don’t want to bother with
having anything fancy.

------
garmaine
Missing license.

~~~
berkut
Which would surely need to be GPL given it seems to be an auto-converted
version of BusyBox, so I would have thought that makes it a derivative?

------
houseboat
This is a very welcome addition to our existing system's core toolchain :)

I just wish that all Rust implementations would include a "Git" or "Docker
containers" section as a stepping stone in the right direction for other
projects.

------
christiansakai
What is this used for? I am interested in contributing

~~~
banachtarski
Out of curiosity, how does one become interested in contributing to a thing
when one doesn't even know what the thing is?

~~~
ggm
The name has pointers to english-as-a-second-language. It could be they were
seeking "what are _you_ using this for" or "what are you _targetting_ with
this work" which goes to the higher purpose. General use of busybox is implied
by what you know of /rescue and/or the small unix for containers work, but
there are also tiny unixes for small computer systems, Pi based embedded
systems, IoT, you name it (busybox is probably overkill for IoT devices but I
could believe its part of the diagnostic)

------
Kenji
Oh no, it seems to just be c2rust. I wish they actually meant "written" as in
"written" and not as in "compiled".

------
daenz
Unless Rust suffers some catastrophic leadership or design choices, I'm
convinced it will be the next language to "eat the world."

~~~
blotter_paper
Rust + Wasm

~~~
miguelmota
Agreed. Rust has incredibly great support for WASM.

