Uutils: A really neat project that deserves more love


#1

I really love this project. It’s been chugging along very slowly for years, and every time I come back to it I’m pleased that it is still receiving a trickle of contributions. But also saddened that it’s moving so slowly.

One of the things that is so great about this project is that what needs to be done is so clear cut - just make sure the programs exist and they pass the busybox test suite. It’s filled with repeatable tasks that are amenable to relative newcomers to Rust. I bet if somebody stepped up to drive this project actively, make the contribution opportunities clear, and escalated them to the twir call for participation regularly, that this project would shape up real fast.

For inspiration, here are some reasons to want uutils to succeed:

  • It is portable and runs on windows
  • It can be compiled as a single portable executable like busybox
  • It is permissively-licensed, where busybox is GPL licensed. busybox is super popular with companies that don’t like to deal with the GPL, which means there is market opportunity to compete with busybox
  • Because it is relatively portable, it could be a good candidate for future operating systems’ coreutils, like Redox and Fuchsia
  • It could be a critical component of a pure-Rust docker image

I don’t actually know the relationship between Redox’s coreutils and uutils - I suspect there is none. Wonder what the opportunities for collaboration are.

I don’t see Arcterus registered here, but cc @Arcterus. Love your stuff! :sparkling_heart:


#2

I really like the idea, but TBH, the fact that it’s not GPL is what stopped me from trying to contribute.

Nonetheless, my best wishes for the project. :slight_smile:


#3

Just out of curiosity, why is it a problem that it’s not GPL? The way I see it, companies would be more likely to help contribute to it because it’s not “viral” like GPL’d software usually is.


#4

First of all, let me state that there is no silver bullet in licensing, and I appreciate BSD, MIT and other licenses in different contexts.

The problem with this case is in possible companies behaviours.

If the software is BSD/MIT, a company could contribute to it and make the contribution open source, but the same happens with GPL. The “viral” nature of the GPL does not stop companies from contributing, in this case, as nothing changes. So being BSD/MIT has no advantage in this case over the GPL.

If a company wants to change the software and keep the changes closed source, the BSD/MIT allows them to do it, while the GPL does not. For me as a contributor this is not acceptable, as my software is used for free and I get nothing back (not just money, but bug fixes, performance improvements, new features, etc.). So I am basically working to make some other company rich without getting anything back.

This could work for very big and widely used projects, as the community will probably come up with something better than the company’s changes, and the company will eventually be forced to rebase onto the new open source project and throw away months of development.
But for small or not yet widely used projects, it could mean death by lack of contributions.

Then there is a special case of a company wanting to contribute but fearing to “give away” patents rights. I’m not an expert on this, but the BSD/MIT would allow them to not distribute the changes (as before) while with the GPL I think it depends on which version. if I remember correctly, GPL3 forces the company to allow the use of patents, while the GPL2 does not cover it, but I don’t know how it would work in a court.

For libraries, I generally think the LGPL is better, as it allows to dynamically link the library to closed source projects without being “viral”, but in Rust we have the “problem” that cargo packages are not dynamically linked. They are statically compiled in. I am waiting an official statement from the GNU foundation on this, but in the meantime, I consider LGPL cargo packages as “dynamically linked”, so not viral.


#5

I generally second what you say, as I also think that copyleft licensing (GPL family or MPLv2) is more appropriate for spare-time projects which one doesn’t get paid/employed for. That being said, I should point out that on the specific issue of software patents, there is one permissive license that got this right IMO, and that is Apache 2.0.

Its terms basically spell out as an agreement between the authors and the users of the Apache-licensed software not to sue each other using patents related to the software:

3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.

So all things being equal, if software patents (which thankfully are not a concern in my country) were the only things preventing someone from contributing to BSD/MIT-licensed software, the easiest fix would probably be to suggest a license change to Apache, not GPL.


#6

busybox is near 1M even with stuff like bzip2/gzip.
Is it possible with current rustc or future rustc in near (1 year) future?

I mean size after compile with something like crt-static


#7

I think there’s room for some collaboration between our Redox core utilities and these core utilities. The main purpose of Redox core utilities is to ensure compatibility with Redox’s syscalls and schemes.


#8

It sounds like Redox’s core utilities would provide the low level interface to the OS and then uutils could build on top of that to add functionality.

Do you have some sort of shim for std to allow people to use APIs from the standard library (like std::fs::File) transparently? It’d be a win:win situation if you can get uutils to work easily on Redox because then it saves you a lot of work manually porting GNU’s coreutils, and uutils gets a bunch of people testing and using the awesome stuff they’ve made.


#9

Redox is already integrated into Rust’s official standard library, so there’s no need for any sort of shim. There’s just a number of fundamental incompatibilities between Redox’s kernel and UNIX-like kernels like BSD/Linux.

Take df and free, for example. Redox provides access to this information through Redox’s schemes feature; whereas Linux/BSD does this completely different, because they don’t use schemes.

As a more in-depth example, take the uname command. On Redox, this information can be obtained from the sys scheme, which is accessible by the following:

let uname_info = File::open("sys:uname").unwrap();

All the information that uname needs is contained within that file.


#10

Oh wow. I thought I had registered here earlier but I guess not (lol). Glad you like my stuff! :smile:

I’m hoping that I’ll be able to spend more of my free time working on the project and we can finally get implementations of all the utilities in the repo soon. That said I’m also working on a JavaScript engine for my custom game engine and am planning to start working on my corbenik fork again, so I’m really having to manage my time right now. :sweat_smile:

In the mean time, we really need people who are willing to submit tests and try to find bugs, so if anyone sees this and is looking for something to do, please come by and help us. There are also some utilities that have been claimed but have stalled implementations (or have not been attempted at all), so if you spot one of those feel free to try working on it.

Shoutout to @mpkh, @ebfe, @nathanross, @jbcrail, @knight42, and @Seldaek (founder of the project).

I just ran a release build on my laptop, and the size of the single executable was 11.3 MiB. After stripping, the executable went down to 6.8 MiB. So it’s clearly much larger than busybox right now. When all the utilities have implementations, we’ll probably spend more time worrying about their size (but in all honestly I don’t think we’ll ever get to be quite as small as busybox).

We would definitely be open to collaboration. I know @ids1024 has been submitting some fixes lately to get some of the utilities working on Redox.


#11

Uutils isn’t on crates.io yet, is it? I was thinking I might install uutils on my laptop and just rely on ~/.cargo/bin/ being before everything else on my $PATH to shadow the existing coreutils on my machine.

Are there any plans in the works to create/submit releases for common package managers like apt, yum or adding uutils to the Arch Linux AUR?


#12

@jackpot51 (Redox’s BDFL) agrees that we work more with uutils, and I intend to make Redox pull in a few utilities from uutils by default soon.