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.
baq 1 hours ago [-]
Fork Ubuntu and threaten their business model, that’ll get their attention.
Only half joking.
yjftsjthsd-h 28 minutes ago [-]
Ubuntu is the fork; just use Debian.
tjoff 22 minutes ago [-]
There are plenty of Ubuntu forks?
collinfunk 17 hours ago [-]
I have. It has been an open bug upstream for years as well.
teekert 16 hours ago [-]
ok, that's concerning, if you post it here I'll vote for it (after confirming).
LtWorf 1 hours ago [-]
My experience is that filing bug reports to ubuntu is a complete waste of time. Not sure if it's different for paying users.
jeffbee 16 hours ago [-]
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.
collinfunk 16 hours ago [-]
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...
I've been a Ubuntu user for about 20 years, and I file bugs every now and then on launchpad. I don't recall any of them ever being fixed.
Maybe the bugs get traction if you have a service contract?
Best to file bugs directly to upstream, but that of course means you should try it on the latest upstream version and not whatever version ubuntu ships, so it's more friction.
amelius 16 hours ago [-]
Let them first fix Snap.
tjoff 2 hours ago [-]
There is no reason for anyone on any distro to use snap.
It will die so just leave it alone.
0x696C6961 7 hours ago [-]
They need to kill snap ...
LtWorf 56 minutes ago [-]
I think ubuntu wants to kill desktop linux. No other explaination of why they push firefox inside snap, which then proceeds to constantly crash, when firefox used normally works completely fine.
I haven't tried chromium but I presume it's the same issue.
At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox.
At least in the past few months the dbus crashes (been using systemd on debian for several years just fine, this never happened) that render the system unusable and un-rebootable have stopped… I guess when my company will decide to upgrade to 26.04 there will be more instability and problems.
cute_boi 3 hours ago [-]
Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.
ChocolateGod 33 minutes ago [-]
AppImages do not work anywhere close to how macOSs .apps do, and even if they did the approach isn't correct for how things work on Linux.
tancop 1 hours ago [-]
Appimages are bloated and unreliable. You can't guarantee that your app will run on any machine because it might depend on different system libraries.
Flatpak uses shared stable runtimes that are the same everywhere and don't take up space more than once. It also comes with a native update system and sandboxing. Snap is the same thing but worse.
suby 13 minutes ago [-]
My problem with flatpak is that the underlying runtime has a limited lifespan. I used the Sublime Text 3 flatpak for many years, and it was deprecated a few months ago because the runtime it was using was no longer supported. This caused people to update the flatpak to Sublime 4, which is good, but I only have a license for 3. In the end I just downloaded the binary for 3 from their website, and it still just worked. Flatpak still doesn't save you from bitrot.
ChocolateGod 33 minutes ago [-]
> Snap is the same thing but worse
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
petre 3 hours ago [-]
I'll avoid it at this point anyway. The Rust coreutils is another reason for that. Snap, monetizing updates, telemetry, enough is enough.
voakbasda 2 hours ago [-]
Yup. After almost 20 years, I have had enough of their crap. All of my new machines are getting Debian. Can’t wait until I am free of Ubuntu.
dark-star 16 hours ago [-]
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?
geokon 20 minutes ago [-]
It's less about the specific issue and more indicative of bad/insufficient test coverage
tosti 14 hours ago [-]
What programmer or programming language can't iterate a loop more than 32000 times?!
IshKebab 14 hours 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:
8MB is the default per-thread stack size from glibc, also seems to be the default "ulimit" from pam or the kernel, I'm not sure. So for the main/default thread (or if not using threads) the process can use setrlimit() and for threads it can use pthread_attr_setstacksize() to get bigger stacks if it knows it may need them.
8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB!
tosti 14 hours ago [-]
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
gpm 13 hours 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]).
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 13 hours 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.
gpm 13 hours ago [-]
> 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 not allocating extra stack frames, the rust compiler just doesn't guarantee that it will perform that optimization (and almost certainly won't when code is compiled without optimizations... for instance).
What people want is the semantic guarantee that the stack frame won't be allocated. Not just a compiler that often performs the optimization. Otherwise you can't be sure that your code will keep working with new compiler flags/versions/architectures/... You could say "whenever the code is the right shape we'll guarantee the optimization" (C++ famously did this for things like copy elision)... but now the shape of code comes with non-obvious semantic guarantees and that's not rust's style. Hence the proposal for a keyword instead.
lioeters 13 hours ago [-]
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.
clhodapp 4 hours ago [-]
No algorithm requires tail-call elimination in a general-purpose language with imperative mutability. It's just another way to express iteration.
jmalicki 4 hours ago [-]
> 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.
That's not implementing tail calls breaks things, that's bad design of implementing tail calls breaking things.
The whole idea of "let's change semantics to make it easier" is dumb.
If you want guaranteed tail calls, change your code until it works.
gpm 4 hours ago [-]
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
jmalicki 4 hours ago [-]
It's not a change in semantics of compiled code. It is only a change of whether or not the code will compile.
IshKebab 10 hours ago [-]
Do any widely used languages guarantee tail call optimization? It's a pretty niche feature.
gpm 10 hours ago [-]
Scala, ocaml, racket, clojure, zig.
For recursion only kotlin.
(For most of these only with syntax specifying it)
hulitu 2 hours ago [-]
Rust ? Because of ... memory safety. /s
Ygg2 14 hours ago [-]
When triaging an issue you have to prioritise. Do you fix a problem that affects 2-3 people or one that may affect thousands?
nh2 1 hours ago [-]
The point is that such bugs shouldn't exist in the first place.
Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety.
Every time you call something recursively you should be thinking "how deep is this?".
BHSPitMonkey 24 minutes ago [-]
By that logic, why even spend effort migrating from a known-working implementation to one which is known to have outstanding bugs that there isn't enough bandwidth to fix?
secondcoming 16 hours ago [-]
That way of thinking just means it'll never be fixed
abirch 16 hours ago [-]
"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it."
Linus Torvalds
LtWorf 12 minutes ago [-]
It's complicated to do it yourself when upstream won't accept your code.
dfox 16 hours 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.
gpm 16 hours 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 (and 2 hours before this link was submitted to HN)
7bit 16 hours ago [-]
What approach would you suggest for priorisation of tickets?
secondcoming 16 hours ago [-]
Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.
gpm 16 hours 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 16 hours 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.
mrkdkirlwkfkf 3 hours ago [-]
Capitalism.
IshKebab 14 hours ago [-]
I mean, that should work... but you can see why that would be considered low priority right?
lynx97 2 hours ago [-]
Wow! Memory safety and such... Reminds me when a friend of mine wrote in IRC long time ago: "Hmm, tail just segfaulted." When I asked "Are you on Hurd?" he just replied "Yes."
erminpour 43 minutes ago [-]
Whether you like Rust or not, it's questionable as to why Canonical would push this so much and do it in such a cavalier way.
Will this really make coreutils more secure? I doubt it, if anything there will be a river of new bugs.
So, again, why are they pushing Rust so much? Having Microsoft make Rust a 'Tier-1' language also doesn't bode well.
sehw 15 minutes ago [-]
People still use ubuntu when Debian and Mint exist?
LtWorf 6 minutes ago [-]
The power of marketing…
Ubuntu does offer some certifications but only for paying customers, so everyone else should really steer clear.
Malakun 16 hours ago [-]
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.
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.
lioeters 13 hours ago [-]
> genuine sudo
That made me curious, it sounds related to this:
Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords - 5 months ago (413 comments)
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.
dwattttt 26 minutes ago [-]
You're specifically frustrated about unbounded stack recursion exhausting the stack, triggered by multiple thousands of directories? It doesn't sound like this is about multi-thousand-deep directory structures, it sounds like it's about something else.
Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.
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.
The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.
stouset 15 hours ago [-]
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.
egorfine 14 hours ago [-]
Same here. Love Rust. Hate rust rewrites.
noosphr 27 minutes ago [-]
The worst thing about rust are the people using it.
LtWorf 5 minutes ago [-]
My impression is that go developers moved to rust.
tcfhgj 7 hours ago [-]
I bet you don't know the reason for existence
estebank 15 hours ago [-]
> last I looked[1] (which was a few years ago)
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
SubiculumCode 2 hours ago [-]
So what is the way forward for Linux to have sandboxi g as strong as Android? Appimage everything? I know it's possible now hacking together things, but I mean by default and integrated.
bayindirh 26 minutes ago [-]
Amutable. Building an immutable and image based system which even the installer can't modify, a-la macOS.
One systemd patch at a time.
uecker 32 minutes ago [-]
Maybe we could develop trustworthy free-software applications again, instead of trying to establish a commercial apps ecosystem on top of Linux?
arjie 2 hours ago [-]
Everything online reminds of when Ubuntu switched to dash for init scripts or something. Good times.
Surac 28 minutes ago [-]
Other distros are based of ununtu. Will the all ship with crippled coreutils from now on?
grougnax 51 minutes ago [-]
Can’t wait for the whole Rust rewrite of Linux!
hk1337 16 hours ago [-]
Was there something wrong with how they are currently written or do they just want the badge that says they converted to Rust?
Flimm 2 hours ago [-]
Neither. They basically see Rust as the future. They want to be able to attract young contributors and to hire young employees who are excited about Rust and who want the safety features. Bear in mind, the average age of the Linux developer is increasing. They also see technical benefits in Rust. And they are increasing test coverage of both the Rust tools and the tools written in C, IIRC.
In reality, I think it much more about taking more control over parts of the ecosystem - the license change is part of it, but also getting rid of the old stubborn communities and maintainers.
01HNNWZ0MV43FF 4 hours ago [-]
License. GNU is copyleft and the new thing is permissive.
We might see a fracture open slowly. For me, even AGPL is not enough
zahlman 4 hours ago [-]
Once they have a more permissive license, cui bono?
pjmlp 1 hours ago [-]
Businesses.
There is a reason all FOSS OS alternatives for embedded systems like Zephyr, NuttX, FreeRTOS, IDF, Arduino,... are not GPL based, while Google has purged Android and ChromeOS from it, with the Linux kernel being the only GPL piece left.
dsign 3 hours ago [-]
Hmm, this doesn’t make sense. You simply don’t replace utilities with many decades of maturity and that “just work” with something that is not as mature. It will open all users of the distro to all sorts of subtle and not so subtle bugs. I for one don’t want to find myself staring at a mysterious segfault when I want to build the latest version of nodejs or flash a microcontroller. It’s such a pity; I have used Ubuntu for close to 23 years.
someothherguyy 3 hours ago [-]
then install the other tool. no one is holding a gun to your head. it isn't windows.
nairboon 2 hours ago [-]
Like how one can easily not use snap on Ubuntu? /s
1 hours ago [-]
goodpoint 16 hours ago [-]
[flagged]
phendrenad2 16 hours ago [-]
[flagged]
mid-kid 15 hours ago [-]
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.
m4rtink 14 hours ago [-]
Cool aspirations but I don't think it has significant enterprise deployments compared to RHEL or SLES.
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.
teekert 17 hours ago [-]
Yeah, shouldn't have called it legacy, perhaps OG would have been more appropriate.
egorfine 16 hours ago [-]
> 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.
teekert 2 hours ago [-]
“Hurd Linux”? Maybe leave that judgement to Torvalds.
Canonical is a company they do what the CEO wants. And you are free to do what you want.
Quick question: are the fruits of your labor mostly given away for free?
fhdkweig 17 hours ago [-]
> Ubuntu devs has been nothing good FOSS
Did you mean nothing "but" good?
teekert 17 hours ago [-]
Yes, sorry and thanx, I played a bit with the sentence, not happy with the first thing I submitted -> Corrected now.
goodpoint 16 hours ago [-]
"nothing good" is more accurate
testdelacc1 16 hours ago [-]
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.
jmclnx 17 hours ago [-]
Probably true, but the direction Linux is going these days is concerning
bigfishrunning 16 hours ago [-]
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.
rvz 15 hours ago [-]
It does not matter. Both (Ubuntu [0], and the Linux Kernel [1]) use, build with and in some cases promote using LLMs.
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.
_ink_ 17 hours ago [-]
Care to elaborate?
amiga386 16 hours ago [-]
GPL -> MIT
skrtskrt 16 hours ago [-]
Does this actually matter that much for some tools when the kernel is GPL?
amiga386 16 hours ago [-]
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.
skrtskrt 8 hours ago [-]
In theory there could be a the MIT version relicensed to GPL and this version could be carried as a standard if having MIT software as core utilities was considered enough of a threat - right? You just have to retain original license/attribution.
That would be an awfully awkward move in the realm of Linux-related politics but if having an MIT-licensed coreutils was such an existential thread, at least you can fix it with aggressive license moves and not code.
bigstrat2003 14 hours ago [-]
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.
amiga386 13 hours ago [-]
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)
skrtskrt 8 hours ago [-]
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?
amiga386 6 hours ago [-]
In the 1980s and 1990s, there were a number of commercial Unices (SunOS, HP-UX, AIX, IRIX, etc.) Every one of them was incompatible with each other, sometimes subtly, sometimes blatantly. They were all competing against each other and all seemed to encourage you to use their proprietary extensions in your software and deliberately fuck over anyone using any other variants.
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.
testdelacc1 16 hours ago [-]
“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.
teekert 16 hours ago [-]
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!
qwj18 16 hours ago [-]
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.
bigfishrunning 15 hours ago [-]
Netcraft may confirm that some day
germandiago 16 hours ago [-]
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.
jmclnx 12 hours ago [-]
You were down voted, odd. But this I fully agree with, the latest thing for me is Wayland being forced upon us.
skrtskrt 8 hours ago [-]
X11 and everything around it is unfixable security hazard slop, just slop that was painstakingly created by humans.
Also Wayland is it being forced on us? I have plenty of coworkers that run X daily because they are still afraid of the Wayland boogeyman despite the fact that their supposed clipboard and screen sharing problems in Wayland (the only two supposed problems they can name) have been solved for years.
17 hours ago [-]
blastonico 16 hours ago [-]
[flagged]
theandrewbailey 15 hours ago [-]
I went upstream and started using Debian instead. Don't listen to the haters: it updates at about the same frequency as Ubuntu LTS.
stonogo 16 hours ago [-]
Or just use Arch, and skip the pointless hype squad
wojciii 16 hours ago [-]
Funny .. Arch started growing on me.
rvz 15 hours ago [-]
Or Pop!_OS that does not vibe slop their distro.
tuananh 16 hours ago [-]
you are being sarcastic right?
bithammerthunde 16 hours ago [-]
[flagged]
dralley 16 hours ago [-]
The project was started long before LLMs existed.
perarneng 15 hours ago [-]
[flagged]
stouset 15 hours ago [-]
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.
Ygg2 13 hours ago [-]
> There were forty-four against this project in just the last audit.
Was there an audit against coreutils? If not, it's not really apple-to-apple comparison.
stouset 10 hours ago [-]
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.
gpm 8 hours ago [-]
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.
collinfunk 7 hours ago [-]
Most of them are TOCTOU races or improperly following symbolic links. For example, uutils mkfifo(1) would create a world-readable and writable FIFO before using chmod(2) to restrict its permissions. Another user could replace that file with a symbolic link between the mkfifo(3) call and the chmod(2) to change the permissions of arbitrary files [1].
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.
There's a whole load of basic bugs reported and ignored:
https://bugs.launchpad.net/ubuntu/+source/rust-coreutils
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.
Only half joking.
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...
Maybe the bugs get traction if you have a service contract?
Best to file bugs directly to upstream, but that of course means you should try it on the latest upstream version and not whatever version ubuntu ships, so it's more friction.
It will die so just leave it alone.
I haven't tried chromium but I presume it's the same issue.
At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox.
At least in the past few months the dbus crashes (been using systemd on debian for several years just fine, this never happened) that render the system unusable and un-rebootable have stopped… I guess when my company will decide to upgrade to 26.04 there will be more instability and problems.
Flatpak uses shared stable runtimes that are the same everywhere and don't take up space more than once. It also comes with a native update system and sandboxing. Snap is the same thing but worse.
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
https://lwn.net/Articles/1035727/
8MB is pretty huge though; musl libc is famous for defaulting to much smaller per-thread stack size of 128KB (to avoid over-committing lots of memory when there are many threads - the main dev is really principled/opinionated on this topic, but again there are a few ways for applications to explicitly size their stacks as large as they need). Linux kernel threads get a bit less than 16KB!
[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. If you want to guarantee that a call can't allocate a new stack frame you should have to say it.
But I can understand the preference for an explicit opt-in, to make clear that it is enforced and not assumed.
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 not allocating extra stack frames, the rust compiler just doesn't guarantee that it will perform that optimization (and almost certainly won't when code is compiled without optimizations... for instance).
What people want is the semantic guarantee that the stack frame won't be allocated. Not just a compiler that often performs the optimization. Otherwise you can't be sure that your code will keep working with new compiler flags/versions/architectures/... You could say "whenever the code is the right shape we'll guarantee the optimization" (C++ famously did this for things like copy elision)... but now the shape of code comes with non-obvious semantic guarantees and that's not rust's style. Hence the proposal for a keyword instead.
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.
The whole idea of "let's change semantics to make it easier" is dumb.
If you want guaranteed tail calls, change your code until it works.
For recursion only kotlin.
(For most of these only with syntax specifying it)
Using recursion on unbounded inputs on a programming language that doesn't support that (which are most) is an extremely classical mistake that really should be known to all programmers, especially those of low level languages that care about safety.
Every time you call something recursively you should be thinking "how deep is this?".
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)
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.
Will this really make coreutils more secure? I doubt it, if anything there will be a river of new bugs.
So, again, why are they pushing Rust so much? Having Microsoft make Rust a 'Tier-1' language also doesn't bode well.
Ubuntu does offer some certifications but only for paying customers, so everyone else should really steer clear.
https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...
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.
That made me curious, it sounds related to this:
Ubuntu 26.04 Ends 46 Years of Silent sudo Passwords - 5 months ago (413 comments)
https://news.ycombinator.com/item?id=47464134
i was referring to their counterfeit sudo emulator written in rust. It's called "sudo-rs" afair.
Security issues discovered in sudo-rs - https://lists.debian.org/debian-security-announce/2025/msg00...
Sudo-Rs Affected by Multiple Security Vulnerabilities - https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10
Sudo-rs enables password feedback by default - https://www.phoronix.com/news/sudo-rs-password-feedback
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.
Because even diving into it, I would agree with a prioritisation decision that puts this bug down the bottom of a priority list.
[1] https://jackson.dev/post/rust-coreutils-dd/
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.
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
One systemd patch at a time.
My source is this interview with the VP of Engineering at Canonical on this topic: https://corrode.dev/podcast/s05e05-canonical/
We might see a fracture open slowly. For me, even AGPL is not enough
There is a reason all FOSS OS alternatives for embedded systems like Zephyr, NuttX, FreeRTOS, IDF, Arduino,... are not GPL based, while Google has purged Android and ChromeOS from it, with the Linux kernel being the only GPL piece left.
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.
And they are slightly behind RHEL: https://commandlinux.com/statistics/linux-server-market-shar...
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.
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.
Canonical is a company they do what the CEO wants. And you are free to do what you want.
Quick question: are the fruits of your labor mostly given away for free?
Did you mean nothing "but" good?
The other comments are about as good as the one you replied to.
[0] https://discourse.ubuntu.com/t/the-future-of-ai-in-ubuntu/81...
[1] https://lwn.net/Articles/1041694/
If it goes really sideways, and it may, you can either fork Linux or move away to something like one of the BSDs.
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 would be an awfully awkward move in the realm of Linux-related politics but if having an MIT-licensed coreutils was such an existential thread, at least you can fix it with aggressive license moves and not code.
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.
2) Seeing how bad the Linux kernel is with all the AI CVEs. It will get worse.
BSD is the future.
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.
Also Wayland is it being forced on us? I have plenty of coworkers that run X daily because they are still afraid of the Wayland boogeyman despite the fact that their supposed clipboard and screen sharing problems in Wayland (the only two supposed problems they can name) have been solved for 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 an audit against coreutils? If not, it's not really apple-to-apple comparison.
We are talking about fourfold more CVEs over a twentyfold reduction in time.
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...