5 ms·

This should surely stop the critics from saying systemd is doing too much and is bloatful. No, but seriously I understand the reason why you'd want this, but w

This should surely stop the critics from saying systemd is doing too much and is bloatful. No, but seriously I understand the reason why you'd want this, but what stops systemd from being divided into smaller modules? Like the Linux I'm used to.

SwellJoe 10y ago
systemd is modular, and is divided into many components. There are several dozen binaries in a systemd package. Where do you believe the lines should be drawn differently?
- Karlozkiller 10y ago
  What I did mean was that at least from my understanding of it, you get systemd, and then you have all of systemd, unable to replace one part of systemd with some other package to handle that specific task. One of the features I would like to see for example is less binary logging and this journalctl madness. Binary logging makes it harder for me to plug in other programs to parse the logs or whatever I want to do. So what I would like to see is modularity in the sense where I can choose to run systemd as an init system, and something not-systemd for logging, or for scheduling or whatever.
  - SwellJoe 10y ago
    On the logging question, does the ForwardToSyslog option not do what you'd like? Most components can be replaced (the journal isn't one of them, AFAIK, but most others can, and the journal can be configured to send things to a plain text log). Personally, I don't find the binary log to be that problematic. It is taking some getting used to, of course. 20+ years of muscle memory for grepping and awking and cutting text log files is hard to overcome, but the amount of help the system provides is nicer. It's better documented and better at guiding the user than the old way, IMHO. Which brings to mind something I like about systemd becoming standard that rarely gets discussed, I think: It brings a level of consistency that some other UNIX systems have had for a long time; the BSDs, for instance, have the feeling of all of the pieces having been designed to work together. Linux has never had that feeling; but with systemd, a large amount of Linux real estate now feels that way. The documentation correctly references other components docs. The way various components work together is reasonably documented because they were built at roughly the same time by roughly the same people (or at least people who interacted during the design), so the interfaces are clearly delineated. That's cool, I think. So, sure, I'm having to learn new stuff every time I interact with systemd, and that's frustrating. I know Linux like the back of my hand, so when I find myself having to read the docs for even simple stuff, I get grumpy. But, I get over it. It's gonna be fine, and we'll all get through this learning curve.
    - dozzie 10y ago
      > On the logging question, does the ForwardToSyslog option not do what you'd like? Of course not. Now you have two logging services. Hardly a replacement.
      - SwellJoe 10y ago
        So, to be clear, it is systemd itself that expects to be able to spit its logs to journald. Other services (most of the rest of a system) can log to whatever target it wants, including plain text files or a running syslog. The idea is that systemd wanted to not implement a bunch of different logging APIs within systemd itself. They wanted one logging API across all of the systemd components; and, then, if the end user needs logs to some other target, they use one utility (journald) to spit it out to that other target. I believe the thinking that went into this decision was sound. The alternative would be for every component in systemd to know about multiple logging targets, which would be exactly what people are accusing systemd of being (but isn't, in this case): bloated. systemd and all of its components log one way, allowing for a very simple logging code path. journald allows you to use those logs in many ways. So, either, systemd would need to expand to include support for a bunch of different logging mechanisms, or it would support one simple logging API and provide a way to export those logs to other targets. Are you here arguing that systemd should be made larger and more complicated, in order to support other kinds of logging (like syslog and plain text files) without the help of journald? To me, this looks like modularization and componentization at a reasonable level of abstraction. It simplifies the logging code for every component, while also providing a means for end users to consume the logs in the ways they prefer, including plain text.
        dozzie 10y ago
        Your reasoning is invalid. It would be just enough if systemd supported syslog, with a mechanism for buffering logs initially until the syslog starts, which systemd already needs and has anyway. It was not a choice between new, custom service and making things complicated by supporting every possible log service. It's not modularization. It's scope creep in pure form.
- mfukar 10y ago
  > There are several dozen binaries in a systemd package. That's not what modular means. Can you use only parts of systemd if you wanted to? Can I e.g. use the very useful dependency-based service initialisation but keeping my log facilities and networking management intact?
  - SwellJoe 10y ago
    "Can you use only parts of systemd if you wanted to?" Yes, though most distributions have chosen to use more than just the init functionality. "Can I e.g. use the very useful dependency-based service initialisation but keeping my log facilities and networking management intact?" No (logs) and yes (networking). Logging from systemd components, as far as I know, have to go through journald, but journald can send it as plain text to syslog, if you want it to. So, kinda yes on that one, too. networkd didn't even exist yet when many people began using systemd for their init, and it is entirely possible to use other methods of managing your network services. RHEL still, AFAIK, has a hybrid model that keeps a lot of the old configuration files even though they have switched to systemd for a lot of stuff. Maybe it uses networkd on the backend; I haven't needed to find out, as the config files work the same way they always have. I think the confusion comes from the fact that very few people want to only use one component of systemd. Even though you can, there is value in all of the pieces working well together and providing a consistent interface and API. Most distros that switch, choose to switch a lot of things over at the same time, because it's just nicer to do so, not because they had to. And, the people who hate systemd don't want any of it, so they never learn enough to know that they probably could get the bits from it they want without being tied to all of it.
    - mfukar 10y ago
      There is value in only some of the pieces working together, too. I'm sure having all the pieces together makes sense for some setups, but not all.

SwellJoe 10y ago

systemd is modular, and is divided into many components. There are several dozen binaries in a systemd package. Where do you believe the lines should be drawn differently?

Karlozkiller 10y ago
What I did mean was that at least from my understanding of it, you get systemd, and then you have all of systemd, unable to replace one part of systemd with some other package to handle that specific task. One of the features I would like to see for example is less binary logging and this journalctl madness. Binary logging makes it harder for me to plug in other programs to parse the logs or whatever I want to do. So what I would like to see is modularity in the sense where I can choose to run systemd as an init system, and something not-systemd for logging, or for scheduling or whatever.
- SwellJoe 10y ago
  On the logging question, does the ForwardToSyslog option not do what you'd like? Most components can be replaced (the journal isn't one of them, AFAIK, but most others can, and the journal can be configured to send things to a plain text log). Personally, I don't find the binary log to be that problematic. It is taking some getting used to, of course. 20+ years of muscle memory for grepping and awking and cutting text log files is hard to overcome, but the amount of help the system provides is nicer. It's better documented and better at guiding the user than the old way, IMHO. Which brings to mind something I like about systemd becoming standard that rarely gets discussed, I think: It brings a level of consistency that some other UNIX systems have had for a long time; the BSDs, for instance, have the feeling of all of the pieces having been designed to work together. Linux has never had that feeling; but with systemd, a large amount of Linux real estate now feels that way. The documentation correctly references other components docs. The way various components work together is reasonably documented because they were built at roughly the same time by roughly the same people (or at least people who interacted during the design), so the interfaces are clearly delineated. That's cool, I think. So, sure, I'm having to learn new stuff every time I interact with systemd, and that's frustrating. I know Linux like the back of my hand, so when I find myself having to read the docs for even simple stuff, I get grumpy. But, I get over it. It's gonna be fine, and we'll all get through this learning curve.
  - dozzie 10y ago
    > On the logging question, does the ForwardToSyslog option not do what you'd like? Of course not. Now you have two logging services. Hardly a replacement.
    - SwellJoe 10y ago
      So, to be clear, it is systemd itself that expects to be able to spit its logs to journald. Other services (most of the rest of a system) can log to whatever target it wants, including plain text files or a running syslog. The idea is that systemd wanted to not implement a bunch of different logging APIs within systemd itself. They wanted one logging API across all of the systemd components; and, then, if the end user needs logs to some other target, they use one utility (journald) to spit it out to that other target. I believe the thinking that went into this decision was sound. The alternative would be for every component in systemd to know about multiple logging targets, which would be exactly what people are accusing systemd of being (but isn't, in this case): bloated. systemd and all of its components log one way, allowing for a very simple logging code path. journald allows you to use those logs in many ways. So, either, systemd would need to expand to include support for a bunch of different logging mechanisms, or it would support one simple logging API and provide a way to export those logs to other targets. Are you here arguing that systemd should be made larger and more complicated, in order to support other kinds of logging (like syslog and plain text files) without the help of journald? To me, this looks like modularization and componentization at a reasonable level of abstraction. It simplifies the logging code for every component, while also providing a means for end users to consume the logs in the ways they prefer, including plain text.
      - dozzie 10y ago
        Your reasoning is invalid. It would be just enough if systemd supported syslog, with a mechanism for buffering logs initially until the syslog starts, which systemd already needs and has anyway. It was not a choice between new, custom service and making things complicated by supporting every possible log service. It's not modularization. It's scope creep in pure form.
mfukar 10y ago
> There are several dozen binaries in a systemd package. That's not what modular means. Can you use only parts of systemd if you wanted to? Can I e.g. use the very useful dependency-based service initialisation but keeping my log facilities and networking management intact?
- SwellJoe 10y ago
  "Can you use only parts of systemd if you wanted to?" Yes, though most distributions have chosen to use more than just the init functionality. "Can I e.g. use the very useful dependency-based service initialisation but keeping my log facilities and networking management intact?" No (logs) and yes (networking). Logging from systemd components, as far as I know, have to go through journald, but journald can send it as plain text to syslog, if you want it to. So, kinda yes on that one, too. networkd didn't even exist yet when many people began using systemd for their init, and it is entirely possible to use other methods of managing your network services. RHEL still, AFAIK, has a hybrid model that keeps a lot of the old configuration files even though they have switched to systemd for a lot of stuff. Maybe it uses networkd on the backend; I haven't needed to find out, as the config files work the same way they always have. I think the confusion comes from the fact that very few people want to only use one component of systemd. Even though you can, there is value in all of the pieces working well together and providing a consistent interface and API. Most distros that switch, choose to switch a lot of things over at the same time, because it's just nicer to do so, not because they had to. And, the people who hate systemd don't want any of it, so they never learn enough to know that they probably could get the bits from it they want without being tied to all of it.
  - mfukar 10y ago
    There is value in only some of the pieces working together, too. I'm sure having all the pieces together makes sense for some setups, but not all.