| |||||||||||||
|
| |||||||||||||
The answers are there, you just don't want to admit they are right answers...The answers are there, you just don't want to admit they are right answers...Posted Jun 1, 2010 11:56 UTC (Tue) by mezcalero (guest, #45103)In reply to: The answers are there, you just don't want to admit they are right answers... by paulj Parent article: The road forward for systemd
If your event "system time may now be considered stable" shall be about NTP then it makes little sense since NTP clients tend to slowly adjust the time instead of making it jump. That means that the time is adjusted fully only after quite a bit of time. Applications should not wait for that. They should just assume that time is correct, right from the beginning. And that is a safe assumption for all machines built in the last 25y. And again, I don't see what systemd has to do with eventing like that anyway. I see no need to multiplex events through an eventing system. Get your events from the respective subsystems directly. Don't add an indirection layer here.
People should handle "in-lifetime" events (as you call them) with the native notification logic available. no need to involve systemd, or dbus or anything.
(Log in to post comments)
The answers are there, you just don't want to admit they are right answers... Posted Jun 1, 2010 13:33 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
I don't know what datacenter you are working in, but I sure don't trust the system time in my datacenter until NTP has started, and at initial startup I don't have it gradually adjust the time as it may be so far off that NTP will decide that it will never get it right and shut down. Instead it does a one-time large jump to get the system time correct.
on some systems I use the -G option, on others I use ntpdate.
The answers are there, you just don't want to admit they are right answers... Posted Jun 2, 2010 6:33 UTC (Wed) by paulj (subscriber, #341) [Link]
It's not a safe assumption unfortunately. There are distressingly many machines out there which deliberately are run without batteries (lower field maintenance) and which hence have the time set at boot. Note that "ntpdate -s" implies setting the time - not slowly adjusting it. Even if you discount this example, I have a strong sense that there are many other high-level events (e.g. the network and printer examples).
What exactly is the "native notification logic"? (Note that many events are application layer).
Also, I'm not saying systemd needs eventing logic. I'm asking whether it makes sense to try solve these problems in a init process, external to applications. (for value of apps that includes those that would be started by it).
In short I'm asking whether actually its user-space that needs fixing to cope with differences in and changes to environmental state? Because it seems that doing that correctly would allow a not-too-fancy init to fire off apps in parallel and not worry about dependencies, as you argue systemd should be able to do with good apps. It seems applications will have to be modified to do this anyway, to get best effect from systemd.
|
|
||||||||||||