1. After resuming from suspension or hibernation, s6-log no longer shows the correct timestamp. Can this be fixed? Thanks.
This is a much more complicated issue than it sounds. Short answer: no, the system needs to readjust the system clock when resuming from suspension/hibernation; it's a problem not only with s6-log, but with every program using the system clock, so the problem should be fixed where it occurs. Long answer: - There are several "clocks" accessible to a userland process via clock_gettime(). They can be roughly classified into "stopwatches" (they count the incremental time since a given starting point) and "wall clocks" (they give you the time of day). - It's often debatable (and debated) what particular clock should be used for a given program. But in the case of s6-log, the answer is clearly: a wall clock. Because it's what is used for timestamping. - POSIX makes no mention of what should happen with clocks when suspending/resuming the system. - Linux has *no* wall clock that explicitly counts time spent in suspension. It only has one (stopwatch) clock that does it, that is named CLOCK_BOOTTIME. - CLOCK_BOOTTIME is not usable for s6-log, because 1. it's not portable, and 2. it's not a wall clock, meaning it can diverge from the human view of system time over long durations (that's the reason why wall clocks are generally preferrable to stopwatches for long-lived processes). - So the only real solution is a mechanism that fixes CLOCK_REALTIME (the portable wall clock that is appropriate for s6-log) after a resume. It is likely done by the next NTP synchronization after the resume, but there is a window where wall clocks give inaccurate information. The kernel could probably help by roughly adjusting CLOCK_REALTIME given the difference between CLOCK_BOOTTIME and CLOCK_MONOTONIC, but as of now it's not doing it. More details: http://man7.org/linux/man-pages/man3/clock_gettime.3.html
2. Some days ago I stumbled upon [1], and found it possibly a much less intrusive alternative to a centralised registry for command names [2]. Any thought on this?
This is just a path searching convention, and the proposal is to basically add . to PATH for binaries containing (but not starting with) a slash. I personally think that anything involving . in PATH is a bad idea, but independently from that, I don't see how it relates to solving name conflicts in a distribution. Can you elaborate on how you would use this? -- Laurent