Hacker News Reader

Comment by denysvitali | Hacker News Reader

Their installer (curl | sh) was taking so long yesterday for me.

It turns out it's incredibly slow... because of the progress bar rendering. This is insane. The installer took 6 minutes to reach 10%:

curl -fsSL https://opencode.ai/v2/install | bash

Managed to fix it by running this instead:

curl -fsSL https://opencode.ai/v2/install | bash 2>&1 | cat

View on HN

I suspect heavy eyes free coding. I spent the last week helping them understand a major security regression in config loading, took two issues/pull requests. Our hunch is the Ai told them what they had was good, not enough human critical thinking.

https://news.ycombinator.com/item?id=50075319

I've switched to Pi because I do not like the direction v2 has taken UX. Nor do I trust the security posturing going forward. There is also the social media stunts of the CEO that push me away.

I'm now trying to advocate Pi adopt system level configuration for similar security reasons. If any HNers would like to add their thoughts, please do so here

https://github.com/earendil-works/pi/issues/10895

Ive anecdotally never found OpenCode to have a real axis where I find it "best". But I havent tried it in a bit, mostly because I don't have a real gap in use case coverage between Codex/CC/Pi. Anything more specific in need probably gets a custom harness.

Maybe the Go plan is changing that for others?

The Go plan is quite good, possibly the best deal out there. I recommend it for anyone interested in trying open weights ($10/month, very generous quota), and you can use it with any harness or direct curl. I have my Go sub configured through GoModel (no relation, my gateway of choice, also very good).

Isn't that an issue with your terminal? Why is stdout so slow?

I think it's due to they are doing a funny business to parse the progress, that's pretty much vibed and no one care. Like instead of using curl's progress, they re-invented a progress tracking with the tracing interface (--trace-ascii), byte by byte :(

https://github.com/anomalyco/opencode/issues/22998 https://github.com/anomalyco/opencode/issues/53702

Okay nevermind this is pretty bad. Although humans do this too and I've also done this without realizing it, only noticed when I was trying to move a file bigger than few kilobytes.

I’m kind of surprised at the overlap in “has progress bar” and “is expected to take a few seconds max”.

I’ve never even debated it for files under hundreds of megs. It’ll show up soon, if I care I’ll do an ls in a loop to look at file sizes. Just log where the file is.

It's one of those paradoxes inherent to software development: even if a tool is designed to work with Big Data, developers are too impatient / feel too unproductive to actually work with Big Data during development, so they only bother testing their tool using small data for 99.9% of development. Problems the tool has under actual Big Data tend to only start being found as of v1.0-rc1.

it's also an inherit bash problem where what you write is what you get, there's no buffer to keep you from slowing something down to a crawl.

I don't think fast gpu rendering terminals should be mandatory for this kind of thing, and if you should have an option that facilitates the need for one then might I suggest falling back to something sensible rather than stalling out for forever when the user doesn't render glyphs as fast as you want them to?

either that or fail outright; dont waste my time.

My terminal has gpu acceleration disabled due to being wasteful with vram and while I don't use opencode I've ran the script and it was completely fine using minimal cpu.

If it doesn't work at least ok with something like xterm, someone really needs to reconsider some life decisions. Htop makes it work, why should a terminal emulator need to crack the engima just to render silly stuff?

Well, stdout is not typically implemented for the purpose of simulating graphics rendering via character manipulation.

https://github.com/ChrisBuilds/terminaltexteffects

All of the common terminals run TTE surprisingly well. That's 60fps, pushing many megabytes per second of text and control sequences.

htop? btop(meh)? iotop? docker build?

...

claude code?

htop and similar TUIs have a refresh rate of 1 frame per second

anything that can run those applications should be able to run a progressbar, but as I have learned it updated the progress bar based on bytes received and not based on time.

Sounds like I'm not upgrading then. My current OpenCode works perfectly and too many life experiences with "don't fix something that ain't broke" ;)

Of course? I never ever upgrade any software unless I'm facing a bug or I want a new feature from the new release. Otherwise it's just taking risk for almost nothing in return.

My laptop fan went nuts on their homepage.

On my phone I can't scroll there. I left again

If you have Nix, you can run it using:

    nix run github:juspay/agent-distro

https://agent-distro.nixos.asia/ brings auto-updating coding agents managed by Nix, along with https://agent-plugins.org/ based profiles.

and they probably haven't stopped hijacking copy paste.

Yes this is why I'll never use the TUI.

The full gui app is decent though.

probably my single biggest beef with their client and why i don't use it all that often outside of non-interactive mode

you are correct, still hijacking

And they created the slowest webpage on the planet Earth. Full throttle slop.

This is a you problem

time curl -fsSL https://opencode.ai/v2/install | bash

real 0m24.975s user 0m9.537s sys 0m14.904s

They might have fixed it in the meantime though

Edit: indeed https://github.com/anomalyco/opencode/commit/d099d2cb2a0869d... / https://github.com/anomalyco/opencode/pull/55586

Reply on news.ycombinator.com