Auf YouTube findest du die angesagtesten Videos und Tracks. Außerdem kannst du eigene Inhalte hochladen und mit Freunden oder gleich der ganzen Welt teilen.
I love rust and projects rewritten in Rust, but I’ve felt pretty mixed about this particular project. The strong copyleft on GNU coreutils is part of what keeps many Linux distros truly free. There’s stuff like BusyBox or BSD coreutils if you need something you can make non-free, but GNU coreutils are just so nice. I wish this reimplementation in rust had been licensed with GPL or a similar copyleft license. At least there’s no CLA with copyright transfer.
Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.
But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you’re program doesn’t have to be GPL. It’s partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn’t be able to extend proprietary code off of it — not that I care about that, but the library makers often do.
Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.
EDIT2: Upon further research it seems that Rust’s dynamic linking implementation lacks a “stable ABI” as compared to other languages such as Swift or C. So I guess we are back to “it is a language issue”. Well thankfully this seems easier to fix than “Yeah Rust doesn’t support dynamic linking at all.”
Edit3: Nvm, I’m very, very wrong. The GPL does require programs using GPL libraries, even dynamically linked, be GPL. It’s the LGPL that doesn’t.
As long as two binaries are compiled with the same version of the Rust compiler, they are ABI compatible.
Even if the compiler version differs, I’ve found that changes to the ABI are fairly uncommon.
Furthermore, anything exposed through the C ABI is stable, so the problem can be circumvented if needed.
It’s not the most ergonomic solution, admittedly, but with some compromises dynamic linking is perfectly feasible.
The lack of ABI stability in Rust means they don’t have to commit to language changes that may prove to be unpopular or poorly designed later.
Swift went through the same growing pains and, IMO, has suffered for it a bit with even quite basic code often needing lots of availability checks. This may seem counter intuitive but Swift is in the unique(-ish) position of having to serve both a huge corporation demanding significant evolution on a regular basis and a cross platform community that don’t want to write an encyclopedia every time a major version of the language is rolled out.
Rust doesn’t have this issue and I think it’s right for them to allow themselves the freedom to correct language design errors until it gains more traction as a systems language - and it’s quite exciting that we’re seeing that traction happen now in realtime!
No that’s the issue: it’s too permissive. It allows corporations or individuals to redistribute and modify the code as closed source, which isn’t desirable for this kind of project.
I love rust and projects rewritten in Rust, but I’ve felt pretty mixed about this particular project. The strong copyleft on GNU coreutils is part of what keeps many Linux distros truly free. There’s stuff like BusyBox or BSD coreutils if you need something you can make non-free, but GNU coreutils are just so nice. I wish this reimplementation in rust had been licensed with GPL or a similar copyleft license. At least there’s no CLA with copyright transfer.
Yeah the licensing is a bit worrying, but it’s not a language issue.
It actually is a language issue.
Although rust can dynamically link with C/C++ libraries, it cannot dynamically link with other Rust libraries. Instead, they are statically compiled into the binary itself.
But the GPL interacts differently with static linking than with dynamic. If you make a static binary with a GPL library or GPL code, your program must be GPL. If you dynamically link a GPL library, you’re program doesn’t have to be GPL. It’s partially because of this, that the vast majority of Rust programs and libraries are permissively licensed — to make a GPL licensed rust library would mean it would see much less use than a GPL licensed C library, because corporations wouldn’t be able to extend proprietary code off of it — not that I care about that, but the library makers often do.
https://en.wikipedia.org/wiki/GNU_General_Public_License#Libraries — it’s complicated.
EDIT: Nvm I’m wrong. Rust does allow dynamic linking
Hmmmm. But it seems that people really like to compile static rust binaries, however, due to their portability across Linux distros.
EDIT2: Upon further research it seems that Rust’s dynamic linking implementation lacks a “stable ABI” as compared to other languages such as Swift or C. So I guess we are back to “it is a language issue”. Well thankfully this seems easier to fix than “Yeah Rust doesn’t support dynamic linking at all.”
Edit3: Nvm, I’m very, very wrong. The GPL does require programs using GPL libraries, even dynamically linked, be GPL. It’s the LGPL that doesn’t.
As long as two binaries are compiled with the same version of the Rust compiler, they are ABI compatible. Even if the compiler version differs, I’ve found that changes to the ABI are fairly uncommon. Furthermore, anything exposed through the C ABI is stable, so the problem can be circumvented if needed. It’s not the most ergonomic solution, admittedly, but with some compromises dynamic linking is perfectly feasible.
The lack of ABI stability in Rust means they don’t have to commit to language changes that may prove to be unpopular or poorly designed later.
Swift went through the same growing pains and, IMO, has suffered for it a bit with even quite basic code often needing lots of availability checks. This may seem counter intuitive but Swift is in the unique(-ish) position of having to serve both a huge corporation demanding significant evolution on a regular basis and a cross platform community that don’t want to write an encyclopedia every time a major version of the language is rolled out.
Rust doesn’t have this issue and I think it’s right for them to allow themselves the freedom to correct language design errors until it gains more traction as a systems language - and it’s quite exciting that we’re seeing that traction happen now in realtime!
If I found the correct repo it seems like it’s MIT licenced which is very permissive, as well.
https://github.com/uutils/coreutils?tab=MIT-1-ov-file
No that’s the issue: it’s too permissive. It allows corporations or individuals to redistribute and modify the code as closed source, which isn’t desirable for this kind of project.
I interpreted your message wrong, now I get it, thanks!