3 ms·

I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are

I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are non-starters because they have hard dependencies on systemd, which is ridiculous. > For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. I use neither logind nor consolekit. These are solutions for problems I don't have. Moreover, they often get in the way: when I ssh into my media PC, I don't want logind/consolekit to tell me I'm not allowed to access the sound or video cards. The only function that machine performs is to do the thing that logind/consolekit are designed to prevent. And it's a required component of systemd. I'm glad it's easier for you to manage services with systemd. But it's easier for me to manage services with OpenRC, and there's nothing wrong with that. As far as handling modern hardware- huh? I guess it's not clear to me what interactions an init manager is supposed to have with hardware. Which really speaks to my primary issue with systemd: it's a freaking monster. It does nine million things, but I only need it to do like three things: start services when I tell it to start services, stop them when I tell it to stop them, and restart them if they crash. (if it's configured to do so) That's it. Why do I need or want it to interact with my hardware? Why does it need an integrated web server in order to start apache? Why does it a logging daemon in order to start syslog-ng? Why do I have to use its built in log reader instead of tail, less, grep etc? Where is the boundary between systemd and the rest of my system?

AsyncAwait 7y ago
> The problem is the systemd monoculture. And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick. > These are solutions for problems I don't have. Good for you. But event handling is something that many systems today do need and I think we should try to optimize for the common use case. As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems. GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc. It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. Mo, it solves real problems for them, so they depend on it. Why is this hard to grasp?
- JdeBP 7y ago
  systemd-logind does require systemd. That was one of the root causes of the Debian Hoo-Hah. * http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html
- nwallin 7y ago
  To start off with: Maybe I'm not on the same page, but your tone feels quite aggressive to me right now. I'm not telling you that you're wrong for choosing to use the software that you use. This isn't a flamewar, I'm not trying to tell you to do different things. I'm just explaining why the OP's criteria for an init manager don't apply to me. It's also 3am my time, and I've had quite a bit to drink. If anything in my post comes off as aggressive, please let me know and I'll edit it in the morning. > And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick. No. OpenRC is very happy sitting on top of busybox init instead of sysvinit.[0] When I encountered problems with my gentoo system built on musl (instead of glibc, #1 source of problems) and busybox (instead of coreutils #2 source of problems, and sysvinit #3 source of problems) they got fixed. A major part of why OpenRC is what it is is to prevent reinventing sysvinit/busybox's wheel. > event handling is something that many systems today do need and I think we should try to optimize for the common use case. > As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems. Security is a concern on all of my systems, however, I do not agree that logind/consolekit add any security (at all) to most systems, or that they add substantial security to a small minority (say 5%) of systems. I would wager that 95+% of all linux systems are one of the following: A) no one is permitted access to any hardware, (video/sound/input) (headless systems, ie server farms, multiuser systems in a university, etc) B) single user account systems, (ie, my laptop. If someone has write access to my .bashrc file, they might as well have root access, and consolekit/logind can't bandaid anything by limiting access to my video device hardware) or C) hpc compute farms. (where the assumption is that all processes have god given write access to the GPUs) In the first class of systems, consolekit/elogind do not add security because all accesses are blocked, (in fact, the existence of consolekit/elogind simply expands the attack surface, making it less secure) in the second class no security is added because the video card is a more difficult attack vector than editing all the common home scripts, in the third class no security is added because whitelist-asterisk-to-video-card is the only sane configuration policy. logind/consolekit are super awesome for eg educational institutions which have computers with multiple seats. Have four schoolchildren sitting at four monitors and four keyboards attached to one desktop computer? Sweet. (actually most schools use chromebooks now, which last I checked uses OpenRC) It's great that projects like consolekit/elogind exist to support those groups. But pretending like that's a common usecase, or pretending that sysvinint can't support those usecases- stop. > GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc. This statement is, at best, disingenuous. If you want to install Gnome on Gentoo, you need to do one of two things: install systemd (Gentoo supports systemd as a first.point.five class citizen (my terminology))[1] or install elogind. elogind is a Gentoo specific forked version of systemd with everything that is not logind-related removed.[2] This code is still all upstream systemd code, and there is not a meaningful path towards an independent fork, the way busybox init exists independently of sysvinit, or syslog-ng exists independent of syslogd, or xorg-x11 exists independently of XFree11. The fact that non-systemd installations of Gnome can possibly exist on Gentoo is a result of Gentoo developers going above and beyond the call of duty, despite barriers placed by the systemd team. And non-linux posix systems, eg FreeBSD - forget it. > It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. I have nothing but respect for the Gnome team. I never implied anything of the sort. I am disgusted by your insinuation. Please walk this statement back. I think that many of the things that the systemd monolith has to offer are valuable. If systemd were a federated constellation of small daemons speaking a reasonably stable API that didn't all have hard dependencies on each other, I would probably be quite happy with it. The problem - again - with systemd is the unforgiving, colossal monolith. I don't have the privilege of dipping my toes into the good parts without having to swallow whole the bad parts. And the bad parts are disgusting. (this is the same problem I have with Microsoft Windows) Modularity is a good thing; systemd is the antithesis of that. [0] https://wiki.gentoo.org/wiki/OpenRC#Replacing_init https://wiki.gentoo.org/wiki/OpenRC#Replacing_init [1] https://wiki.gentoo.org/wiki/Systemd https://wiki.gentoo.org/wiki/Systemd [2] https://wiki.gentoo.org/wiki/Elogind https://wiki.gentoo.org/wiki/Elogind

AsyncAwait 7y ago

> The problem is the systemd monoculture. And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick. > These are solutions for problems I don't have. Good for you. But event handling is something that many systems today do need and I think we should try to optimize for the common use case. As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems. GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc. It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. Mo, it solves real problems for them, so they depend on it. Why is this hard to grasp?

JdeBP 7y ago
systemd-logind does require systemd. That was one of the root causes of the Debian Hoo-Hah. * http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html http://jdebp.uk./FGA/debian-systemd-packaging-hoo-hah.html
nwallin 7y ago
To start off with: Maybe I'm not on the same page, but your tone feels quite aggressive to me right now. I'm not telling you that you're wrong for choosing to use the software that you use. This isn't a flamewar, I'm not trying to tell you to do different things. I'm just explaining why the OP's criteria for an init manager don't apply to me. It's also 3am my time, and I've had quite a bit to drink. If anything in my post comes off as aggressive, please let me know and I'll edit it in the morning. > And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick. No. OpenRC is very happy sitting on top of busybox init instead of sysvinit.[0] When I encountered problems with my gentoo system built on musl (instead of glibc, #1 source of problems) and busybox (instead of coreutils #2 source of problems, and sysvinit #3 source of problems) they got fixed. A major part of why OpenRC is what it is is to prevent reinventing sysvinit/busybox's wheel. > event handling is something that many systems today do need and I think we should try to optimize for the common use case. > As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems. Security is a concern on all of my systems, however, I do not agree that logind/consolekit add any security (at all) to most systems, or that they add substantial security to a small minority (say 5%) of systems. I would wager that 95+% of all linux systems are one of the following: A) no one is permitted access to any hardware, (video/sound/input) (headless systems, ie server farms, multiuser systems in a university, etc) B) single user account systems, (ie, my laptop. If someone has write access to my .bashrc file, they might as well have root access, and consolekit/logind can't bandaid anything by limiting access to my video device hardware) or C) hpc compute farms. (where the assumption is that all processes have god given write access to the GPUs) In the first class of systems, consolekit/elogind do not add security because all accesses are blocked, (in fact, the existence of consolekit/elogind simply expands the attack surface, making it less secure) in the second class no security is added because the video card is a more difficult attack vector than editing all the common home scripts, in the third class no security is added because whitelist-asterisk-to-video-card is the only sane configuration policy. logind/consolekit are super awesome for eg educational institutions which have computers with multiple seats. Have four schoolchildren sitting at four monitors and four keyboards attached to one desktop computer? Sweet. (actually most schools use chromebooks now, which last I checked uses OpenRC) It's great that projects like consolekit/elogind exist to support those groups. But pretending like that's a common usecase, or pretending that sysvinint can't support those usecases- stop. > GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc. This statement is, at best, disingenuous. If you want to install Gnome on Gentoo, you need to do one of two things: install systemd (Gentoo supports systemd as a first.point.five class citizen (my terminology))[1] or install elogind. elogind is a Gentoo specific forked version of systemd with everything that is not logind-related removed.[2] This code is still all upstream systemd code, and there is not a meaningful path towards an independent fork, the way busybox init exists independently of sysvinit, or syslog-ng exists independent of syslogd, or xorg-x11 exists independently of XFree11. The fact that non-systemd installations of Gnome can possibly exist on Gentoo is a result of Gentoo developers going above and beyond the call of duty, despite barriers placed by the systemd team. And non-linux posix systems, eg FreeBSD - forget it. > It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. I have nothing but respect for the Gnome team. I never implied anything of the sort. I am disgusted by your insinuation. Please walk this statement back. I think that many of the things that the systemd monolith has to offer are valuable. If systemd were a federated constellation of small daemons speaking a reasonably stable API that didn't all have hard dependencies on each other, I would probably be quite happy with it. The problem - again - with systemd is the unforgiving, colossal monolith. I don't have the privilege of dipping my toes into the good parts without having to swallow whole the bad parts. And the bad parts are disgusting. (this is the same problem I have with Microsoft Windows) Modularity is a good thing; systemd is the antithesis of that. [0] https://wiki.gentoo.org/wiki/OpenRC#Replacing_init https://wiki.gentoo.org/wiki/OpenRC#Replacing_init [1] https://wiki.gentoo.org/wiki/Systemd https://wiki.gentoo.org/wiki/Systemd [2] https://wiki.gentoo.org/wiki/Elogind https://wiki.gentoo.org/wiki/Elogind