New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: all: require Linux 3.17 kernel for Go 1.24 #67001
Comments
I'm ambivalent about this trend in general. For Go, it also pushes a bit against the compatibility promise. I've been burned multiple times by manufacturers dropping support for old hardware, requiring expensive upgrade purchases that provide no return benefit to me. I still run a 32-bit x86 Mac in the lab because without it I cannot control an important piece of kit that can only be interfaced to an old mac OS version. I can't even connect it to the network for fear some update will render my equipment non-working. While I appreciate the implied - if uncertain - value of "newer is safer, newer is better", what is the actual cost to the project of letting Go binaries run on old OSes? That seems a better way to evaluate this proposal. |
The cost to the project in general is continued maintenance and testing of code paths working around the lack of features from the (relatively) newer kernels. We don't do a great job of testing Go on these old kernels as it is. It probably only kind of works. I should have mentioned that Linux 3.2 was released 12 years ago. It is not bleeding edge by any means. According to https://en.wikipedia.org/wiki/Linux_kernel_version_history, the final 2.6.x kernel was 2.6.32.71 in 2016. We are talking about dropping support for kernels that are very old. |
Talking to @FiloSottile about #66821, it sounds like moving to 3.17 (~2014) as the minimum would let us avoid needing to open /dev/urandom ever, because 3.17 added getrandom(2). That would be a better choice than 3.2. |
This proposal has been added to the active column of the proposals project |
In the way of additional data points, a few popular and older distribution versions and their associated kernel versions (all of which IMO point in favor of this proposal at 3.2 and even at 3.17 👍):
It's a bit hard to browse, but even more aggregated data at https://repology.org/project/linux/versions (I dug up this information to convince myself this was sane and figured it was worth sharing 👍 ❤️) Edit: and see #60792 (comment) for a much longer form of similar data with many more details! 😄 ❤️ |
Red Hat Enterprise Linux 7 is on kernel 3.10 and it's maintenance ends 30 June 2024. Red Hat offers Extended Lifecycle Support until 30 June 2028. Gcloud CLI supports RHEL7 and it includes Golang binaries. You may want to clarify how long Gcloud CLI plans to support RHEL7. |
The RHEL 7.9 OS has a kernel version 3.10.0 and is supported until 2028-06. Changing the minimum version to 3.17 may impact services running on this OS. https://distrowatch.com/table.php?distribution=redhat&pkglist=true&version=rhel-7.9#pkglist |
The RHEL 7 kernel had getrandom backported in 2017, per https://access.redhat.com/errata/RHSA-2017:1842:
So in practice Go programs would continue to work on RHEL 7 if the only 3.10+ feature used is getrandom. |
Thanks for the added details. I think we can say 3.10+getrandom is fine too. |
In 2021 in #45964 we moved the minimum Linux kernel version to 2.6.32.
There is a good summary from @baryluk about what we use from newer kernels at #60792 (comment).
@mdempsky points out in #60792 (comment) that Rust and glibc decided on a minimum kernel version of 3.2 last year.
Adopting 3.2 as Go's minimum seems reasonable given the rest of the Linux ecosystem doing the same.
I propose we announce this in Go 1.23 and make the change in Go 1.24. That will still be a year or so behind glibc and Rust, and the announcement will create time for people to speak up if they are affected and cannot upgrade.
Really everyone should be on newer kernels for security updates anyway.
The text was updated successfully, but these errors were encountered: