At first I was sceptical, but after a few thought, I came to the solution that, if uutils can do the same stuff, is/stays actively maintained and more secure/safe (like memory bugs), this is a good change.

What are your thoughts abouth this?

    • 0x0@programming.dev
      link
      fedilink
      arrow-up
      30
      arrow-down
      3
      ·
      5 days ago

      See other comments: all these rewrites are not using the GPL but rather permissive licenses like MIT. Bye-bye FOSS (in those ecosystems).

    • ParetoOptimalDev@lemmy.today
      link
      fedilink
      arrow-up
      10
      arrow-down
      2
      ·
      5 days ago

      I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.

      Take the recent rsync vulnerabilities for example.

      https://www.cyberciti.biz/linux-news/cve-2024-12084-rsyn-security-urgent-update-needed-on-unix-bsd-systems/#more-2215

      At least this one in a Rust implementation of rsync would have very likely been avoided:

      CVE-2024-12085 – A flaw was found in the rsync daemon which could be triggered when rsync compares file checksums. This flaw allows an attacker to manipulate the checksum length (s2length) to cause a comparison between a checksum and uninitialized memory and leak one byte of uninitialized stack data at a time. Info Leak via uninitialized Stack contents defeats ASLR.

      • 0x0@programming.dev
        link
        fedilink
        arrow-up
        6
        arrow-down
        7
        ·
        5 days ago

        I fear moving away from GPL that moving to Rust seems to bring, but Rust does fix real memory issues.

        So you prefer closed-source code to potentially unsafe open-source code?

        Take the recent rsync vulnerabilities for example.

        Already fixed, in software that’s existed for years and is used by millions. But Oh no, memory issues, let’s rewrite that in <language of the month>! will surely result in a better outcome.

        • ParetoOptimalDev@lemmy.today
          link
          fedilink
          arrow-up
          7
          ·
          5 days ago

          Already fixed, in software that’s existed for years and is used by millions. But Oh no, memory issues, let’s rewrite that in <language of the month>! will surely result in a better outcome.

          Rsync is great software, but the C language fates it to keep having memory issues in spite of its skilled developers.

          Preventing a bug from being possible > fixing a bug.

        • easily3667@lemmus.org
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          edit-2
          4 days ago

          Rust isn’t language of the month unless you’ve been asleep for a decade, old man

          What about the rust version is closed source?

          This whole post is very disingenuous.

          Edit: oh you’re a troll

    • Fonzie!@ttrpg.network
      link
      fedilink
      arrow-up
      7
      arrow-down
      1
      ·
      5 days ago

      Mainly memory safety; split (which is also used for other programs like sort) had a memory heap overflow issue last year to name one. The GNU Coreutils are well tested and very well written, the entire suite of programs has a CVE only once every few years from what I can see, but they do exist and most of those would be solved with a memory and type safe language.

      That said, Rust also handles parallelism and concurrency much better than C ever could, though most of these programs don’t really benefit from that or not much since they already handled this quite well, especially for C programs.

      • 0x0@programming.dev
        link
        fedilink
        arrow-up
        3
        arrow-down
        4
        ·
        5 days ago

        but they do exist and most of those would be solved with a memory and type safe language.

        Maybe.

        Still, there are other sources of bugs beyond memory management.

        And i’d rather have GPL-ed potentially unsafe C code to… closed-source Rust code.

        • ParetoOptimalDev@lemmy.today
          link
          fedilink
          arrow-up
          10
          arrow-down
          1
          ·
          5 days ago

          The Rust code isn’t closed source, but I’d strongly prefer a coreutils replacement to use GPL over MIT as well.

        • Fonzie!@ttrpg.network
          link
          fedilink
          arrow-up
          2
          ·
          edit-2
          4 days ago

          To add to @ParetoOptimalDev@lemmy.today

          The uutils are MIT licensed, simply put it means “do whatever you want with it, as long as you credit us”.
          The coreutils are GPL, simply put “do whatever you want with it but only in other GPL works, also credit us”.

          The coreutils make sure forks will also be open source.
          While the uutils aren’t closed source, they do allow you to make closed source forks.

          The uutils’ license is too permissive.