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?

  • Fonzie!@ttrpg.network
    link
    fedilink
    arrow-up
    7
    arrow-down
    1
    ·
    2 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
      ·
      2 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.

      • Fonzie!@ttrpg.network
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        1 day 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.