lox

It's amazing how many different implementations of sandboxes have popped up in the past few weeks.

I'm CTO at Buildkite, have been noodling on one with a view to have an environment that can run CI workloads and Agentic ones https://github.com/buildkite/cleanroom

I just built something very similar too: https://github.com/lox/slack-cli

I'm working on a poker server to allow holdem bots to play against each other (https://github.com/lox/pokerforbots) and a Pluribus-level bot that plays on it (https://en.wikipedia.org/wiki/Pluribus_(poker_bot)).

Enjoying writing some really fast Zig implementations of hand evaluation and CFR-based solvers.

I don’t disagree that pop culture has distilled spectrum down into a magnitude, but that isn’t how the DSM describes it or how professionals diagnose it (or in my experience how they communicate it). The metaphor is supposed to be like the light spectrum not “less autism ranging to more autism”. Severity scale is distinct to interacting traits of social issues and restricted interests and repetitive behaviors (the spectrum bit).

With a prevalence rate of < 2% (at least in Australia) this seems like an incredibly mathematically flawed take. Whilst a broad/blanket diagnosis isn't useful for making generalisations about individuals in that group, it's certainly societally useful.

No, you resigned. It’s completely possible to have adult conversations and to part ways without being terminated for cause (which “fired” is a euphemism for).

From the article:

> generally available through an API (next to GPT-4)

It’s more than that, doing it well is still beyond sophisticated automation. Many variables that need do be constantly adjusted for. Humans are still much better at it than machines, regardless of the social element.

Is this not essentially what docker did with cgroups? It’s incredibly tricky securing containers, I’m not at all confident process only sandboxes would be adequate.

They do, the parent is either on an older tesla software platform or they haven't looked at settings > service and have ignored the alerts when they occur.

I'm running a Model 3 with 2023.44.39 on it. In the Service menu there are a variety of exactly the things you mentioned.

In the top right corner there is "Tire Service Mileage" with an estimate of when you should service your tires. There is a reset link under that, which links into the "Wheel and Tire" service tab with more maintenance options.

There are alerts for nearly all of the things you mentioned: https://www.tesla.com/ownersmanual/model3/en_us/GUID-E95DAAD...

Regarding the tire wear, the car is heavy with instant torque. I've had to replace my tires quite a few times, but it's the only thing that has needed much servicing for me in the past three years. I'd expect that from a new car though, and I don't have much confidence in it's longevity.

There is a service screen in the UI with alerts and details on when tires were last changed. There is an alert for windshield fluid.

Docker is running as root, so the files written in mounted volumes get mapped to uid 0 on the host. When the agent then goes to re-use the checked out code, it can’t run ‘git clean’.

Username space remapping wasn’t adequate, for reasons I’m a bit blurry on. I think recent kernels have some better options on remapping permissions across file systems.

This stack is run by a single customer on trusted code isolated in their own AWS env. (I wrote it originally 6-7 years back)

There are radically better isolation strategies now. Firecracker and/or Sysbox hardened docker containers is one I’ve recently implemented.

My take is different. I think DevOps was wildly successful, most of our infrastructure is now software that can be managed by Software Engineers. The goal posts have shifted, we now have major software challenges where as before we had hardware and operational challenges.

Well written tools and cross-functional teams that do both operations, feature work and security are still the path forward IMO, we just need to refocus on developer experience.

In 2005 your infrastructure provisioning wasn’t automated. The complexity has increased, but so has what we get. Being able to provision new hardware stacks like software is amazing, in 2005 I had to get quotes from hosting providers.

"This article is a preprint and has not been peer-reviewed"

I don't spend a lot of time on those comparison-style charts if I'm honest, but that is good (and valid) feedback for them. I also hadn't heard of it, I discovered sysbox via jpettazo's updated post at https://jpetazzo.github.io/2015/09/03/do-not-use-docker-in-d..., he's an advisor of nestybox the company that develops sysbox.

For the CI/CD usecase on AWS, sysbox presented the right balance of trade-offs between something like Firecracker (which would require bare metal hosts on AWS) and the docker containers that already existed. We specifically need to run privileged containers so that we could run docker-in-docker for CI workloads, so rootless docker or podman wouldn't have helped. Sysbox lets us do that with a significant improvement in security to just running privileged docker containers as most CI environments end up doing.

Just switching their docker-in-docker CI job containers to sysbox would have mitigated 4 of the compromises from the article with nearly zero other configuration changes.