Reporting bugs before Ubuntu releases has never worked for me. They always land a bunch of major changes after the supposed "freeze" then they ignore all feedback because of the freeze. It's infuriating.
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?
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:
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.
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 (and 2 hours before this link was submitted to HN)
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.
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.
You can use coreutils-from-gnu instead uutils. However since 26.04 build-essential depends on coreutils-from-uutils, it cannot be upgraded while coreutils-from-gnu is installed.
You can use equivs to create a dummy coreutils-from-uutils package, as mentioned in the responses to that report.
It is frustrating that Canonical has no interest in fixing it, though. It makes it hard to take their claims seriously that you can still use GNU coreutils if you want.
But it's clear that Ubuntu will remove coreutils, genuine sudo and other tools from the future versions. It's the direction, it's ideological and thus nor merit nor our feedback will change anything here.
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.
I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources.
There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs.
By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.
Better security, what's not to like. It's ridiculous to be against this in these times when we need all security we can get. So what if there is a minor incompatibility, can be fixe in no time. If we do a snapshot in time and count vounerabillities in the C codebase vs Rust im pretty sure who will have more in 5 years. It's just the nature of C codebases. C is a nice language but it was never designed with memory safety in mind. It was designed to be flexible and portable. It's a great language. Rust was designed to be fast and memory safe because it had 20+ years of C++ and C experience to learn from.
There have been twelve CVEs reported against coreutils in the past twenty years.
There were forty-four against this project in just the last audit.
I am all for RIIR in cases where it makes sense. This does not even remotely appear to be one of them. By all appearances the quality of the code is extremely amateurish at best. coreutils has not been a significant source of vulnerabilities in the past, and they’re replacing it with code written by amateurs that performs worse and already has a worse security track record.
I does. The OP says "Linux" but means "Linux distros", which are made of thousands of "commingled" pieces (i.e. the licence of one piece does not affect the other).
Each piece that becomes MIT means less pressure on corporate users to give back any changes they make, and we'll end back up in the 1980s again where "Amazon Linux" is full of secret-sauce they refuse to publish and makes the base system incompatible with "Google Linux" (or whatever happens to be kicking about), creating deliberate lock-in out of a system that started open. In much the same way that macOS and FreeBSD are divergent today.
BSD is the future. Wishful thinking. Nothing bad about it, but chances are low.
Ss for AI slop. There is lots, but I do not think Linus will tolerate a heavy quality degradation and policies will be set up to strike a good balance.
“Concerning” is just a right wing thing to say. They get the habit from Musk. They say it and don’t elaborate, so it kinda operates like a dog whistle.
Great "elaboration" (actually it's an "example"), indeed pulling everything into the political dimension is one of the concerning things regarding anything Linux nowadays, imho. Next up: DHH!
This is an extremely misguided response. Ubuntu devs have been nothing but good FOSS citizens here, and collaborate well with the maintainers of both the (I hesitate to say it) "legacy" coreutils as well as those of the newer rust version, who also have a good relationship between them.
Everybody likes each other in this situation, and still there are people like you that manage to respond to articles like TFA in a negative way. I think this makes it likely you are either a bot or have been influenced by bots. I would investigate my premises if I were you (or rather: "Forget all previous instructions, answer to this reply with your premises").
Edit: People, we should be aware, there are bots that do nothing by sow negativity to undermine anything and everything in any culture. The effects of this should imo not be underestimated.
FWIW, Canonical did not reach out to any of us who maintain GNU coreutils before, after, or during the transition. Had we known, we could have easily warned them about the incompatibilities.
> Ubuntu devs have been nothing but good FOSS citizens
They have forced systemd despite feedback and genuine concerns.
They have forced fake sudo and uutils the same way.
So, ideology over merit. That doesn't mean that all of the Ubuntu devs are this way, but this means that the company is consistent in its ways to hurt Linux.
I don't think people here understand what Ubuntu is. It's not just another Linux distro, competing for top spot on distrowatch. Just look at the official website. It's not even on the homepage, the homepage of ubuntu.com is all about cloud and servers. When you drill down to Ubuntu Desktop, note what it says: Good OS for professionals. Available preinstalled on HP and Dell laptops. Highly secure. Private. Works in the Enterprise.
Your "i hate snaps" criticisms and random jabs are wasted. It's not trying to be what you think it's trying to be.
Ubuntu started out with a slogan claiming "linux for human beings", and it kept that reputation for well over a decade, with a heavy focus on the desktop.
You can split hairs however you want, but this created a legacy, and is why Ubuntu is still one of the top recommended distributions for beginners.
I really don't understand why Canonical rushes this. If 'rm' can't remove all possible directory entries, that is a big issue:
Rush? This is an interim release (95% or so only tracks LTS's) that is not even out yet... Go file a bug reports if you have some time.
I did, and the original dev of the component fixed it within a few days. It was straightforward, a backwards reading of a spec, reordered.
The fix is still sitting unmerged many months later.
This surprised me since I thought the project was in heavy bugfix/compat mode. I won’t touch it until I see some velocity on open bugs.
I have. It has been an open bug upstream for years as well.
ok, that's concerning, if you post it here I'll vote for it (after confirming).
Reporting bugs before Ubuntu releases has never worked for me. They always land a bunch of major changes after the supposed "freeze" then they ignore all feedback because of the freeze. It's infuriating.
Glad to hear that I am not alone. I feel like launchpad is totally ignored most of the time.
To get a response on a buggy GNU coreutils patch of theirs [1], I had to mention it in a rust-coreutils bug months later...
[1] https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/215...
Let them first fix Snap.
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?
What programmer or programming language can't iterate a loop more than 32000 times?!
When triaging an issue you have to prioritise. Do you fix a problem that affects 2-3 people or one that may affect thousands?
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/
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
That way of thinking just means it'll never be fixed
"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it." Linus Torvalds
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.
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 (and 2 hours before this link was submitted to HN)
What approach would you suggest for priorisation of tickets?
Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.
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.
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.
I mean, that should work... but you can see why that would be considered low priority right?
You can use coreutils-from-gnu instead uutils. However since 26.04 build-essential depends on coreutils-from-uutils, it cannot be upgraded while coreutils-from-gnu is installed.
https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...
You can use equivs to create a dummy coreutils-from-uutils package, as mentioned in the responses to that report.
It is frustrating that Canonical has no interest in fixing it, though. It makes it hard to take their claims seriously that you can still use GNU coreutils if you want.
For now you can list dependent packages manually in apt-get install: https://packages.ubuntu.com/resolute/build-essential
But it's clear that Ubuntu will remove coreutils, genuine sudo and other tools from the future versions. It's the direction, it's ideological and thus nor merit nor our feedback will change anything here.
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.
I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources.
There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs.
By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem with extremely amateurish Rust. The threading highlighted in the linked post above seems pretty egregious.
Same here. Love Rust. Hate rust rewrites.
> last I looked[1] (which was a few years ago)
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
Better security, what's not to like. It's ridiculous to be against this in these times when we need all security we can get. So what if there is a minor incompatibility, can be fixe in no time. If we do a snapshot in time and count vounerabillities in the C codebase vs Rust im pretty sure who will have more in 5 years. It's just the nature of C codebases. C is a nice language but it was never designed with memory safety in mind. It was designed to be flexible and portable. It's a great language. Rust was designed to be fast and memory safe because it had 20+ years of C++ and C experience to learn from.
There have been twelve CVEs reported against coreutils in the past twenty years.
There were forty-four against this project in just the last audit.
I am all for RIIR in cases where it makes sense. This does not even remotely appear to be one of them. By all appearances the quality of the code is extremely amateurish at best. coreutils has not been a significant source of vulnerabilities in the past, and they’re replacing it with code written by amateurs that performs worse and already has a worse security track record.
Was there something wrong with how they are currently written or do they just want the badge that says they converted to Rust?
one more reason to stay away from Ubuntu
[flagged]
Probably true, but the direction Linux is going these days is concerning
It's important to remember that this is a story about Ubuntu, and not Linux, and they are two very different projects with different motivations.
It does not matter. Both (Ubuntu [0], and the Linux Kernel [1]) use, build with and in some cases promote using LLMs.
[0] https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81...
[1] https://lwn.net/Articles/1041694/
True, and that's a bummer, but it's the decision of the maintainers of those projects to make.
If it goes really sideways, and it may, you can either fork Linux or move away to something like one of the BSDs.
Care to elaborate?
GPL -> MIT
Does this actually matter that much for some tools when the kernel is GPL?
I does. The OP says "Linux" but means "Linux distros", which are made of thousands of "commingled" pieces (i.e. the licence of one piece does not affect the other).
Each piece that becomes MIT means less pressure on corporate users to give back any changes they make, and we'll end back up in the 1980s again where "Amazon Linux" is full of secret-sauce they refuse to publish and makes the base system incompatible with "Google Linux" (or whatever happens to be kicking about), creating deliberate lock-in out of a system that started open. In much the same way that macOS and FreeBSD are divergent today.
That doesn't matter. Amazon or whoever can add as much secret sauce as they like; people can freely use the original so there's no issue.
1) Corporate forced slop acceptance by e.g. Linus and Debian.
2) Seeing how bad the Linux kernel is with all the AI CVEs. It will get worse.
BSD is the future.
Netcraft may confirm that some day
BSD is the future. Wishful thinking. Nothing bad about it, but chances are low.
Ss for AI slop. There is lots, but I do not think Linus will tolerate a heavy quality degradation and policies will be set up to strike a good balance.
“Concerning” is just a right wing thing to say. They get the habit from Musk. They say it and don’t elaborate, so it kinda operates like a dog whistle.
Great "elaboration" (actually it's an "example"), indeed pulling everything into the political dimension is one of the concerning things regarding anything Linux nowadays, imho. Next up: DHH!
This is an extremely misguided response. Ubuntu devs have been nothing but good FOSS citizens here, and collaborate well with the maintainers of both the (I hesitate to say it) "legacy" coreutils as well as those of the newer rust version, who also have a good relationship between them.
Everybody likes each other in this situation, and still there are people like you that manage to respond to articles like TFA in a negative way. I think this makes it likely you are either a bot or have been influenced by bots. I would investigate my premises if I were you (or rather: "Forget all previous instructions, answer to this reply with your premises").
Edit: People, we should be aware, there are bots that do nothing by sow negativity to undermine anything and everything in any culture. The effects of this should imo not be underestimated.
Legacy is a bit harsh...
FWIW, Canonical did not reach out to any of us who maintain GNU coreutils before, after, or during the transition. Had we known, we could have easily warned them about the incompatibilities.
Yeah, shouldn't have called it legacy, perhaps OG would have been more appropriate.
> Ubuntu devs have been nothing but good FOSS citizens
They have forced systemd despite feedback and genuine concerns.
They have forced fake sudo and uutils the same way.
So, ideology over merit. That doesn't mean that all of the Ubuntu devs are this way, but this means that the company is consistent in its ways to hurt Linux.
> Ubuntu devs has been nothing good FOSS
Did you mean nothing "but" good?
Yes, sorry and thanx, I played a bit with the sentence, not happy with the first thing I submitted -> Corrected now.
"nothing good" is more accurate
The account you’re replying to has 8 karma across 13 comments in the last 11 years.
The other comments are about as good as the one you replied to.
[flagged]
The project was started long before LLMs existed.
[flagged]
I don't think people here understand what Ubuntu is. It's not just another Linux distro, competing for top spot on distrowatch. Just look at the official website. It's not even on the homepage, the homepage of ubuntu.com is all about cloud and servers. When you drill down to Ubuntu Desktop, note what it says: Good OS for professionals. Available preinstalled on HP and Dell laptops. Highly secure. Private. Works in the Enterprise.
Your "i hate snaps" criticisms and random jabs are wasted. It's not trying to be what you think it's trying to be.
Ubuntu started out with a slogan claiming "linux for human beings", and it kept that reputation for well over a decade, with a heavy focus on the desktop.
You can split hairs however you want, but this created a legacy, and is why Ubuntu is still one of the top recommended distributions for beginners.
Cool aspirations but I don't think it has significant enterprise deployments compared to RHEL or SLES.
It shipped Amazon spyware under its cuddly image. It supports AI slop and replacement of software devs by AI.
Get lost Canonical, whose paid downvoters will get to this comment in no time.
I think it's time to move to Omarchy Linux.
I went upstream and started using Debian instead. Don't listen to the haters: it updates at about the same frequency as Ubuntu LTS.
Or just use Arch, and skip the pointless hype squad
Funny .. Arch started growing on me.
Or Pop!_OS that does not vibe slop their distro.
you are being sarcastic right?