10 ms·
Linux 5.0-rc1
- azhenley 8y agoI went to see what the big changes were to justify a new major version number and saw: “The numbering change is not indicative of anything special. If you want to have an official reason, it's that I ran out of fingers and toes to count on, so 4.21 became 5.0” I laughed out loud.
- Waterluvian 8y agoI can't help myself. I need to know why 5.0. Is there a reason, even a pointless one? Or is it truly a "just because" moment?
- wungsten 8y agoAny reason you choose :) From the OP email: | So go wild. Make up your own reason for why it's 5.0.
- Waterluvian 8y agoBecause 4.22 would unfairly wear down the 2 key.
- usaphp 8y ago> even a pointless one > I ran out of fingers and toes to count on
- techntoke 8y agoBecause 4.20 was a very special release.
- uranusjr 8y agoIt probably is simply “just because”. Not the first time Linus feels it, IIRC 3.0 was basically bumped for the same non-reason.
- hornetblack 8y agoI think there was at least a Google+ poll.
- zanny 8y agoIts seriously just Linus doesn't like counting past 20. We only got 4.20 for the weed meme. 3.19 -> 4.0 and 4.20 -> 5.0 just because.
- irq 8y agoOK so Linus, like most, has 10 fingers and 10 toes: totaling 20.. Yet 4.21 was already assigned. What was the last thing he counted on? Guesses below.
- sigstoat 8y agowhatever it was, he was using a lot of it back for the 1.3 series, which made it up to 1.3.100 at least.
- deleted 8y ago[deleted]
- ianai 8y agoActually it’s enough to know that you’re beyond all appendages. Ie one plus all fingers+toes.
- andrewshadura 8y agoI believe most people, Linus included, have 8 fingers and 2 thumbs, making it 10 digits in total.
- tsukikage 8y ago...but you can count to 256 on 8 fingers...
- djsumdog 8y agoI mean, that's the way it's been forever. IIRC, the release for 3.0 had the same type of message with it. There was no big breaking change, it just felt like it was time to bump the big number.
- craftyguy 8y agoThe kernel versioning (as of 3.0) has always been arbitrary. Go wild.
- mycall 8y agoRIP ISDN
- codersbrew 8y agoMemories!
- fffrantz 8y agoStill regular work for me, this thing just refuses to die
- uniformlyrandom 8y agoI actually prefer a date-based approach to release naming. Given continuous flow of kernel development, I would advocate for releasing a major every year, a minor every month, and patches as needed. Gives you better indication of how much behind you are by just looking at the version.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- CaliforniaKarl 8y agoComing up with a response to this one was harder than I expected. The calendar-based release cycle you describe is pretty different from what is practiced today. Although, if you change the time scales, maybe not so much: Kernels are released on a fairly-predictable cadence now, and patches come in (to the mailing list and maintainer trees) almost constantly. So, if this is as simple as extending timescales, that leads down to an impossible debate: What changes count as minor/major/patches? For example, some would say that adding a driver is just a patch (as it doesn't change other parts of the kernel); some would say that it is major (because it adds new functionality). There's also the human element: If someone has something to contribute, they'll want discussion to start on it sooner rather than later. Also, rolling lots of major changes into a big release may make it hard to tease out bugs—and performance regressions—as the just-released major version makes its way down to individual distributions. So in this case, I think the best think for your needs would be to ignore upstream kernels, and instead rely on a distro kernel: Pick whichever distro you think does kernels the best, and which uses a time-based release schedule, and use their kernel. Or, get an LWN subscription, and keep an eye out for their regular "What's new in this kernel" articles.
- 1stranger 8y agoI assume they were referring to calendar based naming a la Ubuntu. https://calver.org https://calver.org
- sys_64738 8y agoMaybe the kernel should switch to Chrome style versioning? It would solve this dilemma.
- zapzupnz 8y agoIs it really a 'dilemma' though? Basically, a project can set the version numbers how they want. They don't need to justify the change. So long as they and others can refer to each release by a simple and easily identifiable number or moniker, it really makes no difference if it's 5.0 or 4.22. In the end, the Linux kernel is such a big project that there's really no reason to single out any single or a set of changes as significant enough to warrant a version number bump; it's all arbitrary to start with.
- sys_64738 8y agoVersioning isn't just about the practical software build. The version is used to describe differences to non-tech PMs. A PM's eyes will glaze over when you talk 4.22 V 4.16, but you mention v22 versus v22 and then they 'get it'. That's why a Chrome style versioning has value.
- zapzupnz 8y agoIt has value to certain people, sure. But given that it's mainly technically minded people who work with the kernel on a daily basis, and most people don't need to know their kernel version number outside of limited circumstances. I would say for the majority of Linux users, it's the OS version that's more important; that is, getting help with your installation of Ubuntu, it's more useful to know that you're running 18.10 rather than kernel version 4.18. Yes, Chrome-style versioning has value. But is that value applicable to this scenario? I wouldn't say 'no', but I'm fairly comfortable saying "not necessarily". Nothing is universal, and no one solution solves every problem.
- michaelmrose 8y agoAt this rate we would be in triple digit numbers before long.
- shmerl 8y agoSome annoying amdgpu bugs were fixed for Vega users (like one affecting DisplayPort 1.2 monitors with REG_WAIT timeout / dce110_stream_encoder_dp_blank error). * https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/gpu/drm/amd/display/dc/core/dc_link.c?h=v5.0-rc1&id=8c9d90eebd23b6d40ddf4ce5df5ca2b932336a06 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- diminish 8y agoNewer projects have quick version bumps after the success of Chrome's accelerated versioning approach. But for software deeper in solutions, fast version changes appear confusing. I like Apache, nginx with very small bumps. Most newer JS frameworks live fast and die quick. It's also very confusing for developers to decide to jump to newer versions. Expecting 11.20 version around 2037.
- zanny 8y agoThe worst part is its arbitrary. I don't get why Linus is so bent on keeping a three step version number when the first digit has been meaningless since 1996 (or maybe 2011 if you want to be pedantic and call the version change from 2.6.x to 3.x a major revision). For the largest free software project in the world it sure doesn't do much to advertise good practices when informing your user of relative newness of kernels.
- mricon 8y agoVersion 12.0 will be out shortly after, around 1970.
- lostmsu 8y agoIMHO, Linux is failing us, end users. It works great for servers, I can give it that. There it mostly runs on a very narrow set of hardware, or just VMs. It is stable and performant, and customizable. But not on consumer devices. I'd like to use it eventually, but the state of driver support is still abysmal. Android phones lose support after a couple of years, and on desktop/laptops there are numerous problems too. I think that situation is caused by the lack of stable driver API. Now that's what I'll be looking forward to for 6.0.
- c256 8y agoI don’t know if you realize it, but your complaint is “hardware vendors change things too frequently”. Kernel hackers don’t make up the need to do extra work for hardware support just for kicks. Yes, the hits everyone: Windows loses support for old hardware much faster than it used to. Even the closed-ecosystem of OSX/macosx/macOS leaves hardware behind these days. Mobile phone hardware changes so frequently that you can’t even be sure that the same make & model of handset will use the same hardware. In many ways, it’s both a sign of progress and the baseline cost of doing business.
- lostmsu 8y agoWhy do you think it has anything to do with the hardware vendors? They don't want to spend resources upstreaming their changes, but do something else, that's all. Did not we just see a fight last year, between, I think, AMD and Linux, where AMD, instead of the common practice to drop a blob and be done with it, tried to actually upstream some drivers, but they were not up to Linux's coding standards, so got rejected. I am not saying AMD is in right here. Maybe nobody is, given the current state of affairs. But it is end users who are suffering from the conflict of interest between Linux community, who doesn't want to maintain cheaply written code, and hardware companies, who can't make great open source drivers for the same money they can make an OK-ishly made closed source blob, that only supports 2yo LTS. That decision, that I can't have the latest Linux and 5yo drivers that work is simply bad for me as a consumer. Heck, if Linux had stable driver API, somebody could easily go and fix that just slightly buggy AMD driver to be compatible with the latest kernel without much fuss, and without the need to upstream it. And I could use my laptop with the supported kernel again. I think stable driver API for Linux would do a great good to billions of people. Would let them not to spend money every 3 years on a new phone, and let Microsoft to let Windows 10 go, finally bringing proper privacy to the common folk.
- IloveHN84 8y agoI'm still contrary to all those drivers additions that are being made, slowing the compile time. Why don't they get rid of old drivers (say, prior to 2000)? It would make the kernel slimmer for sure. They could made optional and one has to self compile the kernel to enable them
- lostapathy 8y agoYou can already disable building whatever drivers you don’t need when you make your kernel config.
- nailer 8y agoWhy are you building modules you don't use? The kernel seems to be the most half understood part of Linux. Not picking on you specifically, it's actually super common to think: - More drivers means slower build times - To add a driver you need to rebuild a kernel Both of which are wrong and have been wrong for a decade (nearly two!).