3 ms·

1. The binary log is more corruption prone and such corruption has been observed in the wild. It's in the wrong direction. Logs should be simple text files and

by chx 6y ago

1. The binary log is more corruption prone and such corruption has been observed in the wild. It's in the wrong direction. Logs should be simple text files and if complex enough queries are warranted then there should be a copy in a competent database. There is no need to implement a database, we have enough of them. 2. No software is bug free but now one huge piece of software is such that bugs in it crash the entire system. Only the kernel should be so. 3. Speaking of code base size, the more code you run as pid1 the more security holes you have. 4. Throwing out decades of knowledge and replacing it shouldn't be taken lightly and should be accompanied by world class documentation. No such thing. 5. Abusing dbus for IPC is not the best of technical decisions, no wonder they wanted kdbus which of course went nowhere. 6. Speaking of, a lot of things went somewhere because Poettering is basically a bully. kdbus went nowhere because bullying Torvalds is impossible. But really, these sorts of questions shouldn't be decided on who is more insufferable. These guys wouldn't survive contact with a code of conduct and that's not a good thing. (If you remember, Torvalds temporarily didn't.)

__s 6y ago
On kdbus: https://lkml.org/lkml/2015/6/23/657 https://lkml.org/lkml/2015/6/23/657
cookiengineer 6y ago
While I agree with all of your points, I don't necessarily understand why reverting away from systemd would fix this. Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too. Apache binds sigwinch signals to shutdown for a reason, and those were not good reasons to begin with. A more sophisticated alternative daemon would need to improve on the signals concept in the kernel beforehand, which certainly has to change; as kernel signalling currently is not even remotely made for such a use case (of a system daemon). ...so I kind of understand poettering's harsh statements, and why linus and him don't get along so well due to both of 'em having very opinionated and probably opposite views. I think in order to improve at least some of your points, maybe some systemd modules and integration APIs would be the best way to go? Like an sqlite enabled systemd or something? Do you know whether such an initiative already exists?
- cat199 6y ago
  > Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too. false choice - witness rc.d-style init & having a sane shell library / helper programs to handle common start/stop idioms, as is also apparently provided here.
cycloptic 6y ago
Just some small comments... The binary log can be disabled if you don't want to use it. I personally dislike simple text logs and find them frustrating to use and would rather not go back to them, and using a traditional database engine is overkill here. (An on-disk log database only needs to support create and read operations) Regarding security and code base size, it's not clear to me that any other architecture here is going to be less error prone. The problem seems to be that a large number of operations that you probably want your service manager to do on Linux require root or CAP_SYS_ADMIN. It doesn't really seem to matter if you put that stuff outside of pid1, a program that needs the same elevated privileges can still stomp on your system and mess with the state of pid1. I've found systemd has extensive documentation (at https://systemd.io/ https://systemd.io/) and the developers on the IRC and mailing list usually seem to be responsive. I searched and I could not find any examples of this "bullying" on LKML. It looks like Greg was the person who was sponsoring it and trying to get it merged, not Lennart. And I'm not sure I would call their use of dbus to be abuse. I honestly think it would be cool if other low level daemons used dbus in this way because it makes integration (GUIs, automation, remote control, security policies, etc) a lot easier, as long as you familiarize yourself with the tooling around dbus. All that said, systemd is made for a general use case and is not ideal for containers or for embedded. I hope these other init systems can find their niche.

by chx 6y ago

__s 6y ago

On kdbus: https://lkml.org/lkml/2015/6/23/657 https://lkml.org/lkml/2015/6/23/657

cookiengineer 6y ago

While I agree with all of your points, I don't necessarily understand why reverting away from systemd would fix this. Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too. Apache binds sigwinch signals to shutdown for a reason, and those were not good reasons to begin with. A more sophisticated alternative daemon would need to improve on the signals concept in the kernel beforehand, which certainly has to change; as kernel signalling currently is not even remotely made for such a use case (of a system daemon). ...so I kind of understand poettering's harsh statements, and why linus and him don't get along so well due to both of 'em having very opinionated and probably opposite views. I think in order to improve at least some of your points, maybe some systemd modules and integration APIs would be the best way to go? Like an sqlite enabled systemd or something? Do you know whether such an initiative already exists?

cat199 6y ago
> Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too. false choice - witness rc.d-style init & having a sane shell library / helper programs to handle common start/stop idioms, as is also apparently provided here.

cycloptic 6y ago

Just some small comments... The binary log can be disabled if you don't want to use it. I personally dislike simple text logs and find them frustrating to use and would rather not go back to them, and using a traditional database engine is overkill here. (An on-disk log database only needs to support create and read operations) Regarding security and code base size, it's not clear to me that any other architecture here is going to be less error prone. The problem seems to be that a large number of operations that you probably want your service manager to do on Linux require root or CAP_SYS_ADMIN. It doesn't really seem to matter if you put that stuff outside of pid1, a program that needs the same elevated privileges can still stomp on your system and mess with the state of pid1. I've found systemd has extensive documentation (at https://systemd.io/ https://systemd.io/) and the developers on the IRC and mailing list usually seem to be responsive. I searched and I could not find any examples of this "bullying" on LKML. It looks like Greg was the person who was sponsoring it and trying to get it merged, not Lennart. And I'm not sure I would call their use of dbus to be abuse. I honestly think it would be cool if other low level daemons used dbus in this way because it makes integration (GUIs, automation, remote control, security policies, etc) a lot easier, as long as you familiarize yourself with the tooling around dbus. All that said, systemd is made for a general use case and is not ideal for containers or for embedded. I hope these other init systems can find their niche.