3 ms·

Seems pretty impressive they rewrote the coreutils in a new language, with so little Unix experience, and managed to do such a good job with very little bugs or

Seems pretty impressive they rewrote the coreutils in a new language, with so little Unix experience, and managed to do such a good job with very little bugs or vulns. I would have expected an order of magnitude more at least. Shows how good Rust is, that even inexperienced Unix devs can write stuff like this and make almost no mistakes.

nine_k 6mo ago
Yes, it's the lack of Unix experience that's terrifying. So many of mistakes listed are rookie mistakes, like not propagating the most severe errors, or the `kill -1` thing. Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils?
- aw1621107 6mo ago
  > Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? From what I understand, "assigned" probably isn't the best way to put it. uutils started off back in 2013 as a way to learn Rust [0] way before the present kerfuffle. [0]: https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f420d9a8007c574d922018d1 https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f42...
  - nineteen999 6mo ago
    Yeah perhaps learning UNIX API's and Rust at the same time doesn't lead to a drop in replacement ready to be shipped in major distributions. Who whould have thunk it.
    - aw1621107 6mo ago
      Strictly speaking it doesn't preclude eventually producing a production-ready drop-in replacement either, though evidently that needs a fresh set of eyes.
  - bpbp-mango 6mo ago
    exactly this. I wrote one of them back then as a learning experience. some of the code I wrote is still intact, incredibly.
- JuniperMesos 6mo ago
  Why is it even possible to represent a negative PID, let alone treat the integer -1 as a PID meaning "all effective processes"? This seems like a mistake (if not a rookie mistake) in the Linux kernel API itself.
  - antonvs 6mo ago
    Pretty much all the rough edges being discussed here are design mistakes in Linux or Unix, and/or a consequence of using an unsafe language with limited abstractions and a weak type system. But because of ubiquity, this is everyone’s problem now.
    - adrian_b 6mo ago
      You are right, but those who set for themselves the goal to substitute a Linux/UNIX package must implement programs that handle correctly all the quirks of the existing Linux/POSIX specifications. If they do not like the design mistakes, great, they should set for themselves the goal to write a new operating system together with all base applications, where all these mistakes are corrected. As long as they have not chosen the second goal, but the first, they are constrained by the existing interfaces and they must use them correctly, no matter how inconvenient that may be. Anyone who learns English may be frustrated by many design mistakes of English, but they must still use English as it is spoken by the natives, otherwise they will not be understood.
  - nine_k 6mo ago
    -1 is a special case, a way to represent a PID with all bits set in a platform-independent way. It's not very clean, and it comes from ancient times when writing some extra code and storing an extra few bytes was way more expensive.
    - bonzini 6mo ago
      No, -1 is simply the process group with pgid 1: https://stackoverflow.com/questions/392022/whats-the-best-way-to-send-a-signal-to-all-members-of-a-process-group https://stackoverflow.com/questions/392022/whats-the-best-wa... The problem is that -DIGIT doubles as both "signal number" and process group. The right way to invoke kill for a process group however would be "kill [OPTS]... -- -PGID".
twhitmore 6mo ago
[flagged]
gblargg 6mo ago
Rewriting perfectly good code was a colossal mistake.
- Cthulhu_ 6mo ago
  Not necessarily, but was the reasoning sound and have the tradeoffs been made? The website (https://uutils.github.io/ https://uutils.github.io/) shows some reasonable "why"s (although I disagree with making "Rust is more appealing" a compelling reason, but that's just me (disclaimer: I don't like C and don't know Rust so take this comment as you will)), but I think what's missing is how they will ensure both compatibility and security / edge case handling, which requires deep knowledge and experience in the original code and "tribal knowledge" of deep *nix internals.
- dwattttt 6mo ago
  I do wonder whether people got down the article enough to see the list of bugs patched in GNU coreutils. That "perfectly good code" that it sounds like no one should question included "split --line-bytes has a user controlled heap buffer overflow".
  - gblargg 6mo ago
    Yes, perfectly good code can have bugs. This is ridiculous thinking to scrap a codebase because it's not bug-free, to replace it with one riddled with differences in behavior that break everything that uses it.
- kibwen 6mo ago
  The irony here being that GNU's coreutils themselves originated as rewrites, from back when BSD's copyright status was still legally unclear.
  - gblargg 6mo ago
    Understandable as GNU was founded on software freedom. I guess one could argue that the Rust rewrite is to establish some kind of higher standard for correctness.

nine_k 6mo ago

Yes, it's the lack of Unix experience that's terrifying. So many of mistakes listed are rookie mistakes, like not propagating the most severe errors, or the `kill -1` thing. Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils?

aw1621107 6mo ago
> Why were people who apparently did not have much experience using coreutils assigned to rewrite coreutils? From what I understand, "assigned" probably isn't the best way to put it. uutils started off back in 2013 as a way to learn Rust [0] way before the present kerfuffle. [0]: https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f420d9a8007c574d922018d1 https://github.com/uutils/coreutils/tree/9653ed81a2fbf393f42...
- nineteen999 6mo ago
  Yeah perhaps learning UNIX API's and Rust at the same time doesn't lead to a drop in replacement ready to be shipped in major distributions. Who whould have thunk it.
  - aw1621107 6mo ago
    Strictly speaking it doesn't preclude eventually producing a production-ready drop-in replacement either, though evidently that needs a fresh set of eyes.
- bpbp-mango 6mo ago
  exactly this. I wrote one of them back then as a learning experience. some of the code I wrote is still intact, incredibly.
JuniperMesos 6mo ago
Why is it even possible to represent a negative PID, let alone treat the integer -1 as a PID meaning "all effective processes"? This seems like a mistake (if not a rookie mistake) in the Linux kernel API itself.
- antonvs 6mo ago
  Pretty much all the rough edges being discussed here are design mistakes in Linux or Unix, and/or a consequence of using an unsafe language with limited abstractions and a weak type system. But because of ubiquity, this is everyone’s problem now.
  - adrian_b 6mo ago
    You are right, but those who set for themselves the goal to substitute a Linux/UNIX package must implement programs that handle correctly all the quirks of the existing Linux/POSIX specifications. If they do not like the design mistakes, great, they should set for themselves the goal to write a new operating system together with all base applications, where all these mistakes are corrected. As long as they have not chosen the second goal, but the first, they are constrained by the existing interfaces and they must use them correctly, no matter how inconvenient that may be. Anyone who learns English may be frustrated by many design mistakes of English, but they must still use English as it is spoken by the natives, otherwise they will not be understood.
- nine_k 6mo ago
  -1 is a special case, a way to represent a PID with all bits set in a platform-independent way. It's not very clean, and it comes from ancient times when writing some extra code and storing an extra few bytes was way more expensive.
  - bonzini 6mo ago
    No, -1 is simply the process group with pgid 1: https://stackoverflow.com/questions/392022/whats-the-best-way-to-send-a-signal-to-all-members-of-a-process-group https://stackoverflow.com/questions/392022/whats-the-best-wa... The problem is that -DIGIT doubles as both "signal number" and process group. The right way to invoke kill for a process group however would be "kill [OPTS]... -- -PGID".

twhitmore 6mo ago

[flagged]

gblargg 6mo ago

Rewriting perfectly good code was a colossal mistake.

Cthulhu_ 6mo ago
Not necessarily, but was the reasoning sound and have the tradeoffs been made? The website (https://uutils.github.io/ https://uutils.github.io/) shows some reasonable "why"s (although I disagree with making "Rust is more appealing" a compelling reason, but that's just me (disclaimer: I don't like C and don't know Rust so take this comment as you will)), but I think what's missing is how they will ensure both compatibility and security / edge case handling, which requires deep knowledge and experience in the original code and "tribal knowledge" of deep *nix internals.
dwattttt 6mo ago
I do wonder whether people got down the article enough to see the list of bugs patched in GNU coreutils. That "perfectly good code" that it sounds like no one should question included "split --line-bytes has a user controlled heap buffer overflow".
- gblargg 6mo ago
  Yes, perfectly good code can have bugs. This is ridiculous thinking to scrap a codebase because it's not bug-free, to replace it with one riddled with differences in behavior that break everything that uses it.
kibwen 6mo ago
The irony here being that GNU's coreutils themselves originated as rewrites, from back when BSD's copyright status was still legally unclear.
- gblargg 6mo ago
  Understandable as GNU was founded on software freedom. I guess one could argue that the Rust rewrite is to establish some kind of higher standard for correctness.