On Wed, 2020-07-22 at 23:07 +0000, Jóhann B. Guðmundsson wrote:On 22.7.2020 20:39, Neal Gompa wrote:I do not see the benefit of using timesyncd over chrony. Arguably, chrony is a much better implementation and having a consistent time server choice across all variants makes life considerably easier for integration and management.? Timesyncd has a smaller foot-print and lower resource requirements, is part of the system management framework ( already installed ) and serves I would say majority of usecases out there which makes it a better distribution default since today distributions need to cater the entire spectrum ( embedded,cloud, containers, servers, desktop etc. ) and I think you are mistaken if you think that chrony is being used across all variants in Fedora ( I suspect that is an exception rather than a rule these days ).It's in at least the Cloud base image, KDE live install, Server DVD install, Silverblue DVD install and Workstation live install.
So it's not on IoT and CoreOS which also means we already have
experience of running timesyncd instead of Chrony in the
distribution which is good.
On top of that Chrony already has a conflict on timesyncd which means timesyncd stops when chrony has been installed and started.
Timesyncd also has lower priority against Chrony since it's already expected if people install Chrony it's being done on purpose so it's basically just a matter for the Workstation WG ( and others ) to decide to start using timesyncd instead of Chrony and remove it from it's package list.
And realistically speaking the use case for Chrony basically are that you are either running an ntp server or in an IT environment which requires sub-microsecond accurate time ( for example infrastructure at the size of FB ), environment's in which Fedora is seldom run in.
So using an already existing and installed service with smaller footprint makes more logical sense as a default across the spectrum as opposed to install additional component to server niche use cases for 1% of the consumers of the distribution which already have to configure the component for those use cases once the component has been installed.
JBG
_______________________________________________ desktop mailing list -- desktop@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to desktop-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx
