Our great sponsors
-
-
nebraska
Update monitor & manager for applications using the Omaha protocol, optimized for Flatcar Container Linux.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
Flatcar
Discontinued Flatcar project repository for issue tracking, project documentation, etc. [Moved to: https://github.com/flatcar/Flatcar] (by flatcar-linux)
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
toc
⚖️ The CNCF Technical Oversight Committee (TOC) is the technical governing body of the CNCF Foundation.
-
I guess if you found my comment to be "comically hyperbolic" then replying to mine with a "comically reductionist" is fair game
So, anyway, I actually did dig up a concrete example of my experience with it, and I cannot link to the "Additional information" section but that is both why I think the thing was a mess and also why the Miroservices YT joke resonated: https://github.com/flatcar/Flatcar/issues/220
I think the CoreOS boot strategy was decomposed into a bunch of different executables, each responsible for doing their own little slice of the world. Maybe it drew inspiration from systemd in that way. But, just like my real life experience with microservices, it requires keeping a bunch of different projects and their upgrade paths in ones head, knowing their disparate config formats, and when one of them inevitably has a bug, understanding how to troubleshoot what went wrong with the system as a whole
And, again in trying to be reasonable in this discussion[1] I do also understand why one would opt for the data URI, given how much of the rest of Ignition loads content from URLs. I don't believe cloud-init has that remote content paradigm baked into in nearly the same way, so I hear you about that.
And yes, my belief is that JSON is a data-exchange format from _computer to computer_ and making people write them is a poor DX choice, IN MY OPINION. And, to reiterate, I know that CoreOS's perspective is that it is a computer-to-computer transmission from the transpiler-project-o-the-day to the Ignition binary, but that is predicated on one having access to that transpiler binary in all cases, which is quite different from the problem that cloud-init is trying to solve
fn-1: I'm sorry you got hurt by my "tire fire" outburst, and that evidently derailed this whole interaction, but it was my experience
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 that.
Firstly, there was nothing "hacked" out of CoreOS. Flatcar is literally the CoreOS Container Linux repos forked and carried on as is. Once the 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 might help you: https://github.com/flatcar-linux/Flatcar/issues/502
The rpi4 has uefi firmware available, this allows you to boot any generic uefi aarch64 image, you no longer need rpi specific images.
A couple of small things, but primarily I don’t think it actually embraced immutability in the same way. CoreOS container Linux used A/B partitions for updating truly immutably. Partition B didn’t boot? Just boot A again.
Fedora CoreOS and RHEL CoreOS use OSTree [1], no shade on OSTree, it works well, but I slept better with A/B partitions, I just find them easier to reason about.
How does this compare to https://ublue.it/
ublue is based off of fedora and rpm-ostree, which is what "CoreOS" is today.
What happened was old school CoreOS was A/B partition based: https://github.com/coreos/docs/blob/master/os/sdk-disk-parti...
My memory is hazy but here's how I remember it: After Red Hat acquired CoreOS they rebased the entire thing around rpm-ostree, which is the CoreOS people know today: https://coreos.github.io/rpm-ostree/
At the time there was some anxiety in the community as to what would happen, as there was no direct upgrade path from old CoreOS to new CoreOS. Theoretically if we all believed the kool-aid we were drinking it's just a redeploy, no pets!
Kinvolk came along, forked it, and made Flatcar Linux, which kept the A/B partitioning system, and more crucially, let you just change a config file and all your old CoreOS nodes would just move to Flatcar and then you were good to go. So now if you wanted to stay on the system you were comfortable with you could just use Flatcar. If the composability of rpm-ostree attracted you then new CoreOS have you covered. Red Hat deserves a hat tip here because in their documentation/blog they explicitly mentioned Flatcar as an option for people who wanted to stick with what they know, which I thought was cool and how I discovered it!
Later on Microsoft acquired Kinvolk and and then people raised eyebrows. I have not checked in a while but the folks involved continued to do their thing and run it like a good OSS project, hold public meetings, all that stuff.
I use both and they're both high quality.
ublue is based off of fedora and rpm-ostree, which is what "CoreOS" is today.
What happened was old school CoreOS was A/B partition based: https://github.com/coreos/docs/blob/master/os/sdk-disk-parti...
My memory is hazy but here's how I remember it: After Red Hat acquired CoreOS they rebased the entire thing around rpm-ostree, which is the CoreOS people know today: https://coreos.github.io/rpm-ostree/
At the time there was some anxiety in the community as to what would happen, as there was no direct upgrade path from old CoreOS to new CoreOS. Theoretically if we all believed the kool-aid we were drinking it's just a redeploy, no pets!
Kinvolk came along, forked it, and made Flatcar Linux, which kept the A/B partitioning system, and more crucially, let you just change a config file and all your old CoreOS nodes would just move to Flatcar and then you were good to go. So now if you wanted to stay on the system you were comfortable with you could just use Flatcar. If the composability of rpm-ostree attracted you then new CoreOS have you covered. Red Hat deserves a hat tip here because in their documentation/blog they explicitly mentioned Flatcar as an option for people who wanted to stick with what they know, which I thought was cool and how I discovered it!
Later on Microsoft acquired Kinvolk and and then people raised eyebrows. I have not checked in a while but the folks involved continued to do their thing and run it like a good OSS project, hold public meetings, all that stuff.
I use both and they're both high quality.
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 that.
Firstly, there was nothing "hacked" out of CoreOS. Flatcar is literally the CoreOS Container Linux repos forked and carried on as is. Once the 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
The most significant change this acquisition brought to Flatcar was to turn it from a vendor-driven open source project to a community-driven one. Also see Kinvolk's statement at the time: https://kinvolk.io/blog/2021/04/microsoft-acquires-kinvolk/
Since then, the project has opened up and has become fully community driven - releases, features, stewardship, everything. To further underline independent stewardship, Flatcar was recently proposed to join the CNCF as an incubating project: https://github.com/cncf/toc/pull/991 .
Thanks for the feedback :) Apparently there's always room to improve our docs. A maintainer has taken a stab on that (see https://github.com/flatcar/flatcar-website/pull/263 for progress) and we'll update our docs shortly.