On 2026-08-30 06:10 -04:00 EDT, "Warner Losh" <[email protected]> wrote: > On Sat, Aug 29, 2026, 9:57 AM Alexander Ziaee <[email protected]> wrote: > >> On 2026-08-29 11:22 -04:00 EDT, "Dag-Erling Smørgrav" <[email protected]> >> wrote: >> > Alexander Ziaee <[email protected]> writes: >> >> + msyslog(LOG_NOTICE,"ntpdate is deprecated and " >> >> + "scheduled for removal in ntp 4.4, use ntpd -q instead"); >> > >> > Are you also going to fix libexec/rc/rc.d/ntpdate to run ntpd -q instead >> > of ntpdate? If not, please revert. >> >> Why? IIUC that is the legacy script, and bsdinstall is offering >> ntpd_sync_on_start for a few years now [0] instead in line with this >> advice. Also, ntpdate is scheduled for removal upstream. >> > > Only for the last 20 years... I'll believe it when it actually happens. > > Seems to me we should add a warning to rc.d/ntpdate instead >> suggesting that operators switch to ntpd_sync_on_start? >> > > Doesn't that assume you are running ntpd? Far too many people just set the > time and freewheel.
Sure, but my point is that we stopped offering and advertising ntpdate in the installer 4 years ago, because it's deprecated, and the manpage says not to use it, and we offer another service that upstream wants us to use instead. No supported FreeBSD release branch has offered ntpdate in it's installer. > And didn't I leave feedback changing vendor code here wasn't worth it? No, had we got any negative feedback I would have stopped. https://reviews.freebsd.org/D55929 Again, I'm not unwilling to rollback, or to patch ntpdate, I'm just asking why. 1. Everything in the ecosystem from our installer to our doc to our upstream says ntpdate is long deprecated legacy stuff. 2. Usually when we have something, and we silently remove it from new installations but keep it, and provide a new one instead, then we're not supposed to change the old thing. I can patch it if that's what we want to do, I'm just missing context. > [0]: c153a35bfd716fd74e4b3955cc60541b78ab3d8e ("bsdinstall: replace ntpdate >> by ntpd_sync_on_start") Best, Alex
