just_another_person@lemmy.world
on 26 Sep 17:34
nextcollapse
Durrrrrr
thingsiplay@beehaw.org
on 26 Sep 17:36
nextcollapse
It’s expected, because the tools are still in development and have not reached 100% test covered yet. Ubuntu 25.10 is not a long term version, so ideal for real world testing. But now we can expect copy-pasta ai blog posts all over the place. And personal attacks against the programming language itself.
Btw for me persona problem of this replacement is only license switching from strong copy left to permissive, I don’t really like this trend it smells really bad from what corps actuality like more nowadays as fear as fire gpl.I don’t know who exactly staying behind rust coreutils but devs just ignore all request about GPL or responding very cold or find any other stupid excuse like they don’t wanna deal with it. At least they could give their direct point of their views and their motivation about it.but still will not support MIT licence as for main tools for importan core of system
That’s a pretty big problem, I couldn’t care less about the language. But stepping away from GPL is not good at all.
lol@discuss.tchncs.de
on 26 Sep 18:30
nextcollapse
for me persona problem of this replacement is only license switching from strong copy left to permissive
Why does it matter to you? If the developers are fine with the license and how the code they write can be used under it, that’s their prerogative. You don’t lose anything if some company also uses those programs.
I don’t know who exactly staying behind rust coreutils but devs just ignore all request about GPL
What are you expecting them to say? “That’s the license we chose for this thing we’re allowing you to use for free. Use it or don’t, we don’t care”? They have no obligation to justify themselves to you.
will not support MIT licence as for main tools for importan core of system
What do you mean by support? Would be be donating money to the developers if the license was different? The developers don’t get anything from you using their code.
axum@lemmy.blahaj.zone
on 26 Sep 19:32
nextcollapse
I understand the sentiment.
The move to a permissive license opens the door for these tools to possibly become closed source one day.
custard_swollower@lemmy.world
on 27 Sep 09:28
nextcollapse
You know that you can change license of software that you own copyright to? You can take GPL code and change it to something else, but you can’t un-GPL existing released code. It’s the same thing with MIT.
The only people bound by the license are people who use it because it is licensed to them.
The difference is that organisation may develop MIT software without publishing their code.
Why is that a problem if the developers are apparently fine with it?
Everyone can still use the open source version/fork. It could only become a problem if distributions for some reason decided to use that closed source version, which doesn’t make any sense.
I fail to see a worst case scenario here beyond companies being able to profit from the software as well.
Why does it matter to you? If the developers are fine with the license and how the code they write can be used under it, that’s their prerogative.
That’s a bit short-sighted. On the level of the individual project you are right, it’s the dev’s choice. And I think permissive licenses also have a place with security critical software like crypto libraries, where everyone benefits from secure libraries being used as much as possible, even in proprietary software.
But on an ecosystem level, this trend to permissive licensing is very worrying, because if it reaches a critical mass, it opens us up to EEE scenarios. Android is already bad enough, only made bearable by Google having to release much of the source code. Imagine what it would be like today if Google had succeeded with their Fuchsia efforts. So we should at least be wary and give a little pushback to this trend. It’s valid to question if everything under the sun has to be rewritten and if it does, why does it have to be permissive licensing? What’s the end goal?
Maybe I’m missing something, but I’m not sure what the worst case scenario is… like, is some company going to get rich off of their proprietary cp and sudo implementation that they forked off of an open one?
It’s one thing when a company gets the benefits of people’s contributions and doesn’t give back (in the form of source code when they build upon it and at the time they offer binary files). If a company wants to do the work themselves… well now they don’t have too.
GPL promoters typically value software freedom, and may believe it’s generally bad for society when software is proprietary. I don’t know what coreutlis does but I doubt there’s a thoughtful reason to choose MIT license for a clone.
Apple is ok with GPLv2 Bash. Linux kernel is GPLv2, GNU coreutils are GPLv3. Systemd is curiosly also GPLv2. Striping GNU out of GNU/Linux might not be so innocent.
25.10 isn’t on the main upgrade path. Serious users migrate to the new LTS every two years, and very serious users pay for the twelve-year support plan.
Why would something that hasn’t reached sufficient test coverage, or that fails one of the most common test suites around, be put into one of the largest distros around, lts version or not? It’s honestly ridiculous
Every six months between LTS versions, Canonical publishes an interim release of Ubuntu, with 25.04 being the latest example. These are production-quality releases and are supported for 9 months, with sufficient time provided for users to update, but these releases do not receive the long-term commitment of LTS releases.
Key words “production quality”. This sure doesn’t seem “production quality” to me.
thingsiplay@beehaw.org
on 26 Sep 20:24
nextcollapse
A test and benchmark suite from Phoronix is not production. Canonical tested software before in short term supported versions, before they include it in long term. And there was occasions when they reverted back. Production quality is a vague term. Compared to daily development releases, the interim releases are production quality.
I am not defending mistakes, I am setting expectations.
A test suite from phoronix having issues is certainly enough of a canary in the coalmine that this stuff is not ready for showtime. You have been saying that non-lts ubuntu releases are basically unstable releases but that has never been the intent and is not even what they say.
The non-LTS versions are unstable by definition and that’s the goal; to be unstable. And no, I am not talking about buggy stability type, but more like “unchanging, reliable”. In example changing Wayland by default or back then from Unity to GNOME 3 would only happen in a non-LTS version, because that is a huge change and need to be “tested” before LTS commitment. That does not mean Canonical doesn’t care about quality, but that is not the biggest goal with the in between releases. Its like Beta, a current snapshot of the development.
Canonical can state what they want, the history, actions and results are what is important. What do you think is the reason Canonical does the non LTS releases?
There’s still a few weeks until 25.10 releases. If its still issues by release time I’m sure that they’ll either delay the 25.10 release (as they have done in the past) or pause the coreutils-rs rollout and stick to GNU Coreutils for this release.
Yes you’re must likely correct. I was simply pushing back on the other poster talking like ubuntu releases other than lts are unstable/testing releases. They are intended to be stable and usable, which is certainly not the case if they include the core utils replacement as it currently stands.
_edge@discuss.tchncs.de
on 26 Sep 23:13
nextcollapse
We shall hope so.
A few tests failing in beta, when this can be fixed before the release, is hardly newsworthy.
However it leaves a bad taste to even consider replacing coreutils when it’s nur clear that the replacement is rock solid. Those commands are used in millions of shell scripts distributed alongside applications. Should coreutils break, we’d learn the hard way.
Furthermore, 25.10 is a short-term release that exists as a preview for 26.04. 25.10 will receive security patches for nine months. 26.04, as an LTS, will receive security patches for up to 12 years (most of which are paid). Nobody should be seriously migrating to 25.10.
If coreutils-rs does get into the official release of 25.10 and totally tanks it, well, that’s what short-term releases are for.
No… This revisionism to defend canonical is nonsense. LTS releases don’t promise the most recent releases of software, but they promise security and stability updates for longer, so they are more suitable for servers and users who don’t want to worry about breaking changes often.
That’s it. The releases between Long Term SERVICE releases are production ready and not testing releases. They are recommended for most people.
PseudoSpock@lemmy.dbzer0.com
on 26 Sep 18:51
nextcollapse
I warned ya. Rust folks never make a true 1:1 replacement. They have to tweek it. Always.
trevor@lemmy.blahaj.zone
on 26 Sep 19:34
nextcollapse
This type of comment is indistinguishable from the low-tier, rage bait comments under every Phoronix article.
PseudoSpock@lemmy.dbzer0.com
on 26 Sep 20:44
collapse
This isn’t a rage bait comment. Show me one Rust tool replacement made that didn’t alter functionality in some way, causing edge cases, and sometimes even mainline usage, to break and scripts have to be written to accommodate. I’ve not seen it yet. If you have, I will gladly stand corrected. The language is great, it’s the programmers at issue.
axum@lemmy.blahaj.zone
on 26 Sep 19:34
nextcollapse
This is such bad take only because it singles out rust for some weird reason. Tool total rewrites take work regardless of language
PseudoSpock@lemmy.dbzer0.com
on 26 Sep 20:42
nextcollapse
Oh, it’s not the language. It’s the type of people who not only like Rust, but have a compulsion / need / fixation on re-writing existing tools. They say it’s so it’s more secure, but honestly it’s so they can apply their own opinions of how the tool should be. They always promise to make it a drop in replacement, but then then get rid of options, or change what they do… they can’t help themselves. And that is the kind of people who volunteer to port tools to Rust. If they would stick to true 1:1 replacement, this wouldn’t be an issue.
Are there other types of people? Writing software to be bug-for-bug compatible with something else is really difficult and, yes, not fun at all. You will not find many people looking to volunteer for that…
I like tool rewrites. But fixing major issues just before it is used in so many systems? It’s irresponsible.
It should of been given more time to mature.
And Ubuntu is used so much, even the odd versions of it, that if one thing goes wrong later; this will cause a lot of bad press for both Rust and Ubuntu.
It should make the rust community very nervous. So many companies use the Ubuntu:latest tag in so many projects. And millions of people will hear, after being subject to the breakages, that it was all about Rust. Even though it’s not about Rust, just bad management
LeFantome@programming.dev
on 27 Sep 17:38
collapse
I mostly agree.
However, Ubuntu clearly sees 24.10 as the test bed for 25.04 and this is how they get the software tested. That is up to them.
I think also that, if you make a change this big, and only a couple of minor bugs are found and fixed before release, you are in pretty good shape.
And if all bugs are fixed this fast, even bugs found after release may impact only a few.
They have provided a mechanism to use the old utils if you want to be more conservative. Given that, I do not find this “irresponsible”.
There are probably bigger bugs elsewhere in 24.10 right now that will be harder to mitigate.
LeFantome@programming.dev
on 27 Sep 16:35
collapse
It has not even released yet.
Is your claim that non-Rust software gets written and runs perfectly without bugs the first time it is run, never requiring you to “tweek it”? That does not seem strongly evidence based. I assume by tweek, you mean tweak.
Also, they fixed this bug before this story, and your well researched comment, even appeared. The same thing happened just a few days ago when a similar “performance” bug was found. An entire chorus of idiots, including some prominent YouTubers, proudly proclaimed “I warned ya” for that one as well. Many predicting Ubuntu would need to be delayed or that people would be switching to other distros. Of course, the Rust version was already 50% faster than the C version by then and it was still weeks before the release date. Those comments did not age well.
And here we are again.
If you were trying to sound smart, it did not work.
corsicanguppy@lemmy.ca
on 26 Sep 20:05
nextcollapse
LeFantome@programming.dev
on 27 Sep 03:09
collapse
GNU is really its own thing and not reallyPOSIX anymore. So GNU is right even if they are wrong.
This is not me advocating for GNU. I use BSD utils myself.
On this issue, your were right in a way. My understanding is that the uutils version of dd was respecting the fullblock parameter, causing problems on slow pipes. GNU ignore this and was doing partial writes. Uutils has been modified to match GNU and is “working” now. At least, a tested patch has been submitted.
In both these cases, dd serves no real purpose. It’s purely a superstitious charm trying to ensure safe passage of the data. You can see how silly this is when you replace dd with the functionally equivalent cat: cat /dev/sda | pv | cat > /dev/sdb
😂
cornshark@lemmy.world
on 27 Sep 00:00
nextcollapse
LeFantome@programming.dev
on 27 Sep 04:27
collapse
And……fixed.
A few days ago we had a “performance” bug. Before the stories had even been written, the uutils was made 50% faster than GNU.
Now we have an actual difference in behaviour. But it is again fixed before the stories could even go out.
The anti-Rust crew is really trying to celebrate hear but it seems like uutils is proving them wrong so far.
We will see what happens in production I suppose.
WhyJiffie@sh.itjust.works
on 27 Sep 13:39
collapse
I don’t think it’s anti-Rust. I like Rust. I don’t like the uutils license.
snikta@programming.dev
on 27 Sep 07:24
nextcollapse
New non-copyleft Rust implementation. While we’re at it, let’s throw in some blockchain and AI as well. The eccentric South African billionaire CEO will be pleased.
savvywolf@pawb.social
on 27 Sep 08:49
nextcollapse
I’m willing to bet that if the GNU coreutils getting bumped a minor version caused widespread issues for a day, nobody would even bother reporting in it…
Magnum@lemmy.dbzer0.com
on 27 Sep 09:15
nextcollapse
Minor releases aren’t beta. By any convention they should be fully tested, final releases. And if gnu core utils broke systems in a minor release you better believe it would make it to some news.
The instability of choosing a beta software for the literal core of your operating system is kind of the point.
threaded - newest
Durrrrrr
It’s expected, because the tools are still in development and have not reached 100% test covered yet. Ubuntu 25.10 is not a long term version, so ideal for real world testing. But now we can expect copy-pasta ai blog posts all over the place. And personal attacks against the programming language itself.
Btw for me persona problem of this replacement is only license switching from strong copy left to permissive, I don’t really like this trend it smells really bad from what corps actuality like more nowadays as fear as fire gpl.I don’t know who exactly staying behind rust coreutils but devs just ignore all request about GPL or responding very cold or find any other stupid excuse like they don’t wanna deal with it. At least they could give their direct point of their views and their motivation about it.but still will not support MIT licence as for main tools for importan core of system
That’s a pretty big problem, I couldn’t care less about the language. But stepping away from GPL is not good at all.
Why does it matter to you? If the developers are fine with the license and how the code they write can be used under it, that’s their prerogative. You don’t lose anything if some company also uses those programs.
What are you expecting them to say? “That’s the license we chose for this thing we’re allowing you to use for free. Use it or don’t, we don’t care”? They have no obligation to justify themselves to you.
What do you mean by support? Would be be donating money to the developers if the license was different? The developers don’t get anything from you using their code.
I understand the sentiment.
The move to a permissive license opens the door for these tools to possibly become closed source one day.
You know that you can change license of software that you own copyright to? You can take GPL code and change it to something else, but you can’t un-GPL existing released code. It’s the same thing with MIT.
The only people bound by the license are people who use it because it is licensed to them.
The difference is that organisation may develop MIT software without publishing their code.
Why is that a problem if the developers are apparently fine with it?
Everyone can still use the open source version/fork. It could only become a problem if distributions for some reason decided to use that closed source version, which doesn’t make any sense.
I fail to see a worst case scenario here beyond companies being able to profit from the software as well.
That’s just it though. The developers can drop out over time, then some other corp can come in and control it, then close source it.
That’s a bit short-sighted. On the level of the individual project you are right, it’s the dev’s choice. And I think permissive licenses also have a place with security critical software like crypto libraries, where everyone benefits from secure libraries being used as much as possible, even in proprietary software.
But on an ecosystem level, this trend to permissive licensing is very worrying, because if it reaches a critical mass, it opens us up to EEE scenarios. Android is already bad enough, only made bearable by Google having to release much of the source code. Imagine what it would be like today if Google had succeeded with their Fuchsia efforts. So we should at least be wary and give a little pushback to this trend. It’s valid to question if everything under the sun has to be rewritten and if it does, why does it have to be permissive licensing? What’s the end goal?
Maybe I’m missing something, but I’m not sure what the worst case scenario is… like, is some company going to get rich off of their proprietary
cpandsudoimplementation that they forked off of an open one?It’s one thing when a company gets the benefits of people’s contributions and doesn’t give back (in the form of source code when they build upon it and at the time they offer binary files). If a company wants to do the work themselves… well now they don’t have too.
GPL promoters typically value software freedom, and may believe it’s generally bad for society when software is proprietary. I don’t know what coreutlis does but I doubt there’s a thoughtful reason to choose MIT license for a clone.
Apple is ok with GPLv2 Bash. Linux kernel is GPLv2, GNU coreutils are GPLv3. Systemd is curiosly also GPLv2. Striping GNU out of GNU/Linux might not be so innocent.
This is what it’s all about. We all know this.
Sure, but everybody is aware that roughly 30% of the Internet run on
ubuntu:latestand well, that will move to 25.10 soon.And yes, nobody should do this, using a latest tag for docker builds, but everybody does it … So …
25.10 isn’t on the main upgrade path. Serious users migrate to the new LTS every two years, and very serious users pay for the twelve-year support plan.
Why would something that hasn’t reached sufficient test coverage, or that fails one of the most common test suites around, be put into one of the largest distros around, lts version or not? It’s honestly ridiculous
To test it. That’s the whole reason why the 6 months releases between the LTS releases in Ubuntu exists.
ubuntu.com/about/release-cycle
Key words “production quality”. This sure doesn’t seem “production quality” to me.
A test and benchmark suite from Phoronix is not production. Canonical tested software before in short term supported versions, before they include it in long term. And there was occasions when they reverted back. Production quality is a vague term. Compared to daily development releases, the interim releases are production quality.
I am not defending mistakes, I am setting expectations.
A test suite from phoronix having issues is certainly enough of a canary in the coalmine that this stuff is not ready for showtime. You have been saying that non-lts ubuntu releases are basically unstable releases but that has never been the intent and is not even what they say.
The non-LTS versions are unstable by definition and that’s the goal; to be unstable. And no, I am not talking about buggy stability type, but more like “unchanging, reliable”. In example changing Wayland by default or back then from Unity to GNOME 3 would only happen in a non-LTS version, because that is a huge change and need to be “tested” before LTS commitment. That does not mean Canonical doesn’t care about quality, but that is not the biggest goal with the in between releases. Its like Beta, a current snapshot of the development.
Canonical can state what they want, the history, actions and results are what is important. What do you think is the reason Canonical does the non LTS releases?
There’s still a few weeks until 25.10 releases. If its still issues by release time I’m sure that they’ll either delay the 25.10 release (as they have done in the past) or pause the
coreutils-rsrollout and stick to GNU Coreutils for this release.Yes you’re must likely correct. I was simply pushing back on the other poster talking like ubuntu releases other than lts are unstable/testing releases. They are intended to be stable and usable, which is certainly not the case if they include the core utils replacement as it currently stands.
We shall hope so.
A few tests failing in beta, when this can be fixed before the release, is hardly newsworthy.
However it leaves a bad taste to even consider replacing coreutils when it’s nur clear that the replacement is rock solid. Those commands are used in millions of shell scripts distributed alongside applications. Should coreutils break, we’d learn the hard way.
Furthermore, 25.10 is a short-term release that exists as a preview for 26.04. 25.10 will receive security patches for nine months. 26.04, as an LTS, will receive security patches for up to 12 years (most of which are paid). Nobody should be seriously migrating to 25.10.
If coreutils-rs does get into the official release of 25.10 and totally tanks it, well, that’s what short-term releases are for.
No… This revisionism to defend canonical is nonsense. LTS releases don’t promise the most recent releases of software, but they promise security and stability updates for longer, so they are more suitable for servers and users who don’t want to worry about breaking changes often.
That’s it. The releases between Long Term SERVICE releases are production ready and not testing releases. They are recommended for most people.
Damn bruh, I didn’t know that too.
New software has bugs??
Glad to see someone’s working the bugs out.
Silksong has tons of bugs.
If you rely on a bug, it becomes a feature.
Dude, they feature a main bug to kill off all those other bugs.
<img alt="" src="https://lemmy.ml/pictrs/image/a92c9d09-3714-43f2-800d-a5baa3700d79.jpeg">
I warned ya. Rust folks never make a true 1:1 replacement. They have to tweek it. Always.
This type of comment is indistinguishable from the low-tier, rage bait comments under every Phoronix article.
This isn’t a rage bait comment. Show me one Rust tool replacement made that didn’t alter functionality in some way, causing edge cases, and sometimes even mainline usage, to break and scripts have to be written to accommodate. I’ve not seen it yet. If you have, I will gladly stand corrected. The language is great, it’s the programmers at issue.
This is such bad take only because it singles out rust for some weird reason. Tool total rewrites take work regardless of language
Oh, it’s not the language. It’s the type of people who not only like Rust, but have a compulsion / need / fixation on re-writing existing tools. They say it’s so it’s more secure, but honestly it’s so they can apply their own opinions of how the tool should be. They always promise to make it a drop in replacement, but then then get rid of options, or change what they do… they can’t help themselves. And that is the kind of people who volunteer to port tools to Rust. If they would stick to true 1:1 replacement, this wouldn’t be an issue.
Are there other types of people? Writing software to be bug-for-bug compatible with something else is really difficult and, yes, not fun at all. You will not find many people looking to volunteer for that…
I like tool rewrites. But fixing major issues just before it is used in so many systems? It’s irresponsible.
It should of been given more time to mature. And Ubuntu is used so much, even the odd versions of it, that if one thing goes wrong later; this will cause a lot of bad press for both Rust and Ubuntu.
It should make the rust community very nervous. So many companies use the Ubuntu:latest tag in so many projects. And millions of people will hear, after being subject to the breakages, that it was all about Rust. Even though it’s not about Rust, just bad management
I mostly agree.
However, Ubuntu clearly sees 24.10 as the test bed for 25.04 and this is how they get the software tested. That is up to them.
I think also that, if you make a change this big, and only a couple of minor bugs are found and fixed before release, you are in pretty good shape.
And if all bugs are fixed this fast, even bugs found after release may impact only a few.
They have provided a mechanism to use the old utils if you want to be more conservative. Given that, I do not find this “irresponsible”.
There are probably bigger bugs elsewhere in 24.10 right now that will be harder to mitigate.
It has not even released yet.
Is your claim that non-Rust software gets written and runs perfectly without bugs the first time it is run, never requiring you to “tweek it”? That does not seem strongly evidence based. I assume by tweek, you mean tweak.
Also, they fixed this bug before this story, and your well researched comment, even appeared. The same thing happened just a few days ago when a similar “performance” bug was found. An entire chorus of idiots, including some prominent YouTubers, proudly proclaimed “I warned ya” for that one as well. Many predicting Ubuntu would need to be delayed or that people would be switching to other distros. Of course, the Rust version was already 50% faster than the C version by then and it was still weeks before the release date. Those comments did not age well.
And here we are again.
If you were trying to sound smart, it did not work.
I can hear the goalposts moving.
There seems to be a bug in rust md5 implementation. This can break everything, but then everything can soon be fixed too.
Looks like md5 is fine, it’s dd that’s wrong
I will really appreciate the irony when it turns out that it’s the new implementation in Rust that is correct
.
GNU is really its own thing and not reallyPOSIX anymore. So GNU is right even if they are wrong.
This is not me advocating for GNU. I use BSD utils myself.
On this issue, your were right in a way. My understanding is that the uutils version of dd was respecting the fullblock parameter, causing problems on slow pipes. GNU ignore this and was doing partial writes. Uutils has been modified to match GNU and is “working” now. At least, a tested patch has been submitted.
If you pipe, dd is the wrong tool anyway. Replace with cp or cat. dd is a fine scalpel but a bad shovel.
Useless use of dd
😂
The bug: github.com/uutils/coreutils/pull/8750
And……fixed.
A few days ago we had a “performance” bug. Before the stories had even been written, the uutils was made 50% faster than GNU.
Now we have an actual difference in behaviour. But it is again fixed before the stories could even go out.
The anti-Rust crew is really trying to celebrate hear but it seems like uutils is proving them wrong so far.
We will see what happens in production I suppose.
I don’t think it’s anti-Rust. I like Rust. I don’t like the uutils license.
New non-copyleft Rust implementation. While we’re at it, let’s throw in some blockchain and AI as well. The eccentric South African billionaire CEO will be pleased.
Make sure it’s all powered by the cloud
I’m willing to bet that if the GNU coreutils getting bumped a minor version caused widespread issues for a day, nobody would even bother reporting in it…
Do you REALLY think that?
… Yeah? Beta software having bugs isn’t the hottest of takes.
Ubuntu 25.10 entered beta on September 18th. It releases on October 9th. It’s still in beta.
I see what you meant. I consider rust core utils beta so stand by my statement but I see what you meant.
Can you point to an instance that actually happened?
canonical doing canonical things
Related and sane response:
(Low Level) youtu.be/Jgq551IhquA?t=4m7s