Support for CoreOS Container Linux ending in May Posted Feb 5, 2020 21:36 UTC (Wed) by 19h (guest, #134773) [Link] (3 responses) This was just a question of time after the acquisition by Red Hat (after which it became RHEL CoreOS). Although the acquisition alone was a reason for me to seek alternatives, the initiative by Kinvolk (Flatcar Container Linux) is very welcome and makes it straightforward to switch. I'd prefer if CoreOS was released into the public domain and be developed by the community, but I assume that's rather unlikely. Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 9:06 UTC (Thu) by bangert (subscriber, #28342) [Link] (2 responses) Given how even the blurp above mentions the existence of Fedora CoreOS and you yourself mention Flatcar - what specifically is it you dislike about those two community developed alternatives that does not fit your bill? Or do you mean actual Public Domain? Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 10:36 UTC (Thu) by 19h (guest, #134773) [Link] (1 responses) Before this sunsetting of CoreOS by Red Hat was announced it was not fully clear what the future holds for the project. Although the commit frequency dropped, it was hard to argue switching to Flatcar because there was no clarity on whether or not CoreOS will be phased out. I think it would have been beneficial to all users of CoreOS had Red Hat announced these plans earlier and released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. That way it could have been reborn as a community-driven project. But here we are, Red Hat doing business-as-usual. The users of CoreOS that hadn't bought into RHEL Linux / CoreOS yet are on their own, and the acquisition now seems like they simply wanted to own the trademark. Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 13:27 UTC (Thu) by walters (subscriber, #7396) [Link] > released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. All of the code for the OS side is on Github and is already under FOSS licenses; not clear to me what being in the public domain would help. As far as handing over to Kinvolk, I think they already have forks of what they need? > the acquisition now seems like they simply wanted to own the trademark. No. Technologies from the original CoreOS Container Linux as well as Tectonic (important here!) are fundamental to what we're doing with Fedora CoreOS. I helped create Atomic Host, and to be honest I didn't realize how much we'd missed the point about having *automatic* updates on by default. It's not just about having updates be transactional, about having a read-only /usr by default etc. - automatic updates change the whole mindset around who "owns" updates. If I log into a system and type "yum/apt update" and it breaks, the default mentality is it's *my* fault. If I set up Fedora CoreOS and the automatic update kicks in at some point next month it breaks, it's Fedora/FCOS team's fault! (Obviously exaggerating a bit here, but still I think the mentality is real) And a lot of the concepts and code from Tectonic (the CoreOS Kubernetes) are now foundational to OpenShift 4. OpenShift 4 - a huge focus for Red Hat in case you missed it - *depends on Ignition* which came from CoreOS. Oh and - Tectonic was proprietary, OpenShift 4 is fully FOSS. We call it CoreOS because we are continuing and aiming to make better what the original CoreOS Container Linux started. Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 10:20 UTC (Thu) by Darkmere (subscriber, #53695) [Link] (2 responses) Sad to see it go. It was the first server side OS to take a step back from the old read write mess around of server OS. Fedora CoreOS isn’t there. It’s the same as old. Read write modifications and additions that permit mutability of the OS over time. Same with openSUSE kubic/MicroOS. They also permit drift over time, and the “add more software “ features even encourages it. I’m disheartened to see CoreOS gone. Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 13:14 UTC (Thu) by walters (subscriber, #7396) [Link] > Fedora CoreOS isn’t there. It’s the same as old. Read write modifications and additions that permit mutability of the OS over time. Would love more detail on this - what "read write modifications"? Are you talking about package layering? If so...just don't use it! The system stays in a read-only, pure image based state always, by default. However: It *must* be a first class operation to e.g. override the kernel or systemd or whatever if you need to test something. See also [this blog](https://blog.verbum.org/2019/12/23/starting-from-open-and...). But again, if you don't need it, don't use it and there's no overhead from it. Or are you talking about some other form of mutability? Support for CoreOS Container Linux ending in May Posted Feb 7, 2020 17:09 UTC (Fri) by rcampos (subscriber, #59737) [Link] Flatcar should be there :-)
Posted Feb 5, 2020 21:36 UTC (Wed) by 19h (guest, #134773) [Link] (3 responses)
I'd prefer if CoreOS was released into the public domain and be developed by the community, but I assume that's rather unlikely.
Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 9:06 UTC (Thu) by bangert (subscriber, #28342) [Link] (2 responses) Given how even the blurp above mentions the existence of Fedora CoreOS and you yourself mention Flatcar - what specifically is it you dislike about those two community developed alternatives that does not fit your bill? Or do you mean actual Public Domain? Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 10:36 UTC (Thu) by 19h (guest, #134773) [Link] (1 responses) Before this sunsetting of CoreOS by Red Hat was announced it was not fully clear what the future holds for the project. Although the commit frequency dropped, it was hard to argue switching to Flatcar because there was no clarity on whether or not CoreOS will be phased out. I think it would have been beneficial to all users of CoreOS had Red Hat announced these plans earlier and released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. That way it could have been reborn as a community-driven project. But here we are, Red Hat doing business-as-usual. The users of CoreOS that hadn't bought into RHEL Linux / CoreOS yet are on their own, and the acquisition now seems like they simply wanted to own the trademark. Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 13:27 UTC (Thu) by walters (subscriber, #7396) [Link] > released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. All of the code for the OS side is on Github and is already under FOSS licenses; not clear to me what being in the public domain would help. As far as handing over to Kinvolk, I think they already have forks of what they need? > the acquisition now seems like they simply wanted to own the trademark. No. Technologies from the original CoreOS Container Linux as well as Tectonic (important here!) are fundamental to what we're doing with Fedora CoreOS. I helped create Atomic Host, and to be honest I didn't realize how much we'd missed the point about having *automatic* updates on by default. It's not just about having updates be transactional, about having a read-only /usr by default etc. - automatic updates change the whole mindset around who "owns" updates. If I log into a system and type "yum/apt update" and it breaks, the default mentality is it's *my* fault. If I set up Fedora CoreOS and the automatic update kicks in at some point next month it breaks, it's Fedora/FCOS team's fault! (Obviously exaggerating a bit here, but still I think the mentality is real) And a lot of the concepts and code from Tectonic (the CoreOS Kubernetes) are now foundational to OpenShift 4. OpenShift 4 - a huge focus for Red Hat in case you missed it - *depends on Ignition* which came from CoreOS. Oh and - Tectonic was proprietary, OpenShift 4 is fully FOSS. We call it CoreOS because we are continuing and aiming to make better what the original CoreOS Container Linux started.
Posted Feb 6, 2020 9:06 UTC (Thu) by bangert (subscriber, #28342) [Link] (2 responses)
Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 10:36 UTC (Thu) by 19h (guest, #134773) [Link] (1 responses) Before this sunsetting of CoreOS by Red Hat was announced it was not fully clear what the future holds for the project. Although the commit frequency dropped, it was hard to argue switching to Flatcar because there was no clarity on whether or not CoreOS will be phased out. I think it would have been beneficial to all users of CoreOS had Red Hat announced these plans earlier and released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. That way it could have been reborn as a community-driven project. But here we are, Red Hat doing business-as-usual. The users of CoreOS that hadn't bought into RHEL Linux / CoreOS yet are on their own, and the acquisition now seems like they simply wanted to own the trademark. Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 13:27 UTC (Thu) by walters (subscriber, #7396) [Link] > released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. All of the code for the OS side is on Github and is already under FOSS licenses; not clear to me what being in the public domain would help. As far as handing over to Kinvolk, I think they already have forks of what they need? > the acquisition now seems like they simply wanted to own the trademark. No. Technologies from the original CoreOS Container Linux as well as Tectonic (important here!) are fundamental to what we're doing with Fedora CoreOS. I helped create Atomic Host, and to be honest I didn't realize how much we'd missed the point about having *automatic* updates on by default. It's not just about having updates be transactional, about having a read-only /usr by default etc. - automatic updates change the whole mindset around who "owns" updates. If I log into a system and type "yum/apt update" and it breaks, the default mentality is it's *my* fault. If I set up Fedora CoreOS and the automatic update kicks in at some point next month it breaks, it's Fedora/FCOS team's fault! (Obviously exaggerating a bit here, but still I think the mentality is real) And a lot of the concepts and code from Tectonic (the CoreOS Kubernetes) are now foundational to OpenShift 4. OpenShift 4 - a huge focus for Red Hat in case you missed it - *depends on Ignition* which came from CoreOS. Oh and - Tectonic was proprietary, OpenShift 4 is fully FOSS. We call it CoreOS because we are continuing and aiming to make better what the original CoreOS Container Linux started.
Posted Feb 6, 2020 10:36 UTC (Thu) by 19h (guest, #134773) [Link] (1 responses)
I think it would have been beneficial to all users of CoreOS had Red Hat announced these plans earlier and released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. That way it could have been reborn as a community-driven project.
But here we are, Red Hat doing business-as-usual. The users of CoreOS that hadn't bought into RHEL Linux / CoreOS yet are on their own, and the acquisition now seems like they simply wanted to own the trademark.
Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 13:27 UTC (Thu) by walters (subscriber, #7396) [Link] > released the CoreOS project into the public domain (literally) -- or at least collaborate with, or hand over to, Kinvolk. All of the code for the OS side is on Github and is already under FOSS licenses; not clear to me what being in the public domain would help. As far as handing over to Kinvolk, I think they already have forks of what they need? > the acquisition now seems like they simply wanted to own the trademark. No. Technologies from the original CoreOS Container Linux as well as Tectonic (important here!) are fundamental to what we're doing with Fedora CoreOS. I helped create Atomic Host, and to be honest I didn't realize how much we'd missed the point about having *automatic* updates on by default. It's not just about having updates be transactional, about having a read-only /usr by default etc. - automatic updates change the whole mindset around who "owns" updates. If I log into a system and type "yum/apt update" and it breaks, the default mentality is it's *my* fault. If I set up Fedora CoreOS and the automatic update kicks in at some point next month it breaks, it's Fedora/FCOS team's fault! (Obviously exaggerating a bit here, but still I think the mentality is real) And a lot of the concepts and code from Tectonic (the CoreOS Kubernetes) are now foundational to OpenShift 4. OpenShift 4 - a huge focus for Red Hat in case you missed it - *depends on Ignition* which came from CoreOS. Oh and - Tectonic was proprietary, OpenShift 4 is fully FOSS. We call it CoreOS because we are continuing and aiming to make better what the original CoreOS Container Linux started.
Posted Feb 6, 2020 13:27 UTC (Thu) by walters (subscriber, #7396) [Link]
All of the code for the OS side is on Github and is already under FOSS licenses; not clear to me what being in the public domain would help. As far as handing over to Kinvolk, I think they already have forks of what they need?
> the acquisition now seems like they simply wanted to own the trademark.
No. Technologies from the original CoreOS Container Linux as well as Tectonic (important here!) are fundamental to what we're doing with Fedora CoreOS.
I helped create Atomic Host, and to be honest I didn't realize how much we'd missed the point about having *automatic* updates on by default. It's not just about having updates be transactional, about having a read-only /usr by default etc. - automatic updates change the whole mindset around who "owns" updates. If I log into a system and type "yum/apt update" and it breaks, the default mentality is it's *my* fault. If I set up Fedora CoreOS and the automatic update kicks in at some point next month it breaks, it's Fedora/FCOS team's fault! (Obviously exaggerating a bit here, but still I think the mentality is real)
And a lot of the concepts and code from Tectonic (the CoreOS Kubernetes) are now foundational to OpenShift 4. OpenShift 4 - a huge focus for Red Hat in case you missed it - *depends on Ignition* which came from CoreOS.
Oh and - Tectonic was proprietary, OpenShift 4 is fully FOSS.
We call it CoreOS because we are continuing and aiming to make better what the original CoreOS Container Linux started.
Posted Feb 6, 2020 10:20 UTC (Thu) by Darkmere (subscriber, #53695) [Link] (2 responses)
Fedora CoreOS isn’t there. It’s the same as old. Read write modifications and additions that permit mutability of the OS over time.
Same with openSUSE kubic/MicroOS. They also permit drift over time, and the “add more software “ features even encourages it.
I’m disheartened to see CoreOS gone.
Support for CoreOS Container Linux ending in May Posted Feb 6, 2020 13:14 UTC (Thu) by walters (subscriber, #7396) [Link] > Fedora CoreOS isn’t there. It’s the same as old. Read write modifications and additions that permit mutability of the OS over time. Would love more detail on this - what "read write modifications"? Are you talking about package layering? If so...just don't use it! The system stays in a read-only, pure image based state always, by default. However: It *must* be a first class operation to e.g. override the kernel or systemd or whatever if you need to test something. See also [this blog](https://blog.verbum.org/2019/12/23/starting-from-open-and...). But again, if you don't need it, don't use it and there's no overhead from it. Or are you talking about some other form of mutability? Support for CoreOS Container Linux ending in May Posted Feb 7, 2020 17:09 UTC (Fri) by rcampos (subscriber, #59737) [Link] Flatcar should be there :-)
Posted Feb 6, 2020 13:14 UTC (Thu) by walters (subscriber, #7396) [Link]
Would love more detail on this - what "read write modifications"? Are you talking about package layering? If so...just don't use it! The system stays in a read-only, pure image based state always, by default.
However: It *must* be a first class operation to e.g. override the kernel or systemd or whatever if you need to test something. See also [this blog](https://blog.verbum.org/2019/12/23/starting-from-open-and...).
But again, if you don't need it, don't use it and there's no overhead from it.
Or are you talking about some other form of mutability?
Posted Feb 7, 2020 17:09 UTC (Fri) by rcampos (subscriber, #59737) [Link]
Copyright © 2020, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds
LWN