Slashdot Mirror


Linux 4.17 Released (betanews.com)

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

28 comments

  1. I for one welcome . . . by Joey+Vegetables · · Score: 4, Funny

    I for one welcome our 95mb-long "changelog"!

    1. Re:I for one welcome . . . by Joey+Vegetables · · Score: 1

      Whoever modded this "flamebait" . . .did you click the link? I think they linked to the whole source tarball, not the changelog.

    2. Re:I for one welcome . . . by Anonymous Coward · · Score: 0

      That's just their way of saying "We changed everything. All of it."

    3. Re:I for one welcome . . . by Anonymous Coward · · Score: 0

      Now it will be SysLinuxD

  2. "Complete changelog" by maestroX · · Score: 0

    Which turd linked it to the complete sources?

    1. Re:"Complete changelog" by Anonymous Coward · · Score: 1

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

    2. Re:"Complete changelog" by Anonymous Coward · · Score: 0

      "Not too many people say "turd" anymore. But who'd want to?"

              - George Carlin

  3. Linux to get Mozillafied by Anonymous Coward · · Score: 0

    First we will be incrementing the major version every six weeks starting with linux 6.0 in August.
    Then we will drop the existing module system and replace it with web extentions
    We will be putting a new UI every six months
    Finally will be adding ads in dmesg.

  4. Year of the Desktop! by Anonymous Coward · · Score: 0

    Where do you want to go today?

  5. weekly address on Sunday by Anonymous Coward · · Score: 0, Troll

    The sermon of Linux. Microsoft = Satan. Source code = Bible. Linus = savior. Apple = Jewish religion.

    1. Re:weekly address on Sunday by Anonymous Coward · · Score: 0

      You forgot BSD

  6. The complete changelog by Artem+S.+Tashkinov · · Score: 4, Informative

    is a little bit too difficult to parse.

    Here's a few human readable sources:

    https://kernelnewbies.org/Linu...

    https://www.phoronix.com/scan....

    German: https://www.heise.de/ct/artike...

    Russian: https://www.opennet.ru/opennew...

  7. I miss consistant version numbers. by jellomizer · · Score: 3, 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.

    --
    If something is so important that you feel the need to post it on the internet... It probably isn't that important.
    1. Re:I miss consistant version numbers. by Anonymous Coward · · Score: 2, Insightful

      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. It isn't, it's barely a version 1.

      This creates situations in which a new component is still a steaming turd that is missing critical features and stability, but it is presented as version X implying a much more mature and reliable piece of software.

      These days, you could see version 10 or whatever of a piece of software which is really about 1.01 level of maturity, but 10 sounds cooler and better than 1.

      Marketing trumps meaningful version numbers in far too many situations.

    2. Re:I miss consistant version numbers. by Kjella · · Score: 2

      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 time-based releases anyway.

      Which is actually typical of many major projects, there's so much going on there's always a reason to make a release and there's always something that's changed. APIs should be versioned independent of releases. GUIs should give you a "classic" mode grace period before making the switch. Or if you're going totally nuts with a rewrite, rename the old version and offer it separately. Of course then you might find people hate your new version, if that bothers you launch a new version, shove it down their throats and tell them you'll get used to it.

      --
      Live today, because you never know what tomorrow brings
    3. Re:I miss consistant version numbers. by jmv · · Score: 4, 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.

    4. Re:I miss consistant version numbers. by HiThere · · Score: 1

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

      --

      I think we've pushed this "anyone can grow up to be president" thing too far.
    5. Re:I miss consistant version numbers. by TeknoHog · · Score: 1

      Linux for the most part has been rather consistent.

      I miss consist[ae]nt spelling.

      --
      Escher was the first MC and Giger invented the HR department.
  8. The actual changelog (and not the source) by Clockwurk · · 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

  9. when Linux gets to 4.20 by FudRucker · · Score: 2

    will Torvalds smoke a doobie to celebrate???

    --
    Politics is Treachery, Religion is Brainwashing
    1. Re:when Linux gets to 4.20 by Anonymous Coward · · Score: 0

      Or will he pull a 4.19 scam and decide skip 4.20 by jumping to 5.0? :)

    2. Re:when Linux gets to 4.20 by Anonymous Coward · · Score: 0

      Nice! Righteous bud!

  10. Major Release for Ryzen 2200g and 2400g by bryanbrunton · · Score: 1

    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

  11. I'm pleased w/ Linux @ last... apk by Anonymous Coward · · Score: 0

    I 1st tried Slackware in 1994 (version 1.02 iirc) & it sucked (not big range of hardware support). Then in 1999 via RedHat (still pretty shitty but got better on hardware but software was lacking). Then in 2010 while I was in Europe, I ran it on a laptop & saw it getting MUCH better in Kubuntu 10.10 (figures, a decade++ went by) but still, Windows got me back. Now, finally, in 2018 when my install media went sour for Win7 64-bit, I bit the bullet & tried the "latest/greatest" Kubuntu 18.04 plus patches & it is VERY NICE - finally!

    * :)

    (Good job boys - ya got me onboard, for what that says... Me, practically the "poster child" for Windows fanboy on /. !)

    APK

    P.S.=> FreePascal & Lazarus ROCK for Object Pascal development too (for me, this was a BIG PLUS & NECESSARY for me to want to use Linux & IS probably 1 of the biggest reasons - it is one hell of an excellent development tool for 64 applications & is JUST LIKE Delphi, my former favorite (now FreePascal is), to a tee)... apk

  12. Re:I for one welcome . . . day 1 Errata by Anonymous Coward · · Score: 0

    'make prepare' now required or else you'll probably get elfconfig.h errors.

    Cross-compile x86_64 build error I haven't yet figured out...
    arch/x86/kvm/../../../virt/kvm/kvm_main.o: file not recognized: File format not recognized