5 ms·

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 som

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.
      - 10y ago

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.
    - 10y ago