它是 FILETIME, 以 1601/01/01 开始的 100 纳秒数.

https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime

Google Authenticator 导出的 QR 码是它专用的, 可以用某工具来解析, 生成通用的 totp 链接, 再导入密码管理工具.

比如 https://github.com/dim13/otpauth

试试用 UDP 的 mosh (mobile shell) 会不会降低一点网络延迟?

从问题描述来看, 可能是 DNS/代理/路由 设置被改了, 建议找台正常连接同一个 Wi-Fi 的设备, 对比一下两者的配置是否有差异.

如果周边有熟悉 macOS 开发的人的话, 可以在出现网络问题的时候, 按住 option 键点击 Wi-Fi 图标, 里面有个 Create Diagnostics Report, 这一份报告里会有很多日志来帮助定位问题.

给 Apple 敲一个 feedback 等他们慢慢修吧.
以及, 你的场景下可以换一下 tccutil 的参数: `tccutil reset All [bundle_id]` 这样只会清理掉一个 app 的权限.

没装 Xcode: 终端跑 sudo spindump, 建议提前开好 root 权限的 shell, 遇到问题马上执行 spindump.

有装 Xcode: 打开 Instruments.app, Recording Options 里的 Global Options 的 Recording Mode 选 Last xxx seconds.

ARM 版 macOS 强制关机时, 它会在 /Library/Logs/DiagnosticReports 路径下生成一个 reset-xxx.ips 的文件 (或者按时间排序, 找 1MB 以上的文件), 里面记录了强制关机前所有进程+内核的线程堆栈信息. 如果有这文件的话, 应该能找到非常关键的信息.

原文底下有评论说了正解: 需要 jailbreak.

macOS 上禁用 SIP 来获取 task_for_pid 权限只会影响运行在 macOS 上的程序, e.g., simulator 下的 app; 如果需要真机调试的话, 需要在 iOS 上获取进程的 task_for_pid 权限. 在目标 app 没有 get-task-allow 的 entitlement 前提下, 只有 jailbreak 这条路 (虽然还有 Apple Security Research Device Program, 但他们一定知道这问题的答案).

我觉得这可能不是 efistub 而是 Unified Kernel Image? 参见 https://wiki.archlinux.org/title/Unified_kernel_image 与 https://www.phoronix.com/news/Fedora-38-Unified-Kernel-Part-1

我因为 Linux 下 4k 屏幕的缩放效果不理想而一直在用 Windows:
* 如何原生渲染 4k @ 150% 缩放;
* 如何同时使用两个不同缩放的显示器 (4k@150%, 4k@200%).

如果有解决方法 (Gnome/KDE/Sway 均可) 的话, 不胜感激.

可能是执行 install_name_tool 的时机不对.

MachO 外部依赖项的路径是编译链接时的动态库里存储的 id 值, 所以需要在编译链接 heif-enc 之前修改 libaom.3.dylib 的 id.
执行时机正确的话, otool -L libaom.3.dylib 和 heif-enc 的输出里不会出现 rpath.

你指定的 5 个环境变量中, 前 4 个与 rpath 没有关联: PATH 只影响 execve, 下面 3 个是修改编译选项的, 不像会修改 rpath 的链接路径.
我不确定 rpath 是否会从 DYLD_LIBRARY_PATH 搜索路径 (我猜不会), 以及在正式签名等场合下 DYLD_LIBRARY_PATH 是会被忽略的, 最好不要去依赖它.

有一个不修改 CMake 的思路: 在编译完 libaom 后, 手动执行 install_name_tool -id /usr/local/aom/3.6.0/lib/libaom.3.dylib /path/to/libaom.dylib

具体用法参见 man install_name_tool

手边暂时没有 mac 电脑, 没有办法实测有没有其他的坑.

macOS 上程序对系统依赖的判定与 Linux 不一样。

Linux 只保证了系统调用的 ABI 是稳定的，但它不提供任何用户态环境的保障，所以程序需要静态链接 C runtime 等依赖项。

但 macOS 只保证了 C runtime 和一大堆系统库的 API 是稳定的，它不保障系统调用是稳定的 (
https://developer.apple.com/forums/thread/706419 )，程序必须链接到 macOS 提供的 C runtime (以及 libSystem 之类) 的动态库上。

即使在 OS X 10.10 上，系统中也存在 /usr/lib/libz.1.dylib 和 /usr/lib/libSystem.B.dylib 。如果编译选项正确的话，Xcode 14 编译出来的程序能在 macOS 10.13 (甚至更早的系统) 上运行。

TL;DR:
如果只需要支持 Xcode 兼容的 deployment target (Xcode 14: macOS 10.13 或更新)，在满足 (1) 不链接到系统路径以外的动态库，(2) export MACOSX_DEPLOYMENT_TARGET=10.13 环境变量，或者提供了 -mmacosx-version-min=10.13 编译参数，(3) 编译 x86_64 和 ARM64 两份架构的代码，就应该能保证程序能在 macOS 10.13 以后的系统上运行。

如果要支持 OS X 10.9 或更老的系统，或者 i386/PPC 架构的话，就超出我的实践范围了。

首先清理图片文字的边缘, 用 likefont 识别, 识别的结果是 "方正 FW 童趣 POP 体".
然后去 Google 字体名字, 得知 "方正 FW 童趣 POP 体以 Fontworks 字体「ベビポップ EB 」为原型开发".
最后去 Fontworks 对比结果:

https://fontworks.co.jp/fontsearch/babypopstd-eb/?word=特典付きムビチケカード発売決定！

瓶颈不是在磁盘 IO (总共 3104 文件 16.2 GB ，当前写入 38.3 MB/s 使用率 1%)，而是卡在 CPU (10.8%) 上了，7z/LZMA 解压非常耗 CPU 。
PS: Stream 下载速度的瓶颈可能也不是网络，而是 CPU 。

GPU-accelerated terminal 在高分辨率屏幕下可能更省 CPU 资源。
我用 sway 屏幕分辨率 4k 缩放 2x ，草率测试在 Foot/Alacritty 下运行 htop 并上下滚动，发现前者的 CPU 比后者要高数倍。

如果这软件的架构没有大的变化，它会从服务器上下载一个平台相关的、加密压缩后的动态库，用于加解密操作。这动态库更新频率不高，大概一年更新一两次。
如果要 Linux 上原生运行它的协议，就要把它动态下发的动态库解密出来，并把里面的算法重新实现，目前 GitHub 上的项目基本都是这个思路。

如果要研究它协议的话，建议找保护最薄弱的平台下手，比如 iOS, MacOS, Android 。Windows 大概有 VMP 难度会非常大。
需要研究的内容有 (7 年前的信息，可能已过时)：
1 、解密 zsm ；
2 、解压 zsm ，大概还是 LZMA ；
3 、client 提供给 zsm 的接口，大概 2 个动态库，20 个导出函数；
4 、zsm 的 2 个关键导出函数 (code, decode)；

研究完 4 后，就可以在已有 GitHub 代码上更新当前的算法了。

Host synology
HostName server.local
Port 122

Host gitlab
HostName server.local
Port 222
IdentityFile /path/to/ssh.key

按上面配置 ssh_config 后，使用 ssh synology 或者 ssh gitlab 来连接不同服务。

Windows display language, Preferred languages 以及输入法的第一项都是英文吗？
好像有些程序会按输入法列表的第一项显示语言。