← Back to context

Comment by slowin

2 hours ago

I really wish people would mention their stack when they have these curl install scripts. I'd rather use a real package manager, but I'm not totally against installing a compiled binary this way. I am, 100%, not going to install some Java/Type-script nightmare like this though. How is it resolving the dependencies? Is it installing some version of node, bun... on my machine? How's that working with other versions I have installed?

Related: please don't write command line tools in non-compiled languages! Don't make the runtime your user's problem.

I don't know man, seems like a cool project and is open source. I guess he could have just sat on it and used for himself exclusively. It's auditable and totally fine for an open source project and nobody is forced to use it. It's free to use under the MIT license, what else can you really ask for.

I really wish this was not the top comment on HN. It’s a cool project! Maybe try it??! Or just be silent!

  • I agree with you that the author of this project is catching a stray bullet, but I also have to agree with GP that `curl | bash` got way too out of hand.

    I don't know where that came from but it should definitely disappear.

    At least the developer includes the binaries for all platforms in the GitHub release page.

The source is prominently linked: https://github.com/gloom-sh/gloomberb

> please don't write command line tools in non-compiled languages!

Around 40% of Linux CLI tools are written in interpreted languages.

  • The standard Linux CLI tools are installed by a package manager, which has addressed the issues raised upthread. Installs via curl | bash don’t automatically benefit from that.

  • > The source is prominently linked: https://github.com/gloom-sh/gloomberb

    This is how I found out it's a javascript project and didn't install it. I only even bothered to do that because I actually wanted to try it. I'm just saying it would be awesome to have that right there next to the curl command.

    > Around 40% of Linux CLI tools are written in interpreted languages.

    And I prefer not to use those. Everything I said for Javascript holds for Python, Perl, Ruby... as well.

  • Let those be the 40% we prefer less :) Revealing stack does not validate the framework, but we appreciate some foss sauce 'round these parts.

And in the GitHub release page they include compiled binaries anyway... Why would you advertise `curl | bash` as a way to install if there's a binary available?!

Download it, put it wherever you like (probably `~/.local/bin/`) and you're good to use it.

Sometimes I truly wonder...

I know where you're coming from. I've been worried about all the supply chain attacks on npm too. And I'm far from a security expert. However, if you're okay with installing binary packages via `curl somesite.com | sh` I don't think you are in a better position with regards to security.

  • Security is just one of my concerns. I'm actually more worried about borking my system because it's doing some out of band stuff with various javascript pieces that already exist on my system (not by my choice!).

You install some JavaScript nightmare the moment you land on the page!

The only reason to wrap JS in a downloadable executable is deploy it elsewhere like iOS or desktop - I might add: In Trojan horse fashion where the user believes it’s a native app until you accidentally hit your Refresh hot key and you go “Noooooo JavaScript not again!”

You can neva eva escape tha scrip

Embrace