Ntpd-rs: it's about time
discourse.ubuntu.comUbuntu's rollout of a Rust-based coreutils replacement had a bug [0] that, among other things, broke automatic updates.
and the bug was...not subtle, either. it just silently ignored the documented behavior of `date -r` (printing the modtime of a file) [1, 2]
as a time synchronization nerd, I've been following ntpd-rs's development, and tested it out as a possible replacement for Chrony. my overall impression is that like rust-coreutils, it's a well-intentioned project but not ready for prime-time, certainly not at the level of "installed by default on Ubuntu" (even in a non-LTS release)
for example, there's an issue that's been open for ~9 months about logging being unnecessarily verbose, and flooding the system journal [3].
and an issue titled "implement new algorithm" opened by one of the core contributors, with zero description or details [4].
these are not the hallmarks of a stable, mature open-source project.
0: https://lwn.net/Articles/1043103/
1: https://news.ycombinator.com/item?id=45687743
2: https://news.ycombinator.com/item?id=45688185
I count 132 packages in cargo.lock.
chrony has some dependencies too but for important optional features like seccomp or capability dropping that I don't think ntpd-rs even implements...
In upcoming releases, Ubuntu will be adopting ntpd-rs as the default time synchronization client and server, eventually replacing chrony, linuxptp and with any luck, gpsd for time syncing use-cases.
Can they not rewrite all the other daemons in Rust as well? I would rather keep using Chrony on all the Linux distributions that I use.
Just because something's written in rust doesn't make it memory safe. Rust programmers are no smarter than c programmers and cannot be trusted to write unsafe code, and rust doesn't stop you from writing unsafe code. Tell me what part of that is untrue
Not GPL, not interested in replacing chrony