5 ms·

The Server Space is arguably the main place SystemD was designed for, and probably the only place it makes sense to deploy it. There are a subset of use-cases t

• pulisse 8y ago
  > You know what else causes less bugs? LESS CODE, AND LESS FEATURES. The less code there is running on a system, the less code there is to exploit, and the less bugs there are likely to be. PID 1 is a SACRED, HOLY, Process Identifier. Code that runs with this PID has control over the ENTIRE SYSTEM. An exploit in PID 1 is LITERALLY game over. That's an odd point to make in defense of systemd, since one of the primary objections to its use on servers is that it has vastly more surface area than is required for process supervision.
  • kohtatsu 8y ago
    That point wasn't in defence of systemd.
• yellowapple 8y ago
  > The Server Space is arguably the main place SystemD was designed for, and probably the only place it makes sense to deploy it. I have the opposite opinion. systemd is irrelevant on a server (might've been relevant once upon a time, but not in this day and age), and it was developed specifically with end-user devices in mind. Looking at the list of things systemd does (pulled from http://without-systemd.org/wiki/index.php/Arguments_against_systemd#Scope_creep http://without-systemd.org/wiki/index.php/Arguments_against_... ): systemd is an init system In this day and age of virtual machines and containers, this is not really that useful. Most daemons are effectively PID 1 in their respective containers (if there is a separate init, it ain't really doing much besides launching a finger-countable number of daemons), and on the host (assuming you even can access the host) it's still stripped down to the bare minimum (with anything not required for managing VMs delegated to VMs instead of running directly on the hypervisor). As the article mentioned, the startup speed benefits from launching daemons in parallel are hardly useful compared to the long POST times and the limited number of daemons. In contrast, desktops (niche systems like Qubes notwithstanding) do frequently run a lot of daemons on a single logical system. Fast startup does matter for desktops. systemd is actually useful here. systemd provides an UEFI boot loader, systemd-boot (previously gummiboot) Not really sure this is useful anywhere (ain't like there aren't plenty of existing bootloaders). systemd provides a login manager, systemd-logind Given - again - the growing trend toward virtualizing/containerizing everything, this is decreasingly valuable on a server except maybe for SSH logins (and even then). This is more useful for desktops, where login and session management matters a lot more. systemd provides a syslog daemon, systemd-journald Most servers shouldn't be using the vast majority of journald's functionality; they should instead be sending logs to a remote log server (if your servers aren't already doing so, then I suggest getting off Hacker News and fixing that ASAP :) ). Desktops, on the other hand, typically stick to local logging and thus do potentially benefit from an improved local logging system (whether journald counts as "improved" is a matter of taste). systemd provides a mount front-end, systemd-mount [ ... ] systemd provides automount via systemd.automount to substitute autofs This one happens to be useful for both servers and desktops, but in my experience frequent live unmounting/remounting of disks is way more common for desktops than servers (with the sole exception of servers hooked up to, say, an optical media carousel or something like that, and even that's a pretty niche application). RAID wouldn't even be a factor here, since swapping out a disk in an array doesn't involve mounting or unmounting the filesystem(s) on top of that array. The udev sources were merged into the systemd source tree. Benefits servers and desktops more-or-less equally. systemd provides systemd.timer timer units, which can be used to replace cron and at One of the few cases of a systemd feature that's more useful on servers than desktops (though in both cases I've yet to see this actually used instead of cron/at). systemd provides a D-Bus client library, sd-bus (see sd-bus) systemd developed an in-kernel D-Bus implementation, kdbus. D-Bus literally stands for "Desktop Bus". These are explicitly desktop-oriented features. systemd provides a caching DNS resolver, systemd-resolved This is entirely useless on a server; either your server is a DNS server (in which case it's using an actual DNS-serving daemon meant for handling external traffic, i.e. not systemd-resolved) or it's not a DNS server (in which case - unless you're an extreme masochist and consider DNS-cache-related issues to be fun - you're probably going to be pointing /etc/resolv.conf at your network's actual DNS servers and calling it a day). This is way more useful for laptops and mobile devices, which switch networks frequently (and sometimes switch onto e.g. public hotspots or other networks with buggy or overworked or outright adversarial DNS servers of their own). systemd provides a network manager and DHCP client, systemd-networkd systemd provides a HTTP server for journal events, systemd-journal-gatewayd systemd provides a containerization system systemd-nspawn Not sure if I've ever seen these three actually used anywhere; they seem to be equally useless on servers and desktops. ---- Final verdict given the above: systemd was demonstrably developed specifically with desktops in mind (and even more specifically with GNOME in mind, which should be unsurprising given how much Red Hat loves GNOME). The vast majority of its components make far more sense on end-user devices than servers (and the ones that don't are either equally useful or equally useless).