Wandering Thoughts archives

Who I think CentOS Stream is and isn't for

As time goes by and Red Hat people write more official posts (via), I've grown some opinions on who it feels that CentOS Stream is for and is not for. Since I also feel that Red Hat people are not being completely straightforward, I am going to write out my views, as an outsider to the CentOS project but someone who uses CentOS (and Ubuntu LTS) and has in the past used RHEL.

If you want to see if your software will work with upcoming package updates for the latest version of Red Hat Enterprise, CentOS Stream is definitely for you. Giving people a preview of RHEL updates is the expressed purpose of CS. You will not necessarily always be able to build software for RHEL using CentOS Stream, because of periodic ABI and API issues, but Red Hat will probably have a solution for that at some point. CentOS Stream is also probably for you if you operate RHEL systems and want some 'canary' ones to see how future package updates are likely to affect you (and if you see any new bugs or issues).

It's quite possible that for an open source project, using CentOS Stream will also be the easiest way of testing if your software (probably) works on the latest version of RHEL (at least in a fully updated state). However, I'm not all that familiar with the options Red Hat has here (such as their 'Universal Base Image'), and Red Hat may introduce more in the future. If you're a commercial company, the CentOS project distro FAQ makes it clear that Red Hat wants you to buy commercial RHEL licenses.

(Since CentOS Stream for 8 will end package updates in mid 2024, open source projects who want to continue testing for RHEL 8 beyond that point are going to have a problem. I expect that at least some open source projects will simply drop official compatibility with RHEL 8 at that point.)

If for some reason you want to contribute to Red Hat Enterprise, CentOS Stream is also officially for you. The most likely case I can imagine is that you use RHEL (or CentOS) and you have a bugfix or small improvement that you want to push for and contribute, one that Red Hat itself seems unlikely to take on. If you intend to make larger contributions, I hope that you have a strong commercial reason for helping a commercial company with its commercial product.

(To me, this raises significant questions about the future of EPEL. However, Red Hat funds Fedora too, so it could decide to work on funding EPEL should a supply of outside volunteers start to dry up.)

If you want a free RPM based Linux distribution that probably has a five-year support period, CentOS Stream may deliver what you're looking for. Officially it's supposed to, at least at the moment, but one can have concerns about the future and as far as I can tell this is not what CentOS Stream is 'supposed' to be for, at least in the eyes of Red Hat (and Red Hat calls the shots). openSUSE Leap is RPM based and free, but it's only supported for 3 years. Fedora, of course, is RPM based and free but only supported for one year, with version to version migration and an expectation that you'll always be on the most current version.

If you want a well supported Linux distribution with an extremely long support period and fast security updates, CentOS was never really for you in the first place and CentOS Stream is worse (because it definitely has no more than five years of package updates and may have longer delays for security updates). In the past you could press CentOS into service as such a thing and ignore, for example, the delay between RHEL security updates and the rebuilt CentOS security updates that corresponded to them, but you were always accepting a compromise. Now that compromise has blown up on you, although so far only for users of CentOS 8.

(CentOS currently says it will continue supporting CentOS 7 through the end of life of RHEL 7 itself. Since Red Hat calls the shots, I am not certain we should be as confident of that as we might have been before.)

If you want a free version of Red Hat Enterprise Linux, the traditional purpose of CentOS, Red Hat more or less says that CentOS Stream is not for you. It is extremely likely that one goal of Red Hat's management is to make it so that no such thing exists any more (and certainly not one that they help pay for). At the moment the closest you can probably come is Oracle Linux, which is also a rebuild of RHEL, but that's if you're willing to put your trust in Oracle (many people are not). It's possible that you can use CentOS Stream for this anyway, but if a lot of people do so I expect Red Hat to take additional steps to discourage this, such as by dropping 'CentOS Stream for 8' support when RHEL 9 comes out (or even before then).

Since 'a free version of RHEL, including its long support period' was in fact what many people used CentOS for, this leaves a significant number of CentOS users without an obvious Linux distribution to use at the moment, although options may well appear in the future.

Go modules are soon going to be the only future

One of the things that the Go project talked about in Eleven Years of Go, posted in November, is the plans for Go 1.16 and Go 1.17, and along with them the plans for Go modules. A short summary of all of that information is that Go modules are soon going to be our only option. This is said straight up in the article:

We will also finally wind down support for GOPATH-based development: any programs using dependencies other than the standard library will need a go.mod.

The current specifics are set out in the GOPATH wiki page. Go 1.16, expected in February 2021, will change the default to GO111MODULE=on (which requires go.mod even if you are under $GOPATH/src). Go 1.17 will entirely remove support for anything other than Go module mode. Given how the Go authors usually work, I expect this to remove the actual code that supports 'GOPATH development mode', not just remove access to it (for instance by removing checking $GO111MODULE and hard-wiring the value).

(It's possible that this timeline will turn out to be too aggressive and the Go authors will get enough pushback to postpone the removal past Go 1.17. The upgrade to Go 1.16 will be when people who are currently quietly working in GOPATH development mode will be forced to confront this, so this may uncover more people with more practical problems than expected.)

Given this aggressive timeline, I don't think there's any point in explicitly setting $GO111MODULE to 'auto' or 'off' (contrary to what I thought a year or so ago, which I admit that I didn't follow). If anything, you should set GO111MODULE=on now to buy yourself a bit of extra time to find any problems and figure out workarounds and new ways of working if you need them. I'm not going to go that far, but I'm lazy.

I have mixed feelings about the shift overall. I think Go modules are clearly better for development (including for enabling easy self-contained source code), but as someone who mostly consumes Go programs that I get with 'go get ...', it's probably going to make my life more complicated.

(I'd say that it'll make it harder for me to keep up with what programs have updated source code (cf), but in practice I no longer even look; I just do 'go get -u' on everything every so often.)