Ironically, it is rustup that triggered me with this most recently… https://www.rust-lang.org/tools/install

Thank you for the nuanced answer!

You ask why I feel this is less secure: it seems the lowest possible bar when it comes to controlling what gets installed on your system. The script may or may not give you a choice as to where things get installed. It could refuse to install or silently overwrite stuff if something already exists. If install fails, it may or may not leave data behind, in directories I may or may not know about. It may or may not run a checksum on the downloaded data before installing. Because it’s a competely free-form script, there is no standard I can expect. For an application, I would read the documentation to learn more, but these scripts are not normally documented (other than “use this to install”). That uncertainty, to me, is insecure/unsafe.

I do, but some of these scripts are quite complex and hard to parse. When all I would really need to do this myself is a direct download URL and unzip/untar in a folder of my choice, it’s a pain.

Indeed, looking at the content of the script before running it is what I do if there is no alternative. But some of these scripts are awfully complex, and manually parsing the odd bash stuff is a pain, when all I want to know is : 1) what URL are you downloading stuff from? 2) where are you going to install the stuff?

As for running the program, I would trust it more than a random deployment script. People usually place more emphasis on testing the former, not so much the latter.

How I wish CUDA was an open standard. We use it at work, and the tooling is a constant pain. Being almost entirely controlled by NVIDIA, there’s no alternative toolset, and that means little pressure to make it better. Clang being able to compile CUDA code is an encouraging first step, meaning we could possibly do without nvcc. Sadly the CMake support for it on Windows has not yet landed. And that still leaves the SDK and runtime entirely in NVIDIA’s hands.

What irritates me the most about this SDK is the versioning and compatibility madness. Especially on Windows, where the SDK is very picky about the compiler/STL version, and hence won’t allow us to turn on C++20 for CUDA code. I also could never get my head around the backward/forward compatibility between SDK and hardware (let alone drivers).

And the bloat. So many GBs of pre-compiled GPU code for seemingly all possible architectures in the runtime (including cudnn, cublas, etc). I’d be curious about the actual number, but we probably use 1% of this code, yet we have to ship the whole thing, all the time.

If CPU vendors were able to come up with standard architectures, why can’t GPU vendors? So much wasted time, effort, energy, bandwidth, because of this.

How do you people manage this?