Hacker News Reader

Comment by throw0101a | Hacker News Reader

> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev?

What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it.

But it stood on its own merits, was able to mature over time, and when people thought it good, they could willing start using it (or not).

> Everyone seems to hate journald. I'll go ahead and join in the chorus and say that it sounds really bad. But do we have to throw the baby out with the bath water?

And that is exactly my point about things being tightly-coupled. If I (rightly or wrongly) perceive journald to be garbage, how do I not-use it?

View on HN

> What does a time system have to with system start infrastructure?

Accurate time is vital for many cryptographic operations. For example, in the embedded space you may want to have a check that your current disk image (ideally checked by dm-verity) is actually up to date. And to verify the metadata signing that disk image using Uptane/TUF/SUIT or similar protocols you need verifiable time. Or you might need to contact a provisioning server at boot time, and need to be able to verify that server's TLS cert.

(Now, systemd used to have a bug[1] where time-sync.target would be reached before time was actually synced, and Poettering's response to the bug was the all-too-typical typical "yeah, don't worry about it, it's intended behaviour that the time-sync target doesn't mean that time is synced"[2]. But that did get fixed a couple years ago [3].)

[1] https://github.com/systemd/systemd/issues/5097 [2] https://github.com/systemd/systemd/issues/5097#issuecomment-... [3] https://github.com/systemd/systemd/pull/8494

Thats a pretty uncharitable take on what Poettering said. IMO hes right that in many cases you dont want to hold up booting on whether or not time has been synced. I dont want my desktop, or most servers to not boot if the network or NTP server is down.

He also suggests what they can add for people who want this behaviour.

Oh woe is me that systemd does not support my use case of an embedded system needing to verify disk image with accurate time before booting further, as the _default_.

> > But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev?

> What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it.

Nothing, but you're making the common mistake of thinking that systemd is an init system. It isn't. It's a suite of components that more or less can be enabled independently, that no-one's forcing anyone to use. One of these components is an init. Another one in a time sync daemon, etc. etc.

Chrony's great, but if you don't need most of its pretty advanced features, why bother? A simpler, smaller, 'good enough' client might be more suitable.

Isn't software choice a good thing?

> Isn't software choice a good thing?

Yes, but tightly coupling can reduce the ability to make a choice.

I'm not sure how that's true in this case.

I personally need the features of chrony, so despite running debian stable / systemd everywhere, I just turn systemd-timesyncd off.

Tight coupling would be "you can't boot your system unless you use this time sync daemon implementation".

There are definitely degrees of freedom, and I wonder if it would make sense to extend the Free Software Definition[0] backwards further by adding:

* The freedom to not run any program you do not wish to run, for any reason (freedom -1).

Presumably Stallman would agree that government-mandated spyware which happened to be GPL licensed would not really be granting users much freedom. The tight coupling of "you can't boot your system unless you use this time sync daemon implementation" might also count as a violation of this hypothetical freedom.

Applying this to systemd is more complicated though. I'm sure some people would say "Well it's released under a Free Software licence so you can remove or replace any part of the code you don't want.", but that seems almost as unhelpful as saying "Microsoft Windows is Free Software because you can always create a clean-room reimplementation of it".

[0] https://en.wikipedia.org/wiki/The_Free_Software_Definition

>> But (serious question), why does it matter that systemd has an ntp daemon or that it subsumed udev? > >What does a time system have to with system start infrastructure? If you want to write a time daemon, write a time daemon: the chrony folks did, and it's pretty good. Lots of folks have switch away from the old school NTPd to it. > >But it stood on its own merits, was able to mature over time, and when people thought it good, they could willing start using it (or not).

But my question was why does this matter? As far as I know, you don't have to use systemd's ntp thing. You might disagree with the project vision of systemd wanting to include an ntp daemon, but it sounds like it hasn't cause you or the chrony people any real harm. There was a good chance that, if systemd didn't have an ntp daemon, you'd have to replace your distro's default with chrony anyway. So just do that here, too, no?

> And that is exactly my point about things being tightly-coupled. If I (rightly or wrongly) perceive journald to be garbage, how do I not-use it?

You can't, AFAIK. And that sucks. I know you can disable its on-disk logs and enabled some other syslog service, though. In what way(s) is that insufficient?

Are there any other example of tight coupling that are bothersome in systemd?

Reply on news.ycombinator.com