mathtype 专有软件功能简单收费又贵，20 年前就已经是老古董了，之后有段时间因为推出免费版本（记得叫 texaide?，可以作为 latex 公式 wysiwyg 编辑器）顺带着复活过，后来被 wiris 收购回归收费还改得不好用就基本上玩完了。没想到直到现今还有人在用，感觉国内科研界很多人喜欢停留在老旧软件？
另一个类似的软件似乎是 originlab 的 origin

@jsq2627 逻辑上不是同一件事。connection id 就是为了解决诸如 nat rebinding 发生时保持连接的问题，正如 OP 所说是 quic 的“一大特性”，但即使这样，还会有服务器地址 anycasting 的问题，需要服务器端做出改变，与客户端没有关系

@playboy0 也只能表示没看懂。如果是因为问题一，那么应该是选择好的 vps 、机场以及梯子，何况前面已经说到有明显的“感受”，如果是因为问题二，那么禁不禁用没啥差别，问题三似乎是因为 cloudflare 目前不能很好处理 quic 连接 anycasting 的问题，并不是 OP 理解的 NAT 重绑定的“支持”问题，相信会很快解决。所以，似乎没有禁用 quic 的必要性

@ST0RMTR00PER 又看了一下，更新重启（两部分别是整一天前和 2 小时前）后目前的 chronod 的%CPU 虽然都为 0 ，但 CPU time 却高到排至第三位（排在 google chrome 和 identityserviced 之后），说明曾经高过。所以是否是需要耐心等待一段时间，等它完成特定任务后说不定会恢复正常？

第二个 notification center 的 cpu 也有点高，这个和 chronod 一样也和 widgets 有关。是不是启用了某种不同寻常的 widgets （例如 ios 的 widgets ？），在数据同步时导致“大量的对象和数据传输操作”？

看了一下这两个的%cpu 均为 0

@abbb 说实话，这个作者实在是太不上心了：niginx 配置文件是/etc/nginx/nginx.conf ，不是 nginx.cong 。这么明显的 typo ，还特地加了 bold ，这么多年都没有改一下。这个很可能误导了 OP 导致了失败（因为其他的下载解压缩文件和 systemd 配置已经简单到不可能搞不定了）。但是考虑到论坛的样式那么古早，再加上古早的 centos 7 ，建议 OP 还是放弃吧，1 不值得折腾这个，2 即使成功安装也是失败

@raysonx 非常感谢！ OP 真是及时雨。本来 ipv6 是用 HE tunnel broker 一直没有问题，正好今天想试试国内流量不走隧道，结果就，百思不解的时候正好看到 OP 的帖子，完美解决

似乎也不算太糟糕吧，当然也没有用就是了。说实话 launchpad 都基本上没用过

如果实在很强迫，只要把~/Applications/Chrome Apps 文件夹中的内容移到 Trash 就干掉了

@AoEiuV020JP 9 0 貌似是 Google Chrome.app 自身的权限问题，因此需要每次只能用新的手工替换。是不是终端 sudo chown -R root:wheel /Applications/Google\ Chrome.app 可以解决？

@Chaidu 这逻辑。请参见 @Pazakui1259 。人家就是这么设计的，“为了帮助防止恶意软件通过尝试攻击用户密码而导致永久数据丢失”，不是“只要想办法让这个恶意软件别把 OP 的 Mac 锁定就好”。mac 被锁定（严格地说，是 disabled ）可是很严重的事情，一旦发生就只能进入恢复模式抹除硬盘数据重置电脑，如果没有备份这个过程会导致“永久数据丢失”，进一步地，如果这个时候再输错密码 10 次又没有设置 icloud Find My ，那么 OP 的 Mac 就基本等同报废了

mac 只是在开机启动后的登录窗口有 10 次的密码输入限制和延迟，10 次之后进入恢复模式还有 10 次。一旦成功登录，之后的退出屏保、亮屏以及睡眠唤醒的登录界面就都没有次数限制了。这是为了防止熊孩子以及恶意软件故意输错密码让 OP 的 mac 锁定

抱歉查了一下确实休眠（深度睡眠）时通过键盘鼠标能唤醒，并没有断电，本身就设计成这样，应该是没有办法了

休眠本来就会停止供电，要做的是把默认睡眠（ hibernatemode 0 ）改成休眠：
pmset -a hibernatemode 25

但是，能否接受每次唤醒都要抬起按电源按钮？

UTM 理论上似乎可以，因为摘自官网：“UTM employs Apple's Hypervisor virtualization framework to run ARM64 operating systems on Apple Silicon at near native speeds. On Intel Macs, x86/x64 operating system can be virtualized. In addition, lower performance emulation is available to run x86/x64 on Apple Silicon as well as ARM64 on Intel.”

但是，这里的“ARM64 on Intel”应该是指 windows 或 linux 之类。apple silicon 并不是一般的 arm64 ，没有“反向”rosseta 这样的东东在其他 arm 机器上运行 macos 都没有可能，更不要说在 intel 的机器上了。OP 的想法确实非常清奇，估计全宇宙都没有人会想到这么做

这个问题似乎应该是反过来问：为什么 Chrome 等一堆 apps 至今不支持 macos spatial audio ？答案似乎也很简单，类似于 chrome 在 ios 上用 webkit ，macos 上用 blink 的情况。但凡它们都自己的东西的时候，要它们转用苹果的 api ，完全不是首选项的吧，除非...

没办法和 OP 一样上古的人喜欢用上古的协议
有没有配置 tls-crypt 及 pre-shared key ？多年用下来显示似乎只要有 tls-crypt 增加一层加密，就能正常使用

续上，没有仔细看，网卡没有启用 promiscuous mode 。同意 @dbg #1

如果只是这一个 linux 虚拟机存在重复数据包，那么很大的概率是因为该虚拟机的网卡启用了混杂模式。是不是在这个虚拟机上用了某些抓包工具？

这个和所选的 NTP 服务器有关系。如果到服务器的网络单向累积延迟接近甚至超过 200 毫秒，跳数达到甚至超过 30 个，比如默认的 time.windows.com 可能就是这样，那么正常情况就是只能达到秒级的精度，误差范围内就没有必要根据服务器时间更新系统时间了。即使强制同步了也还是一个秒级误差的时间。详情可见 https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/support-boundary-high-accuracy-time

OP 提到的帖子其实只是提问并没有讨论。

如果想要提高精度，OP 的参考资料也已经给出了答案，基本上就是就近选择一个高层级的时间服务器。最理想的，是在局域网内有一个 NTP 服务器且服务器直接连接高精度时间源，这时达到毫秒级的同步精度就就不是问题了。这也是为什么有时候反而是手机上的时间精度更高的原因。

但是话说回来，为什么 OP 需要这么准确的系统时间？

@emyself 需要