9 ms·

For a service manager, yes systemd is great. For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in orde

For a service manager, yes systemd is great. For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in order to test it is completely worth it. For an NTP implementation? Eh. I'm not sure why that needs to be bundled in under the same umbrella as the service manager. It's also just an SNTP implementation, not full NTP, so it's notably feature-crippled relative to better options like chrony. Network management? Meh. Again, that strikes me as something that should be loosely coupled to the service manager. A UEFI implementation? gummiboot was assimilated and become systemd-boot. Was that necessary for technical reasons, or was it just moving a project under the systemd umbrella similar to how there's an umbrella of GNU projects? Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives. At a certain point "systemd" becomes a brand more than anything else, sort of like what IBM has been trying to do with Watson. Yes, it beat Ken Jennings at Jeopardy and that's great. That doesn't mean anything associated with the overall brand is automatically equally amazing.

freedomben 7y ago
Many of those things are not all or nothing. For example you can use chrony with systemd. RHEL 8 does that by default. You can even install rsyslog to consume logs if you want, and it works just fine. I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.
- newnewpdro 7y ago
  You can't replace journald with rsyslog. You can use rsyslog in addition to journald, but there's no way to get journald out of the picture - it's intertwined with the service manager.
  - freedomben 7y ago
    Yes, sorry if what I wrote was misleading. You can't replace journald with rsyslog, but the only complaints I hear about journald are that it's binary so you have to use journalctl to read them. By installing rsyslog you basically get the classic log behavior back. So technically under the hood you're still using journald, but you never have to know it.
    - pferde 7y ago
      My main complaint is that journald is unreliable and is losing log entries (or lines, if you will). I had an automation recipe that would start a bunch of cloud instances, configure them and start certain job via a systemd service unit, and collect logs from this job 24 hours later. Initially, we were pulling these logs via journald as logs for that service unit. But then we noticed that random lines (1-5 lines out of maybe 40 for a single job) would be missing in about half the instances. We ended up pulling those logs from files in /var/log instead, made courtesy of rsyslog. Not a single missed line. Again journald is unreliable and as a whole should be nuked from the orbit.
      - freedomben 7y ago
        Interesting, this is the first time I've ever heard this. How long ago did this happen?
        pferde 7y ago
        Sometimes between August and September, and it was on Suse Linux Enterprise Server 12. The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.
      - newnewpdro 7y ago
        Filtering journal contents by metadata is known to be unreliable. It's not that the logs are missing, it's that they're not getting included by your query. The way journald associates log lines with process metadata is inherently racy. This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.
        7y ago
  - ibotty 7y ago
    You do still _use_ rsyslogd if you enable it. journald is fundamental to some core systemd functionality. Of course you can't get rid of it.
    - newnewpdro 7y ago
      Right, which just turns rsyslogd into another consumer of the journal data analogous to `journalctl --follow --all`. You still have all the overhead (and surface area) of journald being in the loop of everything logged. Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged. If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.
      - bonzini 7y ago
        > If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1. I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
      - ibotty 7y ago
        It also gets back logs from journald! How do you envision `systemctl status $unit` to show the last logs if they are in some random log file?
        7y ago
- evil-olive 7y ago
  Yes, certainly the ability to use other options is still there. But one of the main selling points of systemd (and one that the GP comment was extolling) was the consistency of systemd. And you can't have it both ways - is it great because it's a consistent, cohesive system that provides everything you need for a Linux system, or is it great because it's a modular toolkit that allows you to pick & choose which components to use? I was an Arch Linux user before, during, and after the systemd transition. I welcomed it initially, because pre-systemd Arch had a lot of "here's how to decide which logging daemon / cron daemon / etc to use" which I always thought was unnecessary. As I said, I think it's a great service manager. But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"; SNTP doesn't handle falsetickers well; and under dynamic Docker workloads systemd-timesyncd would decide "network configuration changed, better synchronize the clock" every time a Docker container started or restarted. If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? Each of those has no reason to have any sort of coupling to my service manager. My biggest quibble with stories like this one is that they keep focusing on the decision of systemd as service manager / init system rather than the umbrella of other jobs that the service manager has no good reason to try to take over.
  - brmgb 7y ago
    > And you can't have it both ways - is it great because it's a consistent, cohesive system that provides everything you need for a Linux system, or is it great because it's a modular toolkit that allows you to pick & choose which components to use? You absolutely can have it both way. Systemd is great because it offers a set of tools which are consistent, provide a lot of the functionality you want on a workstation in a cohesive way. It doesn't prevent you from choosing not to use one of the components developed under the project umbrella and uses something different instead. Systemd is modular enough for you to do that. > But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough" Why are you using timesyncd if you need more than SNTP ? Timesyncd is not shipped by default with the systemd init system. It is not even installed by default on RHEL. Nothing prevents you from using a different NTP client with the systemd init system. > If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? It does not imply that at all. You absolutely do not have to use the boot loader, timesyncd, networkd and nspawn with systemd. They are not even installed by default on some distributions. They are not coupled to the service manager.
kresten 7y ago
Yep agreed - solid assessment. Apart from networking. That’s an f*ing mess without systemd.
- isodude 7y ago
  Been trying out systemd-networkd for a couple of years now and it is a mess. Especially when you want to do something like ipsec/vpn/vxlan. Also, no possible way to reload a specific interface?
  - brmgb 7y ago
    > Especially when you want to do something like ipsec/vpn/vxlan. I have a wireguard tunnel setup by networkd with custom rules to only send traffic from a slice through it. It works fine. Take a look at the netdev documentation [1]. What are you trying to do exactly ? [1] https://www.freedesktop.org/software/systemd/man/systemd.netdev.html https://www.freedesktop.org/software/systemd/man/systemd.net...
    - isodude 7y ago
      The problem is rather how the troubleshooting works. You don't know how the network will be parsed or which statements that works with your version. Very difficult to debug when it doesn't behave as it should. After a lot of fiddling with source routing on e.g. Debian Strech I was able to something working. But only half of the times I restarted networkd. I would like some better tooling to assist with more difficult setups.
      - pas 7y ago
        Hm, Stretch has an old version, no? Or do you use a backport repo? But, yes, turning on debug mode is harder than it should be, and it's usually not the right level. (I usually just go for strace first, but with netdev I guess it's using netlink to talk to the kernel, so that'll not help much :/ )
        7y ago
weinzierl 7y ago
What I always wondered is: Why is a lot of the discussion about systemd vs initd when systemd is so many things. And the follow-up question would be: Why hasn't anyone taken apart systemd and reused only the parts they found useful, like the system manager for example. "Systemd: The Good Parts", so to speak.
- kick 7y ago
  The article literally gives an example of people doing that with elogind (though dbus isn't good, it's just necessary for certain software to work).
- blihp 7y ago
  That is pretty much the issue: to some, systemd is too many things. Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
  - bonzini 7y ago
    > picking and choosing pieces of it is far more work than a typical package maintainer takes on. Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
    - aerique 7y ago
      The article mentions that Debian does not have these "embrace, extend" problems yet because they've been using a fairly old version of SystemD, but they are going to run into those issues when they upgrade.
      - bkor 7y ago
        The distribution I use uses a much newer version of systemd. There still isn't any issue not using things mentioned like e.g. networkd and so on.
Ace17 7y ago
We haven't seen anything yet. Wait until PulseAudio is merged into System-D.
- geofft 7y ago
  I've been waiting for almost a decade now. In the meantime I've run systemd in production on thousands of servers (with no audio card) at multiple jobs. How much longer should I wait for horrible things to happen, or can I safely assume that they're not happening?
  - yc12340 7y ago
    Is remotely exploitable (!) CVE in systemd [1] not horrible enough? Or accidentally bricking computers at hardware level [2]? 1: https://nvd.nist.gov/vuln/detail/CVE-2018-15688 https://nvd.nist.gov/vuln/detail/CVE-2018-15688 2: https://lwn.net/Articles/674940/ https://lwn.net/Articles/674940/
    - diffeomorphism 7y ago
      That is a vulnerability in networkd, not in the init system. If you want to count like this you might as well speak of vulnerabilities in GNU. From the second link you posted: > None of that completely ended the systemd squawking, but it was clear to most that the real problem lies in the UEFI implementation. So I am not sure what you hoped to prove here.
    - rrix2 7y ago
      I had no idea that code vulnerability and bugs was a thing lennart invented, too!
    - mathw 7y ago
      Like no other system software ever had a CVE.
    - geofft 7y ago
      You're moving the goalposts. I was supposed to be horrified at bad things like PulseAudio being merged in, not vague bad things in general. If anything, the fact that none of these servers use networkd nor (until very recently, well after that bug was fixed) UEFI is a sign that in fact systemd isn't a giant glob and I can pick and choose components. So, bring on the PulseAudio merge, if it's anything like networkd I have nothing to fear.
nurettin 7y ago
systemd is a dependency graph solution. If you have to know "when network is available" or "when time is synchronized", your init system has to know about these events and that is why I imagine they coupled network and time services. Could it have been done any differently? Perhaps. Would it require more moving parts? Definitely.
- de_watcher 7y ago
  Dependency graph is a tiny part of one of the programs. systemd now is something like all except kernel, DE and applications. It's not clear.
  - dTal 7y ago
    systemd is a distro. I imagine it would have been a heck of a lot less controversial if it had been upfront about that, instead of stealthing into other distros as an 'init system' and then consuming them from the inside like a chestburster from Alien (1979)
- iforgotpassword 7y ago
  Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is. But that would require systemd folks to spend time and effort on thinking about how to integrate existing software into their ecosystem, so they rather roll their own, which obviously takes much more time in total, but it fits the general NIH attitude of the whole project. Oh and it gives them the opportunity to repeat every mistake ever made regarding writing DHCP/NTP/... clients made during the past thirty years, plus some bonus RCEs.
  - mateuszf 7y ago
    > Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is. So you're advocating making systemd even bigger and dependent on more stuff?
mike_hock 7y ago
> At a certain point "systemd" becomes a brand more than anything else Bingo, so what's the problem? Except for the timer/cron functionality, everything else you listed is separate software that just comes from the systemd brand.
arianvanp 7y ago
Service manager and container spawner is the same thing. So yes. The whole insight of systemd is that the cgroup tree can be used for service management. It was a container manager before container management was even a thing. (Including private mount namespaces, network namespaces, all that shebang) Systemd-nspawn contains no new code; just calls existing systemd library code. It gives people a familiar image based interface for a small cost in terms of lines of code. Bootloader i have a less strong argument for but at least it allows them to iterate in hopefully-standards-soon. Also systemd-boot is not an UEFI implementation. I'm not sure where you read that. It's an extremely small UEFI executable that lists a list of boot entries. (Note that an UEFI executable is just a Windows .EXE file). UEFI itself has more lines of code than the Linux kernel, replacing it would be insane (though very noble. See coreboot and Linuxboot projects). One argument is that it allows them to iterate on standards like the following: https://systemd.io/BOOT_LOADER_INTERFACE.html https://systemd.io/BOOT_LOADER_INTERFACE.html And https://systemd.io/BOOT_LOADER_SPECIFICATION.html https://systemd.io/BOOT_LOADER_SPECIFICATION.html And https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html
DCKing 7y ago
Well that's why it's modular. Let's examine the biggest systemd cool aid drinkers, Red Hat. Fedora 31 comes with NetworkManager and no systemd-networkd by default. It doesn't come with systemd-boot. You have to manually install systemd-nspawn. All of this is true on RHEL/CentOS too. With systemd being able to do a lot, doesn't mean it actually does a lot in practice - not yet at least. On Debian, systemd similarily basically only takes care of service and timer management (and cron is still available on all systems). I guess it does NTP too, I don't really spend much time thinking about my NTP client. Yes, systemd is a brand. But just like you don't have to eat every burger at McDonald's, you can choose what works for you.
MertsA 7y ago
How is the systemd project any different in that respect than the GNU project, or FreeBSD? If you don't want systemd-boot, or systemd-networkd, or literally anything other than core systemd and the journal you don't even have to build it, let alone install and run it. The only part of systemd other than core init that you have to run is the journal and even then you can configure the journal to just forward to rsyslog and not store any logs even just in tmpfs. Stuff like systemd-nspawn wasn't even developed to be a container management solution. IIRC the main goal was just to leverage the existing namespacing features in core systemd to allow booting up a minimalistic container in order to make developing systemd easier.
eeZah7Ux 7y ago
> Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives. That's one thing where it's way better.

freedomben 7y ago

Many of those things are not all or nothing. For example you can use chrony with systemd. RHEL 8 does that by default. You can even install rsyslog to consume logs if you want, and it works just fine. I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.

newnewpdro 7y ago
You can't replace journald with rsyslog. You can use rsyslog in addition to journald, but there's no way to get journald out of the picture - it's intertwined with the service manager.
- freedomben 7y ago
  Yes, sorry if what I wrote was misleading. You can't replace journald with rsyslog, but the only complaints I hear about journald are that it's binary so you have to use journalctl to read them. By installing rsyslog you basically get the classic log behavior back. So technically under the hood you're still using journald, but you never have to know it.
  - pferde 7y ago
    My main complaint is that journald is unreliable and is losing log entries (or lines, if you will). I had an automation recipe that would start a bunch of cloud instances, configure them and start certain job via a systemd service unit, and collect logs from this job 24 hours later. Initially, we were pulling these logs via journald as logs for that service unit. But then we noticed that random lines (1-5 lines out of maybe 40 for a single job) would be missing in about half the instances. We ended up pulling those logs from files in /var/log instead, made courtesy of rsyslog. Not a single missed line. Again journald is unreliable and as a whole should be nuked from the orbit.
    - freedomben 7y ago
      Interesting, this is the first time I've ever heard this. How long ago did this happen?
      - pferde 7y ago
        Sometimes between August and September, and it was on Suse Linux Enterprise Server 12. The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.
    - newnewpdro 7y ago
      Filtering journal contents by metadata is known to be unreliable. It's not that the logs are missing, it's that they're not getting included by your query. The way journald associates log lines with process metadata is inherently racy. This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.
      - 7y ago
- ibotty 7y ago
  You do still _use_ rsyslogd if you enable it. journald is fundamental to some core systemd functionality. Of course you can't get rid of it.
  - newnewpdro 7y ago
    Right, which just turns rsyslogd into another consumer of the journal data analogous to `journalctl --follow --all`. You still have all the overhead (and surface area) of journald being in the loop of everything logged. Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged. If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.
    - bonzini 7y ago
      > If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s. Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1. I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
    - ibotty 7y ago
      It also gets back logs from journald! How do you envision `systemctl status $unit` to show the last logs if they are in some random log file?
      - 7y ago
evil-olive 7y ago
Yes, certainly the ability to use other options is still there. But one of the main selling points of systemd (and one that the GP comment was extolling) was the consistency of systemd. And you can't have it both ways - is it great because it's a consistent, cohesive system that provides everything you need for a Linux system, or is it great because it's a modular toolkit that allows you to pick & choose which components to use? I was an Arch Linux user before, during, and after the systemd transition. I welcomed it initially, because pre-systemd Arch had a lot of "here's how to decide which logging daemon / cron daemon / etc to use" which I always thought was unnecessary. As I said, I think it's a great service manager. But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"; SNTP doesn't handle falsetickers well; and under dynamic Docker workloads systemd-timesyncd would decide "network configuration changed, better synchronize the clock" every time a Docker container started or restarted. If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? Each of those has no reason to have any sort of coupling to my service manager. My biggest quibble with stories like this one is that they keep focusing on the decision of systemd as service manager / init system rather than the umbrella of other jobs that the service manager has no good reason to try to take over.
- brmgb 7y ago
  > And you can't have it both ways - is it great because it's a consistent, cohesive system that provides everything you need for a Linux system, or is it great because it's a modular toolkit that allows you to pick & choose which components to use? You absolutely can have it both way. Systemd is great because it offers a set of tools which are consistent, provide a lot of the functionality you want on a workstation in a cohesive way. It doesn't prevent you from choosing not to use one of the components developed under the project umbrella and uses something different instead. Systemd is modular enough for you to do that. > But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough" Why are you using timesyncd if you need more than SNTP ? Timesyncd is not shipped by default with the systemd init system. It is not even installed by default on RHEL. Nothing prevents you from using a different NTP client with the systemd init system. > If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? It does not imply that at all. You absolutely do not have to use the boot loader, timesyncd, networkd and nspawn with systemd. They are not even installed by default on some distributions. They are not coupled to the service manager.

kresten 7y ago

Yep agreed - solid assessment. Apart from networking. That’s an f*ing mess without systemd.

isodude 7y ago
Been trying out systemd-networkd for a couple of years now and it is a mess. Especially when you want to do something like ipsec/vpn/vxlan. Also, no possible way to reload a specific interface?
- brmgb 7y ago
  > Especially when you want to do something like ipsec/vpn/vxlan. I have a wireguard tunnel setup by networkd with custom rules to only send traffic from a slice through it. It works fine. Take a look at the netdev documentation [1]. What are you trying to do exactly ? [1] https://www.freedesktop.org/software/systemd/man/systemd.netdev.html https://www.freedesktop.org/software/systemd/man/systemd.net...
  - isodude 7y ago
    The problem is rather how the troubleshooting works. You don't know how the network will be parsed or which statements that works with your version. Very difficult to debug when it doesn't behave as it should. After a lot of fiddling with source routing on e.g. Debian Strech I was able to something working. But only half of the times I restarted networkd. I would like some better tooling to assist with more difficult setups.
    - pas 7y ago
      Hm, Stretch has an old version, no? Or do you use a backport repo? But, yes, turning on debug mode is harder than it should be, and it's usually not the right level. (I usually just go for strace first, but with netdev I guess it's using netlink to talk to the kernel, so that'll not help much :/ )
      - 7y ago

weinzierl 7y ago

What I always wondered is: Why is a lot of the discussion about systemd vs initd when systemd is so many things. And the follow-up question would be: Why hasn't anyone taken apart systemd and reused only the parts they found useful, like the system manager for example. "Systemd: The Good Parts", so to speak.

kick 7y ago
The article literally gives an example of people doing that with elogind (though dbus isn't good, it's just necessary for certain software to work).
blihp 7y ago
That is pretty much the issue: to some, systemd is too many things. Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
- bonzini 7y ago
  > picking and choosing pieces of it is far more work than a typical package maintainer takes on. Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
  - aerique 7y ago
    The article mentions that Debian does not have these "embrace, extend" problems yet because they've been using a fairly old version of SystemD, but they are going to run into those issues when they upgrade.
    - bkor 7y ago
      The distribution I use uses a much newer version of systemd. There still isn't any issue not using things mentioned like e.g. networkd and so on.

Ace17 7y ago

We haven't seen anything yet. Wait until PulseAudio is merged into System-D.

geofft 7y ago
I've been waiting for almost a decade now. In the meantime I've run systemd in production on thousands of servers (with no audio card) at multiple jobs. How much longer should I wait for horrible things to happen, or can I safely assume that they're not happening?
- yc12340 7y ago
  Is remotely exploitable (!) CVE in systemd [1] not horrible enough? Or accidentally bricking computers at hardware level [2]? 1: https://nvd.nist.gov/vuln/detail/CVE-2018-15688 https://nvd.nist.gov/vuln/detail/CVE-2018-15688 2: https://lwn.net/Articles/674940/ https://lwn.net/Articles/674940/
  - diffeomorphism 7y ago
    That is a vulnerability in networkd, not in the init system. If you want to count like this you might as well speak of vulnerabilities in GNU. From the second link you posted: > None of that completely ended the systemd squawking, but it was clear to most that the real problem lies in the UEFI implementation. So I am not sure what you hoped to prove here.
  - rrix2 7y ago
    I had no idea that code vulnerability and bugs was a thing lennart invented, too!
  - mathw 7y ago
    Like no other system software ever had a CVE.
  - geofft 7y ago
    You're moving the goalposts. I was supposed to be horrified at bad things like PulseAudio being merged in, not vague bad things in general. If anything, the fact that none of these servers use networkd nor (until very recently, well after that bug was fixed) UEFI is a sign that in fact systemd isn't a giant glob and I can pick and choose components. So, bring on the PulseAudio merge, if it's anything like networkd I have nothing to fear.

nurettin 7y ago

systemd is a dependency graph solution. If you have to know "when network is available" or "when time is synchronized", your init system has to know about these events and that is why I imagine they coupled network and time services. Could it have been done any differently? Perhaps. Would it require more moving parts? Definitely.

de_watcher 7y ago
Dependency graph is a tiny part of one of the programs. systemd now is something like all except kernel, DE and applications. It's not clear.
- dTal 7y ago
  systemd is a distro. I imagine it would have been a heck of a lot less controversial if it had been upfront about that, instead of stealthing into other distros as an 'init system' and then consuming them from the inside like a chestburster from Alien (1979)
iforgotpassword 7y ago
Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is. But that would require systemd folks to spend time and effort on thinking about how to integrate existing software into their ecosystem, so they rather roll their own, which obviously takes much more time in total, but it fits the general NIH attitude of the whole project. Oh and it gives them the opportunity to repeat every mistake ever made regarding writing DHCP/NTP/... clients made during the past thirty years, plus some bonus RCEs.
- mateuszf 7y ago
  > Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is. So you're advocating making systemd even bigger and dependent on more stuff?

mike_hock 7y ago

> At a certain point "systemd" becomes a brand more than anything else Bingo, so what's the problem? Except for the timer/cron functionality, everything else you listed is separate software that just comes from the systemd brand.

arianvanp 7y ago

Service manager and container spawner is the same thing. So yes. The whole insight of systemd is that the cgroup tree can be used for service management. It was a container manager before container management was even a thing. (Including private mount namespaces, network namespaces, all that shebang) Systemd-nspawn contains no new code; just calls existing systemd library code. It gives people a familiar image based interface for a small cost in terms of lines of code. Bootloader i have a less strong argument for but at least it allows them to iterate in hopefully-standards-soon. Also systemd-boot is not an UEFI implementation. I'm not sure where you read that. It's an extremely small UEFI executable that lists a list of boot entries. (Note that an UEFI executable is just a Windows .EXE file). UEFI itself has more lines of code than the Linux kernel, replacing it would be insane (though very noble. See coreboot and Linuxboot projects). One argument is that it allows them to iterate on standards like the following: https://systemd.io/BOOT_LOADER_INTERFACE.html https://systemd.io/BOOT_LOADER_INTERFACE.html And https://systemd.io/BOOT_LOADER_SPECIFICATION.html https://systemd.io/BOOT_LOADER_SPECIFICATION.html And https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT.html

DCKing 7y ago

Well that's why it's modular. Let's examine the biggest systemd cool aid drinkers, Red Hat. Fedora 31 comes with NetworkManager and no systemd-networkd by default. It doesn't come with systemd-boot. You have to manually install systemd-nspawn. All of this is true on RHEL/CentOS too. With systemd being able to do a lot, doesn't mean it actually does a lot in practice - not yet at least. On Debian, systemd similarily basically only takes care of service and timer management (and cron is still available on all systems). I guess it does NTP too, I don't really spend much time thinking about my NTP client. Yes, systemd is a brand. But just like you don't have to eat every burger at McDonald's, you can choose what works for you.

MertsA 7y ago

How is the systemd project any different in that respect than the GNU project, or FreeBSD? If you don't want systemd-boot, or systemd-networkd, or literally anything other than core systemd and the journal you don't even have to build it, let alone install and run it. The only part of systemd other than core init that you have to run is the journal and even then you can configure the journal to just forward to rsyslog and not store any logs even just in tmpfs. Stuff like systemd-nspawn wasn't even developed to be a container management solution. IIRC the main goal was just to leverage the existing namespacing features in core systemd to allow booting up a minimalistic container in order to make developing systemd easier.

eeZah7Ux 7y ago

> Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives. That's one thing where it's way better.