Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday February 10 2020, @07:18PM   Printer-friendly
from the lots-of-new-and-shiny dept.

www.phoronix.com

This kernel is simply huge: there is so many new and improved features with this particular release that it's mind-boggling. I'm having difficulty remembering such a time a kernel release was so large.

The quick summary of Linux 5.6 changes include: WireGuard, USB4, open-source NVIDIA RTX 2000 series support, AMD Pollock enablement, lots of new hardware support, a lot of file-system / storage work, multi-path TCP bits are finally going mainline, Year 2038 work beginning to wrap-up for 32-bit systems, the new AMD TEE driver for tapping the Secure Processor, the first signs of AMD Zen 3, better AMD Zen/Zen2 thermal and power reporting under Linux, at long last having an in-kernel SATA drive temperature for HWMON, and a lot of other kernel infrastructure improvements.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Funny) by EJ on Monday February 10 2020, @08:10PM (10 children)

    by EJ (2452) on Monday February 10 2020, @08:10PM (#956495)

    Bigger is ALWAYS better. The kernel should include a web browser, text editor, paint program, etc. Why should you have to get some 3rd party utility to do something any self-respecting OS should already have integrated?

    Memory is cheap. Everyone should have at LEAST a spare 128GB to hold the kernel.

    Starting Score:    1  point
    Moderation   +1  
       Funny=1, Total=1
    Extra 'Funny' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by DannyB on Monday February 10 2020, @08:25PM (4 children)

    by DannyB (5839) Subscriber Badge on Monday February 10 2020, @08:25PM (#956503) Journal

    Memory is cheap. Everyone should have at LEAST a spare 128GB to hold the kernel.

    Hey! Save some of that memory for Java!

    Modern Java is able to take advantage of more memory than ever before. Often this is done on Linux. Imagine a highly optimizing (for speed) compiler that can turn 1 K of native code into many times that much native code. Aggressive inlining. Loop unrolling. NO function call overhead for long stretches of native code. Calls to many functions vanish, or rather are replaced by the code they would call. Dynamically based on the runtime characteristics of your actual hardware at this moment. Something a C compiler can't do ahead of time because it doesn't have the whole picture. When the compiler runs, a function that should get inlined might not even be written yet -- other than as an entry in a .h file.

    --
    The lower I set my standards the more accomplishments I have.
    • (Score: 2) by pipedwho on Monday February 10 2020, @08:45PM (3 children)

      by pipedwho (2032) on Monday February 10 2020, @08:45PM (#956514)

      And it still manages to run much slower than 'non-optimised' native code.

      • (Score: 5, Insightful) by DannyB on Tuesday February 11 2020, @12:30AM (2 children)

        by DannyB (5839) Subscriber Badge on Tuesday February 11 2020, @12:30AM (#956622) Journal

        Native code vs native code? Did you read what I wrote? Did you understand the JIT compiler having the whole runtime picture?

        In any case, it obviously is fast enough that Twitter rewrote [soylentnews.org] their stack in 2012 to Java, specifically for performance. What idiots they must be.

        Java won't win every speed contest. It does win some. But it's not so slow as you think. (Greenspun's tenth rule [wikipedia.org]) For some reason it's been #1 in most of the last fifteen years [youtube.com], but never going below 2nd place.

        There is a simple reason for Java's success. Since the beginning of computers in business, and mostly also in science, money has been the dominant concern. Once upon a time optimizing for dollars also meant optimizing obsessively for every last cpu cycle and byte. No more. Today we optimize for dollars, which means optimizing for developer time. The dominant cost today is developer time. For the price of a developer with benefits for only one year, say $100-$250K, you can buy a pretty sweet server box. Point being that hardware is cheap compared to developer time. That hardware will last more years than that cost of one developer for one year.

        We're still optimizing for dollars, just not for bytes and cpu cycles any more. I know this may come as unwelcome news. I get a rush of dopamine every time I save cpu cycles or bytes. But I'm not obsessed with it. I know my true optimization is ultimately for dollars, which is developer time.

        I don't cite the source here: a language is too low level when it forces you to focus on the irrelevant.

        The irrelevant is anything that isn't relevant to the problem you're trying to solve.

        This is the reality we live in. Hate it as you may, Java is number one. Please consider that there is probably a reason for that. Companies like Red Hat, IBM, Amazon, Microsoft are investing lots of money into research into JVM, its GC, and other VM optimizations. Why is that do you suppose? Not out of the goodness of their hearts. They think there is money to be made by investing major resources into Java.

        Again, I'm sorry if this is unhappy news to you; But it is the REALITY of the world we live in. Not some fantasy world where bytes and cpu cycles are the dominant concern. Ah, to be a programmer back in the 1970's once again. But I can't go back.

        --
        The lower I set my standards the more accomplishments I have.
        • (Score: 0) by Anonymous Coward on Tuesday February 11 2020, @06:21AM (1 child)

          by Anonymous Coward on Tuesday February 11 2020, @06:21AM (#956756)

          You optimize for dollars... I mean developer time, until some developer optimizes in a better and faster way. Then you optimize for developers. It's so confusing for managers.

          • (Score: 2) by DannyB on Wednesday February 12 2020, @08:27PM

            by DannyB (5839) Subscriber Badge on Wednesday February 12 2020, @08:27PM (#957368) Journal

            Based on Java usage, managers don't appear to be confused about optimizing for greed dollars.

            Never have been.

            It's just that once long ago that also meant optimizing for bytes and cycles.

            --
            The lower I set my standards the more accomplishments I have.
  • (Score: 1, Funny) by Anonymous Coward on Monday February 10 2020, @09:00PM (3 children)

    by Anonymous Coward on Monday February 10 2020, @09:00PM (#956526)

    You speak then perhaps of Emacs? For that includes all of the above, and more.
    Emacs 2020 will include a Linux Kernel. :) ...just to "be safe" and be "feature complete."

    • (Score: 1) by DECbot on Monday February 10 2020, @10:13PM

      by DECbot (832) on Monday February 10 2020, @10:13PM (#956563) Journal

      That kernel is just for VMs and containers. The native kernel with kexec functionality isn't scheduled until 2022.

      --
      cats~$ sudo chown -R us /home/base
    • (Score: 4, Funny) by DannyB on Tuesday February 11 2020, @12:32AM (1 child)

      by DannyB (5839) Subscriber Badge on Tuesday February 11 2020, @12:32AM (#956623) Journal

      Here is what happened with Emacs users.

      The first time they get into emacs, they don't know how to exit. So they eventually build all other OS functionality into emacs lisp, being unable to escape.

      --
      The lower I set my standards the more accomplishments I have.
      • (Score: 3, Funny) by Runaway1956 on Tuesday February 11 2020, @01:29AM

        by Runaway1956 (2926) Subscriber Badge on Tuesday February 11 2020, @01:29AM (#956650) Journal

        Huh? Wait a second. Is there an exit? I didn't even know that. When I found myself in Emacs Land, I just nuked from orbit, and repaved.

  • (Score: 2) by DannyB on Wednesday February 12 2020, @08:34PM

    by DannyB (5839) Subscriber Badge on Wednesday February 12 2020, @08:34PM (#957372) Journal

    Memory is cheap. Everyone should have at LEAST a spare 128GB to hold the kernel.

    Here is a convenient memory sizing tool [yourdatafitsinram.net] to help identify which hardware might be big enough to hold your Java hello world program.

    References:
    Java Hello World -- Enterprise Edition [github.com]
    Java Fizzbuzz -- Enterprise Edition [github.com]

    --
    The lower I set my standards the more accomplishments I have.