3 ms·

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.

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.