Mozilla in recent releases is making it really hard for non-systemd distros to comply. Fake non-systemd distros using udev and elogind out of the latest systemd don’t seem to have a problem.…
Until someone can provide actual, techological disadvantages of systemd over currently available, viable alternatives, this is an irrelevant culture war for me. I feel like some people made hating system-d a core element of their identity and personality.
I feel like some people made hating system-d a core element of their identity and personality.
Basically this these days. It started out with people not liking change, not liking the author and miss-understanding what systemd is trying to do. Then latching onto some aspects of it and refusing to let go or change their minds at all.
The tragedy of systemd talk goes over a bunch of the common reasons (and counter points) about why people don’t like systemd as well as the history of init systems.
Even 4chan meme Luke Smith has said he is not sure what is so wrong with system-d to go out of his way to avoid it. Some people across other threads have made some vague comment about vendor lock, but I think people choose it because it solves a problem. Not sure what contract keeps people tied to system-d.
One thing i can think of is that systemd won’t work in chroots(tell me if i’m wrong, help!). That is, apps requiring systemd cannot be run in chroot environment as it does not “boot up” at all. Systemd, due to it being an init system used to boot up, and being a daemon for other apps, makes it that you can’t run such apps in a non-booted environment.
I would like it so much if it was splitted into two something like “initd+systemd” or “systemd+servicesd” for boot up and running services seperately. So you can choose your init system or not to have an init system for chroot.
This looks like a replacement for chroot itself. It would be better if i can spawn a systemd process inside chroot that take care of services. And i can’t understand why it wants to stick into PID 1 of host even when running in chroot.
Until someone can provide actual, techological disadvantages of systemd over currently available, viable alternatives, this is an irrelevant culture war for me. I feel like some people made hating system-d a core element of their identity and personality.
Basically this these days. It started out with people not liking change, not liking the author and miss-understanding what systemd is trying to do. Then latching onto some aspects of it and refusing to let go or change their minds at all.
The tragedy of systemd talk goes over a bunch of the common reasons (and counter points) about why people don’t like systemd as well as the history of init systems.
Even 4chan meme Luke Smith has said he is not sure what is so wrong with system-d to go out of his way to avoid it. Some people across other threads have made some vague comment about vendor lock, but I think people choose it because it solves a problem. Not sure what contract keeps people tied to system-d.
One thing i can think of is that systemd won’t work in chroots(tell me if i’m wrong, help!). That is, apps requiring systemd cannot be run in chroot environment as it does not “boot up” at all. Systemd, due to it being an init system used to boot up, and being a daemon for other apps, makes it that you can’t run such apps in a non-booted environment.
I would like it so much if it was splitted into two something like “initd+systemd” or “systemd+servicesd” for boot up and running services seperately. So you can choose your init system or not to have an init system for chroot.
At first sight, it looks like it can be used with chroots thanks to
systemd-nspawn(I haven’t tried it though)This looks like a replacement for chroot itself. It would be better if i can spawn a systemd process inside chroot that take care of services. And i can’t understand why it wants to stick into PID 1 of host even when running in chroot.
I don’t like <thing> so no one else is allowed to like <thing> seems to be rampant.