61–70 of 185 posts
This site seems scam for not noting origins of llama.cpp and fails to quickly and clearly communicate it NOT being affiliated with GGML org.
> Visit https://llama.app and follow the instructions
It's linked at the start of the README.
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…
>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.
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…
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.
Not sure why it's on the front page now, but I highly recommend using llama.cpp for running AI model locally vs using other inference framework, unless you have a very specific requirement. ggerganov and the team have done a stellar job maintaining the quality while still being fast to implement new models/improvements.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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?
Earlier quoted context omitted.
>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.
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.
curl|sh is convenient for container images I guess.
Earlier quoted context omitted.
>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.
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…
Earlier quoted context omitted.
> 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, :-)
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.
Earlier quoted context omitted.
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.