5 ms·

Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to

Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole. It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, therein: https://www.youtube.com/watch?v=o_AIw9bGogo https://www.youtube.com/watch?v=o_AIw9bGogo

yarrel 7y ago
It's good that systemd apologists have moved on from arguing that it isn't a single binary. But it is not a bunch of loosely coupled tools any more than it is "just" an init replacement.
- eropple 7y ago
  Hmm. "Apologists." Couldn't be that it's been a lot better for me where I regularly interact with it and has been no worse where I don't. It's gotta be apologism. We have to be out to getcha. I think you owe me an apology for that one, dude. More productively: what parts of systemd's ecosystem--aside, apparently, from journald, but the above no-harm-no-foul reply to the sibling still applies as far as I'm concerned--have you had trouble pulling out when you wanted to, out of curiosity?
  - ben509 7y ago
    > It's gotta be apologism. Apologists are engaging in apologia, which means a defense of one's ideas. It's not suggesting a hidden agenda, to the contrary, it suggests the agenda is fully on display since it's plain what is being defended.
JdeBP 7y ago
> Journald is also not part of systemd core--at least, I think so; this one I've never really looked at myself. You really should. journald is not optional.
- eropple 7y ago
  Yup, seems you're right - journald appears to be the only mandatory non-PID1 process for systemd. Good to know. It also will forward happily to rsyslogd if that's your bag and then you never have to look at it, so I'm gonna just give a big ol' emoji shrug on this one.
  - JdeBP 7y ago
    > journald appears to be the only mandatory non-PID1 process for systemd. You need to read a lot more. The Desktop Bus is mandatory too. Lennart Poettering reminded everyone of this back in 2015.
    - eropple 7y ago
      D-Bus, as discussed elsewhere in this thread (where I learned about this, too), is a specification rather than a concrete implementation. Are you asserting that systemd does not work with alternative D-Bus implmentations? That would be weird, seeing as how they wrote an alternative one... Also, since I've been "reading more", and I can check after I get back from lunch--at least at some point Debian shipped systemd without D-Bus on minimal installs. Maybe that's no longer the case, but the stuff I'm reading seems to be post-2015.
      - JdeBP 7y ago
        > Are you asserting You need to stop constructing straw men, too. I asserted what I actually wrote. And Lennart Poettering asserted that > D-Bus has been a core component of Linux systems since more than 10 years. and > D-Bus refers to both a specification, and a reference implementation. back in 2015. I suggest that instead of arguing fallaciously about something that you tell us you have only just learned about, that you go and do that reading.
        eropple 7y ago
        Asking for clarification isn't a strawman, sorry. And it sure seemed like you were correcting me, which is why I asked. But I said that journald was the only mandatory component of systemd outside of PID1. You said this was wrong. I'm waiting for you to extrapolate? Does systemd only work with the "canonical" dbus-broker? Or does it want ("want" as I'm reading stuff that suggests it isn't absolutely required, but I'm not sure and I'm happy to caveat where I'm not sure) a D-Bus broker? Because if it's the latter, and as it's specified and they seem big on meeting specs I'm betting that it's the case, then what I said is correct and you're just being kind of a jerk about it. Or you can keep trying to big-time me instead of engage on the merits of your position. That's cool people stuff, I guess.
tyingq 7y ago
"Systemd is a bunch of loosely coupled tools" As just one example, the nspawn owning package requires a libnss package which pulls in systemd-resolve. I believe it also requires dbus.
luke0016 7y ago
There are lots of variations on the UNIX philosophy [1], but two core points are to: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. systemd has binary format data all over the place, and it is quite difficult to separate out an individual component and have it work properly on its own. Not to mention trying to replace a subcomponent with something else. systemd is, in general, a tightly coupled system with lots of interdependencies. It is, in many respects, the antithesis of the UNIX design philosophy. Hell, even modern Software Engineering practices still talk about decreasing coupling and increasing cohesion. [1] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy
- AsyncAwait 7y ago
  Regarding the UNIX philosophy thing, it's worth noting that it is not automatically The Right Thing to stick by it at any cost. You could argue that UNIX itself does not use the philosophy when it's inconvenient, for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!) Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world. The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world.
  - luke0016 7y ago
    > for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!) Sure. The UNIX Philosophy applies more to userland, I think, than the kernel. Edit: I'll add with regard to the kernel, the internal structure of the kernel still has fairly well-defined subsystems that interact in clear, mostly consistent ways. So while from an execution standpoint it is monolithic, the philosophy is still something that is taken to heart to some extent. > Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world. I think dismissing it as a semantics game is taking it pretty far. It's clearly not a black and white rule, but more a guiding philosophy. When it works, it's beautiful and elegant. The ability to pipe basic UNIX utilities and programs together is something that has always left me a little awestruck. The flexibility and simplicity there is almost profound. SysVinit was far from perfect, but you could at least trace the execution flow from basically start to finish and, if you understood basic *NIX utilities, have a good idea of exactly what was happening. > The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world. Again, it's a philosophy, not a universal truth. A guiding light, if you will. With systemd, that light is pretty dim, if it's on at all.

yarrel 7y ago

It's good that systemd apologists have moved on from arguing that it isn't a single binary. But it is not a bunch of loosely coupled tools any more than it is "just" an init replacement.

eropple 7y ago
Hmm. "Apologists." Couldn't be that it's been a lot better for me where I regularly interact with it and has been no worse where I don't. It's gotta be apologism. We have to be out to getcha. I think you owe me an apology for that one, dude. More productively: what parts of systemd's ecosystem--aside, apparently, from journald, but the above no-harm-no-foul reply to the sibling still applies as far as I'm concerned--have you had trouble pulling out when you wanted to, out of curiosity?
- ben509 7y ago
  > It's gotta be apologism. Apologists are engaging in apologia, which means a defense of one's ideas. It's not suggesting a hidden agenda, to the contrary, it suggests the agenda is fully on display since it's plain what is being defended.

JdeBP 7y ago

> Journald is also not part of systemd core--at least, I think so; this one I've never really looked at myself. You really should. journald is not optional.

eropple 7y ago
Yup, seems you're right - journald appears to be the only mandatory non-PID1 process for systemd. Good to know. It also will forward happily to rsyslogd if that's your bag and then you never have to look at it, so I'm gonna just give a big ol' emoji shrug on this one.
- JdeBP 7y ago
  > journald appears to be the only mandatory non-PID1 process for systemd. You need to read a lot more. The Desktop Bus is mandatory too. Lennart Poettering reminded everyone of this back in 2015.
  - eropple 7y ago
    D-Bus, as discussed elsewhere in this thread (where I learned about this, too), is a specification rather than a concrete implementation. Are you asserting that systemd does not work with alternative D-Bus implmentations? That would be weird, seeing as how they wrote an alternative one... Also, since I've been "reading more", and I can check after I get back from lunch--at least at some point Debian shipped systemd without D-Bus on minimal installs. Maybe that's no longer the case, but the stuff I'm reading seems to be post-2015.
    - JdeBP 7y ago
      > Are you asserting You need to stop constructing straw men, too. I asserted what I actually wrote. And Lennart Poettering asserted that > D-Bus has been a core component of Linux systems since more than 10 years. and > D-Bus refers to both a specification, and a reference implementation. back in 2015. I suggest that instead of arguing fallaciously about something that you tell us you have only just learned about, that you go and do that reading.
      - eropple 7y ago
        Asking for clarification isn't a strawman, sorry. And it sure seemed like you were correcting me, which is why I asked. But I said that journald was the only mandatory component of systemd outside of PID1. You said this was wrong. I'm waiting for you to extrapolate? Does systemd only work with the "canonical" dbus-broker? Or does it want ("want" as I'm reading stuff that suggests it isn't absolutely required, but I'm not sure and I'm happy to caveat where I'm not sure) a D-Bus broker? Because if it's the latter, and as it's specified and they seem big on meeting specs I'm betting that it's the case, then what I said is correct and you're just being kind of a jerk about it. Or you can keep trying to big-time me instead of engage on the merits of your position. That's cool people stuff, I guess.

tyingq 7y ago

"Systemd is a bunch of loosely coupled tools" As just one example, the nspawn owning package requires a libnss package which pulls in systemd-resolve. I believe it also requires dbus.

luke0016 7y ago

There are lots of variations on the UNIX philosophy [1], but two core points are to: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. systemd has binary format data all over the place, and it is quite difficult to separate out an individual component and have it work properly on its own. Not to mention trying to replace a subcomponent with something else. systemd is, in general, a tightly coupled system with lots of interdependencies. It is, in many respects, the antithesis of the UNIX design philosophy. Hell, even modern Software Engineering practices still talk about decreasing coupling and increasing cohesion. [1] https://en.wikipedia.org/wiki/Unix_philosophy https://en.wikipedia.org/wiki/Unix_philosophy

AsyncAwait 7y ago
Regarding the UNIX philosophy thing, it's worth noting that it is not automatically The Right Thing to stick by it at any cost. You could argue that UNIX itself does not use the philosophy when it's inconvenient, for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!) Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world. The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world.
- luke0016 7y ago
  > for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!) Sure. The UNIX Philosophy applies more to userland, I think, than the kernel. Edit: I'll add with regard to the kernel, the internal structure of the kernel still has fairly well-defined subsystems that interact in clear, mostly consistent ways. So while from an execution standpoint it is monolithic, the philosophy is still something that is taken to heart to some extent. > Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world. I think dismissing it as a semantics game is taking it pretty far. It's clearly not a black and white rule, but more a guiding philosophy. When it works, it's beautiful and elegant. The ability to pipe basic UNIX utilities and programs together is something that has always left me a little awestruck. The flexibility and simplicity there is almost profound. SysVinit was far from perfect, but you could at least trace the execution flow from basically start to finish and, if you understood basic *NIX utilities, have a good idea of exactly what was happening. > The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world. Again, it's a philosophy, not a universal truth. A guiding light, if you will. With systemd, that light is pretty dim, if it's on at all.