[HN Gopher] 8 Bits Are Enough for a Version Number...
___________________________________________________________________
8 Bits Are Enough for a Version Number...
Author : Foxboron
Score : 89 points
Date : 2021-02-05 16:00 UTC (7 hours ago)
(HTM) web link (kroah.com)
(TXT) w3m dump (kroah.com)
| Havoc wrote:
| Rather OT, but I wish GKH would get more limelight. Guy comes
| across super charismatic while still having tech cred
| umvi wrote:
| Oh wow, I didn't even realize that was who wrote this article.
| One time I was debugging an insane USB issue and diving deep
| into the usb stack of the kernel (it turned out it was a hw
| bug, but that's another story) and out of desperation emailed
| the usb kernel mailing list for tips, and GKH responded to me.
|
| Anyone who is deeply knowledgeable about _USB_ automatically
| has serious cred in my book. That rabbit hole just about killed
| me.
|
| Here's an AMA GKH did a while back if you want to get to know
| him better:
| https://www.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah...
| beervirus wrote:
| Fixed link: https://old.reddit.com/r/linux/comments/2ny1lz/im
| _greg_kroah...
| carapace wrote:
| (I just added bigint support to a silly little interpreter
| project I'm working on. It took about fifteen minutes, four of
| which were looking up git commands, and the compiler told me what
| to change. Year 2021 and so it goes...)
|
| Sometimes I explain things like this to my a friend of mine who
| is at least as smart as I am but doesn't computer and it's always
| so humbling.
|
| To an intelligent outsider we (ye olde IT industry) look so
| goddamned silly.
| DeepYogurt wrote:
| I love that the resistance to updates and the desire for
| stability has lead to lwn running a news item titled `Two new
| "experimental" stable kernels`. What irony.
|
| https://lwn.net/Articles/845207/
| saiya-jin wrote:
| Sounds like my recent issue in Java with underlying library
| icu4j, which gives a nice start error ("Invalid version number:
| Version number may be negative or greater than 255"). Is an issue
| on quite a few versions of this lib.
|
| What kind of idiot thought hard enough when doing this to
| actually create a custom error message instead of letting it go
| is slightly beyond my comprehension.
| sgtnoodle wrote:
| Is there a lot of pressure to keep these version number types as
| compact as possible?
|
| I suppose it has to do with the use a tuple of 3 values and a
| desire to pack them efficiently into an API?
|
| An API for fetching a version number doesn't need to be
| particularly efficient though. It needs to be friendly to humans
| and easy to reason about in code.
| dezgeg wrote:
| If your target audience is C, packing 3 values into one might
| even be the easiest to reason about, you get a single value
| that you can compare with the usual < and > etc. operators.
| hinkley wrote:
| Humans can make errors in judgement or execution. When we look
| at affordances we look at filtering information to influence
| outcomes, and we try to eliminate mechanical errors like
| hitting the wrong button or transposing two activities.
|
| Which is a long way of saying long numbers get more typos.
|
| It's all a tradeoff though. You just have to have all the
| competing concerns if you want to get a good answer.
| sgtnoodle wrote:
| That's fine and I generally agree with you, but "humans are
| bad at big numbers" doesn't seem like a good rationale for
| choosing a data type for a computer to use to represent a
| piece of information as part of an API that isn't allowed to
| change. Computers are fine with arbitrarily large numbers,
| and in particular, Linux capable platforms are absolutely
| great at 32 or 64 bit numbers depending on their
| architecture. Using 8 bit integers seems like it could have
| been premature optimization. If the original API had just
| used "int" without thinking about it too much, it would have
| had the same practical performance as using an 8-bit type,
| and would have worked up to at least 2 billion on any
| reasonable platform. Maybe the API needed a guaranteed fixed
| size across platforms, though, and the original designer
| thought more than 255 minor versions was crazy?
|
| Solving the "large version numbers are bad for this project"
| problem is a human policy concern, and probably better done
| via education/documentation or an explicit warning in code
| (like a compiler warning or console message if the version
| number is more than 3 base-10 digits.)
| josephg wrote:
| I'm not familiar with the code. But my assumption is that
| it's not that they chose to use an 8 bit integer for the
| y-version field. It's that they chose to use a 24-bit
| number for the whole version. OxXXYYZZ - Eg 0x050801 for
| kernel version 5.8.1. That lets you compare kernel version
| A with kernel version B using a simple u32 cmp. They could
| have used 16 bits per version field - but that would have
| needed a 64 bit integer, which is much slower on some of
| the systems Linux used to run on back when that decision
| was made. In retrospect that was a bad choice, but I'm sure
| it seemed fine in the 90s.
|
| The problem is that if they spill the minor version to 16
| bits (xxyyyyzz) then kernel version 4.256.1 is "newer than"
| kernel 5.8.1 - because 0x04010001 > 0x00050801. And that's
| a compatibility breaking change.
| coding123 wrote:
| Who knew the version number was going to be Linux's first
| breaking API change?!?!
| RcouF1uZ4gsC wrote:
| Just make everything 128 bits and never worry about overflowing a
| counter until we colonize the galaxy.
| TrainedMonkey wrote:
| This message is sponsored by your friendly neighborhood big
| memory/storage consortium /s
|
| On a serious note, using fewer datatypes is super helpful for
| any kind of serialization.
| BearOso wrote:
| _Fewer_ datatypes. "Less" should be used when you're talking
| about a qualitative measure, "fewer" when talking
| quantitatively.
|
| This message is sponsored by your friendly neighborhood
| grammar nazi.
| TrainedMonkey wrote:
| Fixed, thanks for the heads up.
| hinkley wrote:
| Thanks, Stannis.
| linuxftw wrote:
| This is not a thing. There are no rigid rules for using
| less or fewer.
| zimpenfish wrote:
| And the rigid rule that daft old prescriptivits insist on
| seems to have come from some random writer in 1770 going
| "I think this sounds better in this instance".
|
| http://itre.cis.upenn.edu/~myl/languagelog/archives/00377
| 5.h...
| gumby wrote:
| Indeed; I misread that sentence the first time through and
| was briefly puzzled.
| zimpenfish wrote:
| May I direct you to Language Log, a blog of professional
| linguists and grammarians whose archives will be only too
| happy to disabuse you of this daft old prescriptivist
| nonsense?
|
| https://languagelog.ldc.upenn.edu/nll/index.php?s=less+fewe
| r
| samatman wrote:
| Thanks a bunch, Der Fewer...
| Asraelite wrote:
| They're both quantitative. "quantitative" doesn't
| necessarily mean "discrete".
|
| The usual way to refer to this distinction is uncountable
| vs. countable nouns.
| Asooka wrote:
| Nope, it's less. You can use "less few" if a naked less
| bothers you. "Fewer" is not a real word - if it were, then
| we would also use "manyer" as its antonym. And before you
| go off saying I'm wrong, let me remind you that language
| evolves as its speakers will it to. You are speaking
| English, you can decide to change it however you want and
| nobody can claim you're wrong. Whether your change sticks
| or not is a different matter...
| llampx wrote:
| Less applies to uncountable things, fewer applies to
| countable things.
| buzzerbetrayed wrote:
| This article explains there is significantly more nuance
| to it than that: https://www.merriam-webster.com/words-
| at-play/fewer-vs-less
| ecopoesis wrote:
| Until someone decides one data type is good enough and
| everything is a string.
| amelius wrote:
| Yes, after coming back from a roundtrip to the Andromeda
| Galaxy, the Linux kernel will be at version > 2^128.
| a1369209993 wrote:
| Nah, even if we go at a pokey 9km/s, and release a new kernel
| version every second, that wouldn't be enough to overflow
| even a 64bit number.
| rurban wrote:
| CentOS and Debian stable will not like this hack. It's simply a
| trick to force upgrades on systems which promise bug stability.
| moron4hire wrote:
| Well, at the very least, CentOS doesn't really matter anymore,
| does it?
___________________________________________________________________
(page generated 2021-02-05 23:01 UTC)