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.
> 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.
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.
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.
There's a project called "anylinux appimages" that aims to make the most compatible appimages. They also use DwarFS for faster opening and smaller file sizes.
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.
Firefox installed as a snap feels sluggish to me. When I install a Ubuntu system, the first thing I do is to uninstall any snap and install the apt versions of things, possibly adding official PPAs or using Guix to install software.
Indeed. Thought not in all cases I can decide what OS to use. An employer might prescribe which one to use. And any distro will be better than being forced to use Windows.
sandboxing a browser makes total sense. my firefox and chromium running as snaps never crashed a single time for as long as I can remember, and I use both every day, at the same time.
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:
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!
8MB is huge compared to the stacks we used to have when address spaces were 32-bit, but it's tiny compared to how much memory we can actually make use of now. The only real argument I can think of for having such a small stack is that large stack usage is often indicative of an infinite recursion bug and it catches them earlier.
But I don't really buy that for the same reason most programming languages don't limit loops to 8 million iterations (or whatever) by default - it would make catching infinite loop bugs easier!
I say most, because I know of at least one language that did do that - QuakeC! It made lots of sense in that context though.
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?".
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?
Hard to say, but there are legitimate reasons. One of which being they think Rust is growing while C is a shrinking language. Other could be safety (yes, yes the audit did surface bugs). Or even that having a single lib work seamlessly on Windows/Linux/MacOS/Redux/Web.
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."
It's entirely aisine and makes me avoid Ubuntu every time it is possible.
And it is repeated offence, Ubuntu always tried to push the envelope in worst place and way possible
While I supported that idea of Rust coreutils, this your experiment showed me how bad it is. My results are totally different, but not what I expected (edited out long strings of "a/a/a" for brevity). I wouldn't call it stable...
root@71a8c5a6c5e3:/# mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
mkdir: File name too long
root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
gnumkdir: cannot create directory 'a/a/a/.../a/a': File name too long
root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((3 * 1024)) | tr -d '\n')
root@71a8c5a6c5e3:/# rm -rf a
rm: cannot remove 'a/a/a/.../a/a/a': Directory not empty
root@71a8c5a6c5e3:/# gnurm -rf a
root@71a8c5a6c5e3:/# rm -rf a
root@71a8c5a6c5e3:/#
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.
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.
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.
Canonical is just rushing the switch because they want to get rid of software with GPLv3 license, not because there is any technical merit for doing so.
If they want the default to be non-GPLv3 Rust-based that's fine, but some of us don't care (and want the same behaviour everywhere, like on RH-based systems we may also have) and they should leave the GNU as an option. Potentially both could be installed at the same time (it's what update-alternatives is for after all).
That's a better thing to discuss, and I'd expect there to be better bugs to talk about to go with it. Stack exhaustion in an unrealistic environment should be fixed, but a "stop everything" bug it ain't.
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.
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, the the Linux kernel being the only GPL piece left.
I was only thinking about the software, yes. Also a lot of the "Arduino" libraries are not really owned by Arduino, even if they like to attach themself to it, so while it is true what they write about different licenses of the libraries, this what not what I considered to be part of Arduino itself. I was only thinking of the buildtools they release. While these are board specific, these are often "just" a fork of gcc, board-specific linker/image builders, a flasher and the Arduino-build system. Only the latter is what they actually created (arguable not even that: https://arduinohistory.github.io/).
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.
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.
Can vouch for the sentiment, hence why regardless of the ranting, I am quite supportive of whatever helps to improve C and C++ security story.
Also for Rust based rewrites, they could start by bootstraping Rust compiler itself, dependent on C++ to start it.
They don't do it, because even though LLVM and GCC are written in C++, a pure Rust compiler would not scale to the same level of contributions, and existing capabilities.
> The reason for existence of uutils is ideological, not technical.
which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.
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.
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.
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.
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.
i mean, i use ubuntu on multiple personal devices that i use daily and like <3% of the packages installed are managed with snap, and to me, it isn't as bad as everyone makes it out to be.
the point i was trying to make was that it is much harder to replace things like .net / powershell in windows for simple cli workflows.
in linux, you can just drop the executable you want to use in your path. so, gnu coreutils will build on pretty much anything you need them to, and are very stable. it is <5m of effort to build it and swap the executable in your path.
also, as mentioned here, ubuntu will allow you to select which package you want to install from the normal repos, so you don't even need to do that.
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.
Note that the sandbox also relies on the fact that most userspace is managed, the Android team is very clear on what they see as supported use cases for the NDK.
Its not that if they have advertised themselves as a drop-in replacement or not. What made me bummed that cannonical used it as drop-in replacement and it did break some of my installation scripts.
Canonical has been pushing its own agenda for ages, how many examples do you need?
Microsoft making Rust tier 1 is great, it means probably one day we get a VS proper support instead of VSCode only.
If you head off to Microsoft official blogs, you will find out that Microsoft already has tier 1 support for Java (ironically), Python and Go, besides the usual .NET languages and C++.
In the long run yes. Sure, many logic bugs happen in Rust programs as well, but memory safety bugs are another level of hell. At least many classes of exploits will mostly be impossible. Also, Rust program failures tend to be more predictable. For example, in C/C++, if you do out of bound writes in an array or writes in a freed memory block, the behavior is undefined. The program might crash, the memory might be silently corrupted, or nothing might happen at all. In a normal (non unsafe) Rust code these kinds of issues are either prevented by static checks or become explicit runtime panics.
In theory yes, but it requires enough discipline and knowledge. A language that makes it harder to write bad code still has an advantage over a language that doesn't care about bad code.
Can you point to any outstanding, unfixable, memory safety bugs in the coreutils that justify such a rewrite? This is a cynical license issue, not a safety issue. I think there are much more severe security risks which come from behavior divergence of replacement tooling than memory safety bugs from 40 year old widely used/tested software.
Nowadays the non-free-firmware repo is active by default, so the normal official debian image actually works.
It used to be the case that the normal download from the homepage was often useless because it didn't support most networking hardware, but this is no longer the case now.
Debian packages are ancient, unless you use "testing", which will be broken. That being said, Ubuntu is horrible too. The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu.
Ubuntu is basically a packages imported/synced from debian (I think they mostly cherry pick unstable) + ubuntu specific stuff.
Debian Testing is pretty much what many Debian users use on a daily basis. They pretty much invented the notion of rolling releases. Debian stable is of course not cut that often. Ubuntu has a higher frequency of updates. But still, their LTS releases are spaced two years apart. 26.10 follows the recent LTS 26.04 release, so that gives them a good 1.5 years to work on stabilizing this. I've been using Ubuntu server LTS releases for the last ten years or so with generally no major issues. There are always some minor headaches between updates but generally nothing that worries me.
The main criticism here seems to be that these packages need a bit more work or are still lacking certain important features. Getting them out in a non LTS release like this is how they get packages to be ready for LTS releases. If you need LTS now, 26.04 is what you should be using. By 28.04, this should be rock solid.
For me what's risky here is deviating from what other distros are doing. Including Debian. Ubuntu has a history of being opinionated not everything they push through being adopted with great enthusiasm (e.g. Snap). You could make the point here that waiting for Debian to pick this up would be nicer. But you could also make the point that waiting for that is a very slow process.
ever used backports? no need to go to sid. Flatpack/Appimage/Compile from source for the rest (on my debian machine it's just kicad that is not installed from APT, well and the couple of softwares that don't do deb)
Firmwares, that's another story, i have fedora on the laptop for that.
> The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu
If i want to do FPGA development, either ubuntu or a distro old enough to package JDK 11 (sigh) and X. not XWayland. Debian 11 was the last one to have JDK 11 i think (talk about ancient..)
Needless to say FPGA is done on the windows machine these days.
Fil-C[0] can compile GNU coreutils, it has stronger* memory safety guarantees than rust, none of the compatibility issues that a wholesale rewrite has, and performance that seems to be within about a factor of two[1] compared to the normally compiled code..
"Stronger" is absolute bullshit. No data race prevention. No intra-object protection. Mandatory GC, and 5x the compute cost. Nothing like a statically safe language.
I think a lot of the actual issues they're encountering are that the underlying POSIX APIs have a lot of sharp edges which the older versions of the tools have had enough time to work around, while the newer ones are generally running into the same rakes that have been there for decades. It takes a fair amount of time for those to be found and dealt with (though it also takes use, so it's a bit chicken-and-egg).
if the argument is "but bugs!" then that's a nothing burger. Your old code is more battle-tested, but that doesn't inherently make it better. I wish more companies thought like this.
It may not inherently make it better (for some meanings of "better") but it certainly makes it more secure and more stable. Those are attributes which I would value very highly in coreutils.
204 comments
[ 0.23 ms ] story [ 89.2 ms ] thread[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.
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.
The other comments are about as good as the one you replied to.
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?
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.
See: https://pkgforge-dev.github.io/Anylinux-AppImages/
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.
> never crashed a single time
I'm very happy for you. How does that help the people who do encounter issues?
No issues with snap Chromium.
It will die so just leave it alone.
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!
But I don't really buy that for the same reason most programming languages don't limit loops to 8 million iterations (or whatever) by default - it would make catching infinite loop bugs easier!
I say most, because I know of at least one language that did do that - QuakeC! It made lots of sense in that context though.
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?".
That's true of every bug, but you don't have infinite time or manpower, so how do you prioritise?
When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?
- A meaningful error
- not a segfault
One Makefile statement triggered a bug in rust ln:
In parallel build, we would get random failure: Rewrote that Makefile to work-around it, and ended up with the same kind of bugs with parallel $(INSTALL) -D ...Tried latest ubuntu 26.10 which supposedly fixes a lot of TOCTOU races in rust coreutils, but no better.
Gave up and switched back to original coreutils.
Ubuntu users will test this. Once the problems are ironed out, other distros will follow.
> Rewrite this codebase in Rust. Keep it mostly compatible but change the license to MIT.
Your "i hate snaps" criticisms and random jabs are wasted. It's not trying to be what you think it's trying to be.
Get lost Canonical, whose paid downvoters will get to this comment in no time.
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...
https://bugs.launchpad.net/ubuntu/+source/build-essential/+b...
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.
Canonical is just rushing the switch because they want to get rid of software with GPLv3 license, not because there is any technical merit for doing so.
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
I'm don't quite understand what this means: you can say that you want GNU coreutils when you install build-essential? How does that work on the CLI?
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, the the Linux kernel being the only GPL piece left.
Arduino is "just" repacked gcc in a nutshell, so it is GPL-based.
https://support.arduino.cc/hc/en-us/articles/4415094490770-L...
My source is this interview with the VP of Engineering at Canonical on this topic: https://corrode.dev/podcast/s05e05-canonical/
[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.
I would appreciate Go much more otherwise.
Also for Rust based rewrites, they could start by bootstraping Rust compiler itself, dependent on C++ to start it.
They don't do it, because even though LLVM and GCC are written in C++, a pure Rust compiler would not scale to the same level of contributions, and existing capabilities.
which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.
Yes, there is. There are people who genuinely think quality does not matter as log as it is written in Rust as Rust is memory safe.
Is this hyperbolic? Such people are in leadership places?
Many people have decided that this decision supposedly specifically about licensing ideology.
You can make up your mind about which of the two you believe.
See also: https://news.ycombinator.com/item?id=49707948
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751...
It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it:
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...
the point i was trying to make was that it is much harder to replace things like .net / powershell in windows for simple cli workflows.
in linux, you can just drop the executable you want to use in your path. so, gnu coreutils will build on pretty much anything you need them to, and are very stable. it is <5m of effort to build it and swap the executable in your path.
also, as mentioned here, ubuntu will allow you to select which package you want to install from the normal repos, so you don't even need to do that.
One systemd patch at a time.
https://github.com/trifectatechfoundation/sudo-rs#difference...
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.
Microsoft making Rust tier 1 is great, it means probably one day we get a VS proper support instead of VSCode only.
If you head off to Microsoft official blogs, you will find out that Microsoft already has tier 1 support for Java (ironically), Python and Go, besides the usual .NET languages and C++.
In the long run yes. Sure, many logic bugs happen in Rust programs as well, but memory safety bugs are another level of hell. At least many classes of exploits will mostly be impossible. Also, Rust program failures tend to be more predictable. For example, in C/C++, if you do out of bound writes in an array or writes in a freed memory block, the behavior is undefined. The program might crash, the memory might be silently corrupted, or nothing might happen at all. In a normal (non unsafe) Rust code these kinds of issues are either prevented by static checks or become explicit runtime panics.
It used to be the case that the normal download from the homepage was often useless because it didn't support most networking hardware, but this is no longer the case now.
Debian Testing is pretty much what many Debian users use on a daily basis. They pretty much invented the notion of rolling releases. Debian stable is of course not cut that often. Ubuntu has a higher frequency of updates. But still, their LTS releases are spaced two years apart. 26.10 follows the recent LTS 26.04 release, so that gives them a good 1.5 years to work on stabilizing this. I've been using Ubuntu server LTS releases for the last ten years or so with generally no major issues. There are always some minor headaches between updates but generally nothing that worries me.
The main criticism here seems to be that these packages need a bit more work or are still lacking certain important features. Getting them out in a non LTS release like this is how they get packages to be ready for LTS releases. If you need LTS now, 26.04 is what you should be using. By 28.04, this should be rock solid.
For me what's risky here is deviating from what other distros are doing. Including Debian. Ubuntu has a history of being opinionated not everything they push through being adopted with great enthusiasm (e.g. Snap). You could make the point here that waiting for Debian to pick this up would be nicer. But you could also make the point that waiting for that is a very slow process.
ever used backports? no need to go to sid. Flatpack/Appimage/Compile from source for the rest (on my debian machine it's just kicad that is not installed from APT, well and the couple of softwares that don't do deb)
Firmwares, that's another story, i have fedora on the laptop for that.
> The problem comes when you have to use proprietary software made by incompetent vendors, and that only works in Ubuntu If i want to do FPGA development, either ubuntu or a distro old enough to package JDK 11 (sigh) and X. not XWayland. Debian 11 was the last one to have JDK 11 i think (talk about ancient..)
Needless to say FPGA is done on the windows machine these days.
Need a wider variety of people protecting Debian anyway, governance there is getting weird.
They worked pretty fine for decades, now, who needs these rewrites? Not saying it's useless, but in practice, what benefits did this bring?
[0]: https://fil-c.org/.
[1]: https://bannalia.blogspot.com/2025/11/comparing-run-time-per...
* Guaranteed to crash rather than potentially grant arbitrary code execution.
Or it could be you don't have the context like they did. Maybe some hardware bug/quirk that happens on some exotic machine that you don't have.
The current complaint is that they pick the worse one after at the current evaluation.