> 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?
From the page you linked: Nvim creates a default RPC socket at startup, given by v:servername.
You can follow the links on v:servername to read more about the startup process and figure out what that is, but tl;dr, it's a named pipe unless you override it.
> which is very important for the kind of thing eBPF is(1)
The question is, going into 2026, what kind of thing is eBPF? It seems like all hope of it being a security boundary has been thwarted by micro-architectural vulnerabilities to the extent that you can no longer load eBPF programs as non-root. So, is it a security boundary? That's an honest question that I've not been able to find an answer to in the kernel documentation or recent mailing list posts.
If it's not a security boundary, what is it? There's a few other nice properties enforced by the validator, like protos for a subset of kernel functions, which provides some load-time validation that you've built against a compatible kernel. That's something that's lost here, so we don't get the same compile once, run everywhere properties eBPF has. One might argue this is a big loss, but in the branch that eBPF is not a security subsystem, it's worth asking whether these are strictly necessary checks that need to be enforced, or whether they're niceties that bring a higher hope of stability and reduce the burden of code review that are perfectly fine to bypass given those caveats.
IMO eBPF is best viewed as a mechanism that allows you to load "arbitrary" code in specific kernel paths, while guaranteeing that the kernel won't hang or crash.
That's it. Though I said "arbitrary" because the program has to pass the verifier, which limits valid programs to ones where it can make the stability guarantees.
> why compare it to eBPF vs just making a mechanism to load kernel modules written in Rust.
Because it's not just a mechanism to load kernel modules in Rust, it's specifically a mechanism to load them in the same places that ebpf programs are loadable, using the existing kernel machinery for executing ebpf programs, and with some helpers to interface with existing epbf programs.
Interesting: for me, the image quadrants display correctly in Safari, but there is a horizontal white line between the top and bottom left quadrants. You're not seeing that?
I see the white line on mobile, but not on desktop, though my OS versions are wildly different too, so hard to narrow down exactly what it might be there.
I’d be curious about sentiment analysis applied to these. I expect two of the listed to have very positive sentiment, and one generally negative in 2025.
> I expect two of the listed to have very positive sentiment, and one generally negative in 2025.
You are quite correct! Crafting Interpreters actually has the highest average sentiment score across all books with more than 10 comments.
This is the average sentiment score of all three( range being -10 to 10) :
> Do library authors have to test against every type checker to ensure maximum compatibility?
Yes, but in practice, the ecosystem mostly tests against mypy. pyright has been making some inroads, mostly because it backs the diagnostics of the default VS Code Python extension.
> Do application developers need to limit their use of libraries to ones that support their particular choice of type checker?
You can provide your own type stubs instead of using the library's built-in types or existing stubs.
This is a network carrier setting, the issue is that T-Mobile (and maybe others) pushes a profile that does this as part of their network configuration.
I went to Wi-Fi settings, "Edit" in top right, scroll to bottom "Managed" section, and was able to turn off "Auto-Join" for the "t-mobile" managed network just fine. I did this many months ago, I think because I was infuriated at the idea of auto-connecting to a Wi-Fi network I did not opt in to, but regardless, the checkbox has remained off through a few OS updates since (on 26.1 now with a T-Mo prepaid eSIM).
There's no "Managed" section showing up on my phone and the last time I set that network to not auto-join it still did. Lesson learned, I just turn off WiFi and Bluetooth before heading out to Home Depot.
VS Code’s ssh daemon is authenticated.
reply