> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20220304-arm64-shi-yi-ji-jia-gou/we-get-letters.md).

# 读者来信

* 原文：[We Get Letters](https://freebsdfoundation.org/wp-content/uploads/2022/04/MarchApril-Letters.pdf)
* 作者：**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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20220304-arm64-shi-yi-ji-jia-gou/we-get-letters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
