13 ms·

When systemd came out people were saying that it added desktop bloat that was useless for servers, so maybe the truth is in the middle...

bravetraveler 2y ago
Zealots do tend to be wrong, yes.
JoshTriplett 2y ago
Or the people who don't think systemd provides benefits for servers are simply wrong. Sometimes "the truth is in the middle" but more often than not there's a correct and an incorrect answer.
- beeflet 2y ago
  I don't know, I have never had to use systemd. openrc works fine for me and it seems less complicated. What's the killer feature for systemd?
  - throw_a_grenade 2y ago
    systemd (with the constellation of its assorted tooling like udev, logind etc.) is the only system that correctly models stuff that happens around kernel (like hotplugging stuff, on top of starting services). It's a compelling choice for general-purpose distros (those that span both servers and desktop), who don't want to maintain more stuff than they absolutely must (like two different init systems), and almost inescapable for today's DE's. Unfortunately that's about the only good thing that can be said about it. The community is perceived as toxic, because of the way it was adopted (by vote, not by consensus, i.e. pushed down the throats over the reasonable objections of large body of developers) (though it's false: it's not toxic at all, if you just approach them from outside with well founded feature request, they'll be far more accomodating than many FOSS projects). Conduct of lead developers was criticised (cf. kdbus). The stability and code quality has much improved, but at the time of discussion it was questioned. Last but not least, it comes with it's own load of complexity: you need to learn new concepts (e.g. something called "job") that are simply not there in inittab-derived systems like openrc, so it comes across as "undebuggable" if you're before the learning curve.
    - beeflet 2y ago
      I guess but with elogind I have no problem running DEs without systemd. I have just never really come across systemd, having mostly used distros like alpine and gentoo
  - VladStanimir 2y ago
    I am rearely involved in ops, however from what i have gathered i think its killer feature is the exact thing most people complain about when talking about it. Systemd is not an init system, its an entirely system layer that does a lot of things of which init is just one piece. However since there is a unified vision, all the things are controlled and configured the same way. This combined with its near universal adoption makes ops realy easy to do.
  - JoshTriplett 2y ago
    Many, many things. (Note: not an openrc expert, so not commenting on whether it's possible to arrange these things using entirely what openrc provides, in a uniform fashion that works identically on any openrc system.) Universal trivial logging, including of text just printed to the daemon's stdout/stderr, and you can easily ask "give me the log messages from just this application". And you can log to memory for stateless systems, or to disk. Service monitoring as the default expectation: services are a thing that are monitored and restarted if they fail, not a thing that gets run once and hopefully stays running. Full integration with all kinds of event handling. Whether something is triggered by a kernel event (e.g. new device), a timer job, an incoming socket, or system boot, it uses exactly the same mechanism to start a service. So you don't need one mechanism (cron) for timers and another (inetd) for sockets and another (init scripts) for system boot. And all of them use the same service monitoring, logging, etc. Easy integration with various kinds of sandboxing. One line in a .service file and a service runs in a chroot, or has no network access, etc. And then there's just the general standardization effort to unify the dozens of different places that things get configured into one mechanism that's the same across distributions. For instance, before systemd, distributions had various different places to configure the hostname; now, distributions have largely standardized on `/etc/hostname`. There are many more instances of such standardization, and most of them have been successful.
- bonzini 2y ago
  Yes, I totally agree. What I meant is that sometimes enterprise comes first, sometimes desktop comes first, sometimes they meet in the middle.
phendrenad2 2y ago
My impression of SystemD, from reading a lot of Poettering interviews, is that it was inspired by desktop operating systems (Mac and Windows), however, it ironically it was popular with server distro vendors (most notably Red Hat and Microsoft, who have both employed Poettering at one point or another). Believe me, I also looked for any example of desktop Linux getting any kind of prioritization in the kernel, and it just doesn't happen.

bravetraveler 2y ago

Zealots do tend to be wrong, yes.

JoshTriplett 2y ago

Or the people who don't think systemd provides benefits for servers are simply wrong. Sometimes "the truth is in the middle" but more often than not there's a correct and an incorrect answer.

beeflet 2y ago
I don't know, I have never had to use systemd. openrc works fine for me and it seems less complicated. What's the killer feature for systemd?
- throw_a_grenade 2y ago
  systemd (with the constellation of its assorted tooling like udev, logind etc.) is the only system that correctly models stuff that happens around kernel (like hotplugging stuff, on top of starting services). It's a compelling choice for general-purpose distros (those that span both servers and desktop), who don't want to maintain more stuff than they absolutely must (like two different init systems), and almost inescapable for today's DE's. Unfortunately that's about the only good thing that can be said about it. The community is perceived as toxic, because of the way it was adopted (by vote, not by consensus, i.e. pushed down the throats over the reasonable objections of large body of developers) (though it's false: it's not toxic at all, if you just approach them from outside with well founded feature request, they'll be far more accomodating than many FOSS projects). Conduct of lead developers was criticised (cf. kdbus). The stability and code quality has much improved, but at the time of discussion it was questioned. Last but not least, it comes with it's own load of complexity: you need to learn new concepts (e.g. something called "job") that are simply not there in inittab-derived systems like openrc, so it comes across as "undebuggable" if you're before the learning curve.
  - beeflet 2y ago
    I guess but with elogind I have no problem running DEs without systemd. I have just never really come across systemd, having mostly used distros like alpine and gentoo
- VladStanimir 2y ago
  I am rearely involved in ops, however from what i have gathered i think its killer feature is the exact thing most people complain about when talking about it. Systemd is not an init system, its an entirely system layer that does a lot of things of which init is just one piece. However since there is a unified vision, all the things are controlled and configured the same way. This combined with its near universal adoption makes ops realy easy to do.
- JoshTriplett 2y ago
  Many, many things. (Note: not an openrc expert, so not commenting on whether it's possible to arrange these things using entirely what openrc provides, in a uniform fashion that works identically on any openrc system.) Universal trivial logging, including of text just printed to the daemon's stdout/stderr, and you can easily ask "give me the log messages from just this application". And you can log to memory for stateless systems, or to disk. Service monitoring as the default expectation: services are a thing that are monitored and restarted if they fail, not a thing that gets run once and hopefully stays running. Full integration with all kinds of event handling. Whether something is triggered by a kernel event (e.g. new device), a timer job, an incoming socket, or system boot, it uses exactly the same mechanism to start a service. So you don't need one mechanism (cron) for timers and another (inetd) for sockets and another (init scripts) for system boot. And all of them use the same service monitoring, logging, etc. Easy integration with various kinds of sandboxing. One line in a .service file and a service runs in a chroot, or has no network access, etc. And then there's just the general standardization effort to unify the dozens of different places that things get configured into one mechanism that's the same across distributions. For instance, before systemd, distributions had various different places to configure the hostname; now, distributions have largely standardized on `/etc/hostname`. There are many more instances of such standardization, and most of them have been successful.
bonzini 2y ago
Yes, I totally agree. What I meant is that sometimes enterprise comes first, sometimes desktop comes first, sometimes they meet in the middle.

phendrenad2 2y ago

My impression of SystemD, from reading a lot of Poettering interviews, is that it was inspired by desktop operating systems (Mac and Windows), however, it ironically it was popular with server distro vendors (most notably Red Hat and Microsoft, who have both employed Poettering at one point or another). Believe me, I also looked for any example of desktop Linux getting any kind of prioritization in the kernel, and it just doesn't happen.