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 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).
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.
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.
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.
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.
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.
Yup, we have a sidecar process/container that runs for each job and assumes an AWS IAM Role for that specific pipeline (with constraints like whether it’s an approved PR as well). The credentials are provided to the job container via a volume mount. This allows us to have shared agents with very granular roles per-pipeline and job.
We’ve been using Sysbox (https://github.com/nestybox/sysbox) for our Buildkite based CI/CD setup, allows docker-in-docker without privileged containers. Paired with careful IAM/STS design we’ve ended up with isolated job containers with their own IAM roles limited to least-privilege.
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