Probably for a day or two as various indexes and caches are rebuilt in the background, and then not.

I use 26.x on an "original" 8GB M1 MacBook Air and it's as fine as it ever was.

(I also have a MBP, various Mac Mini's and other desktops, so it's not that I'm just used to everything being slow).

Lots of apps gives you other options for how to process the image data.

I've had a bunch of "high-end" digital SLRs and they (and the software processing the raw files) do plenty computational processing as well.

I completely agree that all else being equal it's possible to get photos with better technical quality from a big sensor, big lens, big raw file; but this article is more an example of "if you take sloppy photos with your phone camera you get sloppy photos".

Look at the contribution history, basically all active contributors work for Synadia: https://github.com/nats-io/nats-server/graphs/contributors

That's not a healthy / functioning open source community. Less than 30 people have made more than 10 commits; most of the 160 were "drive by" who fixed a single small thing.

`t1` comes from your computer, so since I told OP they were looking at the wrong thing I have to point you out did as well. :-)

It doesn't really tell you that, not yet. You didn't wait long enough for chronyd to decide.

All your output here shows is that all the servers are equally reachable since you started chronyd (very recently, except the NIST server) and the Facebook server had the most similar time to what is on your system.

For the aaplimg service, you'd be better off using the general hostname than a specific server that appears to be on a different continent than you.

So I just reran and here are the numbers. Outside of my local NTP servers, time.facebook.com still seems to be good.

  MS Name/IP address         Stratum Poll Reach LastRx Last sample               
  ===============================================================================
  ^* 0000000000000000              1   6   377    72  -1724ns[-3212ns] +/-  134us
  ^+ 111111111111111111            2   6   377    70    +13us[  +13us] +/-  215us
  ^+ 222222222222222               1   6   377    68  -1064ns[-1064ns] +/-  135us
  ^- time.cloudflare.com           3  10   377   513  -1511us[-1525us] +/-   18ms
  ^- time.cloudflare.com           3  10   377   914  -2347us[-2375us] +/-   18ms
  ^- virginia.time.system76.c>     2  10   377   620   -987us[-1012us] +/-   54ms
  ^- ohio.time.system76.com        2  10   377   464  -2672us[-2685us] +/-   43ms
  ^- oregon.time.system76.com      2  10   377   511  +1921us[+1906us] +/-   30ms
  ^? 52.148.114.188                3  10   377   67m  +7902us[+7908us] +/-  141ms
  ^? defra1-ntp-004.aaplimg.c>     1  10   377   563   +292us[ +275us] +/-   83ms
  ^? time4.facebook.com            1  10   377   468   -203us[ -216us] +/-   36ms
  ^? ec2-54-81-127-33.compute>     4  10   377   424   -887us[ -900us] +/-   35ms
  ^? time-a-wwv.nist.gov           1  10   377   492  +6515us[+6500us] +/-   25ms

I do use the generic time.apple.com entry along with other "official" names in my chrony.conf. I think my use of ODoH may be the reason why I'm getting systems further than expected. Will have to dig into it a little further.

  pool time.cloudflare.com iburst nts maxsources 2
  server virginia.time.system76.com iburst nts
  server ohio.time.system76.com iburst nts
  server oregon.time.system76.com iburst nts
  server time.windows.com iburst
  server time.apple.com iburst
  server time.facebook.com iburst
  server time.aws.com iburst
  server time.nist.gov iburst

You are mixing up the 'reference time' and the bits of the NTP packet you are supposed to use to actually set the time. The reference time is not it.

You are correct, it seems! Still weird though why Apple's reference timestamp on this particular server is so far off? Thanks for pointing this out!

If only there was a way to figure out what the website address is, maybe they indeed would have "advertised this information" ...

https://www.apple.com/privacy/government-information-request...

This is not the kind of detail that should be buried in small font.

Apple has a privacy report card for every app on their store, a whole “data linked to you” section.

If that is necessary for apps, why is that not necessary for a product that literally can track you?

It should not be buried.

I know it's unlikely to be you, but if you know anyone concerned about someone who had access to their phone tracking them (or other malfeasence), Apple published a "Personal Safety User Guide":

https://help.apple.com/pdf/personal-safety/en_US/personal-sa...

(also a web version: https://support.apple.com/guide/personal-safety/welcome/web )

(and yes, it covers AirTags).

If Cloudflare was an email provider everyone would be blocking them for sending too much spam and not caring about it.

Apple Maps seems to have comparable detail to OSM for that location ... https://maps.apple.com/?ll=44.39273,-110.55472&spn=0.003043,...

Or what do you see that the rest of us don't? :-)