Item — HN Reader

Anything that suggests curl into bash just plain sketches me out. (edit: I know, this isn't totally rational, it just seems weird to me. We download and trust a lot of software and run code from a bunch of package repositories as a regular activity...).

Git clone llama.cpp and build it, it's not hard.

https://github.com/ggml-org/llama.cpp/blob/master/docs/build...

literally just a few steps for the basics:

git clone https://github.com/ggml-org/llama.cpp

cmake -B build

cmake --build build --config Release

9 comments

>Anything that suggests curl into bash just plain sketches me out.

How is it different than trusting any other method of installation? If URL has https and is from an author you trust i dont see the difference.

Package management provides cryptographic attestation over the entire process, including the scripts run. Nothing is arbitrary nor mutable in the default state. The files touched will be in a predictable place and the scope of privilege escalation is clearly defined.

But he’s not using a package, he’s downloading from gir repo and build which exactly same getting a bash script from the same repo and executing it.

It’s not. Try pulling updates after a rebase. Very much not the same as piping arbitrary disembodied text into your shell.

Except the first time you do it

>Nothing is arbitrary nor mutable in the default state.

What do you mean with this?

It's more about installation location for me. For these types of projects, I don't even install it. I just clone, build and run from there. I have no idea where the bash script is going to put things.

Which also makes it not obvious how to uninstall it. pip/npm/cargo etc have well known mechanisms for that.

curl|sh is convenient for container images I guess.

I mean it's probably not, I just haven't got used to it yet. It's about the same level of security as installing a windows app on win2000 25 years ago and blindly downloading a .exe off the internet and running it to get into the install wizard. But indeed I also kind of blindly trust that whatever I'm getting from the debian trixie officially gpg-signed packages isn't backdoored.

One thing I do not do as a matter of practice is install things with a ridiculous number of recursive npm dependencies.

I do not blindly trust anything, and come to the conclusion that downloading binaries from Debian trixie is a lot more safe. There is a world of difference between "curl | sh" and downloading from a curated package repository maintained by a respected community with well-defined processes.

Rendered text cannot be assumed to equal the underlying text, unfortunately

How so? As i understand your point, this would mean we cannot trust GitHub enough to return the same content in git clone vs curl?

As an example, webfonts can make rendered text differ from the underlying text that ends up on your clipboard.

Sure, but doesn't this assume that you cannot the publisher anyway? So why would you not trust their homepage but trust their source-code

Download and inspect it.

There are also prebuilt binary archives for just about any distribution and inference backend for the latest github release:

https://github.com/ggml-org/llama.cpp/releases

No need to compile unless you really need to.

This. I use mise's github backend `mise use --global --pin github:ggml-org/llama.cpp` to grab the release binaries for Linux, Windows and macOS.

> Anything that suggests curl into bash just plain sketches me out.

Yeah, 100% and it's becoming more and more of a thing, see rust install for example.

OTOH, if you're installing llama.cpp, you're more than likely planning to run an LLM on your Linux box with an agentic harness, so a curl into bash thing might be the least of your security concerns, :-)

One way I prevent possible catastrophic fuckups is that the 'doing code work' box that runs opencode or pi or whatever, is its entirely own separate VM and desktop environment (running as a xen or kvm guest and with its own LVM logical volume as boot/root and /home disk), than the machine running llama-server itself.

The harness gets the openai-compatible endpoint fed into it to talk to llama-server across the network, but the VM has no access whatsoever to my personal files, mail, backups/deep storage, fileserver, Documents folder, etc.

> security concerns

Yeah I recently tried the coding harness that's recommended here, Pi, in a bubble wrap sandbox and was horrified to learn that it spams multiple warnings at you if you don't give it write access to its own config/extension folder... Everyone else is rawdogging it I guess.

I think the best course is a docker container or a VM, i agree with the sentiment but trying to restrict the permissions of these things is fighting an uphill battle, it’s probably best to let them reign king in a disposable and isolated environment

You are horrified it needs access to its own stuff? I mean, any software that supports plugins needs access to them, no? How is that unreasonable? And with bwrap that’s an extra cli option.

It's okay-ish for Rust because you only need the curl|bash for Rustup, which is meant as a development environment. On production you can, for example, use APT to download it from Debian.

Backdoored developers are ok?

Yes, as long as their development environment is isolated and they can't push to prod without a review.

Absolutely, and it's even worse when you are asked to blindly download and run software like the Brave browser, which is open source but exclusively packaged and distributed by an adware company with a questionable history. The software itself is open source, but independent builds seem to be discouraged and no Linux distro packages Brave as a result. I built it myself in the past, but it takes close to two hours on a workstation and isn't worth the effort to keep it updated.

so instead of downloading a script with curl and running it with bash, you should download it with git and run it with cmake? if you aren't reviewing the code between download and execution, what's the difference?

You can also install it through homebrew https://formulae.brew.sh/formula/llama.cpp

doesnt look like it is the desktop app, its just cli

    brew install --cask llama-app

https://formulae.brew.sh/cask/llama-app

You're not wrong about the appearance of sketchiness of that, but.... dude, come on. "It's not hard" is only true because you already know how to do it.

Exactly. That way of assuming everyone is a seasoned dev or sysadmin always baffles me. There are a ton of tinkerers out there, we are legion, and we are often reluctant to ask, especially here (as suggested by another parallel comment) because we don't want to receive an answer like this. Full circle.

If you’re unsure how to do it, you can ask others for help or Claude will tell you.

Point Claude Code at a repository and ask how to install it safely. You don’t have to know about make or cryptography of HTTPS or anything, really. It will walk you through the options and risk.

If you have questions about any part of it—i.e. you don’t recognize an acronym or deeply understand why something works—you can ask.

Or ask here! HN is filled with smart humans.

GP is saying "it's not hard", yet you seem to be hearing "you should already know how to do this without ever looking it up".

Those aren't the same assertions.

It's not a sensible assumption that a process must necessarily be difficult or complex just because you don't already know how to do it. There are an unenumerable number of tasks each of us don't know how to do and have never done before which are not difficult at all.

Yes, and that's exactly why the curl|sh exists; you don't need to know the weird esoterica of a 26 year old piece of software. Accessibility matters.

>you don't need to know the weird esoterica of a 26 year old piece of software

You really don't need to know much at all in order to compile llama.cpp. You can literally ask any half decent AI agent to do it for you or give you a step by step guide, and troubleshoot any error you get.

Have you not met anyone who would disown you as a person for suggesting that?

Of course not. That's as absurd, nonsensical, and dogmatic of a position to hold as disowning someone for being gay, or disowning someone for being the wrong religion or race. I tend not to associate with extremists and zealots, regardless of their preferred cause.

Just about everyone I associate with personally is polite, kind, and friendly, and everyone I work with professionally is too serious of a technologist to dismiss the most transformative technology of our lifetimes to date.

I know some people who'd oppose datacenters going up in their neighborhood or town, but nothing as bizarre or irrational as disowning someone else for merely using AI.

It's literally three steps, assuming you have the equivalent of the debian "build-essential" dependencies installed on your system for cmake, compiler. It's the exact three rows of my post, pasted one at a time into the CLI. The llama-server build guide page is actually pretty good.

I mean, sure, if there's people who can't figure that out, they're probably better off using a GUI that is a wrapper on top of somebody else's precompiled llama-server, like unsloth studio or lm studio. There's a good sized market for that and I wish them well.

You're right about all of that up until the point any one of those commands doesn't work and you get a garglblargl amount of incomprehensible error messages. You've been in the sauce for so long that you've forgotten what it's like to start fresh in these things.

Please give it a try before you assume it won't work? Tell me what platform you're on and follow the three sequential cli commands I provided, and if it doesn't compile I'll be glad to look at your error message and get it going in the right direction.

You're missing the trees for the forest, friend. I know how to troubleshoot this stuff. I wouldn't expect some random schmo who's just learning ubuntu for the first time to be able to.

This, "just run these three commands" attitude is exactly the reason why these curl|sh "installers" have become popular.

What would you win? Cmake is capable of executing shell commands and you end up with a binary that will execute on your machine anyway. At the end of the day it is just a matter of trust anyway, isn't it? I personally use bwrap if I'm not confident about the source.

Cloning a repo and building it is not _that_ hard, but easy installation is often the thing that makes or breaks a product. I believe Ollama proves that point in this context.

Mostly agree but at least with git clone you have a hash and the malicious code has to be served to everyone, and GitHub is less likely to get hijacked by a malicious third party.

But yes, still trusting the project with arbitrary code execution on your machine, including build formulas that pull stuff from the internet and suffer from all the above anyways

it's also on the arch repos