Linux

coreutils ships with Ubunutu 26.04, albeit with a number of caveats.

Package: rust-coreutils 
Version: 0.8.0-0ubuntu3 
Priority: required 
Section: utils 
Origin: Ubuntu 
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com> 
Original-Maintainer: Debian Rust Maintainers <pkg-rust-maintainers@alioth-lists.debian.net> 
Bugs: https://bugs.launchpad.net/ubuntu/+filebug 
Installed-Size: 16.0 MB 
Depends: libc6 (>= 2.43), libgcc-s1 (>= 4.2), libselinux1 (>= 3.1~) 
Conflicts: coreutils-from-uutils (<< 0.0.0~ubuntu22~) 
Homepage: https://github.com/uutils/coreutils 
Task: minimal 
Download-Size: 4,235 kB 
APT-Manual-Installed: no 
APT-Sources: http://archive.ubuntu.com/ubuntu resolute/main amd64 Packages 
Description: Universal coreutils utils, written in Rust 
 This packages replaces the GNU coreutils package written in C. 
 It should be a drop-in replacement but: 
  Some options have NOT been implemented, 
  Might have important bugs, 
  Might be slower, 
  Output of the binaries might be slightly different. 

 

If they're translating GPL code to Rust, doesn't that constitute a derived work and require the resulting code to be GPL licenced too?

Using Rust in no way requires the usage of pushover licenses. While it's true that many devs are using pushover licenses, there are plenty of GPL Rust projects. You are just focusing on the sensationalized ones that get mentioned in news cycles.

• AGPL Rust projects on GitHub
• GPL Rust projects on GitHub
• Unfortunately, Codeberg doesn't support filtering by license, but there are Rust projects on Codeberg, some of which will use copyleft licenses here.
• GNOME's GitLab is also rife with GPL-licensed Rust projects.

Wow! What an observant smart thought.

Well, except for the fact that code conversion doesn't give you the permission to change licenses or remove copyright. And the small matter of fact that both projects mentioned are Canonical projects, where whatever code that is not directly copyrighted by Canonical, is contributed by someone who signed an agreement with this stipulation:

(b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable licence under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with Section 2.3.

"Us" being Canonical of course. So they could actually "re-license" the projects right now, without changing a single line of code.

It's always astonishing how condiment in their ignorance people are when it comes to these matters.

You geniuses are getting too predictable with your ignorance.

I literally wrote what's quoted above yesterday replying to someone else.

Which is exactly why you're free to license your code under GPL. If corpos can use, then so can you.

Wait waddup with clang? Any sources I could read up on?

You don't just convert and sleep though. You convert and prune. You slowly rework parts post-conversion to use more sensible approaches/libraries. It's not a one-and-done operation, it's an ongoing thing that they judge the cost of investing in now is less than the long term maintaining C Ubuntu.

Look at the folks in college right now, no one can or will.

But functioning C code is as good as functioning Rust code right?

Practically yes, but also no. The C pointer aliasing rules limit the optimizations the compiler can apply, since any int * might point to any int in scope. It’s even worse than that in the Linux kernel: since it has to be compiled with -fno-strict-aliasing, the compiler has to assume that any pointer can alias any variable in scope.

In contrast, Rust simply disallows aliases to mutable variables and the compiler prevents them in safe code (you can write them in unsafe code but it’s instantly undefined behavior, which is why unsafe Rust is harder to write than C). Every variable that can change has one and only one name. This can sometimes allow the Rust compiler to optimize in ways that wouldn’t be possible in C.

But in practice the impact of this is pretty close to nil as long as you write smallish functions.

From what I get, Rust proposes to make low-level coding easier by forcing programmers into a certain workflow.

Yes and no. It forces programmers to a certain workflow like using a borrow checker to manage memory, but it actually makes programmer's lives easier, because it prevents bugs from runtime. The compiler will throw a fit, over your buggy code if you try to compile, unlike C.

The funny part is that rust is actually a high level language that can do low level stuff.

But functioning C code is as good as functioning Rust code right?

Yes. I prefer C because it is easier to learn than rust, and feel like rust is more comparable to C++. I also feel like llm plus rust is a good combo, these days.

It isn’t always about “new”. For example, some GNU binaries are decades old and were changed only to fix bugs.

C has major disadvantages compared to Rust, which is why even Linus Torvalds said a couple of years ago, to not write any new C code anymore for the Kernel and that old code will be transpiled steadily.

It is not about a cult. It is not about being fancy. It is quite the opposite. Choosing Rust over C is very rational.

Also, obligatory fuck Canonical. Automatic transpiling is such a stupid thing. Have fun maintaining the new code that was written by a machine, while not having any Rust experts in your team.

Because that would require competence.

Because of the users that don’t want to change how they work. But still would like not to be owned by the onslaught of LLM wielding hackers