| ▲ | bijmtir 2 hours ago |
| Docker was basically a commercialisation of lxc and now we got nspawn going full circle. |
|
| ▲ | shykes 2 hours ago | parent | next [-] |
| This is incorrect. Docker in its earlier incarnations was based on openvz, which predates lxc. The lxc project was initially a kernel development project: a collection of kernel patches to add container support. The userland tool was just a companion. When it became apparent that these patches would "win" the race to be upstreamed even though openvz was much more mature, we switched our tooling to lxc. The patches matured over time, but the userland tool (what we now know as "lxc") was finicky. The original open-source release of Docker wrapped lxc for low-level container operations. But it was just too unreliable and we swapped it out for an in-house Go implementation called "libcontainer". As for "commercializing": Docker was famously bad at commercializing anything, we open sourced so much (maybe too much) and still people complained that we were not open enough. |
| |
| ▲ | stingraycharles an hour ago | parent | next [-] | | “Docker was famously bad at commercializing anything, we open sourced so much (maybe too much) and still people complained that we were not open enough” Developers are a tough market to please, especially when your business revolves around open source software. Unless you have an option to do private cloud hosting (like all these databases and other platforms do), it’s incredibly difficult to monetize. In the case of docker, I think it’s in the nature of the product that it’s difficult to monetize. Best you can do is enterprise support contracts, but those aren’t good enough to justify all that VC funding. | | |
| ▲ | dralley 38 minutes ago | parent [-] | | I don't think it's necessarily that difficult to monetize, they just ignored a lot of the needs of enterprise users (rootless, not punching holes in the firewall, not fighting with systemd, private registries) for long enough that other projects (e.g. Podman, Quay) filled the void. |
| |
| ▲ | 2 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | zoeysmithe an hour ago | parent | prev | next [-] | | In the end, how were you able to monetize Docker? | |
| ▲ | bijmtir 2 hours ago | parent | prev [-] | | [flagged] | | |
| ▲ | shykes 2 hours ago | parent [-] | | Earlier incarnations of the project (2008-2011) were python based on openvz+aufs, with the very first prototypes (2007-08) wrapping vserver. We started the transition to lxc+aufs in 2011. Open-sourced the lxc wrapper in 2013. Replaced it with libcontainer in... 2014 I believe? |
|
|
|
| ▲ | lostlogin 2 hours ago | parent | prev | next [-] |
| The LXC way of getting an up per container is pretty great - I’m basic bitch with this sort of thing so I assume it’s less of an issue for the experts but really enjoyed the IP per container when I hit it. |
|
| ▲ | iJohnDoe 2 hours ago | parent | prev [-] |
| I’m a huge fan of nspawn. Always wanted to use VMs instead of Docker and nspawn feels like a natural choice. |
| |
| ▲ | miladyincontrol 2 hours ago | parent [-] | | Its nice having the flexibility for both system containers and application containers. It does feel though that most people forget that nspawn does both, and that it only can do system containers. | | |
| ▲ | iJohnDoe 2 hours ago | parent [-] | | Agreed, I briefly forgot it can do both. Thanks for the reminder. I went down the rabbit hole of Incus and once I realized it requires the full network aspects to be configured, then I figured using KVM, QEMU, Libvirt was more practical. Then stumbled into nspawn and it was basically ready to go. Although, I haven’t done enough research to know if Incus provides certain useful capabilities. | | |
| ▲ | radlad an hour ago | parent [-] | | I'm a huge fan of Incus. VMs, LXC, and OCI containers all under the same Docker-like CLI interface. I run it on a local server and on a dedicated server in a local DC, and connect to both remotely using Nebula. It includes project-level resource separation, advanced networking, clustering, snapshots, and more. Plus, Stéphane Graber is super responsive on the forums and issue tracker. I bounced off of Proxmox, and can't recommend Incus more for hypervisor-type scenarios. | | |
| ▲ | zenoprax 10 minutes ago | parent [-] | | Do you have any experience with multi-node operation with Incus? I like the simplicity of Proxmox for moving VMs and LXCs around but I haven't settled on a solution for OCI. K3S is an option but it's a big jump. I'm moving towards Fedora CoreOS VMs at the moment for live migration and security isolation. |
|
|
|
|