Announcing rkt v0.5, featuring pods, overlayfs, and more

Re:Announcing rkt v0.5, featuring pods, overlayfs, and more by krakensden on Wednesday April 01, 2015 @06:12PM (#9307317)

It's weird seeing all the careful description of a Pod, which is just an explicit rollback of Docker's wishful thinking about single-process containers to something identical to what you'd get with LXC. Which just runs /sbin/init.

The amount of wasted development effort caused by Docker's willful intransigence on this is sort of staggering. The teams I work with using docker are still tripping over new nonsense that would have been solved by... I don't know, using systemd... after almost a year of trying to work through the kinks.

[ Parent | on HN ]

Re:Announcing rkt v0.5, featuring pods, overlayfs, and more by wmf on Wednesday April 01, 2015 @11:55PM (#9308588)

I can imagine that composing a pod out of container images could have advantages over composing a system out of packages because communication between the containers would be more explicit.

[ Parent | on HN ]

Re:Announcing rkt v0.5, featuring pods, overlayfs, and more by krakensden on Thursday April 02, 2015 @11:03AM (#9311077)

I see it as a hassle- I dont want to be doing a bunch or redundant whitelisting to make the percona tools work. Worse, I don't want to ship them separately, xtrabackup uses mysql as a library, which means separate containers only buys you bugs.

Docker's design decisions make sense if you're shipping statically linked, standalone binaries everywhere. Which I suspect docker.io and many other people are doing. But that's also sort of a boring edge case where you don't even need filesystem namespaces except for cleanliness.

[ Parent | on HN ]