If the author is reading this, the hyperlink to the book in the first paragraph is broken. Looks like it's attempting to direct you to an absolute url that was meant to be relative.
I've struggled with this "responsibility" take. What does it mean in the context of an open source project? As far as I understand it, the original contributors of bugs are often not the ones fixing them (though they can be). Is it that if you write enough buggy code you get banned as a contributor? Is it that you're not allowed to say Claude ate my homework?
I don't think it's an abuse, RFC9110 defines 414 as a response for "refusing to service the request because the target URI is longer than the server is willing to interpret". Since adding a query string involves only adding characters, this seems fine; there's no stipulation as far as I can tell that all pages a server hosts must adhere to the same length. I'd be curious if any well-known clients interpret it that way though, and make caching decisions based on it. As far as I know, they shouldn't.
Obviously it's against the spirit of the thing, but I don't think it's wrong per-se.
I've never been in the position that I've had to deal with this. Is the best you can do in this situation to pull the files and optionally republish them to a robots.txt'd path (with authn/z, too)? I can't imagine you can get it pulled from search engines very quickly...
I've been waiting for something like this to come along. I keep hearing people say LLMs are a new abstraction layer, and I fundamentally disagree. We don't commit our compiled machine code, we commit our C. Yet, with LLMs, we commit our generated source code, completely throwing away the English language abstraction.
This seems to scratch that itch. The non determinism makes it probably not suitable for most uses, though.
As far as I'm aware, Pyroscope itself is not a profiler, but a place you can send/query profiles. OpenTelemtry is releasing a profiler, so they don't compare. One can be used with the other.
Not sure how I feel about transcripts. Ultimately I do my best to make any contributions I make high quality, and that means taking time to polish things. Exposing the tangled mess of my thought process leading up to that either means I have to "polish" that too (whatever that ends up looking like), or put myself in a vulnerable position of showing my tangled process to get to the end result.
I don't love the concept, but I do wonder if it could be improved by using a skill that packages and install script, and context for troubleshooting. That way you have the benefits of using an install script, and at least a way to provide pointers for those unfamiliar with the underlying tooling.
> Neovim’s server defaults to named pipes or domain sockets, which do not have this issue. The documentation states that the TCP option is insecure.
Good note on pipes / domain sockets, but it doesn't appear there's a "default", and the example in the docs even uses TCP, despite the warning below it.
(EDIT: I guess outside of headless mode it uses a named pipe?)
> VS Code’s ssh daemon is authenticated.
How is it authenticated? I went looking briefly but didn't turn up much; obviously there's the ssh auth itself but if you have access to the remote, is there an additional layer of auth stopping anyone from executing code via the daemon?
A coworker raised an interesting point to me. The CORS fix removes exploitation by arbitrary websites (but obviously allows full access from the opencode domain), but let's take that piece out for a second...
What's the difference here between this and, for example, the Neovim headless server or the VSCode remote SSH daemon? All three listen on 127.0.0.1 and would grant execution access to another process who could speak to them.
Is there a difference here? Is the choice of HTTP simply a bad one because of the potential browser exploitation, which can't exist for the others?
I'm not very familiar with this layer of things; what does it mean for a GPU to drive a boot sequence? Is there something massively parallel that is well suited for the GPU?
heh - a bit off topic, but Grist was the first place I ever applied for a software job. I was a high school student looking for a summer internship. I remember bombing that phone interview (I was asked about some JS semantics, and then I badly described what a hash table was). They also had a code challenge that you had to email the output to to some hiring address; was a cool way to do it.