10 ms·
8 Bits Are Enough for a Version Number
- RcouF1uZ4gsC 6y agoJust make everything 128 bits and never worry about overflowing a counter until we colonize the galaxy.
- TrainedMonkey 6y agoThis 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 6y agoFewer 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 6y agoFixed, thanks for the heads up.
- gumby 6y agoIndeed; I misread that sentence the first time through and was briefly puzzled.
- hinkley 6y agoThanks, Stannis.
- linuxftw 6y agoThis is not a thing. There are no rigid rules for using less or fewer.
- zimpenfish 6y agoAnd 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/003775.html http://itre.cis.upenn.edu/~myl/languagelog/archives/003775.h...
- samatman 6y agoThanks a bunch, Der Fewer...
- Asraelite 6y agoThey're both quantitative. "quantitative" doesn't necessarily mean "discrete". The usual way to refer to this distinction is uncountable vs. countable nouns.
- Asooka 6y agoNope, 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 6y agoLess applies to uncountable things, fewer applies to countable things.
- buzzerbetrayed 6y agoThis article explains there is significantly more nuance to it than that: https://www.merriam-webster.com/words-at-play/fewer-vs-less https://www.merriam-webster.com/words-at-play/fewer-vs-less
- zimpenfish 6y agoMay 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+fewer https://languagelog.ldc.upenn.edu/nll/index.php?s=less+fewer
- sowbug 6y agoI still can't get over people saying "I need to drink fewer milk."
- ecopoesis 6y agoUntil someone decides one data type is good enough and everything is a string.
- sowbug 6y agoBut note that larger datatypes are viral in the same way C++ const is.
- amelius 6y agoYes, after coming back from a roundtrip to the Andromeda Galaxy, the Linux kernel will be at version > 2^128.
- a1369209993 6y agoNah, 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.
- lilott8 6y agoEspecially after "2^32 is all the space we'll ever need for ip addresses."
- astrobe_ 6y ago... And "640K is enough for everyone". I believe they are all instances of induced demand [1]: If you allocate a large pool of a given resource, you tend to use it more liberally, and in the end the consumption rate is about the same regardless of the size of your pool. It's interesting to note that apparently people prefer to reconsider some wasteful uses of the IP address pool rather than switching to IPv6. That's the story of our societies. Waste the cheap stuff until it becomes too expensive. [1] https://en.wikipedia.org/wiki/Induced_demand https://en.wikipedia.org/wiki/Induced_demand
- DeepYogurt 6y agoI 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/ https://lwn.net/Articles/845207/
- Havoc 6y agoRather OT, but I wish GKH would get more limelight. Guy comes across super charismatic while still having tech cred
- umvi 6y agoOh 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_kroahhartman_linux_kernel_developer_ama/ https://www.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah...
- beervirus 6y agoFixed link: https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroahhartman_linux_kernel_developer_ama/ https://old.reddit.com/r/linux/comments/2ny1lz/im_greg_kroah...
- COGlory 6y agoAlso worth watching, Wendell interview with him: https://www.youtube.com/watch?v=t9MjGziRw-c https://www.youtube.com/watch?v=t9MjGziRw-c
- nashalo_nighly 6y agoI would very much like to hear this battle story
- ctdonath 6y agoPain felt. Took me a month to find what turned out to be an obscure bug in an early USB 2 chip, while implementing it on a printer for Kodak as a proof of concept.
- sgtnoodle 6y agoIs 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.
- hinkley 6y agoHumans 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 6y agoThat'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 6y agoI’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.
- rurban 6y agoCentOS and Debian stable will not like this hack. It's simply a trick to force upgrades on systems which promise bug stability.
- rurban 6y agoFor the current development see here https://lwn.net/SubscriberLink/845120/0b7608296003edfc/ https://lwn.net/SubscriberLink/845120/0b7608296003edfc/ No silly overflow, MINOR will be clamped at 255.
- moron4hire 6y agoWell, at the very least, CentOS doesn't really matter anymore, does it?
- ComputerGuru 6y agoThey can opt out if they do the math and decide that is worth breaking with precedent over.that said, let’s not pretend the maintainers made this decision lightly. It’s a thorny situation and this is the most ideal solution that was put forward, precisely because the (long-term) stability of machines running these distributions is of such importance.
- saiya-jin 6y agoSounds 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.
- james-skemp 6y agoHeh. We ran into this when we were looking at creating Confluence plugins: https://community.developer.atlassian.com/t/confluence-template-plugin-tutorial-404-error/40928 https://community.developer.atlassian.com/t/confluence-templ... We're not a Java team, so it took us far too long to release this was the issue we were running into, and why it wasn't consistent between a few environments.
- coding123 6y agoWho knew the version number was going to be Linux's first breaking API change?!?!
- zamadatix 6y agoBreaking API changes happen all the time, for example here is a syscall being removed after being deprecated for 10 years http://lkml.iu.edu/hypermail/linux/kernel/1911.3/02404.html http://lkml.iu.edu/hypermail/linux/kernel/1911.3/02404.html Linux strives to never break the API, and when it must does it in the most painless way possible. That doesn't mean they don't ever break the API, happens much more often than one would think to be honest. It's just the caution and planning around doing so usually makes it so few people ever even notice.
- Alupis 6y agoSpecifically, the kernel strives to never break Userspace - not necessarily the kernel's API.
- charliesome 6y agoThere might be a nuance here I haven't grasped, but isn't the kernel's API == its syscall ABI == the boundary to userspace?
- Spivak 6y agoYes but when people talk about kernel APIs not being stable they usually mean the APIs designed to be consumed by other kernel developers or kernel module authors.
- carapace 6y ago(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.
- 90minuteAPI 6y agoJust realizing that I spent too much time yesterday taping off edge cases around overflow where a BigInt would be much more appropriate.
- titzer 6y agoI, for one, wish we could go back to using years for major version numbers. And as a stretch goal, trying to align release schedules with calendar years more closely. For example, long-term support versions could be even years. That gives the immediate benefit of knowing how old/how well-supported a given system is just from the year. I can't tell how many projects I've seen fall off and then look back...hey, the last version was from 2007. (not that being from 2007 is bad, it is just an indication that it's no longer being actively maintained and might be bitrotted). When I worked on V8 our strategy was just to mirror Chromium's release cadence: every six weeks, the tip-of-tree became a dev branch, dev became beta, beta became stable, and stable became no longer supported. We did backmerge important bugfixes to beta and stable, but otherwise forgot about it. We never committed to long-term support of any version. That's not great for really important things like a kernel, IMHO.
- apostacy 6y agoAnd this strategy really benefits big institutions like Google, and harms smaller competitors. They are raising the barriers of entry. It is pretty clever.
- titzer 6y agoYeah, and in due fashion Chromium became "critical infrastructure" when SpaceX decided to use it as the basis of the Dragon capsule's UI. They pinned to a super-old version of Chromium that stopped getting updates 18 weeks after release. Which means it is absolutely chock full of bugs.
- refulgentis 6y agoA quality shared with all software :) a threat model that includes bad actors hacking into spacecraft ui using known chromium vulnerabilities would have to include a dizzying array of more tangible physical threats we regularly discount
- titzer 6y ago
- wackget 6y agoIt's 2021. Get an SSL certificate for your website.
- biohax2015 6y agoNo reason to if there’s nothing sensitive on your site.
- deleted 6y ago[deleted]
- gregkh 6y agoAnd what would that help solve?
- peterkelly 6y agoI like Donald Knuth's approach to versioning. Each new release of TeX has one additional digit appended, the most recent version being 3.14159265. The version numbers asymptotically approach π, suggesting the code is converging towards (but never quite reaching) perfection.
- 90minuteAPI 6y agoThat’s amusing but at the same time I’m glad I don’t have to interact with any software doing anything like this.
- taeric 6y agoThe flip side, the stability he chose is impressive. Not stability in "doesn't crash," but in "everything built on this is still standing."
- centimeter 6y agoWhat if he hits a zero?
- galkk 6y agoGiven that last version is 3.14159265 he certainly isn't worried in hitting 0 anytime soon. 3.1415926535 8979323846 2643383279 50
- isaacimagine 6y ago3.14159265358979323846264338327950... So not for a while
- bori 6y agoTheoretically, the version "number" in this case is technically not a number, because you wouldn't do any math operations with it, it's more like a string. So 3.1415926535897932384626433832795 and 3.14159265358979323846264338327950 are two different strings. Practically, since TeX will have no new features as they only fix bugs now and the last bugfix release 3.14159265 was 7 years ago, I think we'll actually never get there.
- mark-r 6y agoI'm not familiar with Linux version numbers, so apologies if this is a stupid question. How often do version numbers increment that any portion would overflow 8 bits? None of the software I've ever worked on would even come close to it.
- Someone 6y agoFirefox is at major version 85. Many of these have “.1” or “.0.1” security update releases. https://en.wikipedia.org/wiki/Firefox_version_history https://en.wikipedia.org/wiki/Firefox_version_history isn’t compete, even if you click through to individual pages, but it would hugely surprise me if there were less than 256. Any product older than 25 years would need only 10 releases/security updates per year to get there.
- mark-r 6y agoSorry if I wasn't clear - I didn't mean 8 bits for the whole number, just 8 bits for each part between decimal points. I can't imagine doing 256 iterations of something without deciding that you need to bump the next number up and start over at 0 or 1.
- Someone 6y agoRereading your remark, you were clear, just not clear enough for my sloppy reading/skimming (it should even have been clear from context alone)
- aasasd 6y agoPffft, could just pull a Linus instead and rename all current releases by adding one in front of the major version and resetting the patch number. 4.4.256 becomes 14.4.0. As a bonus, that would stop Linux's long-time lame lag behind Windows and MacOS, who were on 10 for years already and now 11. Surely this is better than breaking userspace. GKH just invites another Linus' rant on the topic.