5 ms·

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 ins

by slowin 2mo 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.

bobajeff 2mo ago
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.
- slowin 2mo ago
  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!).
  - rbanffy 2mo ago
    I write command line tools primarily with Python and one thing I always try to do is to limit myself to the standard library, which, with Python, is quite sufficient for most of what I do. Anyway, most of what I write is designed to be installed in a virtualenv, which restricts the blast radius to one specific application.
lavela 2mo ago
Agree. If you really want to know what's used here: probably uses bun single-file executables[0] so shouldn't clash with anything else on your system. [0] https://bun.com/docs/bundler/executables https://bun.com/docs/bundler/executables
- mistercheph 2mo ago
  lmao curling and exec'ing a vibe coded script running in a vibe-coded runtime, what could possibly go wrong!
  - otabdeveloper4 2mo ago
    Don't worry about it, it was code reviewed by Claude.
CharlesW 2mo ago
The source is prominently linked: https://github.com/gloom-sh/gloomberb 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.
- rtaylorgarlock 2mo ago
  Let those be the 40% we prefer less :) Revealing stack does not validate the framework, but we appreciate some foss sauce 'round these parts.
  - rtaylorgarlock 2mo ago
    [flagged]
- slowin 2mo ago
  > The source is prominently linked: https://github.com/gloom-sh/gloomberb 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.
  - cztomsik 2mo ago
    I think the point was that even Bash is interpreted.
    - slowin 2mo ago
      I definitely do not think Bash scripts should be distributed.
  - alpha_trion 2mo ago
    Using JS for anything finance related is incredibly naive
deleted 2mo ago
[deleted]
talentedcoin 2mo ago
I really wish this was not the top comment on HN. It’s a cool project! Maybe try it??! Or just be silent!
- Pooge 2mo ago
  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.
- enquirewithin 2mo ago
  You can have any opinion, so long as it’s mine.
  - talentedcoin 2mo ago
    [flagged]
    - xp84 2mo ago
      How is it "adding no value"? It's not crazy to prefer a package manager package to a curl|bash YOLO. OP is stating that preference, which various people have agreed with. If you posted "I love curl|bash install method - please do more of this" that is also fine. Either way it's a signal for both the author and anyone considering shipping this type of software, that their audience may have a certain preference.
    - nemomarx 2mo ago
      I know it's kind of a nitpick, but is there really no value at all in "your install is just curl | bash and that seems insecure and risky" I would want to know that about any project before I try and evaluate it personally.
Pooge 2mo ago
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...
- seanw444 2mo ago
  Convenience. That's usually the answer.
  - rbanffy 2mo ago
    One thing I dislike is that the installer wants super user permissions. That’s a big no-no with JavaScript apps installing global components. All global machine state should be managed with package managers, preferably only one package manager.
- munksbeer 2mo ago
  It seems to have become "the thing" to do. I can't figure out if it is bad as it feels. Why would I run `curl | bash` on something that could be doing literally anything. It feels crazy that all the lessons we've learned just get thrown away. On the other hand, just because I run `brew install someapp`, it somehow feels safer, but why? That app could be doing anything too.
  - wett 2mo ago
    I just learned these two: 1. If the connection dies mid transfer, bash will still execute it. So `rm -rf ~/.local/bin/whatever` can become `rm -rf ~` The author can avoid this by wrapping everything in a function. But you wouldn’t know if they did so if you aren’t outputting it to a file first. 2. Say the link points to an S3 bucket and it gets compromised, there’s no record of the payload to analyze. I’m sure there’s a plethora of other subtleties, but I’ve always had the same question as you and thought I’d share.
- zombot 2mo ago
  The project is vibe-coded slop and coding LLMs are not famous for using obvious or minimalistic approaches.
alaudet 2mo ago
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.
- nemomarx 2mo ago
  https://gloom.sh/cloud https://gloom.sh/cloud Is it? I see some kinda subscription, so there's gotta be some non MIT portion of it
  - alwa 2mo ago
    That page seems to indicate that the subscription is to a real-time data feed, rather than the software itself—am I mistaken?
    - nemomarx 2mo ago
      Unless you're paying to turn on access to purely a third party feed (which would be odd to me) there's some server side code taking those feeds and that the app is calling. Is that server code MIT licensed? An open source interface to a proprietary backend isn't really fully auditable.
- slowin 2mo ago
  I actually don't mean to bag on the author, but I think my complaint is valid. Maybe if they had a note right next to the curl command that said "This installs a single bun bundled executable. Here's a link to the GitHub releases if you'd like to install it yourself", that would be helpful. My point about interpreted languages stands though. These bundled javascript runtime "apps" eat at least 500M of RAM on boot. That's totally not needed for a CLI tool. If it's not bundled, then it's even worse as you hit the supply chain and tooling interference problems (and you still use the same RAM). There are a lot of good, modern, compiled languages. CLI builders should pick up those stacks imho.
tingletech 2mo ago
you can test it out with bunx gloomberb
baist0 2mo ago
yeah! agree. this shity approach when user solves technical problems.
YeGoblynQueenne 2mo ago
>> Related: please don't write command line tools in non-compiled languages! ... unless, of course, it's Perl. Right?
zeroq 2mo ago
disclaimer: I haven't seen the code TS/JS is not the problem. You can, and you should eject your dependencies and package them with your releases. And I don't understand why it's not a common practice. You can even bundle your releases with a runtime, but that's not always the best solution. For something like this I'd actually prefer interpreted code I can inspect line by line rather than having a blob of unknown origin.
qurren 2mo ago
You can always bundle the runtime for interpreted languages and pretend it's compiled.
AgentME 2mo ago
A command line tool in a non-compiled language is still much better than an network-connected tool in a non-memory-safe language.
veltas 2mo ago
In defense given the amount of web content being processed it makes a lot of sense to use JS and related tech. It's put to good use here.
fragmede 2mo ago
If you're gonna be particular about it, that's on you, dude. curl | bash is a stupid way to install software in the first place! But we're all lazy and it's too easy to just copy and paste that. If you're gonna be lazy about it, you don't get to complain about it. curl | less is right there!
zombot 2mo ago
It does have a GitHub link where all these questions are answered: Claude-generated TypeScript slop. So no, you don't want to pipe this into your bash.

by slowin 2mo ago

bobajeff 2mo ago

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.

slowin 2mo ago
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!).
- rbanffy 2mo ago
  I write command line tools primarily with Python and one thing I always try to do is to limit myself to the standard library, which, with Python, is quite sufficient for most of what I do. Anyway, most of what I write is designed to be installed in a virtualenv, which restricts the blast radius to one specific application.

lavela 2mo ago

Agree. If you really want to know what's used here: probably uses bun single-file executables[0] so shouldn't clash with anything else on your system. [0] https://bun.com/docs/bundler/executables https://bun.com/docs/bundler/executables

mistercheph 2mo ago
lmao curling and exec'ing a vibe coded script running in a vibe-coded runtime, what could possibly go wrong!
- otabdeveloper4 2mo ago
  Don't worry about it, it was code reviewed by Claude.

CharlesW 2mo ago

The source is prominently linked: https://github.com/gloom-sh/gloomberb 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.

rtaylorgarlock 2mo ago
Let those be the 40% we prefer less :) Revealing stack does not validate the framework, but we appreciate some foss sauce 'round these parts.
- rtaylorgarlock 2mo ago
  [flagged]
slowin 2mo ago
> The source is prominently linked: https://github.com/gloom-sh/gloomberb 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.
- cztomsik 2mo ago
  I think the point was that even Bash is interpreted.
  - slowin 2mo ago
    I definitely do not think Bash scripts should be distributed.
- alpha_trion 2mo ago
  Using JS for anything finance related is incredibly naive

deleted 2mo ago

[deleted]

talentedcoin 2mo ago

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

Pooge 2mo ago
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.
enquirewithin 2mo ago
You can have any opinion, so long as it’s mine.
- talentedcoin 2mo ago
  [flagged]
  - xp84 2mo ago
    How is it "adding no value"? It's not crazy to prefer a package manager package to a curl|bash YOLO. OP is stating that preference, which various people have agreed with. If you posted "I love curl|bash install method - please do more of this" that is also fine. Either way it's a signal for both the author and anyone considering shipping this type of software, that their audience may have a certain preference.
  - nemomarx 2mo ago
    I know it's kind of a nitpick, but is there really no value at all in "your install is just curl | bash and that seems insecure and risky" I would want to know that about any project before I try and evaluate it personally.

Pooge 2mo ago

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...

seanw444 2mo ago
Convenience. That's usually the answer.
- rbanffy 2mo ago
  One thing I dislike is that the installer wants super user permissions. That’s a big no-no with JavaScript apps installing global components. All global machine state should be managed with package managers, preferably only one package manager.
munksbeer 2mo ago
It seems to have become "the thing" to do. I can't figure out if it is bad as it feels. Why would I run `curl | bash` on something that could be doing literally anything. It feels crazy that all the lessons we've learned just get thrown away. On the other hand, just because I run `brew install someapp`, it somehow feels safer, but why? That app could be doing anything too.
- wett 2mo ago
  I just learned these two: 1. If the connection dies mid transfer, bash will still execute it. So `rm -rf ~/.local/bin/whatever` can become `rm -rf ~` The author can avoid this by wrapping everything in a function. But you wouldn’t know if they did so if you aren’t outputting it to a file first. 2. Say the link points to an S3 bucket and it gets compromised, there’s no record of the payload to analyze. I’m sure there’s a plethora of other subtleties, but I’ve always had the same question as you and thought I’d share.
zombot 2mo ago
The project is vibe-coded slop and coding LLMs are not famous for using obvious or minimalistic approaches.

alaudet 2mo ago

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.

nemomarx 2mo ago
https://gloom.sh/cloud https://gloom.sh/cloud Is it? I see some kinda subscription, so there's gotta be some non MIT portion of it
- alwa 2mo ago
  That page seems to indicate that the subscription is to a real-time data feed, rather than the software itself—am I mistaken?
  - nemomarx 2mo ago
    Unless you're paying to turn on access to purely a third party feed (which would be odd to me) there's some server side code taking those feeds and that the app is calling. Is that server code MIT licensed? An open source interface to a proprietary backend isn't really fully auditable.
slowin 2mo ago
I actually don't mean to bag on the author, but I think my complaint is valid. Maybe if they had a note right next to the curl command that said "This installs a single bun bundled executable. Here's a link to the GitHub releases if you'd like to install it yourself", that would be helpful. My point about interpreted languages stands though. These bundled javascript runtime "apps" eat at least 500M of RAM on boot. That's totally not needed for a CLI tool. If it's not bundled, then it's even worse as you hit the supply chain and tooling interference problems (and you still use the same RAM). There are a lot of good, modern, compiled languages. CLI builders should pick up those stacks imho.

tingletech 2mo ago

you can test it out with bunx gloomberb

baist0 2mo ago

yeah! agree. this shity approach when user solves technical problems.

YeGoblynQueenne 2mo ago

>> Related: please don't write command line tools in non-compiled languages! ... unless, of course, it's Perl. Right?

zeroq 2mo ago

disclaimer: I haven't seen the code TS/JS is not the problem. You can, and you should eject your dependencies and package them with your releases. And I don't understand why it's not a common practice. You can even bundle your releases with a runtime, but that's not always the best solution. For something like this I'd actually prefer interpreted code I can inspect line by line rather than having a blob of unknown origin.

qurren 2mo ago

You can always bundle the runtime for interpreted languages and pretend it's compiled.

AgentME 2mo ago

A command line tool in a non-compiled language is still much better than an network-connected tool in a non-memory-safe language.

veltas 2mo ago

In defense given the amount of web content being processed it makes a lot of sense to use JS and related tech. It's put to good use here.

fragmede 2mo ago

If you're gonna be particular about it, that's on you, dude. curl | bash is a stupid way to install software in the first place! But we're all lazy and it's too easy to just copy and paste that. If you're gonna be lazy about it, you don't get to complain about it. curl | less is right there!

zombot 2mo ago

It does have a GitHub link where all these questions are answered: Claude-generated TypeScript slop. So no, you don't want to pipe this into your bash.