4 ms·

> systemd is cancer Can you expand on this claim?

monsieur 6y ago
So from my point of view systemd is cancer because it's useless creation of some twisted minds and just makes my life harder. There is no init freedom too!!! You are forced to use systemd arch linux or you get banned!!! You're not supposed to ask questions!!!
monsieur 6y ago
Well what it is is that obarun has systemd and systemd-libs blocked in /etc/pacman.conf (ignorepkg) what arch developers do is they add systemd dependencies to almost everything they can but when i edit some specific pkgbuild and remove systemd as dependency, i am able to build this application fine and it runs good without cancer!!!!! And it is annoying, cuz if you want use these programs on arch based distro without systemd, you can't!!! you have to waste your time to remove those nasty dependencies. Other distros have dummy pseudo-systemd-libraries and elogind but obarun doesn't so packages are 'cleaner' few days ago i tried to install qemu on obarun, and guess what brltty (qemu dependency) requries systemd to function!! cuz arch linux devs think they do!!! they put this cancer to dependency, what for?? So because i use obarun i downloaded brltty from aur, removed systemd from dependencies from PKGBUILD and guess what, i have managed to build and use qemu without systemd!!! so why do arch developers add systemd dependencies all the time to packages if it's supposed to be just an init system??? And those packages run fine without systemd?? What's the fucking point??
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.

So from my point of view systemd is cancer because it's useless creation of some twisted minds and just makes my life harder. There is no init freedom too!!! You are forced to use systemd arch linux or you get banned!!! You're not supposed to ask questions!!!

monsieur 6y ago

Well what it is is that obarun has systemd and systemd-libs blocked in /etc/pacman.conf (ignorepkg) what arch developers do is they add systemd dependencies to almost everything they can but when i edit some specific pkgbuild and remove systemd as dependency, i am able to build this application fine and it runs good without cancer!!!!! And it is annoying, cuz if you want use these programs on arch based distro without systemd, you can't!!! you have to waste your time to remove those nasty dependencies. Other distros have dummy pseudo-systemd-libraries and elogind but obarun doesn't so packages are 'cleaner' few days ago i tried to install qemu on obarun, and guess what brltty (qemu dependency) requries systemd to function!! cuz arch linux devs think they do!!! they put this cancer to dependency, what for?? So because i use obarun i downloaded brltty from aur, removed systemd from dependencies from PKGBUILD and guess what, i have managed to build and use qemu without systemd!!! so why do arch developers add systemd dependencies all the time to packages if it's supposed to be just an init system??? And those packages run fine without systemd?? What's the fucking point??

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.