Announcement

Collapse
No announcement yet.

Rust-Written Coreutils Replacement uutils 0.0.19 Released

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

  • #61
    Originally posted by NobodyXu View Post
    That will depend on what crate you use.
    This is not a non-problem. crates.io will evolve. Alternatives to crates.io will spring up. If rust becomes popular there will be tens of thousands of crates that solve gazillions of different problems. This may be good for a rapid development. But the downside is the confusion. There will be crates that pull in hundreds of other crates. It will get difficult to select the correct crates and really difficult to maintain that white list. A rising number of ignorant rust developers will make the problem worse. This is exactly what happened to javascript and to a lesser degree to python.

    Originally posted by NobodyXu View Post
    It's not that evolutionary, and that's why this is not going to be a big problem.
    I don't think so. From a pure web developer-only point of view, "not a big problem" is the natural resulting opinion. The differing sales model results in two fundamental differences:
    - Web applications are short lived compared to native apps. A license issue has a shorter exposure time in a web application.
    - Companies care less about web applications which leaves them under less scrutiny than native applications.

    Originally posted by NobodyXu View Post
    Having a package manager will always better than without one, having to manually install the dependencies using apt-get or manually download, extract and compile really is just wasting time, where you can allocate these resources to actually review the dependencies.
    I don't see rust offering something new here. Dependencies will always need to be managed manually. On the contrary: the simplicity of creating and ease-of-re-use of crates will cause a problem that does not exist in this form in languages like Ada, Pascal, C, D, Haskell etc.

    Besides, I haven't seen a single Linux distribution that lacks a package manager. Windows solves that problem with static linking and installers.

    Comment


    • #62
      Originally posted by Quackdoc View Post
      cargo-deny recursively checks dependency tree as well as opt in deps. I really don't see how this can be possible without an entire team working on it, checking every bit of code to manually make sure there are no patent infringements, as long as the tree is good that would be fine due diligence.
      Up to now, I did not talk about patent issues - that's a whole other bucket full of worms.

      Originally posted by Quackdoc View Post
      assuming you really *need* a crate that pulls in an incompatible dep (which you would find out by adding the crate, running cargo-deny before work starts) it's just like anything else, fork it, strip out or make the deps optional, or replace it yourself, that doesn't really change anything. as for the leaks part. this changes literally nothing. just replace the bits once you are aware of it. and if it's too large to replace you are SOL, but that changes literally nothing from C
      Thanks for confirming that. It's what I expected: nothing new under the sun. cargo-deny is not a silver bullet. It will just point to issues that still need to be managed manually. But which developer runs that tool voluntarily? - unless you have it somewhere into your CI-stack.

      Comment


      • #63
        Originally posted by lowflyer View Post
        This is not a non-problem. crates.io will evolve. Alternatives to crates.io will spring up. If rust becomes popular there will be tens of thousands of crates that solve gazillions of different problems. This may be good for a rapid development. But the downside is the confusion. There will be crates that pull in hundreds of other crates. It will get difficult to select the correct crates and really difficult to maintain that white list. A rising number of ignorant rust developers will make the problem worse. This is exactly what happened to javascript and to a lesser degree to python.
        Like I said, the solution is to use whitelisting of authors or crates, or both.
        Plus blacklisting authors known to be bad actors.

        Originally posted by lowflyer View Post
        I don't think so. From a pure web developer-only point of view, "not a big problem" is the natural resulting opinion. The differing sales model results in two fundamental differences:
        What I was trying to say is that, the companies/corp/devs already has experience dealing with dependencies, using whitelist/blacklist.

        Originally posted by lowflyer View Post
        I don't see rust offering something new here. Dependencies will always need to be managed manually.
        So without a package manager and https://crates.io, you will have to use the tools platform-dependent tool to install them.

        On debian/ubuntu, this will be apt-get.
        On centos/redhat, this will be yum.
        On alpine, this will be apk.
        On macOS, this will be homebrew.
        On windows, this will be chocolatey or scoop.

        As you can see, all of them are maintained separately and your dependencies might not be available there at all.
        Or it is available, but with a different feature set than you expected.

        If they are not available, then you will have to download source code, compile and install it manually.

        Compared to cargo, you just need to edit Cargo.toml and it will get the job done for you, in a cross-platform way.
        Which one is simpler is obvious.

        Comment


        • #64
          Originally posted by lowflyer View Post
          Thanks for confirming that. It's what I expected: nothing new under the sun. cargo-deny is not a silver bullet. It will just point to issues that still need to be managed manually. But which developer runs that tool voluntarily? - unless you have it somewhere into your CI-stack.
          I know it's something I personally often check

          Comment


          • #65
            Originally posted by NobodyXu View Post
            What I was trying to say is that, the companies/corp/devs already has experience dealing with dependencies, using whitelist/blacklist.
            I certainly hope so, but the problem will be worse than what they're used to because of what I tried to explain above

            Originally posted by NobodyXu View Post
            So without a package manager and https://crates.io, you will have to use the tools platform-dependent tool to install them.

            On debian/ubuntu, this will be apt-get.
            On centos/redhat, this will be yum.
            On alpine, this will be apk.
            On macOS, this will be homebrew.
            On windows, this will be chocolatey or scoop.

            As you can see, all of them are maintained separately and your dependencies might not be available there at all.
            Or it is available, but with a different feature set than you expected.

            If they are not available, then you will have to download source code, compile and install it manually.

            Compared to cargo, you just need to edit Cargo.toml and it will get the job done for you, in a cross-platform way.
            Which one is simpler is obvious.
            Two things:
            • On windows you generally don't need a package manager since the installers usually contain everything (yes, it's a waste)
            • Deployment that requires internet access can be problematic. We deliver to customers that operate on completely isolated networks.

            As I mentioned in previous posts, I am not a rust expert, so I have questions:
            • does https://crates.io store the crates in binary or in source form? How is "cross-platform" handled as you mention?
            • how would I deploy a rust application to a customer's machine without internet access?
            • If the crates come in source form (as I suspect) there must be a compiler on the system for that workflow to work. Wouldn't this mandate the use of a package manager on top of (or before) cargo? I don't expect to find all compilers pre-installed on customers machines.

            Comment


            • #66
              Originally posted by lowflyer View Post
              I certainly hope so, but the problem will be worse than what they're used to because of what I tried to explain above
              Handling cargo dependencies should be no difficult than handling python/javascript dependencies.

              Originally posted by lowflyer View Post
              Two things:
              • On windows you generally don't need a package manager since the installers usually contain everything (yes, it's a waste)
              it stores crates in source form and is immutable.
              When you run `cargo build` the first time, cargo will pull down index metadata and then download and extract dependencies based on Cargo.toml and Cargo.lock (optional lockfile, can be used to pin dependencies version).

              Then it would compile dependencies and then your crate.
              Once dependencies are compiled, then would be cached in `target/`.

              You can then use `--offline` mode to build the project offline:

              Code:
                     --offline
                         Prevents Cargo from accessing the network for any reason. Without this flag, Cargo will stop
                         with an error if it needs to access the network and the network is not available. With this
                         flag, Cargo will attempt to proceed without the network if possible.
              
                         Beware that this may result in different dependency resolution than online mode. Cargo will
                         restrict itself to crates that are downloaded locally, even if there might be a newer version
                         as indicated in the local copy of the index.  See the cargo-fetch(1) command to download
                         dependencies before going offline.
              
                         May also be specified with the net.offline config value
                         <https://doc.rust-lang.org/cargo/reference/config.html>.
              Originally posted by lowflyer View Post
            • how would I deploy a rust application to a customer's machine without internet access?
            Same as how you would do it in C++: Distribute compiled pre-built binaries.

            Originally posted by lowflyer View Post
          • If the crates come in source form (as I suspect) there must be a compiler on the system for that workflow to work. Wouldn't this mandate the use of a package manager on top of (or before) cargo? I don't expect to find all compilers pre-installed on customers machines.
          • Rust has a toolchain installer called rustup that installs rustc, cargo and artifacts required for building rust on different platforms (note that it doesn't have components required for compiling C/C++, for that you need cargo-zigbuild).



            On unix, you just need to run 'curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh' and on Windows, you need to download and run https://win.rustup.rs/x86_64 .

            Comment


            • #67
              I forgot to mention that rustup can be used to install any version (including old versions, stable, beta and nightly) of rustc (compiler) and cargo (package manager), plus additional components like rustfmt (code formatter), clippy (linter to find out mistakes), rust-analyzers (lsp-server), llvm-tools, rustc-dev, etc.

              And it can also be used to update the installed stable/beta/nightly rustc and cargo.

              Comment


              • #68
                NobodyXu, your previous post is malformed:
                image.png‚Äč
                Attached Files

                Comment


                • #69
                  lowflyer Thanks, I thought this is just some rendering errors on my browser.
                  I don't know how to fix this, I can't even edit the post now.

                  Michael There seems to be some bugs with the forums, I can't even go to previous page now.

                  Comment


                  • #70
                    NobodyXu, thanks for your explanations. I think part of the confusion is: "rust source package manager" vs "operating system package manager".

                    Originally posted by NobodyXu
                    Same as how you would do it in C++: Distribute compiled pre-built binaries.
                    That means creating an installer that contains all binary dependencies.

                    Originally posted by NobodyXu
                    Most libraries does not come with an installer, boost for example, contains instructions only.
                    That is the reason why boost is per default statically linked on windows. Making it almost hassle-free.

                    Comment

                    • Working...
                      X