3 ms·

Actually read the link. It reads like an OS change log. e.g. https://www.freebsd.org/releases/11.0R/relnotes/ https://www.freebsd.org/releases/11.0R/relnotes/

tyingq 6y ago
Seems like it would, given all the spaces it's in: systemd-networkd, systemd-resolved, systemd-timesyncd, systemd-udevd, systemd-journald, systemd-logind, systemd-nspawn, systemd-cron, systemd-notify, systemd-container, systemd-boot, systemd-oomd, systemd-mount, dbus, ...
- rektide 6y ago
  and there are good & healthy improvements to each of these subsystems. and oh good --json logging support is available everywhere. nice SYSTEMD_COLORS supports new 16 and 256 options for all these tools. my entire system will work much better. with high consistency. this whole monorepo (not monolith) thing is working out.
  - tyingq 6y ago
    It varies. Their sntp client steps time instead of skewing, for example.
    - fl0wenol 6y ago
      I thought that was because it's designed to only jump time once at bootup so that TLS/logging can be sane... so that an NTP client can take over starting at a close offset?
      - tyingq 6y ago
        No, it (systemd-timesyncd) runs as a daemon with settable poll intervals, etc.
    - aarmenaa 6y ago
      systemd-timesyncd is an SNTP client; that's what an SNTP client does. For a lot of use cases, desktops and even most servers, it's perfectly fine and a whole lot less complex. I understand it's not a good fit in some cases; our standard server config disables all other NTP clients, systemd-timesyncd included, in favor of Chrony because we are concerned about highly accurate system clocks and slewing. Interestingly, it appears that systemd has some sort of provisions for this. The `timedatectl` command still works and reports that NTP is enabled and synchronized.
      - tyingq 6y ago
        "that's what an SNTP client does" How so? Compare what msntp does to adjust the time with what systemd-timesync does. Though msntp does have an "immediate" option if you want to be abrupt.

tyingq 6y ago

Seems like it would, given all the spaces it's in: systemd-networkd, systemd-resolved, systemd-timesyncd, systemd-udevd, systemd-journald, systemd-logind, systemd-nspawn, systemd-cron, systemd-notify, systemd-container, systemd-boot, systemd-oomd, systemd-mount, dbus, ...

rektide 6y ago
and there are good & healthy improvements to each of these subsystems. and oh good --json logging support is available everywhere. nice SYSTEMD_COLORS supports new 16 and 256 options for all these tools. my entire system will work much better. with high consistency. this whole monorepo (not monolith) thing is working out.
- tyingq 6y ago
  It varies. Their sntp client steps time instead of skewing, for example.
  - fl0wenol 6y ago
    I thought that was because it's designed to only jump time once at bootup so that TLS/logging can be sane... so that an NTP client can take over starting at a close offset?
    - tyingq 6y ago
      No, it (systemd-timesyncd) runs as a daemon with settable poll intervals, etc.
  - aarmenaa 6y ago
    systemd-timesyncd is an SNTP client; that's what an SNTP client does. For a lot of use cases, desktops and even most servers, it's perfectly fine and a whole lot less complex. I understand it's not a good fit in some cases; our standard server config disables all other NTP clients, systemd-timesyncd included, in favor of Chrony because we are concerned about highly accurate system clocks and slewing. Interestingly, it appears that systemd has some sort of provisions for this. The `timedatectl` command still works and reports that NTP is enabled and synchronized.
    - tyingq 6y ago
      "that's what an SNTP client does" How so? Compare what msntp does to adjust the time with what systemd-timesync does. Though msntp does have an "immediate" option if you want to be abrupt.