mlichvar

Maybe too many things are started from crontab. Public NTP servers observe large spikes in traffic on minute marks due to admins putting ntpdate in crontab instead of running a proper NTP service.

That's what the chrony tempcomp directive is for. But you would have to figure out the coefficients, it's not automatic.

An advantage of constantly loading at least one core of the CPU might be preventing the deeper power states from kicking in, which should make the RX timestamping latency more stable and improve stability of synchronization of NTP clients.

Current Debian, Ubuntu, Fedora, RHEL/CentOS (EPEL) have an ntpsec package, but no ntp package. It's not used by default (that's chrony on most of the distributions), but the users can install it and use it.

The major Linux distributions replaced ntp with ntpsec. A better question would be who is still running ntp. I know about FreeBSD and NetBSD.

ntpsec as a project seems to be doing ok. They are releasing new versions, fix reported issues, accept patches, and develop the code publicly. While ntp still has a huge list of acknowledged but unfixed CVEs.

chrony can be configured to encapsulate NTP messages in PTP messages (NTP over PTP) in order to get the delay corrections from switches working as one-step PTP transparent clocks. The current NTPv5 draft specifies an NTP-specific correction field, which switches could support in future if there was a demand for it.

The switches could also implement a proper HW-timestamping NTP server and client to provide an equivalent to a PTP boundary clock.

PTP was based on a broadcast/multicast model to reduce the message rate in order to simplify and reduce the cost of HW support. But that is no longer a concern with modern HW that can timestamp packets at very high rates, so the simpler unicast protocols like NTP and client-server PTP (CSPTP) currently developed by IEEE might be preferable to classic PTP for better security and other advantages.

On Fedora it is setgid screen, not root.

The Linux kernel keeps time as a 64-bit integer, but it's in nanoseconds, not seconds. It's a Y2262 problem.

Another way to look at it is that MIT gives freedom to the developers and GPL gives freedom to the users. It's a conflict between the two groups.

My current understanding of the wireless technologies wrt to home automation:

- wifi is most reliable, secure, easiest to debug, but usable only for mains-powered devices due to higher energy consumption

- bluetooth LE has lowest energy consumption, best for unreliable broadcasting of data (e.g. temperature sensors), but has shorter range

- zigbee is best for battery-powered devices where reliable communication is needed and is initiated by the device (e.g. switch, window/door sensor)

- zwave is best for battery-powered devices which need to quickly receive data (e.g. door lock or directly controller radiator valves), but security seems problematic according to some reports

Fuzzing needs to cover all important bits of the code to be useful. The problem I see is that incomplete coverage creates a false sense of security. Projects have some minimal fuzzing coverage (e.g. in oss-fuzz) and care less about quality of the code, thinking fuzzing will catch all security bugs.

Rust code needs proper fuzzing too. It takes a lot of effort to ensure everything is covered and stays covered as the code is developed. Crashing libraries or applications can be a denial of service. Sure, it's lower impact than an RCE due to a buffer overflow, but it is still a security issue.