Lennart: The State & Future Of Systemd

[varikonniemi]

They need first to fix their bugs! Unbelievable, even my CH Pedals don't work anymore in 14.04!

14.04 does not even use systemd, so the problem is not where you think it is.

[interested]

Why systemd-timesyncd will be better then ntpdate?

"systemd-timesyncd" is an extremely lightweight NTP client. Actually it is just a SNTP (Simple NTP) client. It works great for small embedded systems or massive and rapid deployment of Linux containers etc.

The use of "ntpdate" is actually discouraged by its main developer because of some inherent accuracy problems, so it has been deprecated for some time now.

More info here:

http://en.wikipedia.org/wiki/Ntpdate

[rob11311]

Why systemd-timesyncd will be better then ntpdate?

I think it must be the theory that providing a baseline of features, always present, makes it easier to write software.
On a low RAM machine, running from cron ntpdate or another time sync command daily to slew the system clock works quite well enough and uses less resources.

Personally I found this addition to systemd, rather tasteless and troubling; secondly what Lennart and Kay perceive as "pointless" differences may eliminate flexibility that could be key in future, as the "Internet of Things" is realised.

Thanks to the monolithic systemd, causing pid 1 to be linked with Dbus, I've had to reboot my Linux box more than Windows in last month The re-exec option, just didn't work and the insecure deleted Dbus lib was still mapped into systemd's memory space. This may be a choice of my distro, rather than a consequence of systemd, I have read Lennart somewhere saying systemd doesn't have to run as pid 1, I would like it not to, so sending a SIGHUP or something to pid 1, or killing systemd would have it auto restarted, solving the security update problem.

[rob11311]

The use of "ntpdate" is actually discouraged by its main developer because of some inherent accuracy problems, so it has been deprecated for some time now

But NTP is about accuracy of order <5ms, and generating very precise timestamps for scientific experiments. Normal usage to avoid intervention of admin to adjust system clocks and avoid clock skew in LAN, just don't need synchronisation that close about 200ms is good enough.

Why fork and include an NTP daemon, why not just provide integration with 3rd party projects? Why does Lennart & Kay, embrace ever more features rather than fix bugs?

[interested]

Slide 84:

"What we are working on:
Verifiable OS images
All the way to the firmware
Boot Loading"

That means likely modification prevention in embedded systems.

I don't think it is so specific. I think the user case is quite generic from embedded to desktop and servers. Looking at the previous slides and other systemd talks by Poettering, it is clear that they want a cryptographically verifiable /usr and order to have that they have to secure the crypto chain all the way from boot. It is unlikely that it is about tampering prevention since there already exist such solutions (TPM) that are effective, but a pain in the ass for end users.

[Calinou]

Or find broken Systemfiles but modification prevention is not a bad thing.

Such a thing must never be enabled by default.

[interested]

But NTP is about accuracy of order <5ms, and generating very precise timestamps for scientific experiments. Normal usage to avoid intervention of admin to adjust system clocks and avoid clock skew in LAN, just don't need synchronisation that close about 200ms is good enough.

Why fork and include an NTP daemon, why not just provide integration with 3rd party projects? Why does Lennart & Kay, embrace ever more features rather than fix bugs?

The point is, that "ntpdated" is neither ntpd nor sntp. It is a bastard hack that has inherent accuracy flaws. Again look at the wiki-link where the ntpdated author is discouraging use of his "ntpdated" in favour of either a full ntp client or sntp client.

I think you other question shows you haven't read up on systemd. systemd actually integrate with third party software like ntpd, in fact that is a major point of systemd that it provides such generic layers between programs and end users.

e.g. "systemd-timedated" can be used by DE's to make GUI's that sets the clock, just like the CLI util "timedatectl" can be used to adjust system time by using ntp: Example "timedatectl set-ntp true"

The point is, that these systemd services and utils doesn't have any inbuilt ntp client at all, they just use whatever version of ntp the distro have installed as their canonical ntp solution. So the distro can change ntp implementation, but all command line utils and their syntax will remain the same, just like they work the same way across all systemd distros, regardless of what ntp solution they use.

So the official systemd way of using ntp, is using third party solutions. systemd just provide a comparability layer for such third party solutions.

[Luke_Wolf]

And those slides are a perfect example of how NOT to turn slides into a pdf... seriously, never do that.

[Nille]

Such a thing must never be enabled by default.

Thats features for a default setting. if you don't need or want it, disable it by yourself.

[interested]

Why fork and include an NTP daemon, why not just provide integration with 3rd party projects? Why does Lennart & Kay, embrace ever more features rather than fix bugs?

systemd doesn't have a ntp daemon since it uses third party ntp solutions, but it does have a simple NTP _client_ (not enabled by default) called systemd-timesync. It is an ultra lightweight sntp client with limited features. It is mostly for mass deployment of OS containers since activating 5000 Linux instances in a few minutes give rise to certain problems on the network when getting ntp time and dhcp information etc.

They do actually fix bugs and make it a high priority. Just look at the mailing list. That systemd seems to develop at speed is because so many developers are working on it. I don't think development will slow down at all over time, but continue with ever more features, though probably mostly new features to already existing components like service management, OS containers etc.