> Mac and Linux: Search for the Terminal in your applications list and open it. Next, copy the below command, paste it into the window (Ctrl+V or Cmd+V), and press the Enter/Return key:
I don't think they specifically target people who tend to go to sleep. But, having worked in the ad engineering, I can imagine they do know how often specific users skip ads and target ads based on that property.
One can also use the Facebook website. It's almost usable on the Firefox mobile to the extent that you can check the news feed or notifications and reply to a comment, but anything more involved is very annoying (so you end up not doing this and long-term using Facebook less, which is a good thing)
LLM would help with this immensely, if only it was allowed (not sure how though... make the ruleset available as a single text field for export/import, maybe?)
Having clocks synchronized between your servers is extremely useful. For example, having a guarantee that the timestamp of arrival of a packet (measured by the clock on the destination) is ALWAYS bigger than the timestamp recorded by the sender is a huge win, especially for things like database scaling.
For this though you need to go beyond NTP into PTP which is still usually based on GPS time and atomic clocks
Actually interesting to think about what UTC actually means and there is seems to be no absolute source of truth [0]. I guess the worry is not that much about the NTP servers (for which people anyways should configure fail overs) but the clocks themselves.
Could you define an absolute source of truth based on extrinsic features. Something like taking an intrinsic time from atomic sources, pegged to an astronomic or celestial event; then a predicted astronomic event that would allow us to reconcile time in the future.
It might be difficult to generate enough resolution in measurable events that we can predict accurately enough? Like, I'm guessing the start of a transit or alignment event? Maybe something like predicting the time at which a laser pulse will be returnable from a lunar reflector -- if we can do the prediction accurately enough then we can re-establish time back to the current fixed scale.
I think I'm addressing an event that won't ever happen (all precise and accurate time sources are lost/perturbed), and if it does it won't be important to re-sync in this way. But you know...
Getting from 95% compatible to 100% compatible may not only take a lot of time, but also result in worsening the performance. Sometimes it's good to drop some off the less frequently used features in order to make the tool better (or allow for making the tool better)
reply