Announcement

Collapse
No announcement yet.

Lennart Poettering Takes To Battling Systemd Myths

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

  • Lennart Poettering Takes To Battling Systemd Myths

    Phoronix: Lennart Poettering Takes To Battling Systemd Myths

    Lennart Poettering, the controversial open-source developer behind PulseAudio and systemd among other projects, has written a lengthy blog post as he attempts to battle some myths about his Linux init daemon...

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

  • #2
    systemd is good, but it is not completely ready yet. Take systemd's user instances: from what I understand, it should be possible to run a user's services/sockets even when he doesn't log in when he is enabled via "loginctl enable-linger $username". But there are currently scripts provided to do that (user-session-units) because lingering doesn't seem to work. When you try to start a systemd user instance on a headless machine, you get errors because the display variable is not set, might be a dbus issue, but user-session-units has a service file that works around that. So, from my impressions, it is not feature-complete yet. Not a biggie though as it already handles much more than any init system I ever saw and makes administration really easy IMHO. TBH, I dunno why you would want to go back to a classic syslog with all the comfort journalctl provides. Or managing your startup dependencies yourself.

    Comment


    • #3
      *grabs some popcorn*

      Comment


      • #4
        Dependency

        Didn't mention that systemd is closely tied to udev and journald and that there is a dependency there and people are forced to use it.

        Comment


        • #5
          Originally posted by uid313 View Post
          Didn't mention that systemd is closely tied to udev and journald and that there is a dependency there and people are forced to use it.
          Standalone udev is supported and he did mention that in the blog post. Nothing depends on Journal so how would that "force" anyone to use systemd?

          In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too. -- [1] For example, systemd-detect-virt, systemd-tmpfiles, systemd-udevd are.

          Comment


          • #6
            That guy screwed up udev.

            Comment


            • #7
              Originally posted by uid313 View Post
              Didn't mention that systemd is closely tied to udev and journald and that there is a dependency there and people are forced to use it.
              systemd depends on udev and journal.
              journal depends on systemd
              udev depends on....the kernel.

              End of dependencies. If you want to build udev, yes, you have to pull in the systemd sources BUT you dont have to build systemd with udev. Just pass the appropriate configure flag and the only thing you'll have is udev.

              The journal is only force-enabled, yes, but it doesn't take exclusive access. I have both journald and syslog running right now on this Arch Laptop. You know what I had to do?

              pacman -S syslog-ng
              systemctl enable syslog-ng
              systemctl start syslog-ng

              And thats it. Anything that gets sent to the journal is automatically (with zero configuration on my end) passed along to syslog. If you dont want to use the journal than you just dont invoke journalctl and you just cat the log files from /var/log like always.


              I know someone will make the comment about Lennart saying he wanted to eventually get rid of udev-without-systemd. Yes, he made the comment, you know what the key-word there is though? "EVENTUALLY." He didn't say "2013." He didn't say "Next release." Or anything else. He said eventually. Which I don't really see that as that big of a problem, its only natural that a project leader would want his project to grow and be successful. (Un)Fortunately there can only be 1 init system in place at any given time on one machine so systemd being ultimately successful and being the standard -would- mean, logically, that sysV and upstart die.

              Comment


              • #8
                Originally posted by asdx
                I wonder what this guy is smoking.

                This has to be the most shittiest things I've ever read about systemd or any project, WTF?

                Hey Lennart, are you going to merge Qt also? and Emacs? and Xorg, etc?

                WTF.

                What a crappy way of managing a project.
                He's actually right. Go look at the Net/Open/Free BSD's source. The kernel and the low-level utilities aren't shared, each group has their own kernel and their own low-level utilities that take the best features that their individual kernels offers and uses them. The middle tier, like ssh, and the higher tier like xorg are shared sure. But the low-level stuff? Group-specific.

                Comment


                • #9
                  Originally posted by asdx
                  Yeah and? Just because that's how it's done in BSD land it means it's the "right and only way" to do things, and it needs to happen the same way in Linux too?

                  Give me a break.
                  Didn't say it was the right way necessarily (Though I do PERSONALLY think that it is. We have the features available in the kernel, may as well use them.)

                  I was just pointing out that if Net/Free/Open BSD want to maintain that they are true unix and that their way is the true unix way....if Linux does something the same way as them, then isnt Linux by extension following the true unix way?

                  Comment


                  • #10
                    Originally posted by asdx
                    Hey Lennart, are you going to merge Qt also? and Emacs? and Xorg, etc?
                    How did you get that impression out of the material you quoted? Basically, Lennart is saying that systemd is not controlled by one czar and development is more collaborative than Linux.

                    I wonder what this guy is smoking.
                    The same thought occurred to me... (about you).

                    Comment


                    • #11
                      Originally posted by asdx
                      However, I don't feel very well about systemd "merging" other components into the systemd repository, look at all the problem it has caused between udev and systemd, lots of people from the Linux community are raging on the udev thing.

                      There has to be a better way of dealing with this.
                      The udev incident was 2 things:

                      1) lennart's quote about eventually removing non-systemd support which got blown WAY out of proportion.
                      2) the commit that broke module loading for certain devices. Which if you actually delved into the mailing lists from lkml...the change made sense. It just broke things in process which pissed Linus off because of his "Dont break shit!" rule (a good rule) and then the udev guys made a fairly "Meh whatever" response to Linus, pissing him off more. BUT, the change they did, the re-ordering of the process for module loading that they did, made sense and was reasonable once you read the discussion and figured out what exactly happened.



                      I'm just gonna pick a few things at random that systemd does, this isnt meant to be comprehensive.

                      Hostname support: does systemd NEED be the hostname controller? No. But its such a simple thing (set HOSTNAME) I dont really see a problem with it.

                      Control login: Interesting idea, and im not against it mainly because of cgroups and the fact systemd tracks processes on a per-user basis no matter what (no double forking). It lets systemd properly follow what exactly started a process and by who to keep everything in line.

                      Rudimentary power management (Sleep, hibernate): Interesting idea, systemd controls modules being loaded and therefore it can ensure that everything is offloaded and reloaded properly.

                      The journal: Lennart was right about one thing: you can edit plaintext logs. (This isnt meant to be a binary vs plaintext log fight) and anyone can forge logs. Since systemd keeps absolute track of services, and processes it kind of makes sense that it would handle their logging too. The beauty here is that journal doesnt take exclusive control, I've got journal and syslog-ng running simultaneously. Journal takes messages from processes, makes its log, then forward the same messages onto syslog and then syslog does its thing.

                      Timezone handling: (See hostname)

                      Hardware clock: (see hostname)

                      Cron: This is one that I don't really see the point of, but as long as you can still run your own cron daemon if you want to, i dont really care lol.

                      udev: This is the one I'll get fought on, I know, but I'm gonna say it anyway. Systemd controls module loading as well as module logging, hardware is useless without drivers (modules), systemd also does hotplugging (multiseat) which means udev and systemd are going to be working hand in hand ANYWAY. Until such a time that Upstart, OpenRC, and SysV are all dead (AND you dont see a new competitor on the horizon) you won't see udev become hard-dependent on systemd... so whats the big deal? You can still build udev solo, you can still use it without systemd.


                      Side note: Every feature I mentioned except process handling (obviously) and the journal are all configurable via compile-time configure switches OR run-time configuration file values so don't jump down my throat about bloat or not being modular. Systemd has the ABILITY to do more when so desired just as it has the ABILITY to do less when so desired, which is only possible if its modular. And if its modular, then it cant be bloated because bloated implies that things are forced. Is the kernel bloated?

                      Comment


                      • #12
                        Originally posted by uid313 View Post
                        Didn't mention that systemd is closely tied to udev and journald and that there is a dependency there and people are forced to use it.
                        Then someone should pick up HAL again and not use udev if it bothers them.

                        Comment


                        • #13
                          Originally posted by Ericg View Post
                          The udev incident was 2 things:

                          1) lennart's quote about eventually removing non-systemd support which got blown WAY out of proportion.
                          Yes, exactly.

                          One of the first things after taking over udev maintenance was a statement to the effect of that if you use anything other than systemd, he will break your system.

                          I wonder why people overreacted.

                          Comment


                          • #14
                            Originally posted by asdx
                            Do you have a link to that discussion? I'm really interested in reading it. Thanks.
                            Very beginning of the thread: https://lkml.org/lkml/2012/10/2/194 I think its the 3rd email from Linus that he starts ripping into systemd/udev developers for breaking stuff. What it comes down to is should the firmware be loaded when the hardware is probed or when the module is actually loaded? if I remember correctly.

                            I can't find the link myself but there's more info in a gentoo forums thread talking about eudev (the gentoo hosted fork of udev v187 or v189)

                            Comment


                            • #15
                              Originally posted by pingufunkybeat View Post
                              Yes, exactly.

                              One of the first things after taking over udev maintenance was a statement to the effect of that if you use anything other than systemd, he will break your system.

                              I wonder why people overreacted.
                              He said he'd EVENTUALLY remove support for non-systemd. People always forget the "EVENTUALLY." Once people started freaking out he clarified that it was not a short-term goal by any means and would only happen once systemd was THE standard in the linux ecosystem and there WERE no competitors TO support.

                              Comment

                              Working...
                              X