staticassertion

Docker is a lot more than just an unprivileged user. In particular, it comes with a seccomp filter. A lot of LPEs are blocked by that filter. Docker is actually a quite decent security boundary - in this case the attackers did not attempt to subvert docker by attacking the kernel attack surface, they attacked a weak configuration via the docker socket being mounted.

The reason you don't use a "grown up VM" is because it's significantly more difficult. Which VM? Firecracker requires KVM and a guest operating system - so how are you getting things in and out in a way that doesn't violate security? That's real work.

gVisor is great and my recommendation, certainly, but the difference between "nothing" and "docker" is actually pretty huge imo.

The solution is to do exactly what you suggest - separate access. In CI this is a matter of having your "build/test" jobs happen separately from your "deploy/publish" jobs.

The trickier part is dev environments, but ideally you take a similar approach. The place that devs do `npm install` should be isolated from, say, your browser / ssh keys etc.

Package manager support would be an amazing win here since you'd have an easier time managing the isolation but you can do this today.

No. NPM's not particularly bad at all tbh.

Most of them definitely let you do that.

That seems like the opposite. Why would someone with high market value stay in one place? 2 years is basically optimal - you vest 50%, maybe collect a promotion, do some good work and learn a lot, and then get to move on for another solid bump/ promotion and a new set of stocks.

I expect the people with low market value to be the ones sticking around labs for long periods of time, they don't have the option to move and they aren't getting poached.

> The harder question is what the architecture around the vulnerability should look like. The principle is to make exploitation harder for an attacker even when a bug exists, so that the gap between when a vulnerability is disclosed and when it is patched matters less. That means defenses that sit in front of the application and block the bug from being reached. It means designing the application so that a flaw in one part of the code cannot give an attacker access to other parts. It means being able to roll out a fix to every place the code is running at the same moment, rather than waiting on individual teams to deploy it.

So nothing new then.

I was rejecting your definition of the hard problem as it contains an assertion that a physicalist wouldn't accept.

Yes, reduction would be one very viable strategy. It doesn't require precisely defining the phenomenon in order for me to just say that it reduces based on the fact that reduction has been a successful approach for everything else in cognition.

> There is an in principle barrier to a transparent structural description of phenomenal consciousness.

Yeah this is what I reject. Why do you say that this is in principle a barrier? You're discussing it as an explanatory gap, not in principle.

> The hard problem identifies the in principle difficulty in explaining phenomenal consciousness, something not definable in terms of structure and function

Great, I'm a physicalist so uhhhh I reject this lol. I think you can define cognitive capabilities and phenomenal experience by reducing to structure and function. You're right that it's simple though.

That's like saying that "water" is a philosophical invention and so if you accept that water is a thing then you've put it into a special category.

You can derive consciousness as a somewhat obvious conclusion of empirical study of behaviors, we have multiple fields of study that lay out cognitive function and criteria.

That's true and probably a kinda critical distinction here. Facebook is sort of making the bet that they can not only treat the world like shit but their direct employees too.

You could have said this every year for so many years about so many companies. If people will work for Palantir, they'll work for Facebook. Facebook could be a lot worse and I think a lot of their employees would stick around.

I guess a response at the industry level would be not hiring ex-FB people etc, treating it as a red flag.

> The no-AI policy of the Zig compiler project is for the compiler, other projects can do whatever they want.

Well, presumably they want to contribute to the compiler. I know that you did not like those contributions, and that view seems entirely valid, but obviously "no AI" rules out their development model (by design, and you likely think that's good, and maybe it is!).

Not intending to defend the bun move, but obviously a project using Zig and also using AI might feel motivated to avoid Zig since they're ruled out as contributors.

Yes. The policy is pretty clear on what the rules are for LLM generated code. You need a reviewer to agree to review LLM generated code, you need to read the code yourself, etc.

I think that the only significant caveat here is the need for reviewers to opt in, otherwise it's effectively "you can do it if you are open about it and are responsible for the output". The only notable ask here that's different from other policies is "if it's an LLM, tell reviewers beforehand".

TBH I think that makes no sense ("I have an LLM written PR ready, can I open it?") but yeah the policy is also in draft and has actually already changed since my first comment.