I think the idea behind it was definitely sound and pretty cool. I used CoreOS a couple of times for internal projects, using Docker (not rkt) but I think as Kubernetes became ubiquitously available on managed services, the need for me to attempt to build my own docker infrastructure started to wane.
I initially had that internal reaction too, but then realized that the value in CoreOS was the updates. If they're specifically going to stop that, at this point it's like any other never gets updates OS (sure the readonly file system still helps tremendously) - so yes, people should get off ASAP. But the September date ensures that anyone that wants to fork and provide updates some other way, can definitely find the time to do that.
I really enjoyed managing a CoreOS cluster in the past. It was one of those project where every product developed was great, like etcd, Ignition, CoreDNS and even Fleet, at the time.
I wonder how far they'd have gotten if they'd refused to sell.
While I never used CoreOS, the team certainly played a big part in the new wave of devops. The team also brought us etcd and a lot of the niceties of the devX in kubernetes et al these days. The article doesn't mention him, but shoutout to Brandon Phillips (technical lead) and his team for so much innovation in the space!
Too soon, I know, but can we soon start talking about abandoning all corporate-managed open source projects?
I wouldn't be surprised at this move if I were a CoreOS user, but I would be pretty pissed off that the next 6 months of my work would be migrating to a new platform for production work, all because the Linux distro I used got bought for its IP and customer list.
Or, say when HashiCorp is eventually bought, and suddenly its parent company decides, no more free tools for you, kids! Buy our other, more crappy products instead, but here's some free samples you can use at small scale. Also you need to rewrite all your code.
This extends to virtually every important project in the cloud computing ecosystem. They're all just run by companies, not a distributed decentralized community of users and developers (cat-herded by a BDFL) like every successful multi-generational open source project. There's also only one widely-supported Linux distribution in the world which isn't run by a corporation, meaning if that distribution ever goes down, everyone who uses Linux for more than its kernel is at the mercy of that given corporation, and we'll probably see massive fragmentation.
Open Source and GNU basically got its start to prevent corporations from preventing you from doing what you wanted with software, but it had a nasty side-effect: they can now make whatever you do with it obsolete and unsupportable. A bit like a car manufacturer no longer shipping replacement parts, forcing you to find some machinists to support an aging fleet of obsolete vehicles. And sure, if the impact is only to corporate engineers, who cares, but as one of those engineers, it is very annoying that we literally are letting them do this to us.
This isn't a corporate-managed open source problem, it's a single developer managed open source problem, with the corporate entity functioning like a single entity. Tons of great open source project exist as updating projects through the force of will of a single passionate developer. When that developer moves on, the project dies. The open source license grants others the ability to continue, but without that singular developer and their passion the reality is in most cases no one will pick up the project and carry it forward. Sure there are examples where projects do survive the death or disappearance of a maintainer, but there are far more projects out there in need of a new maintainer than find one.
It's not too soon to _talk_ about it, even if this seems not to be realistic at the moment.
As developers or users it is a good idea to push projects we're involved with to have non-corporate distribute governance to begin with, or move in that direction.
Of course, that requires multiple people from different organizations or unaffiliated to "adopt" projects as the "apple of their eye", enough to be involved in managing it; and to avoid deterioration into the one-developer-project case. So, a lot of effort by a lot of people, we should each do our part where we are involved.
Also, I'm sure there are lots of GNU/Linux distros which aren't run by a commercial corporation; certainly more than one.
> Red Hat, which purchased the company behind CoreOS in 2018, will, as of Sept.1, 2020, delete all CoreOS images. That means even if you wanted to download CoreOS (without supported updates), you won’t be able to.
> Although Fedora CoreOS is the official replacement for CoreOS, there are a few use cases it cannot replace, such as:
> No native support for Azure, Digital Ocean, GCE, Vagrant, or Container Linux community-supported platforms.
The rkt container runtime, originally developed by CoreOS, is missing.
Have these images of CoreOS (that RedHat will delete) not been added to the Wayback Machine yet? Or not backed up anywhere else?
> For those looking for a non-Red Hat alternative should check out the Flatcar Linux project, [1] a fork of CoreOS Container Linux.
So there is an (almost) equivalent alternative for those who use the images that are going to be deleted (and one that doesn't have the limitations of Fedora CoreOS)?
CoreOS was a competitor but it hasn't really been killed. CoreOS technology is still available but they changed the names of the products when they broke backwards compatibility.
At least in the open source world, other people can continue maintaining the project under a new name (dependent on the specific license). I wonder how Flatcar and Fedora CoreOS will converge/diverge.
Also, was rkt not open source? Or was it just depreciated?
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...
So, Flatcar is to CoreOS as Centos is to RHEL (if you ignore that CoreOS is going away). The differences make it not entirely analogous, but it's probably an easy way express it in very few words.
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.
CoreOS, docker, and mesos was an alternative to kubernetes. I'd say while using flatcar is viable, it looks like kubernetes is what the people have chosen.
Me, too! I got started with both CoreOS and kubernetes using their kubernetes-in-vagrant repo (before it went to the abysmal rkt runtime:
https://github.com/coreos/coreos-kubernetes/blob/v0.4.0/mult... ) and I shepherded that v1.0.6 cluster all the way up to v1.10 when I left. It was a highly educational process
I really prefer DC/OS to K8s. They both have strengths and weaknesses, but I hate we're not this k8s monoculture now. There need to be more container orchestration systems .. and don't kid yourself; few shops are using nomad.
nomad, k8s, mesos+marathon (or something plus mesos), traditional deployment
That's probably about it. Right now, I'm jumping on the k8s bandwagon, but looking to keep it simple. As much as I'd like to look at nomad seriously, too many times I've been caught by not looking at the mainstream.
39 comments
[ 3.5 ms ] story [ 99.6 ms ] threadGoodbye CoreOS.
I get moving on / cutting product lines but I don’t see the need to delete all the images.
I wonder how far they'd have gotten if they'd refused to sell.
I wouldn't be surprised at this move if I were a CoreOS user, but I would be pretty pissed off that the next 6 months of my work would be migrating to a new platform for production work, all because the Linux distro I used got bought for its IP and customer list.
Or, say when HashiCorp is eventually bought, and suddenly its parent company decides, no more free tools for you, kids! Buy our other, more crappy products instead, but here's some free samples you can use at small scale. Also you need to rewrite all your code.
This extends to virtually every important project in the cloud computing ecosystem. They're all just run by companies, not a distributed decentralized community of users and developers (cat-herded by a BDFL) like every successful multi-generational open source project. There's also only one widely-supported Linux distribution in the world which isn't run by a corporation, meaning if that distribution ever goes down, everyone who uses Linux for more than its kernel is at the mercy of that given corporation, and we'll probably see massive fragmentation.
Open Source and GNU basically got its start to prevent corporations from preventing you from doing what you wanted with software, but it had a nasty side-effect: they can now make whatever you do with it obsolete and unsupportable. A bit like a car manufacturer no longer shipping replacement parts, forcing you to find some machinists to support an aging fleet of obsolete vehicles. And sure, if the impact is only to corporate engineers, who cares, but as one of those engineers, it is very annoying that we literally are letting them do this to us.
As developers or users it is a good idea to push projects we're involved with to have non-corporate distribute governance to begin with, or move in that direction.
Of course, that requires multiple people from different organizations or unaffiliated to "adopt" projects as the "apple of their eye", enough to be involved in managing it; and to avoid deterioration into the one-developer-project case. So, a lot of effort by a lot of people, we should each do our part where we are involved.
Also, I'm sure there are lots of GNU/Linux distros which aren't run by a commercial corporation; certainly more than one.
> Although Fedora CoreOS is the official replacement for CoreOS, there are a few use cases it cannot replace, such as:
> No native support for Azure, Digital Ocean, GCE, Vagrant, or Container Linux community-supported platforms. The rkt container runtime, originally developed by CoreOS, is missing.
Have these images of CoreOS (that RedHat will delete) not been added to the Wayback Machine yet? Or not backed up anywhere else?
> For those looking for a non-Red Hat alternative should check out the Flatcar Linux project, [1] a fork of CoreOS Container Linux.
So there is an (almost) equivalent alternative for those who use the images that are going to be deleted (and one that doesn't have the limitations of Fedora CoreOS)?
[1]: https://www.flatcar-linux.org/releases/
Also, was rkt not open source? Or was it just depreciated?
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.
That's probably about it. Right now, I'm jumping on the k8s bandwagon, but looking to keep it simple. As much as I'd like to look at nomad seriously, too many times I've been caught by not looking at the mainstream.