4 ms·

I definitely understand that criticism w.r.t. all of the systemd-verse replacement tools. I'm not an expert. I'm just a software dev and free software nut who

I definitely understand that criticism w.r.t. all of the systemd-verse replacement tools. I'm not an expert. I'm just a software dev and free software nut who wants a free software OS. But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? You say, disparagingly, that it is tightly-coupled and opaque (binary). Why is loosely coupled better in these cases specifically? Weren't `mount`, `ntpd`, `udev`, etc all compiled C code already? How does systmed make those service more opaque? Everyone seems to hate journald. I'll go ahead and join in the chorus and say that it sounds really bad. But do we have to throw the baby out with the bath water? What else about systemd is actually worse than what we had before?

throw0101a 6y ago
> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. But it stood on its own merits, was able to mature over time, and when people thought it good, they could willing start using it (or not). > Everyone seems to hate journald. I'll go ahead and join in the chorus and say that it sounds really bad. But do we have to throw the baby out with the bath water? And that is exactly my point about things being tightly-coupled. If I (rightly or wrongly) perceive journald to be garbage, how do I not-use it?
- tkfu 6y ago
  > What does a time system have to with system start infrastructure? Accurate time is vital for many cryptographic operations. For example, in the embedded space you may want to have a check that your current disk image (ideally checked by dm-verity) is actually up to date. And to verify the metadata signing that disk image using Uptane/TUF/SUIT or similar protocols you need verifiable time. Or you might need to contact a provisioning server at boot time, and need to be able to verify that server's TLS cert. (Now, systemd used to have a bug[1] where time-sync.target would be reached before time was actually synced, and Poettering's response to the bug was the all-too-typical typical "yeah, don't worry about it, it's intended behaviour that the time-sync target doesn't mean that time is synced"[2]. But that did get fixed a couple years ago [3].) [1] https://github.com/systemd/systemd/issues/5097 https://github.com/systemd/systemd/issues/5097 [2] https://github.com/systemd/systemd/issues/5097#issuecomment-276787961 https://github.com/systemd/systemd/issues/5097#issuecomment-... [3] https://github.com/systemd/systemd/pull/8494 https://github.com/systemd/systemd/pull/8494
  - admax88q 6y ago
    Thats a pretty uncharitable take on what Poettering said. IMO hes right that in many cases you dont want to hold up booting on whether or not time has been synced. I dont want my desktop, or most servers to not boot if the network or NTP server is down. He also suggests what they can add for people who want this behaviour. Oh woe is me that systemd does not support my use case of an embedded system needing to verify disk image with accurate time before booting further, as the _default_.
- growse 6y ago
  > > But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. Nothing, but you're making the common mistake of thinking that systemd is an init system. It isn't. It's a suite of components that more or less can be enabled independently, that no-one's forcing anyone to use. One of these components is an init. Another one in a time sync daemon, etc. etc. Chrony's great, but if you don't need most of its pretty advanced features, why bother? A simpler, smaller, 'good enough' client might be more suitable. Isn't software choice a good thing?
  - throw0101a 6y ago
    > Isn't software choice a good thing? Yes, but tightly coupling can reduce the ability to make a choice.
    - growse 6y ago
      I'm not sure how that's true in this case. I personally need the features of chrony, so despite running debian stable / systemd everywhere, I just turn systemd-timesyncd off. Tight coupling would be "you can't boot your system unless you use this time sync daemon implementation".
      - dane-pgp 6y ago
        There are definitely degrees of freedom, and I wonder if it would make sense to extend the Free Software Definition[0] backwards further by adding: * The freedom to not run any program you do not wish to run, for any reason (freedom -1). Presumably Stallman would agree that government-mandated spyware which happened to be GPL licensed would not really be granting users much freedom. The tight coupling of "you can't boot your system unless you use this time sync daemon implementation" might also count as a violation of this hypothetical freedom. Applying this to systemd is more complicated though. I'm sure some people would say "Well it's released under a Free Software licence so you can remove or replace any part of the code you don't want.", but that seems almost as unhelpful as saying "Microsoft Windows is Free Software because you can always create a clean-room reimplementation of it". [0] https://en.wikipedia.org/wiki/The_Free_Software_Definition https://en.wikipedia.org/wiki/The_Free_Software_Definition
- ragnese 6y ago
  >> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > >What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. > >But it stood on its own merits, was able to mature over time, and when people thought it good, they could willing start using it (or not). But my question was why does this matter? As far as I know, you don't have to use systemd's ntp thing. You might disagree with the project vision of systemd wanting to include an ntp daemon, but it sounds like it hasn't cause you or the chrony people any real harm. There was a good chance that, if systemd didn't have an ntp daemon, you'd have to replace your distro's default with chrony anyway. So just do that here, too, no? > And that is exactly my point about things being tightly-coupled. If I (rightly or wrongly) perceive journald to be garbage, how do I not-use it? You can't, AFAIK. And that sucks. I know you can disable its on-disk logs and enabled some other syslog service, though. In what way(s) is that insufficient? Are there any other example of tight coupling that are bothersome in systemd?
Blikkentrekker 6y ago
> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > You say, disparagingly, that it is tightly-coupled and opaque (binary). > Why is loosely coupled better in these cases specifically? It creates extra work for others. udev is far older than systemd; maintainership of the former was eventually inherited by one the latter's lead maintainers, who decided to move the latter into the former, at first promising that the former, which has applications reaching far outside systemd, could still be built and used independently. That promise weakened after about two years and it became increasingly difficult to build and use udev without systemd; — some embedded systems that use udev can't even fit systemd into memory and thus using it is not an option. So, udev in response was forked to eudev by other developers who now have to spend time and money on maintaining this fork and porting udev changes to it. Loosely coupled is better because it allows one to be use without the other if there be such a need; tight coupling is essentially a form of product tying. Why is it better that one can use an iPhone on any computer? rather than only computers designed by Apple? > Everyone seems to hate journald. I'll go ahead and join in the chorus and say that it sounds really bad. But do we have to throw the baby out with the bath water? What else about systemd is actually worse than what we had before? Many call for logind to replace acpid; — I strongly object to this and the difference in functionality between both highlights well the difference in philosophy between traditional Unix design and Lennart's brand. acpid responds to acpi events by calling an executable file with a specific path; for instance `/etc/acpi/actions/powerbtn.sh` is called with arguments that describe the nature of the event when the power button is pressed. logind on the other hand simply allows for a limited list of I believe seven options in a configuration file of what to do when the power button is pressed, not an arbitrary file to be executed. The possibilities of acpid are obviously limitless, and I use them as such. My machine is configured such that when I close my notebook's lid, the machine does not suspend, but rather disables the screen and goes into power-safe mode, but otherwise continues to operate, I can override this behavior by simply creating the file `/run/lid.disable`. I cannot configure my machine to be so flexible with logind which highlights the difference in culture: Traditional Unix design was always about removing restrictions, and this is about providing features, but when the feature one seeks not be provided, then one is out of luck.

throw0101a 6y ago

> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. But it stood on its own merits, was able to mature over time, and when people thought it good, they could willing start using it (or not). > Everyone seems to hate journald. I'll go ahead and join in the chorus and say that it sounds really bad. But do we have to throw the baby out with the bath water? And that is exactly my point about things being tightly-coupled. If I (rightly or wrongly) perceive journald to be garbage, how do I not-use it?

tkfu 6y ago
> What does a time system have to with system start infrastructure? Accurate time is vital for many cryptographic operations. For example, in the embedded space you may want to have a check that your current disk image (ideally checked by dm-verity) is actually up to date. And to verify the metadata signing that disk image using Uptane/TUF/SUIT or similar protocols you need verifiable time. Or you might need to contact a provisioning server at boot time, and need to be able to verify that server's TLS cert. (Now, systemd used to have a bug[1] where time-sync.target would be reached before time was actually synced, and Poettering's response to the bug was the all-too-typical typical "yeah, don't worry about it, it's intended behaviour that the time-sync target doesn't mean that time is synced"[2]. But that did get fixed a couple years ago [3].) [1] https://github.com/systemd/systemd/issues/5097 https://github.com/systemd/systemd/issues/5097 [2] https://github.com/systemd/systemd/issues/5097#issuecomment-276787961 https://github.com/systemd/systemd/issues/5097#issuecomment-... [3] https://github.com/systemd/systemd/pull/8494 https://github.com/systemd/systemd/pull/8494
- admax88q 6y ago
  Thats a pretty uncharitable take on what Poettering said. IMO hes right that in many cases you dont want to hold up booting on whether or not time has been synced. I dont want my desktop, or most servers to not boot if the network or NTP server is down. He also suggests what they can add for people who want this behaviour. Oh woe is me that systemd does not support my use case of an embedded system needing to verify disk image with accurate time before booting further, as the _default_.
growse 6y ago
> > But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. Nothing, but you're making the common mistake of thinking that systemd is an init system. It isn't. It's a suite of components that more or less can be enabled independently, that no-one's forcing anyone to use. One of these components is an init. Another one in a time sync daemon, etc. etc. Chrony's great, but if you don't need most of its pretty advanced features, why bother? A simpler, smaller, 'good enough' client might be more suitable. Isn't software choice a good thing?
- throw0101a 6y ago
  > Isn't software choice a good thing? Yes, but tightly coupling can reduce the ability to make a choice.
  - growse 6y ago
    I'm not sure how that's true in this case. I personally need the features of chrony, so despite running debian stable / systemd everywhere, I just turn systemd-timesyncd off. Tight coupling would be "you can't boot your system unless you use this time sync daemon implementation".
    - dane-pgp 6y ago
      There are definitely degrees of freedom, and I wonder if it would make sense to extend the Free Software Definition[0] backwards further by adding: * The freedom to not run any program you do not wish to run, for any reason (freedom -1). Presumably Stallman would agree that government-mandated spyware which happened to be GPL licensed would not really be granting users much freedom. The tight coupling of "you can't boot your system unless you use this time sync daemon implementation" might also count as a violation of this hypothetical freedom. Applying this to systemd is more complicated though. I'm sure some people would say "Well it's released under a Free Software licence so you can remove or replace any part of the code you don't want.", but that seems almost as unhelpful as saying "Microsoft Windows is Free Software because you can always create a clean-room reimplementation of it". [0] https://en.wikipedia.org/wiki/The_Free_Software_Definition https://en.wikipedia.org/wiki/The_Free_Software_Definition
ragnese 6y ago
>> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > >What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. > >But it stood on its own merits, was able to mature over time, and when people thought it good, they could willing start using it (or not). But my question was why does this matter? As far as I know, you don't have to use systemd's ntp thing. You might disagree with the project vision of systemd wanting to include an ntp daemon, but it sounds like it hasn't cause you or the chrony people any real harm. There was a good chance that, if systemd didn't have an ntp daemon, you'd have to replace your distro's default with chrony anyway. So just do that here, too, no? > And that is exactly my point about things being tightly-coupled. If I (rightly or wrongly) perceive journald to be garbage, how do I not-use it? You can't, AFAIK. And that sucks. I know you can disable its on-disk logs and enabled some other syslog service, though. In what way(s) is that insufficient? Are there any other example of tight coupling that are bothersome in systemd?

Blikkentrekker 6y ago

> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > You say, disparagingly, that it is tightly-coupled and opaque (binary). > Why is loosely coupled better in these cases specifically? It creates extra work for others. udev is far older than systemd; maintainership of the former was eventually inherited by one the latter's lead maintainers, who decided to move the latter into the former, at first promising that the former, which has applications reaching far outside systemd, could still be built and used independently. That promise weakened after about two years and it became increasingly difficult to build and use udev without systemd; — some embedded systems that use udev can't even fit systemd into memory and thus using it is not an option. So, udev in response was forked to eudev by other developers who now have to spend time and money on maintaining this fork and porting udev changes to it. Loosely coupled is better because it allows one to be use without the other if there be such a need; tight coupling is essentially a form of product tying. Why is it better that one can use an iPhone on any computer? rather than only computers designed by Apple? > Everyone seems to hate journald. I'll go ahead and join in the chorus and say that it sounds really bad. But do we have to throw the baby out with the bath water? What else about systemd is actually worse than what we had before? Many call for logind to replace acpid; — I strongly object to this and the difference in functionality between both highlights well the difference in philosophy between traditional Unix design and Lennart's brand. acpid responds to acpi events by calling an executable file with a specific path; for instance `/etc/acpi/actions/powerbtn.sh` is called with arguments that describe the nature of the event when the power button is pressed. logind on the other hand simply allows for a limited list of I believe seven options in a configuration file of what to do when the power button is pressed, not an arbitrary file to be executed. The possibilities of acpid are obviously limitless, and I use them as such. My machine is configured such that when I close my notebook's lid, the machine does not suspend, but rather disables the screen and goes into power-safe mode, but otherwise continues to operate, I can override this behavior by simply creating the file `/run/lid.disable`. I cannot configure my machine to be so flexible with logind which highlights the difference in culture: Traditional Unix design was always about removing restrictions, and this is about providing features, but when the feature one seeks not be provided, then one is out of luck.