| |
| ▲ | epistasis a day ago | parent | next [-] | | I haven't tried opencode, but when I opened pi I was able to complain about that silly and stupid left-padding that LLM TUIs have started using that prevents basic copy-paste operation, and pi was able to edit itself to fix it. So I'm sold on that level alone. Good stuff. | |
| ▲ | zipy124 a day ago | parent | prev | next [-] | | They are different models. OpenCode is trying to be a claude code/codex replacement, where-as pi is something you build yourself, kind of trying to be an emacs type thing compared to vs-code. As in emacs it is more common to write your own extensions, where as in vs-code most people just download them. | | |
| ▲ | agentdev001 a day ago | parent [-] | | I keep butting into the question of; why opencode, when you've got codex available? Codex is open source as well, and i can't seem to picture a situation where one would want Opencode over Codex. As far as I can tell, they tick the same boxes- but one has the support of a big boy model provider. | | |
| ▲ | coder543 a day ago | parent | next [-] | | Well, the reason is simple: over the past several months, it has become very difficult to use Codex with non-OpenAI models. They removed the old edit tool that didn't require OpenAI's free form tool calling (that no other LLM host supports), they are adding tools to every request of a type that break most LLM hosts unless you use a proxy to filter them out, they add a "developer" role to some messages which breaks some chat templates, etc. If someone wanted to fork Codex and make a community-maintained version that supports third party models, that would be great, because I liked Codex better than OpenCode for the most part. Maybe you've found workarounds. Maybe you're using an old version of Codex. Maybe you have your own soft fork. I don't know. But I used to be able to use Codex with self-hosted models, and I gave up on that about a month ago as they kept breaking that. | | |
| ▲ | agentdev001 a day ago | parent [-] | | Ah, I wasn't aware things regressed there. Yea certainly workarounds n soft fork sorts of things definitely would work- but thats a bummer than things have changed. From watching Pr's and issues- seems like openai at least wants to come across as if theyre supporting non-oai models :/ | | |
| |
| ▲ | Carrok a day ago | parent | prev [-] | | If you care about privacy at all, you can route your Opencode requests through an inference provider that does not retain any logs or data. It is also much cheaper. So if your boxes include `Privacy` and `Affordability`, then no, they don't tick the same boxes. | | |
| ▲ | agentdev001 a day ago | parent | next [-] | | You can use the Codex harness with non-openai providers if you want. | | |
| ▲ | arcanemachiner a day ago | parent | next [-] | | Pretty sure you need to use an older version of Codex for this to work. | |
| ▲ | girvo 20 hours ago | parent | prev [-] | | Not very well, if you're using the latest version of Codex. They broke a lot of stuff that made that possible. |
| |
| ▲ | cromka a day ago | parent | prev [-] | | I think they meant using Codex with non-openai providers? |
|
|
| |
| ▲ | sometimelurker 20 hours ago | parent | prev | next [-] | | Ive tried both, and pi's core is a lot smaller but can be extended to have as many features as opencode. personally I like using pi with llama.cpp, and use stuff like pi.dev/packages/pi-llama-cpp-stats to combine them better. there's a lot of stuff you'll feel like pi is missing, but its just optional. | |
| ▲ | trollbridge a day ago | parent | prev | next [-] | | oh-my-pi is a bit of a cross between the two; comes with basically everything OpenCode does, but still easy to customise. OpenCode is nice if you don't want to do a lot of research and just want to get started right away. The OpenCode Go plan for $5 a month for your first month is a great way to do this, with good models to choose from and reasonable usage limits for a beginner. | | |
| ▲ | cromka a day ago | parent [-] | | I use Go plan precisely with Opencode IDE (and also Jetbrains IDE suite), but now also have access Gemini Pro and Claude Pro. And wonder which tooling to invest my time into, especially that MCP servers also potentially come into play here, and I want at least some models/tools to handle private tasks, like handling my increasingly-complex Home Assistant setup. And I also want to start using models according to needs (plan, execution, reviews). This shit gets extremely complicated extremely quickly, not to mention how often this field shifts direction. | | |
| ▲ | trollbridge a day ago | parent [-] | | I use “all of them”. My primary harness is oh-my-pi. I probably use 10 different models on a regular basis. I occasionally use OpenCode. I try to use Codex and Antigravity as much as I can, often using it as a secondary agent (due to different usage pricing models than API). The same skills and MCPs work across harnesses. Edit: I don’t use Claude Code simply because I already have enough to deal with and don’t see a major advantage to their harness. I use Opus credits from my Google subscription on the rare occasion I need them. Cursor is also worth checking out particularly at the $20 a month price tier. If you have Grok you effectively already have it too. I expect to have a completely different answer a year from now. The main “lift” we’ve gotten from AI tools is our clients now get an Android + iOS app + macOS app + Electron + PWA to go with whatever web based app they want us to build, at essentially the same original price. (There’s also a CLI and a TUI, but so far none of them care about that…) We just made the decision to start adding MCPs to apps. Gonna be an interesting conversation in a few weeks when I can tell my business contact he can use his favourite chatbot to now plug in directly to the custom app he bought from me. | | |
|
| |
| ▲ | kordlessagain a day ago | parent | prev [-] | | I like it. One caveat is that it doesn't do MCP tools, but can wire them up with bash (or use CLIs if those are available). |
|
| |
| ▲ | mik3y a day ago | parent | next [-] | | I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. Homebrew, to name just one example, advertises a similar method. (pi.sh also documents other install methods, like `npm`, on their homepage) If trust and security is the issue, unfortunately "better" ideas like hashpipe [1] never achieved critical mass [1] https://news.ycombinator.com/item?id=9318286
| | |
| ▲ | NekkoDroid a day ago | parent | next [-] | | I really hate the `curl <url> | sh` specifically because if your connection drops at a specifically unlucky point in time you are left with a partially executed script which if you are unlucky enough may just have been executing `rm -r ~/.cache/<pkg>/download` but it stopped at `rm-r ~/`. Is it likely? No. Can it happen? Yea. Just make it `curl -o <file> <url> && sh <file>` and this entire problem is gone. | | |
| ▲ | cyberax a day ago | parent [-] | | Most scripts now put all the code into a shell function and call it in the last line of the script, so this bug can't happen. | | |
| ▲ | msdz a day ago | parent [-] | | Correct, and/or in addition, most nowadays prepend something like `set -euo pipefail` to the scripts in the line immediately after the shebang which results in stopping on errors, including things such as syntax errors stemming from e.g. incomplete installer transmission over wire. (At least for bash scripts, I’m not sure whether these are POSIX syntax to be frank.) |
|
| |
| ▲ | TacticalCoder a day ago | parent | prev | next [-] | | > I am genuinely curious what it tells you, as "curl https//.. | sh" has long been an enormously popular approach to distribution in the open source world. It's plain horrible. You could have, for example, a compromised server serving malware but only one out of every 100 download. The only signature you rely on is TLS. Proper package distribution are using proper signatures schemes, are decentralized, even for some offer reproducible builds (meaning you can rebuild the whole package yourself and verify your build matches), etc. Hashpipe is an attempt at reproducing some of those guarantees. Not unlike container pining using hashes. It at least fixes the "Jack and John installed this already and I know I'm getting the same version as they did". Proper software distribution is signed, reproducible and ideally also uses some proof-of-existence for the hashes. My bet is this: in the face of the countless supply chain attacks, we'll see more and more people getting very serious about security, including the security of software distribution. And curl bash'ing won't be part of it. | | | |
| ▲ | tovej a day ago | parent | prev [-] | | What about better ideas like installing from source, or using a package manager? Or even flatpaks. | | |
| ▲ | arbll a day ago | parent | next [-] | | From source: creates much more work for the user. Package managers: ecosystem is fragmented, requiring a long list of distro- and package-manager-specific instructions. Many scripts already install through package managers, they simply make the user’s life easier. Flatpaks: These are clearly designed for desktop applications, with CLIs treated as an afterthought. They may be the best long-term hope, but today they are definitely not as convenient or widely available as a simple script. If you care about adoption, `curl | sh` is the only real option today, which is why virtually all project show it as the first option. | | |
| ▲ | tovej a day ago | parent [-] | | Bullshit. There's plenty of big projects that don't suggest you curl a script right into your shell. If you have curl, you're probably on Linux. Just use the package manager like an adult. | | |
| ▲ | arbll a day ago | parent [-] | | The "like an adult" is what has and will continue to hold back linux on the desktop. Always gatekeeping less technical users instead of acknowledging adoption and ease of use are critical. | | |
| ▲ | pluralmonad a day ago | parent | next [-] | | Is this stance gate keeping users? Isn't a pkg manager installation also a one liner? This seems more like gate keeping lazy distributors. | | |
| ▲ | arbll a day ago | parent [-] | | A lot of those scripts are wrappers around package managers. Creating them is extra work for distributors, but they still do it because package-manager installs are not truly one-liners and offer far less control over the installation experience. Users need to figure out which of the 10+ package managers they should be using, then run several commands. If something fails, the error messages are often cryptic and not easily configurable by the distributor. And that’s before getting into the many rough edges of package managers. Most of them flat-out refuse to handle configuration and leave that part to the end user. Now you also need to document how to edit YAML and restart a systemd service. With an install script this is also solved. For power users, this always looks trivial. In practice it raises the barrier to entry and can meaningfully affect adoption if your product is often used by less technical people. | | |
| ▲ | tovej a day ago | parent | next [-] | | Your arguments do not make even a little sense. In what world does a user have to choose between 10 package managers? Each distro has exactly one. There are also only about three, maybe four main package managers out there. A shell script being piped into bash has so many more ways to break than a package. And if yhe theory is that package managers are fickle (they aren't), then how does adding more complexity help? It is much simpler, much safer, and easier to maintain a package than an install.sh, eapecially for a big project. Configuration can be handled by a script, yes. Here's a crazy idea: Your package can include scripts for configuring the software. It's almost as if most packages do. The scripts/utilities could even restart a systemd service for you. Unless you're talking about configuring your build, in which case we're dealing with an experienced developer who will have no trouble just cloning the repo and building from source. My biggest issue is: if we're dealing with someone who can't use a package manager, we're dealing with someone who doesn't have the capacity to judge how safe a script downloaded off the internet is. This does not drive linux adoption, it drives botnet adoption. | | |
| ▲ | arbll a day ago | parent [-] | | It's crazy to me that even after seeing so many major software distributors choose `curl | sh` as their entry point, people like you will still argue to the ends of the earth that there’s no problem with the package manager ecosystem. I'll stop there. I'm not interested in continuing this discussion when it's being conducted in bad faith. | | |
| ▲ | mik3y 21 hours ago | parent | next [-] | | Bad faith, or perhaps just ignorance. It reminds me of purist junior engineers - and I have been one - refusing to understand or tradeoff in the world beyond their own. Rather than argue with those of us who are pointing out messy realities, this commenter might be better served filing a bug against any number of the projects that offer installation this way, asking them to remove it, and see if it lands any better. Technical purity/superiority isn’t the only factor, or even the most important one, driving projects to offer quick installers like this. | | |
| ▲ | tovej 12 hours ago | parent [-] | | I would appreciate it if you would respond to me directly rather than suggest vaguely that I'm inexperienced and don't understand the realities of software distribution. I would also appreciate it if you actually talk about something concrete rather than simply claiming to be right. You shouldn't pipe stuff from the internet into your shell. Are you claiming that's about some highfallutin "technical purity"? Is it technical purity to check inside the bag when you buy a pig in a poke? No, that's common sense. It's common sense to have some degree of knowledge about what programs you execute on your computer. As root, at that. | | |
| ▲ | mik3y 3 hours ago | parent [-] | | Sure: I think you're essentially missing a whole set of concerns - ones that are not purely technical - behind why this method is popular; and so your arguments wouldn't convince someone actually responsible for one of these scripts to change or cease the practice. Nobody would argue that it's categorically safe/good/smart to blindly pipe a script into your shell; and for the record, I agree. I would also readily agree that habituating users to doing this probably creates new, more general risks especially among how less-technical users interact with their CLI. However, the realities of the "real world" make it popular for a reason, in light of those negatives; tons of scaled projects continue to offer a 1-liner. So we have to ask, why? They'd probably say that's because it (a) improves project adoption, and (b) reduces "install broken" tickets. You have to address the non-technical merits and goals to get behavior to change here, and sadly, I don't think anyone has done that. But who cares about me? I'm not currently maintaining one of these (though I did once). My suggestion to bring your argument to an active project was genuine: try it! I'd be delighted to see you bring about the change you want. [PS: The commenter I replied to originally used the term "bad faith", which they've since edited] |
|
| |
| ▲ | tovej 12 hours ago | parent | prev [-] | | The fact that people do something doesn't make it good. I am arguing in good faith about the merits of the approaches. I am engaging with the points of argument being brought up from the opposing side of the argument (see above). I am not veering off on side-tracks, unlike you, for example. There' a simple good faith argument (that I have been making) which you can try responding to: Running arbitrary code from the internet without checking is bad. There is some effort needed to package software, but that is not that much effort in the grand scheme. |
|
| |
| ▲ | bflesch a day ago | parent | prev [-] | | It's about trust and having an official account for packaging on each platform where my customers getting their software from. | | |
| ▲ | arbll a day ago | parent [-] | | Most official repositories have policies that are incompatible with the needs of software vendors (release timing, supported versions, bundled dependencies, etc...). IMO a lot of the blame falls onto the package manager ecosystem refusing to take into account very valid needs and claiming they aren't real / desirable. |
|
|
| |
| ▲ | 8note a day ago | parent | prev [-] | | i dunno, nothing about most computing is particularly easy to use or intuitive. what has worked over time is having computers of various types in schools, where teachers teach students and let them play with it. nobody teaches about the command line, so nobody knows what to do with it. its also inscrutible without a useable help view, unless you already know how to use the terminal | | |
| ▲ | arbll a day ago | parent [-] | | Windows, macOS, iOS, and Android are definitely much easier to use and more intuitive than Linux today. That’s because their developers are incentivized to put themselves in the shoes of less-skilled users and figure out how to build a good experience for them. I’m all for higher Linux adoption on desktop, but there’s still a lot of resistance to making less-skilled users the primary target instead of power users. Teaching can help, but if it takes 50 hours to learn the basics of Linux versus 5 hours for Windows, it’s a losing battle. |
|
|
|
| |
| ▲ | mik3y a day ago | parent | prev [-] | | The ideas aren't mutually exclusive, and I've never seen an open source project support "curl | sh" without also supporting those methods. Indeed, plenty of these scripts often act as a "what OS and packager do we have" mux. Just look at the source of this one, for example. When you support an open source project at scale and/or with less savvy users, you come to see the benefit of "here, just f'ing slam this into your shell and we'll figure it out" installers. I know I have. | | |
| ▲ | ithkuil 12 hours ago | parent [-] | | There are many ways of implementing a curl | sh installer, some of them robust, some of them not. However they all look the same to the end user. That's a feature and also a potential source of problems since users cannot tell if that particular application they want to install Is implementing the installer correctly or not. The outcome is that most users just trust that application (possibly because it's popular and trusted) and that's fine but it also trains the public that this installation method is ok and that gives a positive feedback for other applications to also offer their software using that installer pattern until at least one of such packages is implemented very badly or sneakily malicious. If only a curl had a flag where you pass the sha256 of the file and it first checks it against the buffered file before outputting it to stdout. That would singlehandedly resolve this whole kerfuffle. The install instructions will be a slightly longer one liner and that's fine because people copy paste it anyway |
|
|
| |
| ▲ | throwaway2027 a day ago | parent | prev | next [-] | | Claude Code does it the same way (which doesn't excuse it obviously) but still. curl -fsSL https://claude.ai/install.sh | bash https://code.claude.com/docs/en/quickstart | | |
| ▲ | ardacinar a day ago | parent [-] | | Yep, that's not an excuse. Claude goes down all the time, should pi also go down? Oh wait (from another comment under this article):
> https://pi.dev/models is throwing an internal server error for me. |
| |
| ▲ | sippeangelo a day ago | parent | prev | next [-] | | Seriously, what is the threat model here? | | |
| ▲ | InsideOutSanta a day ago | parent | next [-] | | There is no threat model that doesn't also apply to pretty much every other distribution method. It's just people who have internalized "don't paste commands from the Internet into your terminal" and aren't thinking about exactly what makes pasting commands from the Internet into your terminal dangerous, and how that applies to this specific case. | |
| ▲ | arbll a day ago | parent | prev [-] | | Nah bro package manager where you copy and paste their custom repo and key from the same website that hosts the `.sh` is definitely safer, trust me /s |
| |
| ▲ | efficax a day ago | parent | prev | next [-] | | it tells you they're just like basically every other CLI targeting project for the last 15 years? I mean is it a big security hole we all accept, yes, it is. But it's not really indicative of much. That's also how I install rust. | | |
| ▲ | croes a day ago | parent [-] | | We also accepted the security risks of npm and such and we get one supply chain attack after another. Maybe security should be at a higher position on our priority list. The careless days are ultimately over but we still don’t act like that. |
| |
| ▲ | Arubis a day ago | parent | prev | next [-] | | I get this, and would recently have had a similar reaction. But I have to ask: do you typically run your agent harness in yolo mode? | |
| ▲ | horsawlarway a day ago | parent | prev | next [-] | | Yeah, totally reasonable comment given the utter security that must come from anthropic with their installer, amiright? oh wait... "curl -fsSL https://claude.ai/install.sh | bash" (right from https://claude.com/product/claude-code) Further - what the flicking fuck do you think an installer is going to do on your system? Not run any commands? Because I've written installers for every platform... they ALL can run commands. So what exactly is the complaint in this comment? If you want to go read the install script - knock yourself out (or hell, point your agent at it...). | | |
| ▲ | kordlessagain a day ago | parent [-] | | And you can simply look at the installer by pulling it up in the browser. | | |
| ▲ | qarl2 a day ago | parent [-] | | You can simply look at the installer by leaving off the "| bash". |
|
| |
| ▲ | tuvix a day ago | parent | prev | next [-] | | both the Julia and Rust programming languages use curl -> sh to install | | |
| ▲ | tovej a day ago | parent [-] | | Both of them provide that option. I've never installed rust without a package manager. Why would I? | | |
| ▲ | qarl2 a day ago | parent [-] | | > Why would I? Because then you can install it without depending on a package manager? | | |
| ▲ | HDBaseT 20 hours ago | parent | next [-] | | Depending on a package manager has its benefits. I personally try and use my operating systems package manager for all applications (in this instance, dnf on Fedora). The moment you start adding a million repos, third party package managers, Flatpaks, Snaps, random curl install scripts, etc, it becomes extremely unmaintainable. What happens if the curl application depends on openssl, maybe with a legacy or specific cryptographic function? I assume the curl script will either install the required version, or include the relevant libraries right? Now that is outside of the system package managers scope, meaning updating openSSL to avoid some vuln now requires extra work. What happens when you go from Fedora 44 to 45? You should be checking all your applications are supported on whatever version or operating system you are running. There is a decently high chance you run into dependency issues when some lib version is updated. Package Managers are (generally) more secure and simple to use for an end user (they are using the OS to begin with). Curl scrips are easier for the software developers. | | |
| ▲ | qarl2 5 hours ago | parent [-] | | Sure. Agreed. I do it myself. But sometimes people don't do that. Sometimes people don't care about that at all. And it's not just sometimes - it's most people. So. They have their option too. And it's at the top, where most people can find it. |
| |
| ▲ | tovej a day ago | parent | prev [-] | | Yeah, from source in that case. Or using a verified binary if I absolutely had to. | | |
| ▲ | qarl2 a day ago | parent [-] | | Yes, if you want to, you can do that. Understand that 99% are comfortable trusting downloads. They know that it's just as easy to sneak backdoors into source code as it is to sneak backdoors into executables. See also: XZ hack. | | |
| ▲ | tovej a day ago | parent [-] | | 99% of developers are most definitely not comfortable piping a script into the shell. I would never runa script without reviewing it. I would install a package from a distros repository without reviewing the contents, however, because I can trust that a distro maintainer has reviewed it, that anyone else in the community can review it, and that that the bytes I'm downloading are the specific bytes I'm supposed to be downloading. If you run a script off the open internet, you're being massively irresponsible. There are so many attack vectors that could be used here, and they are much easier to implement than something like the massive social engineering attack that was XZ. | | |
| ▲ | qarl2 5 hours ago | parent [-] | | As someone who has spent years in the software industry in silicon valley - My experience does not match yours. |
|
|
|
|
|
| |
| ▲ | qarl2 a day ago | parent | prev | next [-] | | My dude - if you're going to trust them then you're going to trust them. You think it's hard to obfuscate shell calls from inside a built executable? What it tells us is that you're probably searching for reasons to grouse about AI. | |
| ▲ | plagiarist a day ago | parent | prev | next [-] | | In general I agree with you, but on the other hand it is an agentic coding agent you should have isolated in a container or VM anyway | |
| ▲ | lo0pback a day ago | parent | prev [-] | | [dead] |
|
