Ubuntu 25.10's Move To Rust Coreutils Is Causing Major Breakage For Some Executables
www.phoronix.com
    • Oinks@lemmy.blahaj.zone
      10·
      11 months ago

      You could make the same kind of articles for the old coreutils if you really wanted to. Just creatively “rewording” the bugfixes from the recent 9.8 release:

      • GNU Core Utilities Are Causing Failures [when copying between NFS and non-NFS filesystems with ACLs]
      • GNU Core Utilities May Cause Data Corruption [with copy ranges larger than 2 GiB]
      • Correctness Bugs Found in GNU Core Utilities [tail --pid may race with reused PIDs]

      I feel like the reactions regarding uutils are a bit… off in general. There seem to be a lot of people who are pathologically negative towards open source projects for, frankly, bullshit reasons, like vague complaints about “Rust evangelism” (what?) or how permissive licensing is against the spirit of open source (WTF).

      Phoronix isn’t helping with these clickbait articles which border on content farming and their failure to moderate their comments of course, but these negative attitudes seems to cut across sites, also including Lemmy, Reddit and even Hackernews.

      The uutils team seems to be doing well but it makes me sad to think about any aspiring open source devs without corporate backing reading such drivel.

    • TrivialBetaState@sopuli.xyz
      91·
      11 months ago

      I think that people are negative towards rust utils, not because of rust or attachment to an old software but because they are not licensed under GPL or another copyleft license. Even if they become faster and more stable in the future, this is a flaw that will not be ignored.

        • TrivialBetaState@sopuli.xyz
          3·
          11 months ago

          I am not sure how to answer that. Are you asking me to give you an example that the GNU coreutils were not used in a closed sourced s/w?

          • FizzyOrange@programming.dev
            1·
            11 months ago

            No, an example where a modification to coreutils was open sourced by a commercial company that might otherwise not have.

            The GPL has been reasonably effective in some cases like the Linux kernel and KHTML at getting companies to release their modifications. But I don’t see that as being significant for coreutils because a) most companies would have zero need to modify them, and b) they could just use the BSD versions if they really wanted.

    • LeFantome@programming.dev
      61·
      11 months ago

      Agreed. Also, some of these “bugs” will just be differences in interpretation.

      For example, the dd problem that prompted all this noise is that uutils was enforcing the full block parameter in slow pipe writes while GNU was not.

      So, now uutils matches GNU and the “bug” is gone.

      There will only be a limited number of these kinds of issues and they will be quickly harmonized. Mountains out of mole hills.

      • fruitcantfly@programming.dev
        6·
        11 months ago

        For example, the dd problem that prompted all this noise is that uutils was enforcing the full block parameter in slow pipe writes while GNU was not.

        So, now uutils matches GNU and the “bug” is gone.

        No, the issue was a genuine bug:

        The fullblock option is an input flag (iflag=fullblock) to ensure that dd will always read a full block’s worth of data before writing it. Its absence means that dd only performs count reads and hence might read less than blocksize x count worth of data. That is according to the documentation for every other implementation I could find, with uutils currently lacking documentation, and there is nothing to suggest that dd might not write the data that it did read without fullblock.

        Until recently it was also an extension to the POSIX standard, with none of tools that I am aware of behaving like uutils, but as of POSIX.1-2024 standard the option is described as follows (source):

        iflags=fullblock
        Perform as many reads as required to reach the full input block size or end of file, rather than acting on partial reads. If this operand is in effect, then the count= operand refers to the number of full input blocks rather than reads. The behavior is unspecified if iflags=fullblock is requested alongside the sync, block, or unblock conversions.

        I can also not conceive of a situation in which you would want a program like dd to silent drop data in the middle of a stream, certainly not as the default behavior, so conditioning writes on this flag didn’t make any sense in the first place

    • jasory@programming.dev
      1·
      11 months ago

      Sure, but is there an actual reason to be switching?

      Uutils doesn’t seem to be an evolution of coreutils, but a functional clone. What advantage do we get with that?

      Note: I have pull requests against uutils so I’m by no means anti-Rust or against the project. But I personally would not replace coreutils with it.