3 ms·

yeah, this is a bug. And yes, it should be fixed. But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?

secondcoming 17d ago
That way of thinking just means it'll never be fixed
- gpm 17d ago
  Nah, people should (and do) fix small issues as well as big issues. Lying about the scale of issues and calling them "big" when they aren't just leads to no ability to prioritize or evaluate. Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
  - sylvestre 13d ago
    Because Collin reported it in Ubuntu too :)
- abirch 17d ago
  "The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds
  - dfox 17d ago
    The problem there is that this is exactly the class of bug that does not exist in GNU coreutils because of philosophy of that project. Non-existence of such bugs proves that the impementation is not copied from AT&T code.
  - LtWorf 16d ago
    It's complicated to do it yourself when upstream won't accept your code.
- 7bit 17d ago
  What approach would you suggest for priorisation of tickets?
  - secondcoming 17d ago
    Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.
    - gpm 17d ago
      This isn't a port - it's a re-implementation without any use of the original source. That's also not all that's happening. It's also making improvements like better internalization support, better error messages, and a small handful of other extensions.
      - collinfunk 17d ago
        I have had to tell them repeatedly to stop copying tests verbatim, including the original comments from GNU coreutils. So I doubt this is true, which is frustrating.
        leni536 16d ago
        What's wrong with them using the coreutils tests?
        RichardLake 16d ago
        If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.
        leni536 16d ago
        > and you can't include GPL code in a MIT licensed project without making it GPL. Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.
tosti 17d ago
What programmer or programming language can't iterate a loop more than 32000 times?!
- IshKebab 17d ago
  It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that far away: https://lwn.net/Articles/1035727/ https://lwn.net/Articles/1035727/
  - tosti 17d ago
    OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
    - gpm 17d ago
      For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]). [1] https://github.com/rust-lang/rust/issues/112788 https://github.com/rust-lang/rust/issues/112788 [2] https://github.com/rust-lang/rust/issues/153827 https://github.com/rust-lang/rust/issues/153827 By-default guaranteed tail calls really isn't rust's style, because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. If you want to guarantee that a call can't allocate a new stack frame you should have to say it.
      - lioeters 17d ago
        Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same. But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
geokon 16d ago
It's less about the specific issue and more indicative of bad/insufficient test coverage
throw0101a 16d ago
> But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system? When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?
- liamgm 16d ago
  AI agent needs , rust memory safety , wasm , parralel task
monegator 16d ago
from a ground-up rewrite, in a memory safe language i expect at the very least - A meaningful error - not a segfault

secondcoming 17d ago

That way of thinking just means it'll never be fixed

gpm 17d ago
Nah, people should (and do) fix small issues as well as big issues. Lying about the scale of issues and calling them "big" when they aren't just leads to no ability to prioritize or evaluate. Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)
- sylvestre 13d ago
  Because Collin reported it in Ubuntu too :)
abirch 17d ago
"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds
- dfox 17d ago
  The problem there is that this is exactly the class of bug that does not exist in GNU coreutils because of philosophy of that project. Non-existence of such bugs proves that the impementation is not copied from AT&T code.
- LtWorf 16d ago
  It's complicated to do it yourself when upstream won't accept your code.
7bit 17d ago
What approach would you suggest for priorisation of tickets?
- secondcoming 17d ago
  Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.
  - gpm 17d ago
    This isn't a port - it's a re-implementation without any use of the original source. That's also not all that's happening. It's also making improvements like better internalization support, better error messages, and a small handful of other extensions.
    - collinfunk 17d ago
      I have had to tell them repeatedly to stop copying tests verbatim, including the original comments from GNU coreutils. So I doubt this is true, which is frustrating.
      - leni536 16d ago
        What's wrong with them using the coreutils tests?
        RichardLake 16d ago
        If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.
        leni536 16d ago
        > and you can't include GPL code in a MIT licensed project without making it GPL. Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.

tosti 17d ago

What programmer or programming language can't iterate a loop more than 32000 times?!

IshKebab 17d ago
It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that far away: https://lwn.net/Articles/1035727/ https://lwn.net/Articles/1035727/
- tosti 17d ago
  OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
  - gpm 17d ago
    For what it's worth there's reasonably active [1] work on implementing opt-in guaranteed tail calls - but it's not particularly fast going. LLVM (the backend rust uses) needs better support for musttail (e.g. some architectures just don't support it [2]). [1] https://github.com/rust-lang/rust/issues/112788 https://github.com/rust-lang/rust/issues/112788 [2] https://github.com/rust-lang/rust/issues/153827 https://github.com/rust-lang/rust/issues/153827 By-default guaranteed tail calls really isn't rust's style, because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. If you want to guarantee that a call can't allocate a new stack frame you should have to say it.
    - lioeters 17d ago
      Not so familiar with this area, but isn't the existing behavior of implicitly creating new stacks more of a problem than implicit tail-call elimination? Seems the latter is a kind of compiler-level optimization, of which there are already many (I think) that change the semantics internally but guarantee the outward behavior stays the same. But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.

geokon 16d ago

It's less about the specific issue and more indicative of bad/insufficient test coverage

throw0101a 16d ago

> But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system? When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?

liamgm 16d ago
AI agent needs , rust memory safety , wasm , parralel task

monegator 16d ago

from a ground-up rewrite, in a memory safe language i expect at the very least - A meaningful error - not a segfault