@iximiuz@rumpl@Docker@solomonstre@crosbymichael As to the move from "single binary" to splitting into multiple projects (runc, containerd), there were various reasons (some of those may have been captured in the blogposts linked elsewhere in this thread);
@iximiuz@rumpl@Docker@solomonstre@crosbymichael Originally, Docker used LXC as part of the runtime; while that got us there, there were times where it wasn't always a close fit, and at times there were portability/compatibility issues (taking into account different distros).
The deprecation of docker-shim (and Docker Engine as runtime) marks the completion of a long-term commitment to provide a modern runtime for Kubernetes 1/15
When the kubernetes project was started, it chose the Docker Engine as runtime (a logical choice, as at the time, the Docker Engine was about the "only" runtime) 2/15
However, the Docker Engine was not designed with orchestration in mind, and not designed to be used as runtime for Kubernetes; the Docker Engine has many features that make sense for local development (build, run) and running non-orchestrated containers, 3/15
I noticed this some time ago; happy to see this little gem being added to the @github UI
A thread on what it is, and why it's really, really useful 1/15
Perhaps you have never ran into this yourself, but if you're maintaining an (open source) project on GitHub that has forks, chances are you have been "confused", or had the scare of your life because of this 2/15
I don't have full insight into how _exactly_ it's setup behind the scenes (@calavera explained it to me once, but I forgot the details); GitHub keeps references to all forks of a repository, effectively making all forks of a codebase form a single, giant git repo 3/15
I see vendoring mentioned as "not the right solution" for dependency management. I agree that vendoring in itself was not the solution for dependency management, but this should be somewhat nuanced.
2/40
Vendoring is addressing multiple things, and go modules *can* address some of those.
So what does vendoring provide?
- reproducibility
- facilitate auditing source code
- guard against dependencies going AWOL (leftpad, y'all!)
- speed
- build in air gapped environments