blixtra

1. We are confident we have a very robust path to revenue.

2. Given the team, it should be quite obvious there will be a Linux-based OS involved.

Our aims are global but we certainly look forward to playing an important role in the European tech landscape.

As per the announcement, we’ll be building this over the next months and sharing more information as this rolls out. Much of the fundamentals can be extracted from Lennart’s posts and the talks from All Systems Go! over the last years.

Hi, Chris here, CEO @ Amutable. We are very excited about this. Happy to answer questions.

If you want to know more about Varlink, Lennart Poettering gave a talk about it at All Systems Go! last year. https://media.ccc.de/v/all-systems-go-2024-276-varlink-now-/...

I’ve now had 2 IONIQ 5s stolen in Berlin, the last a couple months ago. Each seemingly using a keyless access hacking device. That’s enough for me to not see a Hyundai or Kia in my future anytime soon. And I very much liked the IONIQ 5. But if I can’t keep one more than 2 years, what’s the point? I’ve lost all trust in those companies, upgrade or not.

We, the Headlamp project, don't make any claims about being state-of-the-art as that's hard to define. But we do think Headlamp ranks high among having the best user experience and believe the fact that we're a 100% open-source project is a huge plus compared to some other projects in the space.

I think one area that we are rather different than other projects is that Headlamp is not only focused on end-users but also for teams looking to build their own Kubernetes UX by leveraging the Headlamp plugin system. Our thinking is that this will foster broader community participation and make Headlamp the most viable project in the space.

If you find that there is anything missing please file an issue and we'll consider it: https://github.com/headlamp-k8s/headlamp/issues/new

Flatcar is a host OS to run containers. It is not a base OS to build containers.

The update server supports the Omaha protocol, is called Nebraska and is available here under an Apache license: https://github.com/kinvolk/nebraska

Our team hosts the public server, but any Flatcar user can run Nebraska themselves and point their nodes to that.

Thanks for dropping the mic, I'll kindly pick it up.

I'm the initiator of the Flatcar Container Linux project and former CEO of Kinvolk. Thus, I'm rather knowledgeable about the project and was involved in most decisions.

The controversy you speak of is very new to me. If you could point to any references, I'd love to be aware of them.

Firstly, there was nothing "hacked" out of CoreOS. Flatcar is literally the CoreOS Container Linux repos forked and carried on as is. Once the CoreOS EOL was reached we started updating the stale packages. That's it. Any further updates are what any distro would do in the course of maintenance to remain modern and relevant.

Secondly, anything that was previously termed the "Pro" version is now just available in the standard version. So there is no difference. To my knowledge, the project doesn't even produce any Pro versions any longer and I don't think there are even any references to it in our docs. But even when we did have a Pro version, all the work we did was done in the open and was in our source repositories. We just didn't release public builds of those.

Unlike CoreOS, we also developed* and open sourced the update server. It's called Nebraska and available here under an Apache license. https://github.com/kinvolk/nebraska

With regard to a license matrix, you can find all licenses for each release in the respective release directory. For example this one: https://stable.release.flatcar-linux.net/amd64-usr/current/f...

If you do find anything that is not 100% open source, let me know and I'll follow up to make sure that's corrected.

I'm happy your excited about your project. But I think you'll fine it's better in the open source space to compete on merit and form relationships rather than tear down other projects and the work of the people behind the projects.

* based on the Core Roller project: https://github.com/coreroller/coreroller

This is incorrect. It’s an immutable OS. But containers can be started and stopped as much as you want. It’s the sole purpose of Flatcar.

This might help you: https://github.com/flatcar-linux/Flatcar/issues/502

I'll answer my own question after doing some more digging. It seems that as the columnar code is a self-contained PostgreSQL extension, you're only using the API which would be fine as there is no linking involved.

The project looks very interesting. But I had a look at the license of the Citus source code and it appears to be under an AGPL license and I didn't see an exception for the part of the code that you're including in Hydra. FWIU, AGPL code is not compatible with including in Apache code, although the opposite is compatible. So, I'd be interested to know if I'm understanding this wrong or if there is some license exception I'm not seeing.

CoreOS lives on as Flatcar Container Linux. https://twitter.com/kelseyhightower/status/12831024012520980... It's a fully-compatible, drop-in replacement.

I'm not exactly sure what you're asking. But Flatcar Container Linux is completely open source. In fact, everything we do at Kinvolk is. We do not build open-core products.

For example, we've gone a step further than CoreOS did and have a fully open-sourced update server, Nebraska (https://github.com/kinvolk/nebraska). We also generate a list of contents and licenses for each build. Here is an example from the most recent stable: https://stable.release.flatcar-linux.net/amd64-usr/2512.2.1/...

Chris from Kinvolk here. Happy to see you're having success with Flatcar. We, of course, agree that CoreOS Container Linux was a huge success. The uptake that we've seen in Flatcar usage, especially since the CoreOS EOL date on May 26th, has been extraordinary. So from what we a can see, the market is there for a minimal Linux for containers and and we're happy to continue filling that need with Flatcar.

Wow, thanks for the nice words! I'll make sure Alban sees them. :)

Currently for the stable and beta channels that is true for now. Of course that changes in May when we fully take over maintenance. But for the alpha channel, and experimental edge channel, we have already diverged with updated packages.

But, yes, in the beginning we simply removed the CoreOS trademark similar to how CentOS removes the RHEL trademark. But very different from CentOS, we knew from the start that the upstream would eventually go away and all maintenance would be carried by Kinvolk and other contributors.

Flatcar Container Linux is a drop-in replacement for CoreOS Container Linux which in my mind (I conceived the fork) makes it more than "an (almost) equivalent alternative". You can literally update straight into Flatcar from CoreOS using the standard update process. See https://docs.flatcar-linux.org/os/update-from-container-linu...

Most of our Flatcar Container Linux users run Kubernetes. It's really an ideal match for a minimal container OS.

A former rkt dev here. rkt was archived by the CNCF with our blessings. Was just speaking to other rkt folks at FOSDEM about archiving the project on GH as well, which should happen shortly. We will also announce deprecation of rkt in Flatcar Container Linux very soon. rkt really changed the container runtime landscape for the best and we're happy to see that other projects improved because if it and that the space was able to consolidate a bit.

Chris from Kinvolk here. Our Flatcar builds are already completely independent of CoreOS builds. This is quite exciting for us as we can finally start updating the included software versions. We've been doing this a while for the edge channel (https://www.flatcar-linux.org/releases/) and have been waiting to do that with the other channels.

The whole point of CoreOS Container Linux was to deliver a steady stream of security/software updates. We've been eager to update packages for Flatcar Container Linux but have wanted to maintain as much compatibility as possible for as long as possible. Fairly soon, however, we'll be introducing an updated kernel and user space (systemd, Docker, etc.) into the alpha channel. For us, this will mark the point where we feel like we're fully taking the reins from CoreOS and carrying forward the original objectives.

Just to reiterate what others have said, because this comes up quite a bit. You should not use CoreOS or Flatcar images as the base for your containers. They are intended to be the host operating system upon which you run the containers. Their key features that make them an awesome host OS for containers (no package manager, for example) make them unsuitable for use as the base image of containers.

Chris from Kinvolk here.

We're happy to talk about what you need on the security front. Some of the folks working on Flatcar Container Linux have a very strong security background; worked on AWS' EC2 security team, do regular pentesting for distributed systems[1], have reported dozens of security issues to upstream projects packaged in Flatcar Container Linux, including the kernel.

We've just now started breaking away from the upstream project, and updating packages. Addressing any open security issues is front and center in our efforts. If you have concerns we'd love to hear them.

We worked with CoreOS team for years (was our founding project) and they trusted us on the security front. We feel that if you trusted CoreOS and know our team + background, you should have just as much trust in Kinvolk.

[1] https://www.youtube.com/watch?v=ze1vgh8sjlE

Happy to answer any questions about Flatcar Container Linux (https://www.flatcar-linux.org/).

It should be noted that we went a step further than CoreOS by releasing the update service we use to manage updates as an open source project, Nebraska (https://github.com/kinvolk/nebraska).

We started Flatcar Container Linux to provide the option of continuing as is. We don't like to see perfectly good software be discarded simply because of an acquisition. We understand the hassle with porting configurations and have found a good number of organizations who are supporting our effort through support contracts to continue in the manner they intended when they chose to use CoreOS Container Linux.

We also released the update service as an open source project, Nebraska (https://github.com/kinvolk/nebraska). That was something that was closed source with CoreOS. This allows you to be in control of your updates.

Kinvolk (https://kinvolk.io), the Kubernetes Linux experts | Berlin, Bengaluru ONSITE or REMOTE | Full Time

Kinvolk is a company focused on services and products for open-source cloud native Linux technologies. While having started out 4+ years ago as a consulting company (we built rkt with CoreOS, for example), we've recently added products to the mix. The first of which is Flatcar Container Linux, our drop-in replacement for CoreOS Container Linux. Building on this, we've introduced Lokomotive, our Kubernetes distribution, a major focus of development for us atm. In addition, we're building a collection of tools for debugging and security based on BPF and other low-level Linux technologies which will be integrated with our Linux + Kubernetes stack.

Kinvolk only works on/with open source technologies and all our products will be fully open source, NOT open core.

We're also the folks behind Cloud Native Rejects (https://cloud-native.rejekts.io/) and All Systems Go! (https://all-systems-go.io/)

If you're interested in working with an expert team that fully understands the the system, is passionate about open source, and building cutting edge technologies then by all means, apply within!

We have a number of openings in BERLIN, BEGELURU and remote:

* Technical Account Manager

* Visual and Brand Designer

* Events coordinator

* Kubernetes Operations Engineer (especially interested in this role being distributed to have follow-the-sun support)

* Cloud Infrastructure Engineer

* Linux Software Engineer

Find the full details at https://kinvolk.io/careers/

Kinvolk (https://kinvolk.io), the Kubernetes Linux experts | Berlin, Bengaluru ONSITE or REMOTE | Full Time

Kinvolk is a company focused on services and products for open-source cloud native Linux technologies. While having started out 4+ years ago as a consulting company (we built rkt with CoreOS, for example), we've recently added products to the mix. The first of which is Flatcar Container Linux, our drop-in replacement for CoreOS Container Linux. Building on this, we've introduced Lokomotive, our Kubernetes distribution, a major focus of development for us atm. In addition, we're building a collection of tools for debugging and security based on BPF and other low-level Linux technologies which will be integrated with our Linux + Kubernetes stack.

Kinvolk only works on/with open source technologies and all our products will be fully open source, NOT open core.

We're also the folks behind Cloud Native Rejects (https://cloud-native.rejekts.io/) and All Systems Go! (https://all-systems-go.io/)

If you're interested in working with an expert team that fully understands the the system, is passionate about open source, and building cutting edge technologies then, by all means, apply within!

We have a number of openings in BERLIN, BEGELURU and remote:

* Technical Account Manager

* Kubernetes Operations Engineer (especially interested in this role being distributed to have follow-the-sun support)

* Cloud Infrastructure Engineer

* Linux Software Engineer

* Events coordinator

* Visual and Brand Designer

Find the full details at https://kinvolk.io/careers/

True, the current Lokomotive repository consists of mostly code forked from Typhoon, something we state in the article. There are a number of small and largish modifications: support for Packet, additional PSPs, etc. But this is just the base Kubernetes portion of Lokomotive. Lokomotive includes 4 main parts, 2 of which have been release thus far. The other public portion of Lokomotive ist the underlying OS, Flatcar Linux. The integration with the recently announced Flatcar Linux Edge channel is the main motivation for releasing at this point; stay tuned for some projects that build on top of this. The other 2 parts will be rolled out this summer. Those are lokoctl, the installer, and Lokomotive Components, a collection of base cluster component.