Linux 4.17 Released (betanews.com) 28
Mark Wycislik-Wilson, writing for BetaNews: In his weekly message to the Linux community on Sunday, Linus Torvalds announced the release of Linux 4.17. The release comes a couple of months after the first release candidate, and in his message Torvalds also talks about version 5.0 of the Linux kernel. Having previously said that Linux kernel v5.0 "should be meaningless," he said that this next major numerical milestone will come around "in the not too distance future." For now, though, it's version 4.17 -- or Merciless Moray, if you prefer -- that's of interest. Linux kernel 4.17 is not a major release, and Torvalds announced it without much fanfare. "So this last week was pretty calm, even if the pattern of most of the stuff coming in on a Friday made it feel less so as the weekend approached. And while I would have liked even less changes, I really didn't get the feeling that another week would help the release in any way, so here we are, with 4.17 released."
I for one welcome . . . (Score:4, Funny)
Re: (Score:2)
"Complete changelog" (Score:1)
Re: (Score:1)
m'smash
TFA says the link goes to the new kernel, not the changelog
The complete changelog (Score:5, Informative)
is a little bit too difficult to parse.
Here's a few human readable sources:
https://kernelnewbies.org/Linu... [kernelnewbies.org]
https://www.phoronix.com/scan.... [phoronix.com]
German: https://www.heise.de/ct/artike... [heise.de]
Russian: https://www.opennet.ru/opennew... [opennet.ru]
I miss consistant version numbers. (Score:4, Insightful)
Major version changes meant a significant difference while minor changes were small changes and fixes.
Skipping numbers in version dictated the amount of change in the fix. So if I went from version 3.03 to 3.50 I know there was a lot of work done, but not enough that would break compatibility, or add significant features.
Linux for the most part has been rather consistent.
But google and Firefox with their full number upgrades, makes it more difficult to judge the complexity of the patch. We are on Firefox 60. but it is more like Firefox 7.28 or something like that. Then Microsoft decides to make no sense all together. The Intel Processors lineup is just as bad by hiding their generation of processors as secondary next to the type of processor.
Re: (Score:2, Insightful)
I doubt in Linux, but I know for commercial stuff version numbers are now the domain of marketing.
We have a vendor, and the version of the core component was X, reflecting a fairly mature product. The pieces and add-ons around the product, their marketing decided to give the same version ... which in many cases led to what is essentially a brand new (warts and all) component being labelled as version X. I
Re: (Score:3)
Major version changes meant a significant difference while minor changes were small changes and fixes. Skipping numbers in version dictated the amount of change in the fix (...) Linux for the most part has been rather consistent.
Well +0.1 every three months is consistent, but it's in complete contraction to the rest you said. There's absolutely no useful major/minor version in the numbering, there's never any skipping it's just one month merge window, two months of RCs, release. Now with random major version bumps that mean nothing. He could have switched to Ubuntu's YY.MM format like Linux 18.06 and lost nothing, at least then everyone would know at a glance how old the kernel is. It's what makes the most sense when you're doing t
Re: (Score:2)
Actually, given that "major version numbers don't mean anything special" there's a lot to be said in favor of a date based numbering schema. Preferably one that's yy.mm.dd during development changing to yy.mm or yy.mm(f) on release, were the (f), if present, denotes "Whoops, this is the fix number to the release version.".
Re:I miss consistant version numbers. (Score:5, Interesting)
It's not so much that the numbering changed. What really changed was the development methodology and the numbering just reflects that. Going from 2.4 to 2.6 took forever because there were too many changes, some not so well tested and because it was taking forever to stabilize, more changes would come in because otherwise it would take years before they could come in. So progress was (relatively) slow and new features had to be shipped through custom patches rather than mainline. There's been a general realization (not just for the kernel) that that kind of development cycle just couldn't work anymore. That's why the kernel has moved to a shorter development cycle. It means there's less pressure to put new features "as soon as possible because otherwise it will be delayed by years", so much fewer things to debug in each release and overall, everything's better. The only drawback is for people who don't want to upgrade as often and that's why there are a few special "stable" releases once in a while (and Firefox has ESRs). If Linus had kept the old development model, I suspect the current "stable" kernel would still be a 2.6.x and there would be a 2.7.392 development kernel that still wouldn't be ready to ship.
Re: (Score:2)
Linux for the most part has been rather consistent.
I miss consist[ae]nt spelling.
The actual changelog (and not the source) (Score:3, Informative)
So this last week was pretty calm, even if the pattern of most of the
stuff coming in on a Friday made it feel less so as the weekend
approached.
And while I would have liked even less changes, I really didn't get
the feeling that another week would help the release in any way, so
here we are, with 4.17 released.
No, I didn't call it 5.0, even though all the git object count
numerology was in place for that. It will happen in the not _too_
distant future, and I'm told all the release scripts on kernel.org are
ready for it, but I didn't feel there was any real reason for it. I
suspect that around 4.20 - which is I run out of fingers and toes to
keep track of minor releases, and thus start getting mightily confused
- I'll switch over. That was what happened for 4.0, after all.
As for the actual changes since rc7 - the shortlog is appended - it's
mostly drivers, networking, perf tooling, and a set of nds32 fixes.
With some random other stuff thrown in. Again, the shortlog is
obviously only the last calm week, the overall changes since 4.16 are
much too big to list in that format.
The big 4.17 stuff was mentioned in the rc1 email when the merge
window closed, but I guess it's worth repeating how 4.17 is actually a
slightly smaller kernel than 4.16, thanks to the removal of a number
of effectively dead architectures (blackfin, cris, frv, m32r, metag,
mn10300, score, and tile). Obviously all the other changes are much
more important, but it's always nice to see spring cleaning like that.
And with this, the merge window for 4.18 is obviously open. I actually
have some travel the second week of the merge window, which is very
inconvenient for me, but I do hope that we'll get all the big stuff
merged the first week and it won't impact any release scheduling. But
we'll have to see.
Linus
---
Aaron Ma (1):
Input: synaptics - add Intertouch support on X1 Carbon 6th and X280
Al Viro (2):
fix io_destroy()/aio_complete() race
Revert "fs: fold open_check_o_direct into do_dentry_open"
Alex Williamson (1):
Revert "vfio/type1: Improve memory pinning process for raw PFN mapping"
Alexander Duyck (1):
net-sysfs: Fix memory leak in XPS configuration
Alexander Shishkin (2):
stm class: Use vmalloc for the master map
intel_th: Use correct device when freeing buffers
Antoine Tenart (1):
crypto: inside-secure - do not use memset on MMIO
Ard Biesheuvel (1):
net: netsec: reduce DMA mask to 40 bits
Arnaldo Carvalho de Melo (1):
perf tools: Fix perf.data format description of NRCPUS header
Arnd Bergmann (1):
IB: Revert "remove redundant INFINIBAND kconfig dependencies"
Bart Van Assche (1):
scsi: scsi_transport_srp: Fix shost to rport translation
Benjamin Tissoires (2):
Input: synaptics - add Lenovo 80 series ids to SMBus
Input: elan_i2c_smbus - fix corrupted stack
Chris Wilson (3):
drm/i915/lvds: Move acpi lid notification registration to
registration phase
drm/i915/query: Protect tainted function pointer lookup
drm/i915/query: nospec expects no mo
when Linux gets to 4.20 (Score:3)
Major Release for Ryzen 2200g and 2400g (Score:2)
The 4.16rc series and now hopefully 4.17 are HUGE major releases if you want to actually use AMD's APUs in the Ryzen 3 2200g and Ryzen 5 2400g.
Essentially, those AMD CPUs were worthless (when using on chip APU) until very recently with Linux if you want to run even the most basic 3D games.
You need to also use Mesa 18.2:
https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa