虽然工作里没接触过 Linux perf, 但遇到过类似的场景, 也需要解析程序的符号.

最好的办法是, 让生产环境有符号文件可查.

如果遇到难以复现的问题, 并且无法拿到那份特定程序的符号信息, 就会变得很麻烦, 但总有办法.

我目前的做法是:

* 找到复现问题用的, 没有符号的程序 A,
* 用类似的配置编译一份带符号的程序 B,
* 用 BinExport 配合 IDA Pro, Binary Ninja 或者 Ghidra 分别导出程序 A 和 B 的信息,
* 用 BinDiff 去匹配程序 A 和程序 B 里相似的函数, 生成一个 SQLite 数据库,
* 自己写脚本读取 SQLite 里程序 A 的符号信息, 填充到收集的原始资料里.

@stinkytofux Oray 开头的音频设备, 大概率是向日葵远程面用来捕捉系统声音的虚拟设备.

我发现 OP 贴的 iperf3 结果好像有点不正常: 在客户端发送 85353 个 UDP 包, 服务器收到 85328 个 UDP 包, 丢包率是 0% 的前提下, 为什么客户端发送了 114 MBytes, 但服务端只收到了 4.02 MBytes?

有大佬愿意解释一下吗?

@PainAndLove 不建议折腾, 这种做法会 *小概率* 引发兼容问题, 比如利用 copy-on-write 或者 clonefile 的软件可能无法正常工作.

如果还是想把 Caches 整个文件夹移动到 RamDisk 的话, 建议写一个脚本来初始化 RamDisk 和创建 Caches 软链接; 并利用 LaunchAgent 的方式, 在用户登陆后自动执行这个脚本.

进入 Recovery 删 Caches 软链接.

1. 参照 https://support.apple.com/102518 进入 macOS Recovery,
2. 打开 Disk Utility, 左侧找到 Data 分区, 右键后, 选择挂载, 记录挂载点的路径, 退出 Disk Utility,
3. 在菜单栏里, 选 Utilities -> Terminal,
4. 运行 rm [挂载点路径]/Users/[用户名]/Library/Caches, 示例 rm /Volumes/Data/Users/mac/Library/Caches
5. 左上角 Apple 图标 -> Reboot.

它是 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=特典付きムビチケカド定！