I love cloud-native and containers just as much as the next person but the nomenclature for different things which do some but not all of the same things can be pretty confusing.
We have the phrase “container engine” which could mean dockerd or Podman; “container runtime” to me usually refers to containerd or CRI-O but could also refer to runc and crun; and “container manager”, which could alternately refer to dockerd and Podman or to “orchestrators” like k8s Swarm and Nomad. “Desktop app” is what I would call Docker Desktop, Podman Desktop etc.
From cursory reading this appears to be a new desktop app for containers. However they say that the container logic runs behind the real dockerd, so I suppose they’ve slotted it in where containerd goes? So it would be a new container runtime. I feel that’s a little odd to conflate the two, but that’s getting into the hole we’ve already dug with these terms.
the wording and claims they/ai used here is also purposely obtuse regardless of cloud native jargon.
Their test setup based on their docs is `docker run --rm alpine true`.
Which almost certainly guarantees kiri's claim is comparing the warmed boot time with a cached image with docker which calls out to containerd under the hood. Generally cold start is what people actually notice & care about most.
Anyhow I looked under the hood a bit, there's some concerning things calling out to me like they default to deferring actual cleanup before responding with exit notification. It's a tradeoff but clean up failures result in silent pile ups: https://github.com/libracoder/kiri/blob/b249eccc2ed708ce10d7....
disclaimer: I maintain smolvm, a vm that uses crun as the container runtime for running containers.
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.
There‘s an interactive benchmark further down. They‘re measuring the time to start a container. Honestly something I don‘t cafe for, 200ms more for a container start I do every several days is not something I notice.
And the memory davings is for more than 100 processes. So more than 100 containers? I‘ve got a couple running. Won‘t notice a difference again.
Orbstack is great because the bind mounting is really fast. No talk about that one…
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...
scrolled through the website, it's the definition of ai generated slop, irrelevant claims, flashy animations to distract the user from actually reading the slop lmaoooo what a huge waste
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?
I love cloud-native and containers just as much as the next person but the nomenclature for different things which do some but not all of the same things can be pretty confusing.
We have the phrase “container engine” which could mean dockerd or Podman; “container runtime” to me usually refers to containerd or CRI-O but could also refer to runc and crun; and “container manager”, which could alternately refer to dockerd and Podman or to “orchestrators” like k8s Swarm and Nomad. “Desktop app” is what I would call Docker Desktop, Podman Desktop etc.
From cursory reading this appears to be a new desktop app for containers. However they say that the container logic runs behind the real dockerd, so I suppose they’ve slotted it in where containerd goes? So it would be a new container runtime. I feel that’s a little odd to conflate the two, but that’s getting into the hole we’ve already dug with these terms.
the wording and claims they/ai used here is also purposely obtuse regardless of cloud native jargon.
Their test setup based on their docs is `docker run --rm alpine true`.
Which almost certainly guarantees kiri's claim is comparing the warmed boot time with a cached image with docker which calls out to containerd under the hood. Generally cold start is what people actually notice & care about most.
Anyhow I looked under the hood a bit, there's some concerning things calling out to me like they default to deferring actual cleanup before responding with exit notification. It's a tradeoff but clean up failures result in silent pile ups: https://github.com/libracoder/kiri/blob/b249eccc2ed708ce10d7....
disclaimer: I maintain smolvm, a vm that uses crun as the container runtime for running containers.
> One Apple-silicon Mac, one runtime at a time. Measured numbers replace these soon.
:))))))
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.
what do you use?
I would really like to understand why it claims it's such much faster than OrbStack or Docker Desktop?
What is the architecture or technology decision that makes that 8x claim possible?
My question is wether "8x faster than docker" means that containers run faster or that the tooling around them runs faster
There‘s an interactive benchmark further down. They‘re measuring the time to start a container. Honestly something I don‘t cafe for, 200ms more for a container start I do every several days is not something I notice.
And the memory davings is for more than 100 processes. So more than 100 containers? I‘ve got a couple running. Won‘t notice a difference again.
Orbstack is great because the bind mounting is really fast. No talk about that one…
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...
> 200K lines of code
And who is going to read all that to make sure it doesn't contain malware?
I'm extremely loath these days to casually clone any repos from untrusted sources.
This problem has preceded llms by at least a decade
If you have enough tokens, a LLM will happily read every line. That’s how we are all getting inundated with bug reports now.
Sure looks like it. Not sure any of the contributors on GH are even real people.
Excellent Persian name
In France it's a popular brand of cheese for kids: https://fr.wikipedia.org/wiki/Kiri_(marque_fromag%C3%A8re)
la vache qui rit ⟶ kiri
Oh, Laughing Cow! https://en.wikipedia.org/wiki/The_Laughing_Cow noble heritage.
Just came to mention the same. I hope they go with a family of products next.
It's Lgbo, check the docs.
Naming is hard :-)
scrolled through the website, it's the definition of ai generated slop, irrelevant claims, flashy animations to distract the user from actually reading the slop lmaoooo what a huge waste
I hate these vibecoded websites
Is anyone still using docker ? I'm surprised they don't compare to podman & all that I see used these days
They did.
https://runkiri.com/podman-alternative/
Okay, so given how they don't include podman timings on that page, can we conclude that this is not faster than podman?
That wouldn't be surprising.
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