The plan for merging CoreOS into Red Hat

Posted May 15, 2018 9:21 UTC (Tue) by nim-nim (subscriber, #34454)
In reply to: The plan for merging CoreOS into Red Hat by nevyn
Parent article: The plan for merging CoreOS into Red Hat

Containers just compound the terrible inertia in propagating fixes in Go. What you think are single purpose containers that ship a single app are actually single purpose containers that ship a single app composed of aa private copy of hundreds of other Go projects in its GOPATH.

The container + private copy thing means you can avoid dealing with code changes in the code of those other projects.

But avoiding dealing with code changes also means avoiding propagating fixes.

The plan for merging CoreOS into Red Hat

Posted May 15, 2018 12:31 UTC (Tue) by liw (subscriber, #6379) [Link] (1 responses)

It's 2018, where is the +1000 button on LWN? This is why we don't have flying cars, personal jet packs, and fluffy little robot kittens who fulfil our every need: lack of upvote buttons on LWN. Sheesh.

In other words, I agree with nim-nim on embedding code copies on containers. We have a problem and we need to solve it.

The same problem occurs in other contexts as well, when embedding dependencies are used. There's a clear need for a solution to this problem that makes sure security fixes, and other fixes to sufficiently grave bugs, get smoothly and swiftly and securely distributed to all the embedded copies.

In a way it's similar to what distributions like Debian do for their stable releases: packaged software is not updated to every new upstream version, fixes are backported to the versions in the stable release. I fear the way Debian does this is highly labour intensive, and probably doesn't scale.

Note that technical solutions are not enough. There is also a need for the software developers, sysadmins, and users to understand the issues, and to use whatever solutions there are.

I don't have the solution, but I do see the problem.

The plan for merging CoreOS into Red Hat

Posted May 15, 2018 23:29 UTC (Tue) by pabs (subscriber, #43278) [Link]

> I fear the way Debian does this is highly labour intensive

The Debian security team has automated some aspects of their patch backporting:

https://debconf17.debconf.org/talks/166/