Announcement

Collapse
No announcement yet.

Systemd 217: Many New Features, Even More Bug-Fixes

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Systemd 217: Many New Features, Even More Bug-Fixes

    Phoronix: Systemd 217: Many New Features, Even More Bug-Fixes

    Lennart Poettering announced the release today of systemd 217 and it's quite a big update...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    A feature has been dropped from systemd? this is a miracle

    Comment


    • #3
      This one is good:

      "net.core.default_qdisc = fq_codel"

      Fighting "bufferbloat" is a good thing. Faster networks for everyone.

      LWN has a nice feature about it from the 2014 "Linux Plumbers Conference":

      Comment


      • #4
        Originally posted by pheldens View Post
        A feature has been dropped from systemd? this is a miracle
        readahead has been removed too, so it's 2 features removed.
        Wait, "The "multi-seat-x" tool has been removed from systemd", so make that 3.
        Last edited by mark45; 28 October 2014, 07:25 PM.

        Comment


        • #5
          Originally posted by mark45 View Post
          readahead has been removed too, so it's 2 features removed.
          Wait, "The "multi-seat-x" tool has been removed from systemd", so make that 3.
          Specifically:

          Originally posted by Release Announcement
          * systemd's readahead implementation has been removed. In many circumstances it didn't give expected benefits even for rotational disk drives and was becoming less relevant in the age of SSDs.

          * The "multi-seat-x" tool has been removed from systemd, as its functionality has been integrated into X servers 1.16, and the tool is hence redundant.
          So basically, they've dropped two things that were no longer relevant - one because the job it was doing became obsolete, the other because it was a workaround for missing functionality elsewhere. I'm not certain why the firmware loading was removed, but I'd guess it's because the job is now being done elsewhere...

          Comment


          • #6
            Originally posted by Delgarde View Post
            I'm not certain why the firmware loading was removed, but I'd guess it's because the job is now being done elsewhere...
            The option to load it from user space has been removed, but the usual/sane way to do it - from the kernel - is there and will stay of course. The Linux devs aren't dicking around removing important features to satiate the over the top "security" paranoia of certain admins of a certain BSD flavor.

            Comment


            • #7
              the kernel doesn't load out-of-tree firmware...

              Comment


              • #8
                Originally posted by Release Announcement
                Among the many changes to find with systemd 217 are changes to job time-outs, systemd-logind handling lid switch events when the system is docked or multiple displays in use, a new user console daemon that's considered a preview feature, user-space firmware loading support has been dropped, udev updates, KDBUS handling improvements, and many, many other changes along with plenty of bug-fixes.
                Originally posted by gens View Post
                the kernel doesn't load out-of-tree firmware...
                Does this mean that firmware can only be loaded from /lib/firmware now? But wasn't that already the case? Are we still allowed to download our own firmware blobs and dump them into /lib/firmware for drivers to pick up on?

                Comment


                • #9
                  Originally posted by Sonadow View Post
                  Does this mean that firmware can only be loaded from /lib/firmware now? But wasn't that already the case? Are we still allowed to download our own firmware blobs and dump them into /lib/firmware for drivers to pick up on?
                  3rd party firmware blobs also go in /lib/firmware
                  the kernel itself does not load them because of licensing and idk problems so udev has to tell the kernel to load them
                  they probably removed the possibility to load firmware directly by udev (udev would read it and send it over netlink to the kernel)
                  so its probably as to not be able to load firmware from anywhere else other then /lib/firmware, as that is the place where the kernel does load it from when asked to

                  Comment


                  • #10
                    Great, now my laptop actually shuts down when asked to shut down instead of going to sleep after entering the console during shut down because the lid was closed. That was retarded. Thanks systemd for being slightly less retarded. Love you shutting down in under 5 seconds btw.

                    Comment

                    Working...
                    X