Thread

Run Qwen 3.8 Flash Next (125B) on consumer hardware (RTX 4090) at 100T/s

741 points · 330 comments · snehesht

deadbunny · 1791120801 · focus · HN ↗
> Set up Strata on this PC for me: <a href="https://github.com/Niko1221/Strata" rel="nofollow">https://github.com/Niko1221/Strata - follow docs/AI_SETUP.md in that repository.
And I thought piping to bash was bad
1. snehesht · 1791120880 · focus · HN ↗
  Yeah, I was surprised at first then had to dig through setup.py and setup.sh files to figure out.
2. gchamonlive · 1791121597 · focus · HN ↗
  Piping to bash is definitely worse because there is no plan mode in bash. Agents also normally don't execute anything transparently, at worst you'll see it doing something weird in the logs.
3. Skunkleton · 1791126347 · focus · HN ↗
  I've never understood the security argument people are making when they complain about `curl foo | bash`. I get that these scripts sometimes mess up your bashrc or whatever, but from a security perspective I see no issue. You are already installing software from the same domain. If they were going to do something nasty, they could do it with any of the software you are using from them. It doesn't have to be the setup script.
  1. spiorf · 1791126793 · focus · HN ↗
    People with less experience normalize that behaviour and when the domain is not trusted the habit let their guard down. See all the clickfix attacks.
  2. sspiff · 1791126870 · focus · HN ↗
    The setup script often runs privileged (by calling sudo) and that's not unexpected when installing new software.
    When I install something, and it asks for my root password later, I will be much more likely to think "hold up, this ain't right".
    jeremyjh · 1791126986 · focus · HN ↗
    Can you give me a popular example that requires sudo? I don't think that is very common at all.
    serf · 1791127102 · focus · HN ↗
    every single bash replacement for one.
    oh my zsh is a specific example.
    chsh requires sudo on most installs.
    minitech · 1791127618 · focus · HN ↗
    cat >> ~/.bashrc <<'EOF' sudo() { sudo install-drivers-without-your-permission command sudo "$@" } EOF
    (this is not an endorsement of curl | sh, just an indictment of the state of software)
    nagaiaida · 1791135328 · focus · HN ↗
    when people left their laptops unlocked, we used to wrap their sudo so that the output would be pre- and postfixed with ascii dolphins
  3. serf · 1791127149 · focus · HN ↗
    a script isn't getting hashed to see whether or not it's the one the website intended to serve you, for one.
    what use is hashing every piece of software that goes thru the distros package manager just to throw caution to the wind at the layer above it?
    w.r.t. "it's already from the same domain" , well most bash/z install scripts either invoke a package manager or they download and untar a package that has nothing to do with the host domain, anyway.
  4. layer8 · 1791127281 · focus · HN ↗
    I push binaries from untrusted sources through VirusTotal before running them. Piping a Bash script from curl bypasses that. Furthermore, such Bash scripts, when they aren’t self-contained, make security checks more difficult than a self-contained archive, installer, or binary, even when downloading the script without immediate execution.
    Iolaum · 1791127473 · focus · HN ↗
    Nothing is stopping anyone from pointing their agent to that script to review and audit it before running it.
    layer8 · 1791127676 · focus · HN ↗
    I don’t believe an agent can do that effectively without a sandbox to run the script in, if the script isn’t self-contained.
    And everyone running a research agent on every download can’t be the solution. It’s much more effective to crowdsource a security database based on hashes. But for that, the downloads need to be self-contained.
    parsimo2010 · 1791129389 · focus · HN ↗
    You could always curl the install script, and modify it to run the virus scan in between the build and install steps.
  5. thomastjeffery · 1791127953 · focus · HN ↗
    The real problem is that we just aren't using package managers. We should be using package managers. Package managers are really really good.
    [deleted] · 1791128040 · focus · HN ↗
    [deleted]
  6. ffsm8 · 1791128634 · focus · HN ↗
    You can detect the use of curl|bash server side, hence it's an essentially undetectable attack vector. People have shown poc attacks of that kind all the way back in the 2010s
    <a href="https://news.ycombinator.com/item?id=17636032">https://news.ycombinator.com/item?id=17636032
    The original blog is no longer available though.
    But I've not had that stop me from doing that myself, I am more towards the "I like easy" then the "I want to be secure" crowd
    wsc981 · 1791129571 · focus · HN ↗
    There’s a snapshot on web archive:
    <a href="https://web.archive.org/web/20250109045029/https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-bash-server-side/" rel="nofollow">https://web.archive.org/web/20250109045029/https://www.idont...
    throooooo · 1791136736 · focus · HN ↗
    How would you do that? Just rely on the user agent? I use curl quite a lot, but don't pipe to a shell.
  7. minitech · 1791128945 · focus · HN ↗
    To compare it to just one other option: when you run `npx foo`, you know* that you’re getting the same public artifact that anyone else running it at the same time would get. (If you have a `min-release-age` configured, you also benefit from that.) If I wanted to distribute software like this, I’d include npm-shrinkwrap.json; then, with `npx foo@1.2.3`, you could be similarly confident in getting the same app every time.
    (I picked this option for ease of comparison, getting a couple of major security wins with very low effort; I don’t recommend `npx`ing stuff in an otherwise unprotected environment either.)
    * well, you can be somewhat more sure
    athrowaway3z · 1791130561 · focus · HN ↗
    So to be clear; the solution is then something like
    `curl <a href="https://raw.githubusercontent.com/my/domain/setup.sh" rel="nofollow">https://raw.githubusercontent.com/my/domain/setup.sh | sh`
    Note we dont even have a hash there - just a promise that a third party (github) has a log of whatever was hosted at that url.
    nagaiaida · 1791135554 · focus · HN ↗
    maybe then we'll pin hashes instead of filenames, and oops now anybody can fork my/domain and hand out a link that looks official with whatever contents they wish
    slowin · 1791133210 · focus · HN ↗
    While I don't think piping curl into bash is the most secure, npm installing has proven time and time again to open yourself up to supply chain attacks. At least with curl you know that you're getting the supply chain put together by the software author. With npm, every single library is a vector for attack every time you update.
    minitech · 1791133552 · focus · HN ↗
    You’d be getting the supply chain put together by the software author in either case. It’s common to do both badly, but if you care about doing it well, that’s easier with npm (e.g. shrinkwrap, as mentioned) and can be taken farther (the non-varying artifact thing).
    slowin · 1791135641 · focus · HN ↗
    Npm dependencies resolve at install time though, so some of the pinned versions may have changed ownership or otherwise been modified since the author pinned them. With the curl | bash solution you're getting a singular supply chain packaged by the author at release time.
    cpuguy83 · 1791138333 · focus · HN ↗
    With curl|bash you are literally getting anything that happens to be in that script. These are frequently poorly constructed, so not check hashes or pin dependencies they install. Even security companies (see trivy supply chain attack) get these badly wrong.
    I'm not replying here to say one is better than than the other (npm has obviously had its share of problems) but rather to combat claims that curl|bash is somehow safer, it absolutely is not, in fact it's all the bad stuff about npm without the pretense of being potentially safe.
  8. rlpb · 1791129694 · focus · HN ↗
    It's `curl foo | sudo bash` that's the bigger objection. Running software usually shouldn't require root, and then the equivalence argument you make doesn't hold.
  9. bee_rider · 1791133988 · focus · HN ↗
    The intended workflow is to download the install scripts, download the source code, read them both, and then start running things. That’s how Open Source is secured. Piping from bash to curl is just the most obvious warning flag.
    majorchord · 1791135288 · focus · HN ↗
    And practically zero people are actually using this "intended workflow" in the real world.
    bee_rider · 1791138133 · focus · HN ↗
    Yes, the status quo is quite bad, which is why it gets complained about a lot.
  10. IshKebab · 1791139073 · focus · HN ↗
    There is no argument. It's just people's reflex reactions.
    The technical excuses they come up with (e.g. that the server can detect it and send different content) are just post-hoc justifications for their instinct.
    Just ignore them.
4. mrinterweb · 1791136269 · focus · HN ↗
  And yet people will let AI agents run autonomously on their machines. I feel like we're reaching peak YOLO with security.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.