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 12 hours ago [-]
Fork Ubuntu and threaten their business model, that’ll get their attention.
Only half joking.
yjftsjthsd-h 12 hours ago [-]
Ubuntu is the fork; just use Debian.
jeltz 6 hours ago [-]
My solution was to stop using Ubuntu and move to Debian.
liamgm 4 hours ago [-]
And in that debian install rust unix coreutils as default
geokon 10 hours ago [-]
There's very little incentive to switch. When people release for Linux they almost always first/only test it works on Ubuntu - hence it's going to be the least buggy. (ex: GOG only seemingly tested games on Ubuntu)
So the switching cost is buggy software. You'd need something radically different that brings enough new features to the table to make it worth it the switch and dealing with bad/non-existant support.
I think something like Nix/Guix but with stable library versions that matches Ubuntu/Debian LTS ones 1-to-1 could get traction
4 hours ago [-]
pessimizer 6 hours ago [-]
Embrace the lock-in.
drdexebtjl 9 hours ago [-]
Then you would have to embrace their bad decisions, such as this one, and if you do, what’s the point?
Everything just needs to run from a container with their expected runtime environment.
tjoff 12 hours ago [-]
There are plenty of Ubuntu forks?
oefrha 9 hours ago [-]
This is certainly not just affecting interim releases. Ubuntu 26.04.1 has been released but is currently held back from do-release-upgrade for the LTS channel (which IIRC is unusual for a LTS's .1 release) due to rust-coreutils issue:
> Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS
via Update Manager a couple of weeks following this release after some planned
backports to address regressions in a recent version of rust-coreutils.
The apparently related bug in the origin project is https://github.com/uutils/coreutils/issues/2949, filed back in 2022 and which sat unmoved for several years until, probably not coincidentally, almost the same time yesterday that this appeared on Hacker News.
mort96 8 hours ago [-]
This is what made me move away from Ubuntu. Use LTS and encounter issues with outdated packages? "Well duh, you're supposed to upgrade to interim releases if you need remotely up to date software". Use interim releases and encounter bugs? "Well duh, it's an interim release. Of course it's a buggy mess, nobody uses those"
Every Fedora release is intended to be solid and they come out twice a year.
here_to_learn 5 hours ago [-]
I moved to Fedora from Ubuntu about a year ago for my laptop. My main motivation was not be defaulted to snap packages. I have had a great experience i.e it gets out of the way and it doesn't fall apart when I update stuff. I was worried about SELinux but find Fedoras defaults just fine and intuitive.
sick_of_slop 5 hours ago [-]
[dead]
LtWorf 12 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 1 days 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 1 days 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.
b112 8 hours ago [-]
Upstream for much is Debian, but of course Ubuntu forks from testing, and then modifies...
But if you can identify it as a bug in a version in Debian, that's a good place to file, as Ubuntu will get the fix eventually.
gdevenyi 8 hours ago [-]
Reporting bugs _at all_ in Ubuntu has never worked for me.
Perepiska 9 hours ago [-]
It can fail blazingly fast!
amelius 1 days ago [-]
Let them first fix Snap.
tjoff 13 hours ago [-]
There is no reason for anyone on any distro to use snap.
It will die so just leave it alone.
0x696C6961 18 hours ago [-]
They need to kill snap ...
LtWorf 12 hours 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.
zelphirkalt 11 hours ago [-]
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.
mrheosuper 10 hours ago [-]
why bother with ubuntu at all ? If you want ubuntu but without snap out of the box, Zorin is 1 option. Or if you also hate gnome, linux mint.
zelphirkalt 9 hours ago [-]
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.
9 hours ago [-]
IlikeMadison 9 hours ago [-]
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.
mhluongo 7 hours ago [-]
Both have performance issues when installed as snaps across my 24.04 and 26.04 machines.
LtWorf 3 hours ago [-]
I sandbox with firejail. There is no reason to use snaps. Also in firejail I never experienced a crash.
> never crashed a single time
I'm very happy for you. How does that help the people who do encounter issues?
fn-mote 7 hours ago [-]
> I haven't tried chromium but I presume it's the same issue
No issues with snap Chromium.
cute_boi 14 hours ago [-]
Yes, please. Linux distros is better with macos approach. And making appimage first class makes a lot of sense.
ChocolateGod 12 hours 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 12 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 11 hours 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.
novafunc 6 hours ago [-]
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.
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
petre 14 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 13 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.
tored 7 hours ago [-]
It is Year of the Linux Desktop, not Year of the Linux Cli.
nottorp 9 hours ago [-]
But this is totally not a memory ownership bug! It's some other kind of bug!
PunchyHamster 9 hours ago [-]
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
flossly 8 hours ago [-]
Ubuntu is free. But Canonical is for profit. In these cases "if you are not paying for the product, you are the product" applies.
Ubuntu users will test this. Once the problems are ironed out, other distros will follow.
froh 11 hours ago [-]
to enable GPL free embedded Ubuntu, field tested on all platforms (because it happens to be the default).
znpy 10 hours ago [-]
And that’s why i keep ubuntu far from my computers…
dark-star 1 days 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?
throw0101a 7 hours ago [-]
> But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?
When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?
It's less about the specific issue and more indicative of bad/insufficient test coverage
tosti 1 days ago [-]
What programmer or programming language can't iterate a loop more than 32000 times?!
Ygg2 1 days 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 12 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?".
Ygg2 6 hours ago [-]
> The point is that such bugs shouldn't exist in the first place.
That's true of every bug, but you don't have infinite time or manpower, so how do you prioritise?
BHSPitMonkey 12 hours 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?
dboreham 9 hours ago [-]
Fashion.
Ygg2 6 hours ago [-]
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.
IshKebab 1 days 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!
IshKebab 4 hours ago [-]
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.
tosti 1 days ago [-]
OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.
gpm 1 days 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 1 days 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 1 days 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 24 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 15 hours ago [-]
No algorithm requires tail-call elimination in a general-purpose language with imperative mutability. It's just another way to express iteration.
spider-mario 9 hours ago [-]
Sure, but mutual recursion might require `goto` for example. Or an explicit state machine.
clhodapp 9 hours ago [-]
I can see how it might require an explicit state machine (keep a mutable state number and switch over the inlined bodies of what could be functions), but I'm not seeing how it could require `goto`.
Are there more-complex relationships that might require it?
spider-mario 7 hours ago [-]
I meant it more in the sense that “you need one or the other” rather than “some cases require one and some other cases require the other”.
jmalicki 16 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 15 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 15 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.
gpm 7 hours ago [-]
Guaranteeing an optimization that otherwise only might run is a change in semantics. The attribute doesn't allow (in any sensible language) the code to simply not compile because the optimizer doesn't feel like it today (or you compiled with -O0), it forces the compiler to not allocate a stack frame wherever the code fits the structure that makes that definitely possible and fails to compile wherever it doesn't (even if after other optimization passes it happens to fit a structure that makes it possible).
shiomiru 10 hours ago [-]
I don't think that's related? The bug alluded to looks something like
function rm(node) {
for (const child of ls(node))
rm(child);
unlink(node);
}
and no amount of tail call optimization will save you here, because this isn't tail recursion. Of course you could rewrite it using an explicit stack + tail recursion, but then you might as well be using a while loop.
IshKebab 21 hours ago [-]
Do any widely used languages guarantee tail call optimization? It's a pretty niche feature.
gpm 21 hours ago [-]
Scala, ocaml, racket, clojure, zig.
For recursion only kotlin.
(For most of these only with syntax specifying it)
lioeters 5 hours ago [-]
How interesting. I'd seen LISP(y) implementations like Scheme guarantee tail-call since recursion is a very common technique in that language family. But I didn't know Zig supported it.
They have an @call built-in that guarantees: always/never tail, as well as always/never inline. That's neat, I can see how that would be useful in various situations.
8 hours ago [-]
pjmlp 4 hours ago [-]
Depends on how widely we consider Scheme and Raket adoption in CS curriculum.
hulitu 13 hours ago [-]
Rust ? Because of ... memory safety. /s
monegator 6 hours ago [-]
from a ground-up rewrite, in a memory safe language i expect at the very least
- A meaningful error
- not a segfault
secondcoming 1 days ago [-]
That way of thinking just means it'll never be fixed
abirch 1 days ago [-]
"The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it."
Linus Torvalds
dfox 1 days ago [-]
The problem there is that this is exactly the class of bug that does not exist in GNU coreutils because of philosophy of that project. Non-existence of such bugs proves that the impementation is not copied from AT&T code.
LtWorf 11 hours ago [-]
It's complicated to do it yourself when upstream won't accept your code.
7bit 1 days ago [-]
What approach would you suggest for priorisation of tickets?
secondcoming 1 days ago [-]
Ideally there should have been no tickets at all if all that's happening is a program being ported to another language.
gpm 1 days 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 1 days ago [-]
I have had to tell them repeatedly to stop copying tests verbatim, including the original comments from GNU coreutils. So I doubt this is true, which is frustrating.
leni536 10 hours ago [-]
What's wrong with them using the coreutils tests?
RichardLake 9 hours ago [-]
If they followed the license nothing. My uninformed knowledge is that the rust based rewrite is MIT, the originals are GPL, and you can't include GPL code in a MIT licensed project without making it GPL.
heinrich5991 9 hours ago [-]
But you should be able to use a GPL test suite on an MIT-licensed program (or even a proprietary one, without the program needing to be under the GPL.
leni536 9 hours ago [-]
> and you can't include GPL code in a MIT licensed project without making it GPL.
Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.
mrkdkirlwkfkf 15 hours ago [-]
Capitalism.
gpm 1 days 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)
IshKebab 1 days ago [-]
I mean, that should work... but you can see why that would be considered low priority right?
sick_of_slop 5 hours ago [-]
[dead]
lynx97 13 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."
HackerThemAll 8 hours ago [-]
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:/#
And then they plan to move to a new Rust-based NTP. No comment...
kd913 8 hours ago [-]
I wouldn’t judge the ntpd-rs move from this. Have been running it for 9 months or so with a nts pool in ntp server mode on my pi5. Been rock solid.
barbarkaragul 11 hours ago [-]
Hi, this is not a one bug.when the change app flags not working or not happening. I was measured with bsd and busybox.
linsomniac 6 hours ago [-]
Beware that rust coreutils on 26.04 currently has really bad performance with larger block sizes. Ganeti uses "dd bs=1M" as part of a disc image transfer pipeline, and with 26.04 performance dropped from ~350MB/sec to 30MB/sec, with the dd command CPU-bounded.
The issue seems to be that it is operating on partial buffers and then having to copy remainder of that 1M buffer around as part is consumed. Coreutils 0.11 solves that but 26.04 is at v0.8.
I've always used "bs=32k" because decades ago I did some testing and found that seemed to be large enough that it reduced the overhead while not being so large that it caused other problems, one of the most noticeable being scheduler issues where performance went into the toilet, especially on SD or USB thumb drives. Using this also seems to work better with rust coreutils dd.
torginus 30 minutes ago [-]
How can a command which was explicitly designed to do nothing but read and write disk become CPU bound?
dale_glass 5 hours ago [-]
Why are we still using dd?
Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.
dijit 5 hours ago [-]
I don’t know of a better tool that operates on raw blocks, maybe there is one.
`dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.
dale_glass 3 hours ago [-]
How about bmaptool? It can work on sparse images.
In general, I don't see the point in manually specifying block sizes most of the time. What I want nearly always the maximum performance, and that should be possible to derive from the hardware, and/or benchmarking.
What about uses like say, skipping data? seek= and skip= are in block sizes, that may not be ideal for performance.
A smart tool should be able to write in 1 MB blocks and yet still skip 512 bytes.
akdev1l 5 hours ago [-]
cp file.iso /dev/sda
WhyNotHugo 4 hours ago [-]
This isn't portable though, it's a GNU-specific "smart" things. Elsewhere, this overwrites the target device file.
akdev1l 3 hours ago [-]
How exactly is cp not portable?
Whatever behaviour you’re describing is not how POSIX mandates cp to work. In fact you can do this with busybox too.
cp will open("/dev/sda", O_WRONLY | O_TRUNC) and simply start writing to that file descriptor.
3 hours ago [-]
jasomill 4 hours ago [-]
Redirection doesn't overwrite device files, so
cat foo.img > /dev/sda
works and should be portable. No control over the buffer size, though.
ewy1 5 hours ago [-]
this works great but in my experience sometimes you should add
&& sync
not sure why it's necessary only sometimes!
rascul 5 hours ago [-]
The kernel has a cache used for block devices.
If you want to be more targeted:
blockdev --flushbufs /dev/sda
linsomniac 6 hours ago [-]
ProTip: You can switch back to Gnu coreutils on 26.04 with:
Just curious, why the 'sudo tee {file} > /dev/null'?
c0balt 5 hours ago [-]
it writes to the file with elevated priviledges and doesn't write it back to the terminal, effectively a 'sudo sh -c '{cmd} > {file}''.
sudo tee is a common way to work around priviledge restrictions in shell pipes (you can't easily 'sudo' a pipe), if /secure was 0600 and owned by root:
"sudo echo "test" > /secure" or "sudo printf '' > /secure", would not work because your user's shell process can't write to /secure. However, "echo 'test' | sudo tee /secure" works because the elevated 'sudo tee' can write to the file.
erminpour 12 hours 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.
senfiaj 9 hours ago [-]
>> Will this really make coreutils more secure?
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.
While the migration could be done more gradually, 26.10 is not an LTS release and is not considered stabe enough. The next LTS is 28.04, so I hope there is 1.5+ years for things to stabilize.
rshackleford1 2 hours ago [-]
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.
erminpour 2 hours ago [-]
Rusty Shackelford :D
aliceFish 5 hours ago [-]
new C++ STL standard makes it no more undefined.
senfiaj 5 hours ago [-]
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.
pjmlp 11 hours ago [-]
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++.
torginus 25 minutes ago [-]
Why does 'Ubuntu defaultism' still exist in the Linux world? Them replacing packages with shitty unworkable broken snap substitutes that can break the system when updating, and have a habit of reinstalling themselves...
pantalaimon 9 hours ago [-]
It removes a GPLv3 dependency that might stop some companies from adopting Ubuntu Core.
headsman771 7 hours ago [-]
Even more reason not to use it. Its clear that user freedom is under greater threat than it ever has been.
monegator 6 hours ago [-]
MIT License
Malakun 1 days 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.
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 12 hours 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.
LtWorf 7 hours ago [-]
This isn't the first issue with uutils.
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.
throw0101a 7 hours ago [-]
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).
LtWorf 4 hours ago [-]
That would work, but they also don't want everybody to switch to the better alternative and nullify their effort.
dwattttt 7 hours ago [-]
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.
Arcuru 1 days ago [-]
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 1 days 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.
pantalaimon 9 hours ago [-]
I think this is more about the licence, the Rust rewrite just makes it easier to swallow/gain contributors.
egorfine 1 days ago [-]
Same here. Love Rust. Hate rust rewrites.
pjmlp 11 hours ago [-]
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.
noosphr 12 hours ago [-]
The worst thing about rust are the people using it.
LtWorf 11 hours ago [-]
My impression is that go developers moved to rust.
pjmlp 11 hours ago [-]
I doubt it, as Rust approach to language design is the antithesis of Go's culture.
I would appreciate Go much more otherwise.
timcobb 7 hours ago [-]
> 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.
steveklabnik 5 hours ago [-]
The original authors of uutils do not particularly care about licensing, and the Rust ecosystem defaults to MIT/Apache2. So they chose that.
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.
As I have told the authors privately, I find it quite difficult to take their claim that they "don't care about licensing" seriously. 13/14 of the projects under uutils are relicensing GNU or GPL'd software. The other one, shadow-rs, is totally vibe-coded, and the README mistakenly says the original shadow is GNU software under the GPL, which is neither true. If 14/14 are relicensing, or in that one case, what is thought to be relicensing, the simple explanation is that it is an explicit goal of the project.
jeltz 6 hours ago [-]
> Are people saying that there's an ideology of pushing rust for things without concern for quality?
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.
timcobb 4 hours ago [-]
> 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?
pessimizer 6 hours ago [-]
Rewrite it in anything that isn't GPL.
timcobb 54 minutes ago [-]
With the motivation of then being able to use it in closed or non-GPL products down the line?
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
hermitShell 7 hours ago [-]
Manny comments I agree with - it's a mistake, it's a reason to leave the distro...
I'd like to point out that Ubuntu/Canonical is now seemingly philosophically separate from the origins of GNU and Linux. If you're curious, read "Hackers" by Stephen Levy. They've lost the plot, so to speak, about the core spirit of open software and hardware, which is what gave the projects life in the first place. A philosophical understanding and unity between many, many top notch independent developers.
Another note is how AI contributions to such libraries and programs is going to have an unknown effect on quality. It's almost like there's a business case to rip all the good FOSS written by humans out of the hands of github and apt, and curate all the best source code to ensure it remains in circulation, and extant copies are available that are not washed out by loose standards WRT AI contribs. Or if not a business case, perhaps a reasonable reaction and a good personal vendetta.
INTPenis 7 hours ago [-]
They should do like Solaris did and offer multiple different core tools in different paths, until they're up to par at least. It's not that complex of a workaround.
I don't use Ubuntu but this is huge, it's just as big as when FreeBSD switched to all BSD licensed user tools, I remember having to learn how tar worked again.
WatchDog 11 hours ago [-]
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..
* Guaranteed to crash rather than potentially grant arbitrary code execution.
quotemstr 11 hours ago [-]
"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.
logicchains 11 hours ago [-]
It's coreutils, there shouldn't be any threads to be data racing.
tcfhgj 10 hours ago [-]
Haven't threads been one of the reason some core util got faster?
collinfunk 10 hours ago [-]
Only GNU sort uses threads. There is still some room for improvement there, if anyone wants to take a shot at it. :)
zamadatix 3 hours ago [-]
I think I saw the Rust based implementations sometimes used a separate thread for background tasks like statistics reporting. Not much additional in the way of "directly" using threads, but I wonder how many could actually be any faster with direct threading.
t43562 5 hours ago [-]
I had a go at making an Ubuntu package recently - and to setup a PPA for it. That was a nightmare from hell that I gave up on (from ambiguous documentation, to 100s of how-tos that don't quite work for my case to making a package build in their system). To me it seems odd that coreutils is worth footling with when other problems seem to stand out to me.
Alien1Being 11 hours ago [-]
Ubuntu continues on it's quixotic mission to kill Linux...
1saadcodes 4 hours ago [-]
I'm struggling to see the upside of replacing working coreutils when the replacement still has bugs that the old implementation doesn't. Rust being safer is nice, but that doesn't help much if the new rm segfaults
hk1337 1 days 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 13 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.
Interestingly enough, young developers have no issues writing C or C++ when it comes to game development, Pebble, Arduino or ESP-32 coding.
nottorp 8 hours ago [-]
Those are more expensive!
pjmlp 8 hours ago [-]
Seriously doubt it, given that there is enough FOSS on those domains as well.
uecker 12 hours ago [-]
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.
4 hours ago [-]
collinfunk 10 hours ago [-]
Canonical hasn't contributed anything to GNU coreutils in the time since the switch was announced, just to be clear.
01HNNWZ0MV43FF 15 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 15 hours ago [-]
Once they have a more permissive license, cui bono?
pjmlp 12 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.
1718627440 4 hours ago [-]
> Arduino,... are not GPL based
Arduino is "just" repacked gcc in a nutshell, so it is GPL-based.
pjmlp 2 hours ago [-]
You need more than a compiler, so it is complicated, and not pure GPL,
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/).
gramakri2 8 hours ago [-]
We already had a problem with sudo-rs not handling all the options that previous sudo did. I am quite surprised sudo-rs is now the default even.
sehw 11 hours ago [-]
People still use ubuntu when Debian and Mint exist?
jcarrano 8 hours ago [-]
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.
jillesvangurp 7 hours ago [-]
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.
monegator 6 hours ago [-]
> Debian packages are ancient
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.
pjmlp 11 hours ago [-]
Yes, proprietary hardware support out of the box, and pre-installed option by the few OEMs that sell GNU/Linux computers.
PunchyHamster 9 hours ago [-]
My nvidia GPU worked just fine.
Debian has non-free repo you know...
pjmlp 9 hours ago [-]
I know how well it has worked in practice since the Walnut Creek CDROMs were a thing.
LtWorf 7 hours ago [-]
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.
spider-mario 7 hours ago [-]
How long ago was that? I tried Debian about 15-20 years ago and I don’t recall encountering that issue.
(The issue I do remember encountering was random kernel panics that I didn’t have with Ubuntu on the same machine.)
monegator 5 hours ago [-]
as soon as wifi became a widespread thing, you had to add the required package to the installer. It stopped being an issue with bookworm
LtWorf 2 hours ago [-]
Got to love this website :D Downvoted for completely true information with no ideological spin :D :D :D
Brendinooo 8 hours ago [-]
Why would I switch off of Ubuntu? It's what came with my system.
pessimizer 6 hours ago [-]
Mint is downstream from Ubuntu still afaik. They had/have LMDE as an escape hatch, maybe they should pull the ripcord (to mix metaphors.)
Need a wider variety of people protecting Debian anyway, governance there is getting weird.
LtWorf 11 hours ago [-]
The power of marketing…
Ubuntu does offer some certifications but only for paying customers, so everyone else should really steer clear.
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.
swiftcoder 5 hours ago [-]
the uutils project bills themselves as a drop-in replacement for coreutils. sudo-rs does not bill itself as a drop-in replacement for sudo
hwc 5 hours ago [-]
I had no idea they were doing this; good for them!
1. What fraction of the core OS can be switched over? Can they oxidize systemd?
2. Are other distros going to switch over (e.g. Debian, which I think of as the ur-distro)?
SubiculumCode 13 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.
uecker 12 hours ago [-]
Maybe we could develop trustworthy free-software applications again, instead of trying to establish a commercial apps ecosystem on top of Linux?
pjmlp 4 hours ago [-]
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.
bayindirh 12 hours 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.
1718627440 4 hours ago [-]
This is actually already required to be supported by complying to the FHS.
hexfish 11 hours ago [-]
AppImage is not a sandbox
whatsakandr 7 hours ago [-]
They could just compile the core utils with fil C and call it a day.
rurban 4 hours ago [-]
How can you undo that. Is `sudo apt install coreutils` enough?
lrvick 6 hours ago [-]
Meanwhile I just booted stagex on AWS without any C code at all other than the kernel and libc.
In a dev branch we now have rust ssh, dhcp, init, job management, etc. Rust all the things. Very soon will be able to swap the kernel for Asterinas and drop the last couple libc dependencies to have a complete rust OS that is Linux binary compatible.
I wonder how many other distros will rustmax.
Surac 12 hours ago [-]
Other distros are based of ununtu. Will the all ship with crippled coreutils from now on?
suby 11 hours ago [-]
Linux Mint mentioned on their blog that they would be using the Rust versions.
dsign 15 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.
overfeed 11 hours ago [-]
on the other hand, Rust is memory safe!
rurban 3 hours ago [-]
Almost, but not really
someothherguyy 14 hours ago [-]
then install the other tool. no one is holding a gun to your head. it isn't windows.
nairboon 13 hours ago [-]
Like how one can easily not use snap on Ubuntu? /s
12 hours ago [-]
pessimizer 6 hours ago [-]
Next step, make them subtly incompatible with gnutils. Then make them a Ubuntu dependency, then a systemd/Gnome dependency. Then take Ubuntu closed source. Success, suckers!
arjie 13 hours ago [-]
Everything online reminds of when Ubuntu switched to dash for init scripts or something. Good times.
18Deepnar 8 hours ago [-]
how helpful is it for it to be transitioned to rust, how does it help?
grougnax 12 hours ago [-]
Can’t wait for the whole Rust rewrite of Linux!
atoav 11 hours ago [-]
I would be very curious about a bit more concrete and substential criticism what is bad (or good) about how the both versions, that goes beyond general arguments like:
Just because it is Rust, it is not safe!
It worked before, don't replace it!
etc.
Not that these are not valid points of criticism, but in my opinion if we have two core utils we can (and should) pick the better one after careful continous evaluation. And if the old one is the better one on the day of the release, so be it. Having two competing solutions can have benefits for everybody looking for the best core utils they can get in the long run.
I had to reimplement and reverse engineer old tech myself as part of my dayjob and had those engineers seen my results it probably would have improved their work as well, since I usually found oddities that they probably did not intend to be that way. This means my work on their work could be seen as another pair of eyeballs, bullet-proofing their original work, instead of seeing me as a threat. That additional pair of eyeballs is crucial to open source software.
This is why it is sad that too much about this whole discussion feels like yet another culture war, heated on the stove of social media figures looking to convert heat into ad revenue.
Which is why I would love to have more concrete points of technical criticism of specific bits maybe even to specific lines in the code or specific reproducable behavior.
If we go the culture-war route nobody wins, if we discuss both solutions on their merits, we all can win.
1718627440 4 hours ago [-]
> we can (and should) pick the better one after careful continous evaluation
The current complaint is that they pick the worse one after at the current evaluation.
rcxdude 9 hours ago [-]
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).
mrheosuper 9 hours ago [-]
> since I usually found oddities that they probably did not intend to be that way.
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.
nalekberov 11 hours ago [-]
If you ask their motivation? "We want to make them safer"
They worked pretty fine for decades, now, who needs these rewrites?
Not saying it's useless, but in practice, what benefits did this bring?
froh 11 hours ago [-]
it's GPL free. which is good for embedded, the business side of it. like cars.
rwmj 11 hours ago [-]
Good for car manufacturers, not necessarily for cars or their owners. As a car owner I quite like manufacturers to be forced to produce source code.
LtWorf 7 hours ago [-]
Car manufacturers really really hate GPLv3 and the requirement that users need to be able to change the code.
They claim it is for compliance but it's well known that user modifications to cars are no longer the responsibility of the car company. I think it's more on principle than any real legal concern.
justincormack 11 hours ago [-]
The kernel is still GPL
rcxdude 9 hours ago [-]
but GPLv2
ramon156 8 hours ago [-]
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.
6031769 7 hours ago [-]
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.
synergy20 5 hours ago [-]
one more reason back to Debian
forest_brothers 5 hours ago [-]
[dead]
goodpoint 1 days ago [-]
[flagged]
phendrenad2 1 days ago [-]
[flagged]
mid-kid 1 days 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 1 days 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 1 days ago [-]
Yeah, shouldn't have called it legacy, perhaps OG would have been more appropriate.
egorfine 1 days 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 14 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 1 days ago [-]
> Ubuntu devs has been nothing good FOSS
Did you mean nothing "but" good?
teekert 1 days ago [-]
Yes, sorry and thanx, I played a bit with the sentence, not happy with the first thing I submitted -> Corrected now.
goodpoint 1 days ago [-]
"nothing good" is more accurate
testdelacc1 1 days 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 1 days ago [-]
Probably true, but the direction Linux is going these days is concerning
bigfishrunning 1 days 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 1 days 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_ 1 days ago [-]
Care to elaborate?
amiga386 1 days ago [-]
GPL -> MIT
skrtskrt 1 days ago [-]
Does this actually matter that much for some tools when the kernel is GPL?
amiga386 1 days 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 19 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 1 days 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 24 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 19 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 17 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.
qwj18 1 days 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 1 days ago [-]
Netcraft may confirm that some day
germandiago 1 days 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 24 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 19 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.
LtWorf 7 hours ago [-]
People don't use Xorg daily because they are afraid of wayland. People use Xorg daily because they have tried wayland and there was something that stopped working.
Xorg allows running sub-instances.
Wayland is now older than Xorg was when "it was really old, we need something new".
testdelacc1 1 days 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 1 days 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!
1 days ago [-]
blastonico 1 days ago [-]
[flagged]
theandrewbailey 1 days 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 1 days ago [-]
Or just use Arch, and skip the pointless hype squad
wojciii 1 days ago [-]
Funny .. Arch started growing on me.
sesm 8 hours ago [-]
SteamOS switched from Debian to Arch for a reason.
rvz 1 days ago [-]
Or Pop!_OS that does not vibe slop their distro.
tuananh 1 days ago [-]
you are being sarcastic right?
bithammerthunde 1 days ago [-]
[flagged]
dralley 1 days ago [-]
The project was started long before LLMs existed.
perarneng 1 days ago [-]
[flagged]
stouset 1 days 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 1 days 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 21 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 20 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 18 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.
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.
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.
So the switching cost is buggy software. You'd need something radically different that brings enough new features to the table to make it worth it the switch and dealing with bad/non-existant support.
I think something like Nix/Guix but with stable library versions that matches Ubuntu/Debian LTS ones 1-to-1 could get traction
Everything just needs to run from a container with their expected runtime environment.
> Users of Ubuntu 24.04 LTS will be offered an automatic upgrade to 26.04.1 LTS via Update Manager a couple of weeks following this release after some planned backports to address regressions in a recent version of rust-coreutils.
https://discourse.ubuntu.com/t/ubuntu-26-04-1-lts-released/8...
The apparently related bug in the origin project is https://github.com/uutils/coreutils/issues/2949, filed back in 2022 and which sat unmoved for several years until, probably not coincidentally, almost the same time yesterday that this appeared on Hacker News.
Every Fedora release is intended to be solid and they come out twice a year.
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.
But if you can identify it as a bug in a version in Debian, that's a good place to file, as Ubuntu will get the fix eventually.
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.
> 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.
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.
See: https://pkgforge-dev.github.io/Anylinux-AppImages/
IIRC Snap relies heavily on AppArmor for sandboxing, so on anything non-Ubuntu the sandboxing is non-existent.
Ubuntu users will test this. Once the problems are ironed out, other distros will follow.
When the GNU coreutils version doesn't have this bug and thus affects zero users, why should I bother with the Rust version?
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?
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.
[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.
Are there more-complex relationships that might require 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.
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)
https://ziglang.org/documentation/master/#call
They have an @call built-in that guarantees: always/never tail, as well as always/never inline. That's neat, I can see how that would be useful in various situations.
- A meaningful error
- not a segfault
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.
Why is that? The tests are not linked to the distributed binaries. You can also distribute project sources with mixed licenses.
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)
The issue seems to be that it is operating on partial buffers and then having to copy remainder of that 1M buffer around as part is consumed. Coreutils 0.11 solves that but 26.04 is at v0.8.
I've always used "bs=32k" because decades ago I did some testing and found that seemed to be large enough that it reduced the overhead while not being so large that it caused other problems, one of the most noticeable being scheduler issues where performance went into the toilet, especially on SD or USB thumb drives. Using this also seems to work better with rust coreutils dd.
Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.
`dd` is a real power user command, I’d prefer that it isn’t doing “intelligent” things, especially not by default.
In general, I don't see the point in manually specifying block sizes most of the time. What I want nearly always the maximum performance, and that should be possible to derive from the hardware, and/or benchmarking.
What about uses like say, skipping data? seek= and skip= are in block sizes, that may not be ideal for performance.
A smart tool should be able to write in 1 MB blocks and yet still skip 512 bytes.
Whatever behaviour you’re describing is not how POSIX mandates cp to work. In fact you can do this with busybox too.
cp will open("/dev/sda", O_WRONLY | O_TRUNC) and simply start writing to that file descriptor.
If you want to be more targeted:
apt install coreutils-from-gnu coreutils-from-uutils- --allow-remove-essential
And pin it so an upgrade doesn't flip it back with:
printf 'Package: coreutils-from-uutils\nPin: release a=*\nPin-Priority: -10\n' \ | sudo tee /etc/apt/preferences.d/uutils > /dev/null
sudo tee is a common way to work around priviledge restrictions in shell pipes (you can't easily 'sudo' a pipe), if /secure was 0600 and owned by root:
"sudo echo "test" > /secure" or "sudo printf '' > /secure", would not work because your user's shell process can't write to /secure. However, "echo 'test' | sudo tee /secure" works because the elevated 'sudo tee' can write to the file.
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.
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.
While the migration could be done more gradually, 26.10 is not an LTS release and is not considered stabe enough. The next LTS is 28.04, so I hope there is 1.5+ years for things to stabilize.
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++.
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.
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?
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.
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.
[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.
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.
I would appreciate Go much more otherwise.
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.
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, for Ubuntu's take on this: https://news.ycombinator.com/item?id=49707948
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?
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:
You weren't kidding: it was exactly 4 years ago ("September 13, 2022").
I'd like to point out that Ubuntu/Canonical is now seemingly philosophically separate from the origins of GNU and Linux. If you're curious, read "Hackers" by Stephen Levy. They've lost the plot, so to speak, about the core spirit of open software and hardware, which is what gave the projects life in the first place. A philosophical understanding and unity between many, many top notch independent developers.
Another note is how AI contributions to such libraries and programs is going to have an unknown effect on quality. It's almost like there's a business case to rip all the good FOSS written by humans out of the hands of github and apt, and curate all the best source code to ensure it remains in circulation, and extant copies are available that are not washed out by loose standards WRT AI contribs. Or if not a business case, perhaps a reasonable reaction and a good personal vendetta.
I don't use Ubuntu but this is huge, it's just as big as when FreeBSD switched to all BSD licensed user tools, I remember having to learn how tar worked again.
[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.
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.
Arduino is "just" repacked gcc in a nutshell, so it is GPL-based.
https://support.arduino.cc/hc/en-us/articles/4415094490770-L...
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.
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.
(The issue I do remember encountering was random kernel panics that I didn’t have with Ubuntu on the same machine.)
Need a wider variety of people protecting Debian anyway, governance there is getting weird.
Ubuntu does offer some certifications but only for paying customers, so everyone else should really steer clear.
https://github.com/trifectatechfoundation/sudo-rs#difference...
1. What fraction of the core OS can be switched over? Can they oxidize systemd?
2. Are other distros going to switch over (e.g. Debian, which I think of as the ur-distro)?
One systemd patch at a time.
In a dev branch we now have rust ssh, dhcp, init, job management, etc. Rust all the things. Very soon will be able to swap the kernel for Asterinas and drop the last couple libc dependencies to have a complete rust OS that is Linux binary compatible.
I wonder how many other distros will rustmax.
I had to reimplement and reverse engineer old tech myself as part of my dayjob and had those engineers seen my results it probably would have improved their work as well, since I usually found oddities that they probably did not intend to be that way. This means my work on their work could be seen as another pair of eyeballs, bullet-proofing their original work, instead of seeing me as a threat. That additional pair of eyeballs is crucial to open source software.
This is why it is sad that too much about this whole discussion feels like yet another culture war, heated on the stove of social media figures looking to convert heat into ad revenue.
Which is why I would love to have more concrete points of technical criticism of specific bits maybe even to specific lines in the code or specific reproducable behavior.
If we go the culture-war route nobody wins, if we discuss both solutions on their merits, we all can win.
The current complaint is that they pick the worse one after at the current evaluation.
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.
They worked pretty fine for decades, now, who needs these rewrites? Not saying it's useless, but in practice, what benefits did this bring?
They claim it is for compliance but it's well known that user modifications to cars are no longer the responsibility of the car company. I think it's more on principle than any real legal concern.
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.
Xorg allows running sub-instances.
Wayland is now older than Xorg was when "it was really old, we need something new".
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...