I think the headline might be confusing because docker/podman already have the concept of a runtime. E.g. you can pass `--runtime` to set it on the fly or set it in the config...
For example, I don't use crun but a more security hardened runtime instead.
Interesting! So based on architecture[1], the daemon responsible for container… scheduling(?) works directly with the VM. There's no traditional init system. The "guest agent" is the initd (kind of a unikernel, huh?) so the overhead of spawning a container is as directly through the kernel syscalls as possible while the other bits happen on the macOS host?
The question I have is, does that mean Kiri implements its own entire container runtime or does it use containerd or some other runtime as its backend?
Expecially considering that pretty much every post-Docker container tech is "faster" than Docker. Docker is a pretty low bar these days IMO, it would've been better how Kiri compares to actual performant container runtimes like Podman, systemd-nspawn, incus etc.
And for macOS, the comparison should be done against Apple containers, OrbStack, Colima etc.
Seems to be specifically a desktop containers runtime for Mac written in Rust. It uses Nftables for networking on linux, too, unlike docker which is really nice.
Looking at the codebase this is either not majorly AI generated or the spent a lot of time cleaning up the tells I recognize, so I'd say not slop.
almost 200K lines of code materialized in about 2 weeks, and the code is full of em-dashes. if this wasn't vibecoded, they sure tried their hardest to make it look like it was...
I think the headline might be confusing because docker/podman already have the concept of a runtime. E.g. you can pass `--runtime` to set it on the fly or set it in the config...
For example, I don't use crun but a more security hardened runtime instead.
Interesting! So based on architecture[1], the daemon responsible for container… scheduling(?) works directly with the VM. There's no traditional init system. The "guest agent" is the initd (kind of a unikernel, huh?) so the overhead of spawning a container is as directly through the kernel syscalls as possible while the other bits happen on the macOS host?
The question I have is, does that mean Kiri implements its own entire container runtime or does it use containerd or some other runtime as its backend?
[1]: https://docs.runkiri.com/features/#what-runs-where
My question is wether "8x faster than docker" means that containers run faster or that the tooling around them runs faster
Expecially considering that pretty much every post-Docker container tech is "faster" than Docker. Docker is a pretty low bar these days IMO, it would've been better how Kiri compares to actual performant container runtimes like Podman, systemd-nspawn, incus etc.
And for macOS, the comparison should be done against Apple containers, OrbStack, Colima etc.
My question, not clear from the front page, was if it runs faster on MacOS than colima with vz. Full benchmarks claim that it does.
So that's interesting. The offering of container runtimes (also thin VMs in general) on MacOS has been improving a lot.
I scrolled through and it just seems like yet another contaienr runtime.
Anhone want to convince me this isn't just slopware?
Not sure, but the documentation is wrong. It’s not a (micro)VM per container. So it’s basically an Orbstack clone.
Seems to be specifically a desktop containers runtime for Mac written in Rust. It uses Nftables for networking on linux, too, unlike docker which is really nice.
Looking at the codebase this is either not majorly AI generated or the spent a lot of time cleaning up the tells I recognize, so I'd say not slop.
almost 200K lines of code materialized in about 2 weeks, and the code is full of em-dashes. if this wasn't vibecoded, they sure tried their hardest to make it look like it was...
Sure looks like it. Not sure any of the contributors on GH are even real people.
Excellent Persian name
Naming is hard :-)