undefined

points

by slowin3 hours ago |

comments

by CharlesW2 hours ago|

[-]

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.

by antonvs1 hours ago|

parent|

[-]

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.

by slowin2 hours ago|

parent|

prev|

[-]

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

by rtaylorgarlock2 hours ago|

parent|

prev|

[-]

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

by alaudet1 hours ago|

prev|

[-]

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.

by slowin2 minutes ago|

parent|

[-]

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. There are a lot of good, modern, compiled languages. CLI builders should pick up those stacks imho.

by nemomarx1 hours ago|

parent|

prev|

[-]

https://gloom.sh/cloud

Is it? I see some kinda subscription, so there's gotta be some non MIT portion of it

by alwa28 minutes ago|

parent|

[-]

That page seems to indicate that the subscription is to a real-time data feed, rather than the software itself—am I mistaken?

by nemomarx2 minutes ago|

parent|

[-]

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.

by bobajeff2 hours ago|

prev|

[-]

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.

by slowin2 hours ago|

parent|

[-]

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

by Pooge2 hours ago|

prev|

[-]

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

by seanw4441 hours ago|

parent|

[-]

Convenience. That's usually the answer.

by lavela2 hours ago|

prev|

[-]

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

by mistercheph2 hours ago|

parent|

[-]

lmao curling and exec'ing a vibe coded script running in a vibe-coded runtime, what could possibly go wrong!

by otabdeveloper42 hours ago|

parent|

[-]

Don't worry about it, it was code reviewed by Claude.

by 2 hours ago|

prev|

[-]

deleted

by tingletech1 hours ago|

prev|

[-]

you can test it out with

  bunx gloomberb

by talentedcoin2 hours ago|

prev|

[-]

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

by Pooge1 hours ago|

parent|

[-]

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.

by enquirewithin1 hours ago|

parent|

prev|

[-]

You can have any opinion, so long as it’s mine.

by talentedcoin1 hours ago|

parent|

[-]

Why should anyone care about your opinion if you are adding no value to the conversation?

by xp841 hours ago|

parent|

[-]

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.

by nemomarx1 hours ago|

parent|

prev|

[-]

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.

by tealmoonx1 hours ago|

prev|

[-]

[flagged]

by slater1 hours ago|

parent|