Linux: concerns over systemd adoption and Debian's decision to switch

Thu Oct 23 23:51:21 UTC 2014

On 10/23/14 4:01 PM, Simon Lyall wrote:
> On Wed, 22 Oct 2014, Stephen Satchell wrote:
>> On 10/22/2014 08:20 PM, Simon Lyall wrote:
>>> On Wed, 22 Oct 2014, Miles Fidelman wrote:
>>>> And maybe, you should check out some of the upstream bug reports re.
>>>> systemd interactions with NTP.
>>>
>>> If you think the current situation is all good then maybe you should
>>> look at other bugs for ntp. eg this one I that affected me with Ubuntu
>>> Disktop. They only run time syncing when the network is bounced so if
>>> you have a stable network then your machine will never sync:
>>>
>>> https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1178933
> [..]
>> I'm a long-time user of NTP, and what you are asking for is a no-good
>> way of doing things.  What you are supposed to do is use the ntpdate(8)
>> utility *ONCE* on boot to initially set the system clock, then you have
>> ntpd(8) running to do two things for you:  sync up to one or more time
>> sources, and discipline the local clock.
> [..]
>> That's the SERVER way of running a time synchronization.  So it would
>> appear that you have a quarrel with GUI support, not with NTP itself.
>
> What my point was is that the "simple default for end users" [1] is
> already significantly broken in Ubuntu (that is just one bug that bit
> me, there are plenty of others).
>
> The systemd system seems to offer and improvement on the existing
> "simple default" setup while still enabling experts to run a full ntpd
> install if they wish.
>
> [1] - I know how to setup and run ntpd, I didn't expect to need to do it
> on my workstation however.

If you are actually arguing that because Ubuntu made a mistake on how 
the "Internet time synchronization" option is configured, therefore we 
need systemd, you need to rethink your position. :)

FWIW, the problem you're describing with that option is real, and was 
revisited in later versions. As of 14.04 it was still broken, but for a 
different reason having to do with permissions on the ntpd install. 
However, fixing that problem doesn't require systemd, it requires fixing 
*that* problem.

I am not against systemd per se, I honestly don't know enough about it 
to form an intelligent opinion. The line of reasoning (I believe to be) 
espoused here is quite concerning, "If there is a problem, we need to 
bring the solution into systemd." To the extent that's accurate, it's 
overwhelmingly likely to be wrong.

I could say a lot more about Unix system design philosophies from my 
time in the FreeBSD project, but this thread started off-topic, and has 
only gotten worse. :)

Doug