Announcement

Collapse
No announcement yet.

Rust-Written Coreutils Replacement uutils 0.0.19 Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Vaporeon View Post
    If you re-implement something proprietary and release it under a free license, people bother a lot about making sure the project is clean-room (see WINE).
    If you re-implement a GNU project and release it under the permissive MIT license, washing it of copyleft protections, no one seems to question the legalities of that.
    It's based on the BSD implementations. Did you forget those exist?

    The only connection to GNU is the behavioral test suite. There are absolutely no copyrights in that, the behavior of GNU utilities.

    Comment


    • #22
      Originally posted by bug77 View Post

      You don't have to pull any dependencies, you can always write and use your own code. It all comes down to whether you trust your own skills more than code that's out there, in the open.
      Also, it's not like you pull those dependencies directly in prod. You can (and should) always audit the resulting binaries.
      If there's one lesson that C programmers haven't learned in 50 years and counting, it's not to trust your own code.

      This lesson was learned much faster within the specialized domain of cryptography, but it applies equally well everywhere else.

      Comment


      • #23
        Originally posted by darcagn View Post
        It really goes both ways though.

        When I compile a Rust utility and it pulls down like 80 dependencies my gut tells me, "Jeez, well, there's no way this author is auditing all of these projects' changes!"
        When I compile a C utility with no dependencies and see most of the tree hasn't been updated in years, my gut tells me "Ah, I love the rock solid stability of old C code bases."

        But that's just my gut, thinking further about it, how many C programs have authors copy/paste code from random libraries in tree and never update them or audit them ever again? Do they track those code snippets and included files and go back and check against CVEs?

        What it comes down to is Rust's Cargo is a more powerful tool. Its power allows the proactive, diligent maintainer update faster to eliminate vulnerabilities; its power allows the careless, lackadaisical maintainer to update faster and introduce attacks from the outside.

        Ultimately sharing code as much as possible and giving it as many eyes as possible is the spirit of open source, and Rust's tools better facilitate that; its dependency locks and versioning system should mitigate most of the concerns people have as long as project maintainers don't overrely on dependencies and take auditing them more seriously
        Honestly, if the internet and language package managers existed in the 70's we probably wouldn't even be having this conversation wrt C.

        Comment


        • #24
          Originally posted by mathletic View Post

          For binaries like the core utils, GPL is no problem. Like with the Kernel. You don't modify these basic tools and sell them with profit. You don't link to these binaries. MIT and GPL makes no difference.
          A surprising number of people don't get this distinction. The GPL provides no meaningful advantage whatsoever for generic, boring, POSIX-mandated system components.

          Comment


          • #25
            Originally posted by Developer12 View Post

            If there's one lesson that C programmers haven't learned in 50 years and counting, it's not to trust your own code.

            This lesson was learned much faster within the specialized domain of cryptography, but it applies equally well everywhere else.
            What can I say, I currently have 3 layers of tests for my code. And that's before QA runs their e2e suite

            Comment


            • #26
              Originally posted by RahulSundaram View Post

              I mostly agree with you but companies do prefer permissive licensed tooling even for basic tools. For instance, all the GPL enforcement actions around busybox (a minimal alternative to coreutils for embedded systems), resulted in Android and others moving to permissively licensed toybox instead. This isn't because they were selling busybox patches for profit but GPL enforcement for busybox was anchored for full GPL compliance for everything else that the vendor shipped and vendors did have other features in other components they were selling for a profit and compliance meant that they would lose that feature advantage potentially. Having said that the Rust rewrite in this case seems more like a passion project and nothing to do with organizations which already have plenty of other permissive licensed alternatives already.
              That's the SFC's fault for relying exclusively on busybox. There is no copyleft software on earth that is so valuable that it can't be replaced. At the end of the day, it's just software.

              Comment


              • #27
                Originally posted by Developer12 View Post

                That's the SFC's fault for relying exclusively on busybox. There is no copyleft software on earth that is so valuable that it can't be replaced. At the end of the day, it's just software.
                SFC has never exclusively relied on busybox. They do plenty of GPL enforcement outside of it including for Samba and Linux kernel.

                Comment


                • #28
                  Originally posted by ZeroPointEnergy View Post
                  I have some serious reservations when it comes to this rust projects. On one side, it's nice that rust has language features that makes the programs more secure. On the other hand, it basically pull down 80 dependencies which makes it more vulnerable to supply chain attacks. I'm not convinced that is a win.
                  The problem is not with pulling down dependencies. Code re-use is a GOOD THING. The problem is with authenticating them to avoid those supply chain attacks. Cargo provides some limited form of protection by letting you specify git checkout IDs, but having built-in support for PGP-signed tags would be good.

                  Note though that the supply chain attacks are no worse in Rust than in C. If you are worried that someone may compromise a crate like clap that is used by uutils, the risk is really no greater than someone compromising C-written GNU coreutils' repository or tarballs.

                  Comment


                  • #29
                    Originally posted by RahulSundaram View Post

                    [...] the Rust rewrite in this case seems more like a passion project and nothing to do with organizations.
                    seems.. mmm... Redox is written in Rust and received an "anonymous" (who is interested in paying that?) $400,000 donation

                    https://www.reddit.com/r/Redox/comments/xjsn1a/redox_os_receives_anonymous_400000_donation/‚Äč

                    Comment


                    • #30
                      Originally posted by Nth_man View Post

                      seems.. mmm... Redox is written in Rust and received an "anonymous" (who is interested in paying that?) $400,000 donation
                      Redox is unrelated to the topic. I specifically said, in this case ie) uutils.

                      Comment

                      Working...
                      X