Item — HN Reader

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.

15 comments

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

In case the author is, like so many people, sensitive to this kind of criticism, I will say this:

Thank you for giving the world your free software. Feel no compunction to undertake extra work to please people who criticize your work. They are not paying for your software and are not paying your bills. If your install eats enormous amounts of ram or uses a programming language they do not like, that is their problem. In your case for example they are free to get Bloomberg.

If you want to do free work to please critical people, ok. But I wouldn’t bother. Thank you for all the work you did to write your software and then the even more work you did to share it. I write my own software but don’t bother sharing it because it’s a lot of work, so I appreciate you.

I don’t know, man. Maybe if they’re that sensitive to criticism they should leave the industry.

This kind of hug boxing might have been fine five years ago during the ZIRP era, but in an age where two sticks of RAM is becoming $800 (and data centers are causing dirty sin power that can wear down electronics), I think the developers have a duty to be efficient with their programs and to do what is necessary to not ship a 500 MB ram sink with every single app.

It is frankly unforgivable and it’s a drain on the skill of the industry to just say “yeah no man it’s OK. It’s OK don’t worry don’t worry about your app being completely inefficient and a drain on your users resources. Don’t worry about it. Your app is so good that nobody will ever be using any other application on their PC“

Is this developer paying for my RAM? I run local models on consumer hardware. I can’t afford a 500mb of RAM for a CLI app. Thank you for that. Thank you for writing your CLI software in a way that I have to close it in order to use other parts of my computer.

Not to mention interpreted languages are slower than compiled languages, and we are talking about a financial terminal. Talk about not even understanding the functional requirements of the thing you are building. I might go get Bloomberg terminal instead of this just because I know it’s gonna actually be faster and make me money. This might actually lose me money.

Just because they built an application that “competes” with a closed source tool does not mean that their open source tool is good or worth adopting.

I mean, have some respect for and actual thought about who your end user is.

Imagine in the 80s or 90s telling a software developer not worry about porting their Amiga fintech application to another architecture like sparc. Imagine telling a developer in the 90s and 00s not to worry about browser compatibility and thanking them for making it only for IE to protect their fragile ego.

Imagine telling the creators of UNIX “yeah, no PDP 11 is good. You could stop there anyone who wants to run it on a different architecture is just an ingrate who doesn’t respect the effort you put in.” Because they already did so much work.

This is a farce. GP had a valid constructive criticism and a valid input worth considering when you take into account the functional requirements of a financial terminal.

Just because you are willing to cut corners on things that you don’t release does not mean that it is OK to release a piece of software with cut corners. But you know that, or you would release your software. I’m certainly projecting because I know that that’s why I write tools for myself that I don’t publish, but even then I use compiled languages and go out of my way to avoid JavaScript type script, python, and all of that.

But if this project were to ever take off and they were to monetize or start charging enterprise licenses the very first thing I would ask for is the compiled version that doesn’t rely on interpreted languages or a 500 MB node folder.

https://gloom.sh/cloud

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

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

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.

It's a completely legitimate complaint. If anything, it's an even stronger complaint because of the lack of provenance. And even stronger when you consider that there is intent to monetize: https://gloom.sh/cloud

It doesn't take a genius to realize this entire project was probably vibe coded. What does the script actually do? What assumptions does it make about the user's system? Has any human actually looked at it to figure that out?

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.

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

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

Using JS for anything finance related is incredibly naive

I think the point was that even Bash is interpreted.

I definitely do not think Bash scripts should be distributed.

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

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.

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

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.

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.

Convenience. That's usually the answer.

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.

The project is vibe-coded slop and coding LLMs are not famous for using obvious or minimalistic approaches.

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

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

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

you can test it out with

  bunx gloomberb

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!

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.

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.

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

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

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.

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

... unless, of course, it's Perl. Right?

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

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.

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