mirashii

> The only exception is if the local scan goofs in some way.

Basically this, if it fails or if you wish to escalate past that, then there's a path that would hit Persona (or, would have, they've since ended their relationship with Persona. Previously, you'd open a ticket in Zendesk, which is where data was breached from before).

https://support.discord.com/hc/en-us/articles/30326565624343...

> We don’t sell your personal information.

No evidence that they sell your data against their privacy policy has ever come to light, so I think you should probably back that claim with evidence if you think otherwise.

Previously, they handled this escalation path via Zendesk, which was breached revealing all of the messages with IDs.

Now, they're trying out Persona for this path.

7-zip is not a serious project and its use should be strongly discourged.

This isn’t necessarily true, there are a variety of legal doctrines specifically to handle things like this. Take, for example, the major questions doctrine.

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.

VS Code’s ssh daemon is authenticated.

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.

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.

No it doesn’t.

> they'd use snappy or zstd

What is being used more doesn’t matter, what’s compiled in and enabled matters.

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 not my personal experience nor the experience of a number of folks that I know personally. I think it's pretty hard to generalize about this.

> The vast majority of stuff on GitHub goes unnoticed by the vast majority of people. And only a very small minority of people ever interact with the few projects they do pull from GH.

So what? It's probably not going to impact you, so it's okay and we just have to deal with it? I reject that logic entirely.

No, it just protects you from a valid but unexpected optimization to your incorrect code. It's even spelled out clearly in the docs: https://www.gnu.org/software/c-intro-and-ref/manual/html_nod...

"Code that misbehaves when optimized following these rules is, by definition, incorrect C code."

> We have compiler behavior for incorrect code, and it's refusing to compile the code in the first place

This isn't and will never be true in C because whether code is correct can be a runtime property. That add function defined above isn't incorrect on its own, but when combined with code that at runtime calls it with values that overflows, is incorrect.

Potentially invoking and invoking are not the same.

But do they? Where?

More likely, you mean that a particular compiler may say "while the standard says this is UB, it is not UB in this compiler". That's something wholly different, because you're no longer invoking UB.

People are taught it’s very bad because otherwise they do exactly this, which is the problem. What does your compiler do here may change from invocation to invocation, due to seemingly unrelated flags, small perturbations in unrelated code, or many other things. This approach encourages accepting UB in your program. Code that invokes UB is incorrect, full stop.