91–100 of 338 posts
Has the code quality in that repo gotten to a good point then? I haven't followed it much, but last I looked[1] (which was a few years ago) almost every tool I looked at in detail had pretty bad performance or correctness issues. [1] https://jackson.dev/post/rust-coreutils-dd/
The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.
Earlier quoted context omitted.
It doesn’t even matter. The sheer disparity in vulnerabilities over twenty years versus one year is impossible to hand-wave away. We are talking about fourfold more CVEs over a twentyfold reduction in time.
It really does matter. I don't know enough about this specific case, but multiple order of magnitude differences in CVE numbers are frequently explained by different policies towards finding and assigning CVEs in many many cases. Absent more information the default should be to hand wave it away as probably such a difference. CVE counts are not a even slightly reliable metric.
Other ones I find concerning are that you could also bypass '-- no-preserve-root' with a symbolic link to root [2]. Or by using paths equivalent to "/", e.g., "/../" [3]. Historically, GNU coreutils has been pretty good with symbolic links and avoiding TOCTOU races. The only notable one I can remember is a chmod(1) bug [4].
I agree with your general point that the number of CVEs is a useless metric, though.
[1] https://nvd.nist.gov/vuln/detail/cve-2026-35352 [2] https://nvd.nist.gov/vuln/detail/cve-2026-35349 [3] https://nvd.nist.gov/vuln/detail/cve-2026-35338 [4] https://github.com/coreutils/coreutils/commit/425b8a2f534fe0...
[flagged]
Cool aspirations but I don't think it has significant enterprise deployments compared to RHEL or SLES.
And they are slightly behind RHEL: https://commandlinux.com/statistics/linux-server-market-shar...
Earlier quoted context omitted.
We've balkanized Linux but you're free to use the original (which we are deliberately incompatible with, as is rival #2, rival #3, rival #4, etc. and we're all mutually incompatible with each other)
Amazon and other clouds already patch the hell out of Linux, but they don't distribute physical devices with that Linux on it to anyone, so they don't have to deliver source code either. I am not totally sure I see the actual concern here, that a company is going to sell devices with a really great `find` implementation but not contribute it upstream?
What it meant was a headache for writing platform-agnostic software. It was not a productive way to create software.
Replacing GPL software with MIT software just encourages this behaviour to come back. We already see it with how macOS userland took FreeBSD and sprinkled incompatibilities everywhere.
Earlier quoted context omitted.
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
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 [2] https://github.com/rust-lang/rust/issues/153827 By-default guaranteed tail calls really isn't rust's style,…
No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
Earlier quoted context omitted.
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 [2] 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. No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
Was there something wrong with how they are currently written or do they just want the badge that says they converted to Rust?
We might see a fracture open slowly. For me, even AGPL is not enough
Earlier quoted context omitted.
> because it means subtle changes (introducing a destructor, re-ordering code, etc) can change semantics without you realizing it. No, it won't change semantics - if you say @musttail or similar, it will simply fail to compile if you, say, introduce a destructor - the semantics will not subtly change.
Uh, yes, if you guarantee the semantics only when the code explicitly opts in and not by default then semantics will not subtly change, that is the point of my comment
Earlier quoted context omitted.
> implicitly creating new stacks I'd argue that it's explicit - that's what a function call does and you don't have implicit function calls in rust. > 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. What you're asking for here already exists. Tail calls might be optimized into n…
I see it, certain algorithms need guaranteed tail-call elimination, otherwise they are too inefficient and must be manually unrolled or rewritten to avoid blowing the stack. So a compiler optimization that is "nice to have" is not good enough.
Was there something wrong with how they are currently written or do they just want the badge that says they converted to Rust?
License. GNU is copyleft and the new thing is permissive. We might see a fracture open slowly. For me, even AGPL is not enough