[HN Gopher] The imminent stable-version apocalypse
___________________________________________________________________
The imminent stable-version apocalypse
Author : Tomte
Score : 97 points
Date : 2021-02-08 10:41 UTC (1 days ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| stonesweep wrote:
| 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.
| [deleted]
| jolmg wrote:
| > 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).
|
| [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/
| einpoklum wrote:
| A whole article about a version macro. :-(
|
| Well, at least it had a fun Leon Trotsky quote...
| edoceo wrote:
| Ye olde "we'll never need more than X of Y" bug
| cuspycode wrote:
| Of which the most famous instance was: "we'll never need more
| than two digits to represent the year in a date".
| function_seven wrote:
| Okay, but I'll die on the hill that 128 bits ought to be
| enough for any IP address, right?
|
| (Bracing myself for the introduction of Smart Nano Carbon,
| with individually addressable nanotubes)
| thisrod wrote:
| > 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.
|
| The iPhone was released in 2007.
| mjevans wrote:
| 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]"
|
| https://en.wikipedia.org/wiki/IPv6#Global_addressing
| roughly wrote:
| There's ~2^270 atoms in the universe, so that feels like a
| safe upper bound for the time being
| MauranKilom wrote:
| Naturally, there's an xkcd about exactly that:
| https://xkcd.com/865/
| not_knuth wrote:
| https://tools.ietf.org/html/rfc1606
|
| :)
| gizmo686 wrote:
| You don't need to go that far. Preempting fragmentation can
| use up bits quickly if you're not careful.
| retrac wrote:
| 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.
| kmeisthax wrote:
| /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.
| [deleted]
| chrisweekly wrote:
| >"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."
___________________________________________________________________
(page generated 2021-02-09 23:01 UTC)