Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Operating Systems Linux IT Technology

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."

Linux 4.17 Released

Comments Filter:
  • by Joey Vegetables ( 686525 ) on Monday June 04, 2018 @10:39AM (#56724836) Journal
    I for one welcome our 95mb-long "changelog"!
    • Whoever modded this "flamebait" . . .did you click the link? I think they linked to the whole source tarball, not the changelog.
  • Which turd linked it to the complete sources?
    • by Anonymous Coward

      m'smash
      TFA says the link goes to the new kernel, not the changelog

  • by Artem Tashkinov ( 764309 ) on Monday June 04, 2018 @11:04AM (#56725004) Homepage

    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]

  • by jellomizer ( 103300 ) on Monday June 04, 2018 @11:05AM (#56725012)

    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)

      by Anonymous Coward

      Major version changes meant a significant difference while minor changes were small changes and fixes.

      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

    • by Kjella ( 173770 )

      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

      • by HiThere ( 15173 )

        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.".

    • by jmv ( 93421 ) on Monday June 04, 2018 @02:47PM (#56726584) Homepage

      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.

    • Linux for the most part has been rather consistent.

      I miss consist[ae]nt spelling.

  • by Clockwurk ( 577966 ) on Monday June 04, 2018 @11:08AM (#56725026) Homepage

    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

  • by FudRucker ( 866063 ) on Monday June 04, 2018 @11:16AM (#56725086)
    will Torvalds smoke a doobie to celebrate???
  • 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

"If it's not loud, it doesn't work!" -- Blank Reg, from "Max Headroom"

Working...