5 ms·

The ntp and dns are easy to replace, they're not part of the actual systemd binary. Fedora from what I remember, doesn't even enable systemds ntp service on Wor

The ntp and dns are easy to replace, they're not part of the actual systemd binary. Fedora from what I remember, doesn't even enable systemds ntp service on Workstation. Logging is a bit different, but you can tell journald to use syslog.

jimktrains2 7y ago
I don't mean in terms of the binary, but in terms of the whole system.
- vetinari 7y ago
  You would have to write quite a bit of code... The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd. And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts together won't do it.
  - michaelmrose 7y ago
    It's a very strange argument that I have seen previously that someone could write an alternative to systemd but haven't ergo systemd must be the best alternative. This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
    - vetinari 7y ago
      > This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. Alternative doesn't mean 100% substitute both ways. The pre-systemd didn't go in their abstraction in the way, that systemd does - it is basically system-level, event handling machine. The events could be not only boot, but also hotplug, timer, socket connection or others, and their handling is configured by the system or admin in unified way, including unified way of adjusting system-supplied units. Other inits just ran scripts at some order the boot and that's it, ignoring, that something doesn't have to happen at boot, but at some other time. That's one of the things, that systemd handles way better, than any suggested alternative. By ignoring where systemd is strong, you won't make the alternatives any better. > The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it. No. I don't see why we should have the Sisyphos task of maintaing sysv/cron/etc idiosyncrasies forever. Sometimes, it is better to get rid of the collected warts, and not limit the system to existing semantics.
      - JdeBP 7y ago
        > The pre-systemd didn't go in their abstraction On the contrary, that's exactly what systemd's predecessor, Upstart, did. systemd, in contrast, did not. Basing the system around the concept of events triggering things turned out to cause problems, as discussed by Lennart Poettering and by Debian Technical Committee members during the Debian Hoo-Hah as their reason for not choosing Upstart.
        vetinari 7y ago
        The problem wasn't that Upstart was event-based, but HOW the event system was designed. See http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html, section "On Upstart". It names two big issues with HOW.
  - jimktrains2 7y ago
    I didn't mean that everything was in a single binary, but that everything is tightly coupled. Just because a binary is replaceable, doesn't mean the replacements that have existed for decades will be "drop in" or integrate as well, which leads to feeling like a second class citizen or the overhead originally mentioned.
    - vetinari 7y ago
      I didn't mean single binary either. I meant, that systemd solves some category of problems, that other tools didn't solve, didn't intend to solve and didn't even care for what the problems are. For distribution maintainers, systemd was something to welcome, that did address their problems. So yes, there is no replacement (the requirement for it being drop-in only places the bar higher), because there's nothing else that scratches the same itch.
JdeBP 7y ago
> you can tell journald to use syslog No. One can tell syslogd to read from the journal. There is no mode of operation for journald that does not have the journal, on disc or in a memory filesystem. And journald itself is not optional. The only optional part is choosing to have an extra old-style syslog daemon that is using the journal as input. * https://unix.stackexchange.com/a/294206/5132 https://unix.stackexchange.com/a/294206/5132 * https://unix.stackexchange.com/a/332315/5132 https://unix.stackexchange.com/a/332315/5132
__david__ 7y ago
> The ntp and dns are easy to replace, they're not part of the actual systemd binary. They really aren't. It took us a full week of work to get dnsmasq to work in place of systemd-resolved. The problem is that they are tied in to the dhcp client and it only seems to know how to update systemd-resolved's configuration. So getting our custom search path out of dhcp was a huge pain. I like almost every other part of systemd, but trying to excise systemd-resolved from Ubuntu 18.04 was massively frustrating to the point where I started thinking, "maybe the systemd haters are right…"

jimktrains2 7y ago

I don't mean in terms of the binary, but in terms of the whole system.

vetinari 7y ago
You would have to write quite a bit of code... The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd. And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts together won't do it.
- michaelmrose 7y ago
  It's a very strange argument that I have seen previously that someone could write an alternative to systemd but haven't ergo systemd must be the best alternative. This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
  - vetinari 7y ago
    > This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools. Alternative doesn't mean 100% substitute both ways. The pre-systemd didn't go in their abstraction in the way, that systemd does - it is basically system-level, event handling machine. The events could be not only boot, but also hotplug, timer, socket connection or others, and their handling is configured by the system or admin in unified way, including unified way of adjusting system-supplied units. Other inits just ran scripts at some order the boot and that's it, ignoring, that something doesn't have to happen at boot, but at some other time. That's one of the things, that systemd handles way better, than any suggested alternative. By ignoring where systemd is strong, you won't make the alternatives any better. > The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it. No. I don't see why we should have the Sisyphos task of maintaing sysv/cron/etc idiosyncrasies forever. Sometimes, it is better to get rid of the collected warts, and not limit the system to existing semantics.
    - JdeBP 7y ago
      > The pre-systemd didn't go in their abstraction On the contrary, that's exactly what systemd's predecessor, Upstart, did. systemd, in contrast, did not. Basing the system around the concept of events triggering things turned out to cause problems, as discussed by Lennart Poettering and by Debian Technical Committee members during the Debian Hoo-Hah as their reason for not choosing Upstart.
      - vetinari 7y ago
        The problem wasn't that Upstart was event-based, but HOW the event system was designed. See http://0pointer.de/blog/projects/systemd.html http://0pointer.de/blog/projects/systemd.html, section "On Upstart". It names two big issues with HOW.
- jimktrains2 7y ago
  I didn't mean that everything was in a single binary, but that everything is tightly coupled. Just because a binary is replaceable, doesn't mean the replacements that have existed for decades will be "drop in" or integrate as well, which leads to feeling like a second class citizen or the overhead originally mentioned.
  - vetinari 7y ago
    I didn't mean single binary either. I meant, that systemd solves some category of problems, that other tools didn't solve, didn't intend to solve and didn't even care for what the problems are. For distribution maintainers, systemd was something to welcome, that did address their problems. So yes, there is no replacement (the requirement for it being drop-in only places the bar higher), because there's nothing else that scratches the same itch.

JdeBP 7y ago

> you can tell journald to use syslog No. One can tell syslogd to read from the journal. There is no mode of operation for journald that does not have the journal, on disc or in a memory filesystem. And journald itself is not optional. The only optional part is choosing to have an extra old-style syslog daemon that is using the journal as input. * https://unix.stackexchange.com/a/294206/5132 https://unix.stackexchange.com/a/294206/5132 * https://unix.stackexchange.com/a/332315/5132 https://unix.stackexchange.com/a/332315/5132

__david__ 7y ago

> The ntp and dns are easy to replace, they're not part of the actual systemd binary. They really aren't. It took us a full week of work to get dnsmasq to work in place of systemd-resolved. The problem is that they are tied in to the dhcp client and it only seems to know how to update systemd-resolved's configuration. So getting our custom search path out of dhcp was a huge pain. I like almost every other part of systemd, but trying to excise systemd-resolved from Ubuntu 18.04 was massively frustrating to the point where I started thinking, "maybe the systemd haters are right…"