4 ms·

Anyone dare to incur the wrath of the Rust contingent by linking to the elephant in the room? OK then, I will https://www.rust-lang.org/tools/install https://

Anyone dare to incur the wrath of the Rust contingent by linking to the elephant in the room? OK then, I will https://www.rust-lang.org/tools/install https://www.rust-lang.org/tools/install

RMPR 6y ago
In the meantime all the distributions (at least the major one) have Rust in their official repositories.
- est31 6y ago
  Unless you are on a rolling release distro, you can run into problems with the rust compiler package being out of date, as the rust ecosystem quickly starts requiring newer versions. 500 crates for a medium sized project are not unheard of, and if one of the maintainers decides to adopt a new feature, you run into issues. That's why in order to write Rust, you'll likely need rustup, which is packaged on way less distros than the rust compiler is. Debian for example doesn't have an official rustup package.
  - jjgreen 6y ago
    > That's why in order to write Rust, you'll likely need rustup It seems that way, which is a big disincentive to use Rust at all.
    - lock-free 6y ago
      The same issues exist for other languages and runtimes so I'm not sure why Rust having a standard solution is a disincentive. How many ways are there to ruin a python environment?
      - avhon1 6y ago
        The issue is worse with Rust, which is still a young and rapidly-changing language. Debian stable currently packages rustc 1.41.1 (February 2020), which is 11 releases behind the most recent 1.48.0 release. The older compiler's differences after 10 months include: * doesn't have subslice patterns * has `Error::description`, which has since been deprecated * doesn't have x86 CPU feature detection * lacks fix for unsound typecasts between integers and floats * lacks fix for incomplete constant propagation * doesn't let you use conditionals, loops, match, $$, or || in constant fns, or cast arrays to slices in constant fns * has less-helpful error messages and backtraces * doesn't let you implement traits on arrays with lengths >32 * has worse type inference, this (valid since 1.43.0) code doesn't compile because 0.0 and &0.0 are f64s: let n: f32 = 0.0 + &0.0; * requires you to import standard libraries to use predefined numeric constants (like MAXINT or NaN) * doesn't support Control Flow Guard on Windows * doesn't generate documentation links from classpaths (you have to write relative file paths instead) and numerous libraries being pre-stable. For code that you're writing yourself, not having these features is mostly just a quality-of-life issue: you'll have to do things that you wouldn't have to do if you had the latest compiler. For code that you're collaborating on, having an 10-months-older compiler can be a showstopper: the code might just not compile at all, and very likely the only fix will be to uninstall your system-packaged rustc and install the version from rustup. Contrast this with C/C++ development, where your system's pre-packaged compilers are much more likely to be sufficiently up-to-date. These languages are more mature than Rust: they change slower, and new features are adopted by programmers more gradually. For example, the Linux kernel only requires GCC 4.9 [1], which was released in 2013. Debian stable supplies GCC 8.3, which will probably be able to compile unmodified kernel source code for many years without being updated. [1] https://www.kernel.org/doc/html/latest/process/changes.html https://www.kernel.org/doc/html/latest/process/changes.html
        lock-free 6y ago
        I can contrast with C/C++ development, where C++17/20 are not available by default on many distros because package managers lag so far behind the curve and new projects get tied to outdated versions. I just don't really see this as a problem - Rust really isn't that much of a moving target, and the benefit is there is one solution to the problem: use Rustup to manage your Rust installation. That is significantly more robust than "use your package manager."
    - richardwhiuk 6y ago
      Or avoid distributions like the former CentOS.
gspr 6y ago
Yikes.
kzrdude 6y ago
What, specifically is wrong with it? The article writes this is obviously bad, but I think it needs to be expanded upon, it's not obvious.
- beojan 6y ago
  `curl | bash` downloads an installation script and runs it as it's being downloaded, with no opportunity to read the script and ensure it does nothing malicious, and has no inadvertent bugs that could cause damage.
  - taejo 6y ago
    Just like if I'd done `curl > install.sh; bash install.sh` without reading install.sh or installed a binary package, both of which are done every day by people with work to do and without the time, skill and inclination to audit millions of lines of source code.
    - ciceryadam 6y ago
      or curl --output instead of using stdout
  - willeh 6y ago
    As opposed to downloading a binary and running it? We don't verify what the binaries we download contain, why do it for a bash script?
    - dastx 6y ago
      I suppose the difference is iff people do very script before they run, this could bypass it. But I think, those people would definitely download it, inspect it, then run the downloaded script.
      - VBprogrammer 6y ago
        I think it would take next to no effort to hide something in a bash script in such a way that it passed casual inspection even by an expert. See code obfuscation competitions for examples.
est31 6y ago
The suggestion of the website is certainly not great, but note that: * It has been improved a little by the https and tls 1.2 parameters compared to earlier versions that didn't have these params * You are not required to install rustup that way. There are many rustup packages available in distros today. Arch has one, nix OS has one. Debian is dragging their feet [0] but they aren't entirely opposed to the idea, so maybe something will change about this in the future. * Even if the download process is secured, rustup doesn't really verify any signatures, it just downloads what's inside the manifest. So you can download potentially malicious code if the S3 bucket is hacked that rustup downloads the compiler from. * Even if the entire process of obtaining rustc is secured, the standard way of using rust + cargo basically gives maintainers access to your local computer through build.rs and other methods. You can sandbox the cargo invocation, but who does that? [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955208 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955208
deleted 6y ago
[deleted]

Anyone dare to incur the wrath of the Rust contingent by linking to the elephant in the room? OK then, I will https://www.rust-lang.org/tools/install https://www.rust-lang.org/tools/install

RMPR 6y ago

In the meantime all the distributions (at least the major one) have Rust in their official repositories.

est31 6y ago
Unless you are on a rolling release distro, you can run into problems with the rust compiler package being out of date, as the rust ecosystem quickly starts requiring newer versions. 500 crates for a medium sized project are not unheard of, and if one of the maintainers decides to adopt a new feature, you run into issues. That's why in order to write Rust, you'll likely need rustup, which is packaged on way less distros than the rust compiler is. Debian for example doesn't have an official rustup package.
- jjgreen 6y ago
  > That's why in order to write Rust, you'll likely need rustup It seems that way, which is a big disincentive to use Rust at all.
  - lock-free 6y ago
    The same issues exist for other languages and runtimes so I'm not sure why Rust having a standard solution is a disincentive. How many ways are there to ruin a python environment?
    - avhon1 6y ago
      The issue is worse with Rust, which is still a young and rapidly-changing language. Debian stable currently packages rustc 1.41.1 (February 2020), which is 11 releases behind the most recent 1.48.0 release. The older compiler's differences after 10 months include: * doesn't have subslice patterns * has `Error::description`, which has since been deprecated * doesn't have x86 CPU feature detection * lacks fix for unsound typecasts between integers and floats * lacks fix for incomplete constant propagation * doesn't let you use conditionals, loops, match, $$, or || in constant fns, or cast arrays to slices in constant fns * has less-helpful error messages and backtraces * doesn't let you implement traits on arrays with lengths >32 * has worse type inference, this (valid since 1.43.0) code doesn't compile because 0.0 and &0.0 are f64s: let n: f32 = 0.0 + &0.0; * requires you to import standard libraries to use predefined numeric constants (like MAXINT or NaN) * doesn't support Control Flow Guard on Windows * doesn't generate documentation links from classpaths (you have to write relative file paths instead) and numerous libraries being pre-stable. For code that you're writing yourself, not having these features is mostly just a quality-of-life issue: you'll have to do things that you wouldn't have to do if you had the latest compiler. For code that you're collaborating on, having an 10-months-older compiler can be a showstopper: the code might just not compile at all, and very likely the only fix will be to uninstall your system-packaged rustc and install the version from rustup. Contrast this with C/C++ development, where your system's pre-packaged compilers are much more likely to be sufficiently up-to-date. These languages are more mature than Rust: they change slower, and new features are adopted by programmers more gradually. For example, the Linux kernel only requires GCC 4.9 [1], which was released in 2013. Debian stable supplies GCC 8.3, which will probably be able to compile unmodified kernel source code for many years without being updated. [1] https://www.kernel.org/doc/html/latest/process/changes.html https://www.kernel.org/doc/html/latest/process/changes.html
      - lock-free 6y ago
        I can contrast with C/C++ development, where C++17/20 are not available by default on many distros because package managers lag so far behind the curve and new projects get tied to outdated versions. I just don't really see this as a problem - Rust really isn't that much of a moving target, and the benefit is there is one solution to the problem: use Rustup to manage your Rust installation. That is significantly more robust than "use your package manager."
  - richardwhiuk 6y ago
    Or avoid distributions like the former CentOS.

gspr 6y ago

Yikes.

kzrdude 6y ago

What, specifically is wrong with it? The article writes this is obviously bad, but I think it needs to be expanded upon, it's not obvious.

beojan 6y ago
`curl | bash` downloads an installation script and runs it as it's being downloaded, with no opportunity to read the script and ensure it does nothing malicious, and has no inadvertent bugs that could cause damage.
- taejo 6y ago
  Just like if I'd done `curl > install.sh; bash install.sh` without reading install.sh or installed a binary package, both of which are done every day by people with work to do and without the time, skill and inclination to audit millions of lines of source code.
  - ciceryadam 6y ago
    or curl --output instead of using stdout
- willeh 6y ago
  As opposed to downloading a binary and running it? We don't verify what the binaries we download contain, why do it for a bash script?
  - dastx 6y ago
    I suppose the difference is iff people do very script before they run, this could bypass it. But I think, those people would definitely download it, inspect it, then run the downloaded script.
    - VBprogrammer 6y ago
      I think it would take next to no effort to hide something in a bash script in such a way that it passed casual inspection even by an expert. See code obfuscation competitions for examples.

est31 6y ago

The suggestion of the website is certainly not great, but note that: * It has been improved a little by the https and tls 1.2 parameters compared to earlier versions that didn't have these params * You are not required to install rustup that way. There are many rustup packages available in distros today. Arch has one, nix OS has one. Debian is dragging their feet [0] but they aren't entirely opposed to the idea, so maybe something will change about this in the future. * Even if the download process is secured, rustup doesn't really verify any signatures, it just downloads what's inside the manifest. So you can download potentially malicious code if the S3 bucket is hacked that rustup downloads the compiler from. * Even if the entire process of obtaining rustc is secured, the standard way of using rust + cargo basically gives maintainers access to your local computer through build.rs and other methods. You can sandbox the cargo invocation, but who does that? [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955208 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955208

deleted 6y ago

[deleted]