读者来信
作者：Michael W Lucas
亲爱的 FreeBSD 期刊来信专栏回答者：
ARM64 现在是一级架构，大家都很兴奋。我该怎么用它？我应该立即把我的桌面、服务器和媒体服务器都换成 ARM64 吗？光是读了这一期，我就已经激动得不行了。我应该多快行动？
——搜寻神奇机器的人
“今天是我自己的，”我今早醒来时心想。“我可以懒洋洋地躺着，想想那必然降临到我头上的辉煌成功，只要我能把袋熊、校车和藻类护柱的那段事瞒住就行，这本该易如反掌，因为没人知道护柱是什么，只有少数几个文人对袋熊一无所知。我大概应该写一两句话，比如说硬盘报告的信息不仅是欺骗性的，更是主动背叛的，这样我就能声称自己在做真正的工作，而不是在屋里转来转去，听着 1930 年代的钢丝录音混音带，想着怎么阻止松鼠在我应急裤里筑巢。我不是常常需要裤子。它们让糟糕的日子变得完全可怕，比如我得离开家去找一家能区分‘承诺’和‘吹嘘’的意式冰淇淋服务。当前这家不是。也许下一家是。”
然后你的信就到了，SOAM，毁了一个原本完美的日子。
往好的方面想，我可以粉碎你的希望。这总是件乐事。
所有操作系统都有“一级架构”的概念。这意味着操作系统可以安装在该架构上，能运行，并且会提供更新以修复不可避免的缺陷。崩溃转储会得到与任何其他主要平台相同的、好坏参半的关注。听起来不错，对吧？
问题在于系统管理员不运行硬件。我们甚至不运行操作系统。我们运行的是应用程序。FreeBSD 在 ARM64 上可能是一级架构，但那并不意味着你的应用程序也是。是的，有很多软件包可用。许多 Ports 能构建。也许甚至大多数都能。但代码能编译，并不意味着它能工作，更不用说与你那堆冒充应用栈的恶意软件互操作了。人们在现实世界里用 ARM64 做真正的工作，但那不意味着你能。你觉得 Linux 主义够糟了？等你看到 Intel 主义再说。当然，人们正在修改他们的应用程序让其在 ARM64 上工作，但架构的改变开辟了广阔的全新缺陷领域。明显的缺陷已被发现。剩下的是高度特定的缺陷。你的环境高度特定。从逻辑上讲，这些缺陷都归你。
许多技术专家声称 ARM64 是不可避免的。唯一不可避免的是核心转储和我脖子上那橙绿相间的皮疹。本应更明智的人吹嘘 ARM64 的优势，仿佛计算领域里有什么能改进，而我们都知道，痛苦永远不会消失，只会换个形式。装一台 ARM64 Web 服务器，你会发现行为的细微变化会危及你的应用程序。推广 ARM64 的人不停唠叨“功耗降低”和“开放平台”，他们极为固执，所以我怀疑他们最终会得逞。换个痛苦，就像休息一样好。
那么，你该做什么？
你可以先别给本刊写信。那会是一种改进。
如果做不到，就该为失败做准备。
你的关键应用程序能在 ARM64 上运行？好……某种意义上的“好”。
你还不能开始用它。即使你纯粹为了测试搭建一套 ARM64 系统，并开启所有能找到的调试以便捕获应用程序错误并提交 bug 报告，你几乎可以肯定不知道“正常”是什么样子。你对正常的认知是：服务台电话安静。当你的全新 ARM64 系统开始喷出晦涩消息，内容关于锁、更新，以及开发者们喋喋不休的胡言乱语——正是这些胡话让你的组织认定这堆谎言能解决他们的问题——时，你完全不知道这些是否正常。
你起步的地方错了。
应用程序开发者很少设计有用的日志。少数人有此意图。许多开发者设计他们自己觉得有用的日志，这跟对你有用不是一回事。你需要知道正常日志长什么样，才能识别异常。
应用程序开发者很少设计有用的日志。少数人有此意图。
从你的旧环境开始摆弄 ARM64，那里满是 AMD64 或 MIPS 甚至（呃）i386 硬件。列出你的关键应用程序。为每一个搞清楚如何收集调试数据。健康的系统把一切都发到 syslog，在那里你可以按需分发到单独的日志文件，但许多现代开发者已抛弃这一健康实践，转而使用随机挑选的、恰好符合他们偏见的日志系统，所以你得（呃，呃）读文档。一些系统管理员有集中式日志服务器，可以在那里分析他们管理的每台系统的消息，但他们是优等生，我们不再讨论他们。最坏情况下，找一个公网上的 log4j 实例，把你所有的调试都倒进去。他们不会介意的。
为每个关键应用程序挖掘日志配置信息时，列一份清单，记录如何为每一个提交 bug 报告。在某个特别令人恼火的缺陷让你血压升高、触发你大脑里内置的“杀一个开发者还是屠光他们”的决策回路之前做这件事，会容易得多。
既然你有了对比基线，就可以安装你的 ARM64 系统，看看会发生什么。别误会，它会失败的。一如既往，问题在于它会如何失败。你的 ARM64 系统的日志会塞满晦涩无意义的消息。幸运的是，你已经有运行中的服务器，它们有自己晦涩无意义的日志消息。你可以对比两者，加上运气，或许再在新月时分某个废弃十字路口做一次简单的咒语，分辨出哪些消息指示你真正的错误。
准备一份 bug 报告。
发给应用程序开发者。
如果他们回复，几乎肯定会纳闷你为什么以从未设想过的方式使用他们的应用程序，但这恰恰是 UNIX 的用途所在，所以别理他们的嘀咕。一个问题接一个问题解决，直到你的应用程序真正能在 ARM64 上运行。开源软件就是这样运作的。正是像你这样的人做这些打磨和解决问题的苦活，未来几十年像我这样的懒蛋才能坐享其成。
如果你觉得这答案不够，那也没办法。我听见松鼠在车库里干呕，所以我才知道我的应急裤子在哪儿。我大概应该某年洗一次。
有问题想问 Michael？请发送至 letters@freebsdjournal.org
MICHAEL W LUCAS 在调试硬件平台迁移上花了太多个十年。他的最新著作包括《DNSSEC Mastery》和《$ git sync murder》。他还出版了《Letters to Ed(1)》，收录了本专栏前三年的内容。我们完全不知道他凭什么觉得你会花钱买在这里免费得到的东西。
《PAM Mastery》 by Michael W Lucas
可插拔认证模块（PAM）：威胁还是危害？
PAM 是系统管理中最容易被误解的部分之一。许多系统管理员宁愿忍受认证问题，也不愿冒险把事情弄得更糟。PAM 的本质使它不同于任何其他 Unix 访问控制系统。如果你有 PAM 苦恼或 PAM 谜团，你需要《PAM Mastery》！
“Michael W Lucas 又一次精准命中。”——nixCraft
最后更新于