blixtra

As to why we'd do it in the first place, the answer is that our mission as a company is to support foundational Linux technologies for cloud-native infrastructure. We're not looking to create new technologies, but to improve and support those that exist and are widely used already. Container Linux fits that description to a T. Additionally, as we mention in the FAQ, we were already being asked to support Container Linux. Thus, we knew that there was demand and it fits our company mission.

So when the acquisition was announced, it was a rather easy decision to make; one that we'd already been considering. But knowing that it was also likely to face changes under new "owners" allows us to also be in the position of preserving a technology that we feel is fundamentally sound.

That's a very valid question and one we also asked ourselves before taking on the task. There are three main considerations that made us feel this is doable. Firstly, Flatcar is a minimal Linux distro, with more effort made to reduce the number of packages rather than expand. Secondly, Flatcar has not only Container Linux as an upstream, but also Gentoo, which is also a common upstream for Chrome OS and Container-optimized Linux, so well tended to. Thirdly, the technologies (kernel, systemd, containers, low-level Linux userspace) are our core focus as a company. These three considerations are what led us to feel confident in picking up the project and have the motivation to do so.

The way I personally see it, if you were ok with using an OS from a team of veteran Linux/open-source contributors in 2013 you should be ok with using one from a team of veteran Linux/open-source contributors in 2018. But this time it's from a team that does not take venture funding.

Lastly, it is telling that the ppl that have the most confidence in us pulling this off are the ppl we've worked with as clients or through open source collaborations. We're happy to start there and prove ourselves along the way to other.

Chris from Kinvolk here.

Flatcar Linux is generally available and we are committed to keeping it as a drop-in replacement for Container Linux for the long-term. We were excited about the idea of CoreOS when it was announced in 2013 and think it's a project worthy of sustaining.

Happy to answer questions about it.

Chris from Kinvolk here.

It's open for general use now. :)

Chris from Kinvolk here. As Jimmy mentioned, we've done a good chunk of the work on rkt with CoreOS and are happy to support customers using rkt, and have done so for CoreOS, BlaBlaCar, NASDAQ and others in the past.

But we've chosen not to go the startup route, which means we can only really afford to work on rkt in the context of paid work. We're looking at doing more of this in the future through support contracts for Flatcar Linux[0], a fork of CoreOS' Container Linux, which includes rkt in the images, and through the contracts we get here and there from users looking for new features in, or support for, rkt directly.

But rkt, as is, remains a great container runtime. It's our preferred runtime when running outside of Kubernetes, atm. The Kubernetes integration via rktlet[1] works well but does not have 100% functional parity with the default CRI implementation. It probably needs about 3 person-months of work to get there at this point.

So yeah, it works well, but does indeed need a bit more love. If you're interested in helping out, get in touch.

[0] https://www.flatcar-linux.org/

[1] https://github.com/kubernetes-incubator/rktlet

Right, Clear Containers is a feature of both rkt and cri-o container runtimes. rkt has had that feature for a couple years, if I recall correctly.

Kinvolk | Linux and Cloud Infrastructure Engineers | Berlin, DE | Full-time | ONSITE (or REMOTE for those that have done it before)

Kinvolk is a small (currently 12 ppl) software engineering team/consultancy focused on open-source systems-level Linux and distributed systems projects. Some our our specialties are container runtimes, (e)BPF, systemd and Kubernetes. We mostly work in Golang, C and Rust. We've worked with some of the best companies in the cloud infrastructure space; CoreOS on rkt, WeaveWorks on Weave Scope, Chef on Habitat+Kubernetes, etc.

Most of what we do is in the open, so check out our Github activity: https://github.com/kinvolk/

We are not VC funded, but work almost exclusively with companies that are.

Please see https://kinvolk.io/careers/ for the positions. INTERNS are also welcome.

We hire based on cooperativeness, respectfulness, attention to detail, and technical skill; in that order.

If not in the EU, we can help with a VISA to Germany provided you have a college degree.

Right, thx for pointing that out. This post is a follow-up to the talk Alban gave.