| 15 Oct 2021 |
 @timdeh:matrix.org | of course, maybe they made nspawn just to be jerks. Who knows 😅 | 20:29:54 |
 David Arnold (blaggacao) | Since there's an open standard, I beleive the latter is true. | 20:30:24 |
 @kraftnix:matrix.org | nspawn is alright (having used it for quite a while) the overhead is definitely less than running a full systemd-based OS | 20:30:49 |
| @timdeh:matrix.org | Well I just meant that when given the choice, it seems like the systemd devs roll their own solution rather than working with existing standards | 20:31:29 |
| @kraftnix:matrix.org | thats definitely true | 20:31:44 |
| @timdeh:matrix.org | so maybe they could have worked with OCI but chose not to | 20:31:44 |
| @kraftnix:matrix.org | the runtime overheads are actually fairly small (looking at my server atm), my bigger nspawn containers (like matrix, gitea, nextcloud) are using ~120-150MB RAM and ~15-20 extra processes, while a slim container (like openldap) seems fine with 20MB of RAM and 10 processes | 20:35:52 |
| David Arnold (blaggacao) | The runtime overhead isnprobably not the problem, they all do the same thing. | 20:36:35 |
| David Arnold (blaggacao) | The problem is the interface 🙂 | 20:36:42 |
| David Arnold (blaggacao) | * The runtime overhead is probably not the problem, they all do the same thing. | 20:36:57 |
| @kraftnix:matrix.org | thats true, i would totally not use it without nix | 20:37:21 |
| David Arnold (blaggacao) | You can even run VMs on the OCI interface if I'm not completely wrong. | 20:37:21 |
| @timdeh:matrix.org | I think that's what kata-containers are all about isn't it? | 20:37:43 |
| David Arnold (blaggacao) | Or at least the interop between OCI and VMs is close to given. | 20:37:50 |
| @timdeh:matrix.org | systemd is just annoying when it comes to standards. even their versioning scheme is completely non standard 😅 | 20:38:14 |
| David Arnold (blaggacao) | There are VM runtimes, yeah. | 20:38:17 |
| David Arnold (blaggacao) | There can be a nix runtime, too. | 20:38:25 |
| David Arnold (blaggacao) | Why not? | 20:38:43 |
| @timdeh:matrix.org | unless you wanna start an effort to redefine all the existing NixOS modules from scratch using some other format, then a NixOS runtime is the only viable runtime 😆 | 20:40:02 |
| @timdeh:matrix.org | there is already the aforementioned OCI builder derivation for simple stuff | 20:40:24 |
| @timdeh:matrix.org | Although maybe Nix should advertise more how awesome it is at building these containers! Because I think it is probably the best container builder frontend to docker/OCI that exists atm. | 20:41:10 |
| David Arnold (blaggacao) | The category "NixOs runtime" is not really precise. It's more "artifact runtime". | 20:48:55 |
| David Arnold (blaggacao) | * The category "NixOs runtime" is not really precise: it's more "artifact runtime". | 20:49:10 |
| David Arnold (blaggacao) | NixOs containers are NixOS artifacts. | 20:49:26 |
| @timdeh:matrix.org | well yeah, I wasn't aiming for exact precision in this context 😛 | 20:49:42 |
| David Arnold (blaggacao) | But it's important to avoid the "Nixos-bias" 😆 | 20:50:05 |
| @timdeh:matrix.org | I reserve that brain exhausting exercise for when I actually enter the code editor 🙂 | 20:50:09 |
| David Arnold (blaggacao) | So the conclusion is NixosContainer artifacts have no reason to not be OCI compliant artifacts. | 20:50:43 |
| David Arnold (blaggacao) | (no evident [to me] reason) | 20:50:57 |
| @timdeh:matrix.org | In theory yes | 20:51:00 |
