Linux 5.0-rc1
117 points by ojn 6 years ago | 49 comments- azhenley 6 years 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 6 years 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?
- zanny 6 years 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.
- uranusjr 6 years 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 6 years agoI think there was at least a Google+ poll.
- hornetblack 6 years ago
- techntoke 6 years agoBecause 4.20 was a very special release.
- wungsten 6 years agoAny reason you choose :)
From the OP email:
| So go wild. Make up your own reason for why it's 5.0.
- Waterluvian 6 years agoBecause 4.22 would unfairly wear down the 2 key.
- Waterluvian 6 years ago
- usaphp 6 years ago> even a pointless one
> I ran out of fingers and toes to count on
- zanny 6 years ago
- djsumdog 6 years 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 6 years agoThe kernel versioning (as of 3.0) has always been arbitrary. Go wild.
- irq 6 years 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.
- ianai 6 years agoActually it’s enough to know that you’re beyond all appendages. Ie one plus all fingers+toes.
- sigstoat 6 years 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.
- andrewshadura 6 years agoI believe most people, Linus included, have 8 fingers and 2 thumbs, making it 10 digits in total.
- tsukikage 6 years ago...but you can count to 256 on 8 fingers...
- tsukikage 6 years ago
- ianai 6 years ago
- Waterluvian 6 years ago
- uniformlyrandom 6 years 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.
- CaliforniaKarl 6 years 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 6 years agoI assume they were referring to calendar based naming a la Ubuntu.
- 1stranger 6 years ago
- michaelmrose 6 years agoIt seems likely that the people that have been doing this for decades have a reason for the current methodology.
Generally how far exactly you are behind mainstream is useless information it produces exactly zero actionable intelligence. For most people in fact no amount of information would be actionable because mostly what they ought to do is run whatever their distribution comes with. For those who do indeed need more info. For example X.y supports their hardware better or at all. In fact what they need to know in that case is what version will provide a better experience and why. Knowing how far behind they are would be pointless. Knowing this in fact will lead at least some to upgrade pointlessly and potentially hit exciting new bugs/incompatibilities that their distro hasn't tested against. As an example I note that zfs on linux now supports a max of kernel 4.19. It might in theory work with 4.20 but it might not. Joe user notices that 4.20 is out. His distro ships with 4.19 he decides to upgrade and suddenly he can no longer actually mount his root filesystem with the new kernel and he has managed to remove 4.19. Another annoying example we might suppose that the proprietary driver package he uses to talk to his gpu doesn't build against the newest kernel and he boots no further than a text console when booting.
Even if the kernel doesn't break userspace it doesn't mean that stuff doesn't ever break.
What you are suggesting is that release cadence be optimized to give more useless info to laymen to help them make worse decisions.
- zanny 6 years agoThe version.patch notation is still meaningful to Linux because each version increment means new features and support. If the latest is version 50 and you are on 48 you should be suspicious if that unsupported PCI device works on that newer release.
Its just the major version that is always redundant because Linux never breaks userspace compatibility.
But of all software projects the Linux kernel is definitely not a poster child for having a reasonable methodology to versioning. Just some choice released kernel version names: 0.95, pre2.0, 2.2 and 2.4 but no 2.1 or 2.3, 2.6 lasted 8 years, 3.19 - 4.0 because Linus felt like it, and 4.20 -> 5.0 because Linus felt like it.
The only consistent number has been patch releases.
- zanny 6 years ago
- zanny 6 years agoBesides what others have said kernel releases aren't special. They are just quarterly. There would be no "big" release each year because any arbitrary release can be "big" or not. Nobody is going to keep major functionality out of the kernel just because they want to wait for a bigger number to go up.
- azernik 6 years agoThat's not how kernel development actually works. There's a set of supported releases that continue getting fixes over time - e.g. 4.20 will keep on getting patch fixes for a while. Better to have nothing referring to a date than some digits referring to dates and some not.
- jplayer01 6 years agoHuh? Ubuntu does the date as version and they do patch fixes and what not.
- jplayer01 6 years ago
- 6 years ago
- 6 years ago
- CaliforniaKarl 6 years ago
- shmerl 6 years 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/lin...
- diminish 6 years 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 6 years 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 6 years agoVersion 12.0 will be out shortly after, around 1970.
- zanny 6 years ago
- IloveHN84 6 years 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 6 years agoYou can already disable building whatever drivers you don’t need when you make your kernel config.
- nailer 6 years 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!).
- lostapathy 6 years ago
- mycall 6 years agoRIP ISDN
- codersbrew 6 years agoMemories!
- fffrantz 6 years agoStill regular work for me, this thing just refuses to die
- fffrantz 6 years ago
- codersbrew 6 years ago
- sys_64738 6 years agoMaybe the kernel should switch to Chrome style versioning? It would solve this dilemma.
- zapzupnz 6 years 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 6 years 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 6 years 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.
- zapzupnz 6 years ago
- sys_64738 6 years ago
- michaelmrose 6 years agoAt this rate we would be in triple digit numbers before long.
- zanny 6 years agoThere have been plenty of Linux releases with triple digit patch series. I'm familiar with 3.18 reaching 131 and I know 3.0 and 3.2 got over a hundred each as well.
Also, by any reasonable definition, there is no meaningful difference between 4.20 or 420. You just put a period in there. The major number has no real significance.
- zanny 6 years ago
- zapzupnz 6 years ago
- lostmsu 6 years 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 6 years 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 6 years 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.
- lostmsu 6 years agoFinal point. A bit of a parallel/analogue.
The binary compatibility came, and package maintainers rejoiced. Finally, they did not have to make a package for each distribution separately, and could get to actually improving the contents of the packages themselves.
The docker came, and the ops and admins rejoiced. Finally, they are able to build a giant web app, and deploy it anywhere with that tiny container daemon, even on Windows. So they can actually focus on improving their web apps instead of wasting Saturday nights tweaking configurations.
When the stable driver API comes, the driver developers will rejoice.
- lostmsu 6 years agoThen again, how is the need to upstream drivers affecting small businesses doing hardware? Forget AMD, they might (arguably) find resources to do the clean-up. But mom, who learned a bit of programming to make a driver for Mom&Pop's Pool Acidity Sensor will never be able to upstream.
So small business needs it even more. Don't you think that is a good reason on its own?
- maxnoe 6 years agoThen, is getting a driver upstreamed for linux really harder than getting it trusted/signed for Windows or macOS?
- maxnoe 6 years ago
- lostmsu 6 years ago
- imtringued 6 years agoWhy should vendors care? Even Qualcomm outright admitted that they prefer to "ship it and drop it" rather than keep supporting old devices.
- lostmsu 6 years agoHave you replied to a wrong comment?
- lostmsu 6 years ago
- c256 6 years ago