Nice to see el pulpo magnifico's camp be spotless on the mini-map in the blog post.

The author clearly hasn't worked for a big company. An $8m mistake? Meh, not great, but it probably seemed like a good idea at the time. Seen worse.

Oh, it was $8m over several years? That's a couple of projects that didn't pan out, or a small team that wasn't firing on all cylinders for a stretch.

Nobody got fired because there was nothing unusual to fire anyone for.

You must be using some flavor that doesn't have systemd, at least. Or a Linux from a decade ago.

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.