Announcement

Collapse
No announcement yet.

Lennart: The State & Future Of Systemd

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

  • Lennart: The State & Future Of Systemd

    Phoronix: Lennart: The State & Future Of Systemd

    Lennart Poettering gave a talk recently in Beijing about the state of systemd and its future ahead...

    http://www.phoronix.com/vr.php?view=MTczNDk

  • #2
    They need first to fix their bugs! Unbelievable, even my CH Pedals don't work anymore in 14.04!

    Comment


    • #3
      Originally posted by mike4 View Post
      even my CH Pedals don't work anymore in 14.04!
      Are you going to mention that in every systemd/udev topic?

      Comment


      • #4
        Originally posted by mike4 View Post
        They need first to fix their bugs! Unbelievable, even my CH Pedals don't work anymore in 14.04!
        What is a CH Pedal and since when 14.04 uses sytemd?

        Comment


        • #5
          http://www.chproducts.com/Pro-Pedals-v13-d-716.html

          I'm going to mention this until it gets fixed. Hopefully not alike xinput2 which is broken for years:

          http://forum.winehq.org/viewtopic.php?f=8&t=23007

          Udev is a can of bugs, sigh.

          Comment


          • #6
            Why systemd-timesyncd will be better then ntpdate?

            Comment


            • #7
              Originally posted by mike4 View Post
              I'm going to mention this until it gets fixed.
              Phoronix is not the place...

              Comment


              • #8
                Slide 84:

                "What we are working on:
                Verifiable OS images
                All the way to the firmware
                Boot Loading"

                That means likely modification prevention in embedded systems.

                Comment


                • #9
                  Originally posted by mike4 View Post
                  http://www.chproducts.com/Pro-Pedals-v13-d-716.html

                  I'm going to mention this until it gets fixed. Hopefully not alike xinput2 which is broken for years:

                  http://forum.winehq.org/viewtopic.php?f=8&t=23007

                  Udev is a can of bugs, sigh.
                  Could You include Your X.Org log?
                  Do any of the hints mentioned here work:
                  http://forums.x-plane.org/index.php?showtopic=71300

                  Comment


                  • #10
                    Originally posted by Mat2 View Post
                    That means likely modification prevention in embedded systems.
                    Or find broken Systemfiles but modification prevention is not a bad thing.

                    Comment


                    • #11
                      Originally posted by mike4 View Post
                      They need first to fix their bugs! Unbelievable, even my CH Pedals don't work anymore in 14.04!
                      14.04 does not even use systemd, so the problem is not where you think it is.

                      Comment


                      • #12
                        Originally posted by Mat2 View Post
                        Why systemd-timesyncd will be better then ntpdate?
                        "systemd-timesyncd" is an extremely lightweight NTP client. Actually it is just a SNTP (Simple NTP) client. It works great for small embedded systems or massive and rapid deployment of Linux containers etc.

                        The use of "ntpdate" is actually discouraged by its main developer because of some inherent accuracy problems, so it has been deprecated for some time now.

                        More info here:
                        http://en.wikipedia.org/wiki/Ntpdate

                        Comment


                        • #13
                          Originally posted by Mat2 View Post
                          Why systemd-timesyncd will be better then ntpdate?
                          I think it must be the theory that providing a baseline of features, always present, makes it easier to write software.
                          On a low RAM machine, running from cron ntpdate or another time sync command daily to slew the system clock works quite well enough and uses less resources.

                          Personally I found this addition to systemd, rather tasteless and troubling; secondly what Lennart and Kay perceive as "pointless" differences may eliminate flexibility that could be key in future, as the "Internet of Things" is realised.

                          Thanks to the monolithic systemd, causing pid 1 to be linked with Dbus, I've had to reboot my Linux box more than Windows in last month The re-exec option, just didn't work and the insecure deleted Dbus lib was still mapped into systemd's memory space. This may be a choice of my distro, rather than a consequence of systemd, I have read Lennart somewhere saying systemd doesn't have to run as pid 1, I would like it not to, so sending a SIGHUP or something to pid 1, or killing systemd would have it auto restarted, solving the security update problem.
                          Last edited by rob11311; 07-05-2014, 04:32 AM.

                          Comment


                          • #14
                            Originally posted by interested View Post
                            The use of "ntpdate" is actually discouraged by its main developer because of some inherent accuracy problems, so it has been deprecated for some time now
                            But NTP is about accuracy of order <5ms, and generating very precise timestamps for scientific experiments. Normal usage to avoid intervention of admin to adjust system clocks and avoid clock skew in LAN, just don't need synchronisation that close about 200ms is good enough.

                            Why fork and include an NTP daemon, why not just provide integration with 3rd party projects? Why does Lennart & Kay, embrace ever more features rather than fix bugs?
                            Last edited by rob11311; 07-05-2014, 04:42 AM. Reason: Frustration!

                            Comment


                            • #15
                              Originally posted by Mat2 View Post
                              Slide 84:

                              "What we are working on:
                              Verifiable OS images
                              All the way to the firmware
                              Boot Loading"

                              That means likely modification prevention in embedded systems.
                              I don't think it is so specific. I think the user case is quite generic from embedded to desktop and servers. Looking at the previous slides and other systemd talks by Poettering, it is clear that they want a cryptographically verifiable /usr and order to have that they have to secure the crypto chain all the way from boot. It is unlikely that it is about tampering prevention since there already exist such solutions (TPM) that are effective, but a pain in the ass for end users.

                              Comment

                              Working...
                              X