Live data from Hacker News

Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

coreos.com

61–70 of 70 posts

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#61
post #51

RH became irrelevant when everyone was moving to cloud shenanigans and they didn't update their pricing accordingly. when even fortune50 have to drop your product they used for decades because of costs, that's a very clear indication of the end.

Source?

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#62
post #55

What is the story with rkt? Is it deprecated?

Yes, they announced at the Red Hat summit that they'll be phasing out development of rkt, though of course will do nothing to stop outside development. Between docker and cri-o, I think they decided that the need for a third supported and actively developed runtime wasn't enough to justify the effort. I'm excited to have the rkt developers work on cri-o, assuming that's where they're going.

Bummer, I preferred it in some ways.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#63

Earlier quoted context omitted.

I happily use Ubuntu on a few thousand servers running 10s of thousands of containers. We're a polyglot shop with lots of java and lots of go/node and my comfort level with ubuntu is high.

Thanks so much for sharing -- I think I'm going to give Ubuntu Server a try -- Canonical has done so much for open source (as noted by the other comment) and a bunch of innovation lately -- LXD is something I've actually wanted to play with as well as a virtualization option, which I actually failed to set up on Container Linux[0]. I swear I'm not trying to blog-spam, I just legitimately have been dealing with this s…

Server is based on a very minimal seed. There are no graphics drivers or anything X or desktop related. The seed is ultimately very close to what a cloud instance of Ubuntu will include if you want to give it a spin.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#64
post #51

RH became irrelevant when everyone was moving to cloud shenanigans and they didn't update their pricing accordingly. when even fortune50 have to drop your product they used for decades because of costs, that's a very clear indication of the end.

Source?

I have heard(both directly from customer and from friends at other orgs) of 3 Global 500 companies in the past 6 months walking away from OpenShift due to licensing costs. I am sure this will play out more frequently over the next 12-18 months.

Take some time to review RH's annual statement from 2017. Think about where they were in 2013/14, where we are at today and what things might look like in 2023. I am interested to see how they navigate the market. There is a fleet of Titantic like vessels plowing through the enterprise ocean right now...it will be interesting to observe what plays out over the next 3-5 years.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#65
post #51

RH became irrelevant when everyone was moving to cloud shenanigans and they didn't update their pricing accordingly. when even fortune50 have to drop your product they used for decades because of costs, that's a very clear indication of the end.

Source?

Call redhat and ask how much it would cost to do a "lift and move" strategy (i.e. just pack your legacy software in a vm and run it of the 'cloud')

They will do some crazy calculation and say, "well, aws will place the VM into a zillion machines, so that times our license per machine, plus our license per users per machine, you own us infinite dollars" ...it is that silly. If you don't trust me on this call them.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#66
post #50
post #3

If you have a deployed fleet of CoreOS instances, FlatCar[1] looks like a viable alternative. This article from NewStack gets into the details. [1] https://www.flatcar-linux.org/ [2] https://thenewstack.io/flatcar-linux-the-coreos-operating-sy...

Maintaining an operating system is a massive undertaking. Can Kinvolk guarantee that they will support the distro after Red Hat stops working on it?

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.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#67
post #3

If you have a deployed fleet of CoreOS instances, FlatCar[1] looks like a viable alternative. This article from NewStack gets into the details. [1] https://www.flatcar-linux.org/ [2] https://thenewstack.io/flatcar-linux-the-coreos-operating-sy...

Why would one want to do that?

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.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#68
post #66
post #50

Earlier quoted context omitted.

Maintaining an operating system is a massive undertaking. Can Kinvolk guarantee that they will support the distro after Red Hat stops working on it?

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-opt…

Thank you for your response!

I wish you the best of luck, choice is important for the ecosystem.

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#69

Earlier quoted context omitted.

does Alpine Linux provide Transactional Updates?

Try NixOS for something that has something close to transactional updates.

Using dockerTools in Nix means you get distroless images!

Re: Fedora CoreOS, Red Hat CoreOS, and the future of Container Linux

#70
post #30

Earlier quoted context omitted.

It's slow and hard to debug :( (at least in my experience - setting up OpenStack with it) I used to prefer Chef, but then with CoreOS the dream started to come true, just pack up everything in a container, and 12-factor configure it and that's it, and now I just can't wait for k8s to eat the world, and we'll be back full circle with helm instead of yum/apt.

Not ad-hominem but what do you know how to do? Package other peoples stuff in a config + install and then run scans against it?

I don't get what you mean, could you please elaborate a bit?
Post reply on HN