> So what is to be done? As of this writing that has not yet been worked out, but there are a couple of options on the table... Stable maintainer Greg Kroah-Hartman suggested that he could "leave it alone and just see what happens". But, as Slaby pointed out, that will create the wrapping problem described above, which could confuse user space. If this is done, he said, it would be necessary to mask the minor version to eight bits, causing it to wrap back around to zero; whether that would cause confusion is another question. Version numbers are normally expected to increase monotonically.
Apparently with the exception of the masking to 8 bits, it seems like that's what's being tried in the end[1][2][3]:
> I did a release of the 4.4.256 and 4.9.256 releases today that contain nothing but a new version number.
> With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
> Right now I’m asking that everyone who uses these older kernel releases to upgrade to this release, and do a full rebuild of their systems in order to see what might, or might not, break. If problems happen, please let us know on the stable@vger.kernel.org mailing list as soon as possible as I can only hold off on doing new stable releases for these branches for a single week only (i.e. February 12, 2021).
Unpopular opinion: the team releases LTS kernel updates too fast the past few years, I've received 3x already in the first week of February and 8x during January for 5.4 series. During that same period, I have 4x (Feb) and 8x (Jan) tip revision kernels (5.9/5.10) upgrade - the supposed stable LTS kernel versions are changing as fast as the tip revisions.
So you want us to just stop fixing bugs and pushing out those fixes to users? That feels risky, if you do not want to upgrade to solve known problems, that's fine, feel free to skip upgrades. But why would you want to prevent those who want to run secure systems that ability?
The answer doesn't have to be so tetchy as your ire puts it, it's as simple as reducing releases to once a week or once every other week. I respect your work greatly, but you've taken the "throw the baby out with the bathwater" approach to your answer here; two Production LTS kernels a week seems excessive to me.
Why is it "excessive"? We are running 30+ fixes a day in these kernel releases, who would benefit if we delayed in getting those known-bug/security fixes out to the world quickly and properly tested (as we are currently doing)?
Why wait? What is a slower cadence going to accomplish?
If you only want to upgrade your kernel once a week, then you are free to do so regardless of how many releases they make during the week. Unless they've been introducing regressions by releasing too aggressively, there's no upside to releasing less often.
According to the only option I have for a "Broadband" (FCC 25mbit down 3mbit up) ISP... No, they're still happily giving me only a /64 IPv6 address.
IPv6 wants to reserve the lower 64 bits for RNG addresses (sure, fine), and the upper 32 bits for classification and global routing (also fine?); leaving 32 bits for inner-ISP subnet needs. In practice the ISPs seem intent on at _best_, for an actual business class connection (which I've seen) providing a /56 to that, but forcing stupid router firmware to eat /4 of that, leaving in practice a /60 on the business link.
"Stateless address autoconfiguration (SLAAC) requires a /64 address block, as defined in RFC 4291. Local Internet registries are assigned at least /32 blocks, which they divide among subordinate networks.[42] The initial recommendation stated assignment of a /48 subnet to end-consumer sites (RFC 3177). This was replaced by RFC 6177, which "recommends giving home sites significantly more than a single /64, but does not recommend that every home site be given a /48 either". /56s are specifically considered. It remains to be seen whether ISPs will honor this recommendation. For example, during initial trials, Comcast customers were given a single /64 network.[43]"
I've been sort of fortunate given how terrible American Internet is to be on Charter (legacy Time Warner). Due to their agreement with the FCC they can't (yet) put any cap on data use, and they've always given me a /56 when I request one. [1]
Really not looking forward to having to move or Charter finally implementing caps. With a lot of luck I'll be somewhere with municipal fiber, but I'm not hopeful.
[1] If you don't send an IPv6 prefix hint, you get a /64. I can get a /56 reliably by requesting it. Behavior with /48s is a bit buggy. Last time I tested it I could get a /48 some of the time, but sometimes the request would fail and I'd end up with a /64, so I went with the stable option instead.
> 128 bits ought to be enough for any IP address, right?
Here's something I find really amusing. In the late 90s, when IPv6 was being introduced, the joke was that 128 bits would suffice until we all had massively parallel wrist watches. Which would never happen, certainly not in our lifetimes.
Well, maybe. If you're trying to use the IP address to include routing information, maybe it's not enough. It's only 16 groups of 8 bits, or 8 groups of 16.
We wouldn't use them up in the same way we used up IPv4, there really can be 4 billion devices to address. But I could see some important spaces becoming very crowded when you try to cram multiple levels of routing information into that small a space, resulting in exploding complexity of routing tables as you try to garbage collect from sparse areas.
I've seen some people express reservation by how greedily they're allocating IPv6 blocks. Will home network /64 prefixes one day be like how Ford Motor Company owns all of 19.0.0.0 in IPv4? Well, probably not. But there's already a lot fewer than 128 bits of real addresses to hand out.
/64 is the smallest available subnet by design and many things will break the moment you try to subdivide further. The idea was that the lower 64 bits would identify a particular NIC by it's MAC address; this was later changed to be a randomized suffix. This is why most machines typically have hundreds of v6 addresses - they generate a new one every few hours.
>"As has often been pointed out, the stable-kernel releases are meant to be stable; that means they should be even more averse to ABI breaks than mainline releases, if that is possible. This may be a hard promise to keep for the next set of stable kernels, though, for the most mundane of reasons: nobody thought that there would be more than 255 minor updates to any given kernel release."
This is a fascinating problem. The velocity of kernel releases makes this problem both catastrophic and fleeting at once because it must be solved and, once solved, will quickly become a footnote in kernel history.
Also loved this quote:
Leon Trotsky once said that "old age is the most unexpected of all things that can happen to a man".
I have the rather unpopular opinion that structured versions are kind of a useless feature that, while perhaps once necessary, have become needless with today's culture of version pinning and better access to documentation.
Apparently with the exception of the masking to 8 bits, it seems like that's what's being tried in the end[1][2][3]:
> I did a release of the 4.4.256 and 4.9.256 releases today that contain nothing but a new version number.
> With this release, KERNEL_VERSION(4, 4, 256) is the same as KERNEL_VERSION(4, 5, 0).
> Right now I’m asking that everyone who uses these older kernel releases to upgrade to this release, and do a full rebuild of their systems in order to see what might, or might not, break. If problems happen, please let us know on the stable@vger.kernel.org mailing list as soon as possible as I can only hold off on doing new stable releases for these branches for a single week only (i.e. February 12, 2021).
[1] 8 Bits Are Enough for a Version Number -- https://news.ycombinator.com/item?id=26037687
[2] https://lore.kernel.org/lkml/1612534196241236@kroah.com/
[3] https://lore.kernel.org/lkml/1612535085125226@kroah.com/