短暂性策略（Policy of transience）

[Simon Tatham, 2025-05-09]

Introduction

我在计算机使用方面有一些习惯，按照许多人的标准来看，这些习惯有些不寻常（尽管有些比其他习惯更甚），并且所有这些习惯都指向同一个方向。 在我采用每个习惯的时候，我并没有意识到这一点。每个习惯在它自身的上下文中，似乎由于这样或那样的原因都是令人期望的，但是直到稍晚一些我才发现贯穿它们所有习惯的共同主题。 这个主题并非总是我最初采用该习惯的原因 - 但我认为这是在我尝试了其他原因之后，我_保留_所有这些习惯的原因。 在本文中，我将描述我正在思考的习惯，以及它们都是实例的更一般的想法，我现在将其视为“短暂性策略”。 我并不试图说服其他任何人，他们应该采取这种通用策略，甚至不应该采取任何特定的习惯。 我只是在这里提出这些想法，以防万一人们感兴趣，供人们考虑，并决定他们是否会发现其中任何或全部内容有用。 如果其中任何一项对您有用，那就太好了 - 如果您认为它不适合您，那也没关系。

The habits

这是我现在在“短暂性策略”的一般标题下分类的习惯列表。 我_认为_这些是我采用它们的大致时间顺序，但很难确定。

Turn off persistent shell history

我使用 Linux 命令行，特别是 bash。 像许多其他现代 Unix shell 一样，bash 保留了您键入的命令的历史记录，以便您可以回忆它们并再次运行它们，或者稍微修改之前的命令来做一些新的事情。 这可以在短时间内立即使用：键入一个命令，它不能完全工作，回忆它并编辑一个错字，然后再试一次。 但从长远来看也很有用：回忆您上周、去年或每月一次运行的命令。 为了支持此功能的长期使用，bash 在您退出 shell 时将您的 shell 历史记录保存到一个文件（默认为 ~/.bash_history），并在启动时重新加载该文件。 因此，即使您自运行命令以来已经注销或重新启动了整台机器，您仍然可以回忆起该命令。 许多人发现此持久历史记录功能非常有用，并花费大量精力进一步改进它——您可以配置更大数量的存储命令，某些 shell 会不断同步其历史记录，而不仅仅是在退出时，还有一些插件可以帮助您更轻松地搜索它，等等。 总的来看，似乎是：shell 历史记录很好，更多、更易于使用的历史记录甚至更好。 但我走的是相反的路。 我不寻常的习惯是：通过在我的 .bashrc 中输入命令“unset HISTFILE”，完全关闭历史记录文件。 我仍然可以在 shell 的单个实例中获得历史记录，因此我可以编辑我的最后一个命令十次，直到它正常工作； 但历史记录不会在我的终端窗口之间共享，也不会在您注销并重新登录时保留。 我允许自己使用的_所有_ shell 历史记录都是本地化的和短期的。 我早在我的 Linux 使用生涯中就开始这样做了，在我第一次发现历史记录文件的存在后不久。 我认为我最初的动机是一种非常模糊的隐私问题：我的 shell 会记住那么多关于我过去所做的事情的细节，这感觉很_令人毛骨悚然_。 关于 shell 历史记录，肯定存在有效的_特定_隐私问题。 有时您会错误地在命令行上输入一个实际的密码等秘密信息。 （糟糕，焦点在错误的窗口中。）有时您只需要捏着鼻子，故意将密码放在命令行上，因为一些设计糟糕的工具不允许您以任何其他方式传递它。 （当然，这已经是一种危险，因为系统的其他用户可以在 ps 中看到它——但在命令实际运行时非常短暂地冒这个风险是一回事，而在 ~/.bash_history 中保存密码的副本几个月或几年是另一回事。） 但我不认为我一开始就想到了任何具体的事情：我只是对这个想法感到普遍的不安。 （当然，如果您_知道_您刚刚在命令行上写了一个密码，您可以故意从该 shell 的历史记录中删除该命令，然后再将其保存到文件中。 但是，如果您是偶然这样做的，您可能不会意识到您需要这样做； 如果您必须回忆该命令并重试几次，您可能无法清理它的每个实例。） 但是在采用了这个策略之后，并将“unset HISTFILE”放在我在所有 Unix 帐户之间共享的标准 .bashrc 代码段中，我发现它还有另一个好处：它迫使我保持更有条理。 如果我输入了一个_有价值的_ shell 命令——一个做了足够有用的事情，以至于我将来可能再次需要它，并且足够长和复杂，以至于我不得不从头再次弄清楚它会让我感到恼火——那么我不能依赖它恰好在我的 .bash_history 中。 所以我把它放在其他地方：可能是我 .bashrc 中的一个 shell 函数，或者是我随机的有用小脚本目录中的一个 shell 脚本。 或者只是记在一个笔记文件中，提醒我自己一些要记住的有用 shell 命令。 我发现这是一种更有用的记忆 shell 命令的方式。 首先，此过程将命令的_工作_版本与之前的所有失败尝试分开。 即使在 bash 的一个实例的上下文中，当我瞄准两个命令之后的更正版本时，我有时也会不小心回忆起命令的_错误_版本； 拥有_一年的_我自己失败的尝试可供意外回忆的想法似乎令人恐惧！ 相反，我故意只保存_工作_版本，并在关闭 shell 时将所有失败的尝试扔进垃圾箱。 其次，当我故意以任何这些方式保存命令时，我会给它一个名称，并写一条注释来解释它有什么用，以及我将来可能再次发现它有什么用。 而且很可能我会将它提交到我的一个小个人 Git 存储库之一，以便它保留下来，在我的机器之间共享，并且如果它在某些新的上下文中不能完全工作，我可以稍后更新它。 当然，这意味着在我_确实_保存命令以供以后使用时，需要付出更多的努力。 但我的印象是，从长远来看，这种努力是值得的。

Clear my GUI desktop regularly

我通常不会在单个 GUI 会话中保持数月之久的登录状态。 （这可能是列表上_最不_寻常的事情之一，但这是我采用这些习惯的时间顺序中的位置。） 我关闭笔记本电脑的次数比暂停它们的次数更多。 我将暂停视为我正在做的事情中非常暂时的暂停的工具：如果我在火车上使用我的笔记本电脑，现在我必须起床并换乘另一辆火车，这似乎是 20 分钟暂停的一个很好的用法。 但是当我到达最终目的地时，我会完全关闭笔记本电脑。 我从不让笔记本电脑暂停过夜（除非是错误）。 也充当远程登录服务器或构建服务器的机器必须保持开启状态。 但即使在那里，我也不喜欢让单个登录会话长时间保持活动状态。 在我有办公室台式电脑的年份（虽然现在我正在使用笔记本电脑），我会在一天开始时登录，并在回家之前注销，而不是仅仅锁定我的屏幕并将所有窗口留在那里直到第二天早上。 即使我实际上没有每天注销一台机器，我也会每天 apt upgrade 它，并且如果 apt 告诉我需要重新启动_立即_，就像因为它安装了内核更新一样 - 我不是那些人中的一员，他们因为所有打开的窗口中不想丢失的东西而将重新启动挂起数月。 因此，我运行的任何东西通常都不会有超过几周的正常运行时间。 并且更频繁地，即使我实际上没有注销，我也会关闭所有打开的应用程序，清除桌面，并从头开始。 当然，这会在我启动机器、登录并开始使用它做某事时，给我的早晨例行程序增加一些精力。 我通过简化打开我使用的常用应用程序的工作流程来最大限度地减少这种情况——键盘快捷键的混合使用（我不必通过 GUI 开始菜单来查找我的任何常用工具）和智能窗口管理器配置（我的 WM 自动将窗口放置在我喜欢的位置）。 我为什么开始这样表现？ 我认为更多的是我从未_停止_像这样表现。 当我还很小的时候，家里的电脑与其他家庭成员共享，所以你不能让你的会话运行很长时间，因为其他人想使用这台机器。 在那一代的计算机上，“暂停”和“切换用户”并不是一回事。 通常也没有任何理由让机器一直开启，因为它没有连接到网络，所以它不会做任何有用的事情。 但我确实有一些更具体的原因不想让会话，甚至是特定的一堆终端窗口永远运行。 一个原因是，这是对累积状态变化的防御。 在一个特定的终端中，我可能已经弄乱了诸如 PATH 之类的环境变量，然后该终端不再处于其默认状态。 也许我这样做是因为这对于我正在使用该终端窗口所做的特定事情来说是明智的。 但是如果我忘记了我已经这样做过，并为其他事情重用同一个窗口，那么剩余的状态可能会让我感到困惑。 在_好_的情况下，我想做的事情不起作用。 在坏的情况下，我尝试的某些事情_确实_有效，这在终端的默认状态下不起作用，然后我将它放在一个脚本中（或者更糟糕的是，将其发送给其他人），并且当它在未修改的环境中运行时，它会在以后意外失败！ 出于这种原因，我经常避免为两个不相关的项目使用同一个终端窗口：如果我停止使用（比如说）PuTTY 并开始使用（可能是）我的益智游戏，这是一个 ^D 窗口并在同一屏幕位置打开一个新窗口的习惯。 但另一个原因是：我发现定期关闭我所有的应用程序对我有用。 如果我关闭笔记本电脑时仍然在某种程度上进行编码（例如，因为火车已经到了），那么_因为_我即将关闭它，我会确保将所有内容都置于良好的状态：从我的工作中进行本地 git 提交，写一些笔记给自己，告诉我我还有什么要做，总的来说，确保当我下次启动笔记本电脑并尝试恢复我正在做的事情时，我可以记住它是什么以及我到了哪里。 无论如何，这澄清了我的想法，并允许我下次带着新鲜的头脑回来，重新阅读我的笔记，并可能产生新的想法。 它还有助于机器之间的可转移性。 在我对未完成的工作进行那些 git 提交之后，我通常会将它们推送到另一台机器（至少如果我当时有网络）。 部分原因是防止数据丢失。 而且，如果下次我在另一台机器上（比如我的家用台式电脑）处理同一件事，我可以从我在笔记本电脑上停止的地方_在那里_继续。 如果我所有的工作状态都包含在笔记本电脑的 GUI 会话中，我将_必须_继续在笔记本电脑上工作，即使我已经回到家，那里有更大的显示器。

Close my entire web browser frequently

在前一节中，我提到我经常关闭_所有_我的 GUI 应用程序，包括 Web 浏览器。 但不仅如此：我关闭 Web 浏览器的频率比关闭终端和编辑器窗口的频率_更高_。 很多时候，如果我正在处理像编码这样的事情，我根本没有打开浏览器。 如果我需要参考基于 Web 的文档，我经常不得不从头开始启动 Firefox 才能做到这一点。 我可能会在跟踪超链接时打开一些选项卡，但当我完成时，我会努力关闭这些选项卡，并且最好关闭整个浏览器。 我_不_做的一件事是将打开的浏览器的选项卡列表用作长期阅读列表。 （甚至不是“在今天内阅读”，更不用说几周了。）我知道这是很多人使用浏览器的一种常见方式，以至于需要浏览器插件或扩展程序来帮助管理成百上千个选项卡。 如果我曾经在一个浏览器中打开了 100 个选项卡，那是因为我出于某种直接目的（要么使用脚本，要么通过单击大型索引上的每个超链接）快速连续地打开了它们，并且我即将立即浏览所有选项卡，以寻找我想要的东西，然后尽可能快地再次关闭它们，以摆脱这种可怕的混乱。 我为什么这样工作？ 同样，一个原因是，当机器较小的时候，几十年前这样做是有意义的——您的浏览器会消耗您想要用于其他用途的内存，因此您只会在需要时打开它。 所以这_有点_像我从未费心更改的 1990 年代的习惯。 但是，同样，我也有一些更具体的原因。 一个是我的 cookie 管理策略。 我配置 Firefox 在我关闭浏览器时删除_所有_ cookie，除了我配置为异常的极少数网站。 在我看来，这似乎是在允许所有 cookie（所有东西都在跟踪您）和完全拒绝 cookie（某些网站甚至无法工作）之间的一个很好的平衡。 这样，我的浏览器_接受_我想要使用的某个网站的 cookie，因此实际上没有任何东西会失败——但下次我使用该网站时，浏览器不会记住它们。 但只有在我没有让浏览器在这些访问之间运行的情况下，这才会带来隐私好处，并且每天多次关闭整个浏览器是一种很好的方法。 不使用我的选项卡栏作为我的待读列表的另一个影响是，如果我_确实_想要维护一个待读列表，我必须以其他方式来做——并且这种方式很可能涉及到将 URL 写下来，并提醒我自己它是什么_用_的，也许我从哪里得到的，以及（如果适用）当我到达该页面时我计划做什么。 （即使只有少数几个选项卡和一个短暂的时间间隔，我也可以非常心不在焉地忘记最后一部分！对于像我雇主的 CI 系统这样的网站，我可能出于许多不同的详细原因想要打开这些网站，我打开一个选项卡并带有特定的意图，两分钟后访问它，却忘记了我想要它做什么。一周后记住 URL 的重点是不可能的。）

Turn off X11 session management

在我使用 Linux 的某个时刻，桌面环境引入了一项功能，可以在注销时保存您的桌面布局——您打开了哪些应用程序，每个应用程序的窗口在屏幕上的什么位置，以及每个应用程序在做什么。 这个想法_是，即使您必须注销、关闭电源，并在下次打开机器时重新登录，您仍然可以从上次停止的地方继续。 我希望这可能可以正常工作，如果您是主要运行办公套件应用程序的那种计算机用户。 您当然可以想象一个文字处理器或电子表格应用程序能够以非常少的信息记录其工作状态的重要方面——“我有一个_这个_大小的窗口，在这里，编辑_这个_文档[由路径名指定]，视口显示文档的_这个_部分，光标就在_这里”——并在使用正确的选项重新启动时将所有这些都设置回去。 但如果您主要是一个终端用户，使用 GUI 作为在六个 shell 提示符之间以及偶尔的文本编辑器或 Web 浏览器之间切换焦点的便捷方式，那是没有希望的。 没有可能保存 shell 会话的状态，以便您可以在第二天从上次停止的地方继续。 或者更确切地说，有，但它涉及保存所有涉及进程的完整内部状态——换句话说，是休眠机器而不是关闭它。 有些事情，比如 SSH 会话，甚至无法在休眠中幸存下来。 出于这个原因，我在遇到会话管理后立即将其关闭。 我看不到重新生成_一半_窗口的意义，而且不仅如此，还有一半不容易手动重新创建的窗口。 （我也从未在我的任何 GUI 软件中实现会话管理 API 的应用程序端。这在 PuTTY 或 pterm 中没有多大意义，原因我刚刚提到，但我的益智游戏系列可以更容易地支持这一点。但是，从来没有人抱怨缺少它。） 您现在可能可以猜到运行中的主题是什么：因为我不依赖系统以我离开时的相同状态重新启动所有内容，所以我必须努力记住该状态_是什么_。 理想情况下，这是通过首先使状态变得简单来完成的，例如完全完成一项任务而不开始下一项任务。 如果我确实必须离开一件未完成的事情（而且我不仅仅是快速重新启动并立即返回），我会写下一些笔记给自己，以提醒我自己我到了哪里。 如果未完成的事情严重依赖于特定终端的 shell 历史记录（就像我不断回忆起一些复杂的测试命令以在每次构建后重新运行一样），那么该命令也会被复制到我的笔记中，或者复制到一个小小的 test.sh 文件中，或者类似的，以便在下次启动后启动新终端时仍然可用。

Use a tmpfs on ~/mem as my main scratch space

当我第一次获得一台装有 SSD 而不是旧式旋转硬盘的机器时，我听说过 SSD 磨损，我对此有点担心，但我不太确定应该_如何_担心，并且想谨慎行事。 我当时正在处理一些涉及每次运行中大量磁盘访问的事情，_并且_需要多次运行。 （它涉及数据库，所以它在做大量的 fsync。我只打算在_实时_数据上运行一次——这是一次性的格式转换——但我必须在测试数据上反复运行，直到我做对为止。） 我不想成为 SSD 用户的第一个举动是在第一周通过运行未完成的程序太多次来耗尽整个 SSD。 我当时的电脑有足够的 RAM，因此我能够通过简单地制作一个 Linux“tmpfs”来解决这个问题——一个仅由 RAM（如果启用了交换，则由交换空间支持的文件系统），该文件系统在重新启动时甚至在卸载时都会消失。 我只是运行了一对类似于这样的命令

mkdir ~/memsudo mount -t tmpfs -o size=32g none ~/mem

然后我在那里进行了该磁盘密集型转换工具的所有测试运行，因此它根本不会写入我漂亮的新 SSD。 一旦此练习让我产生了在我的主目录中挂载 tmpfs 的想法，我认为我会将其保留一段时间，因为我可以发现它可能很有用的其他方式。 我最终将其作为我的工作流程的永久组成部分，现在我在我拥有 root 的所有 Linux 机器上设置了相同的安排。 特别是，我经常想要下载一些软件的源代码（通过 git clone、apt source 或只是下载和解压一个 tarball），以便找到关于它的一个非常小的东西。 通常，一旦我完成了这件事，我就不再需要源代码了——但在我回答了我的初始问题的那一刻，我从来没有_完全_确定这一点，所以我把它留在原地，以防我在半小时后想知道别的东西。 然后我当然会忘记删除它。 我过去在 ~/tmp 中做过这种事情，它曾经是（现在也是）我磁盘上的一个普通的持久目录。 当然，它逐渐变得越来越满，里面装满了源代码树，我曾经下载过一次并且再也没有使用过，以及其他类似的杂物，比如我生成的大型数据文件、strace 日志等。 整理和清理 ~/tmp 是一件琐事，每隔一段时间就会阻止我的磁盘被填满。 但这再也不会发生在我身上了，因为现在我把所有这些一次性下载和日志文件都放在 ~/mem 中，它们会在下次重新启动时自动消失。 （我仍然有一个 ~/tmp，但现在它用于_不太_临时的事情——可能需要持续一两周并且在重新启动后仍然存在的东西，而不是接下来的半小时。我通过对它的大多数子目录进行日期戳记来处理清理问题，所以我可以一眼看出某些东西是去年或十年前的，并猜测不再需要它。） 当然，这样做的负面影响是我冒着丢失我实际想要保留的数据的风险。 但是当我在 ~/mem 中放置一个文件或源代码树时，我_知道_我做了什么，所以我密切关注我可能想要保留它的任何原因。 如果我确实想要保留它，我不会仅仅将其迁移到具有相同抛弃名称的 ~/tmp：我会想到一个更有条理的地方来放置它，并给它一个更合理的名称，并且可能会为自己写一个关于我想要它做什么的自述文件。 如果我对_每一个_一次性下载都这样做，那将是一项巨大的工作，但如果我只对我从 ~/mem 提升到持久存储的一小部分东西这样做，那就不会太糟糕了。

Policy of transience

所有这些习惯之间的共同主题现在可能很明显了，但我仍然会更正式地说明它。 我认为所有这些习惯都是一般“短暂性策略”的实例，该策略说：事物要么应该以有组织的方式_故意_永久存在，要么应该严格临时存在。 我不喜欢事物_意外地变成_永远存在。 我上面描述的所有习惯都可以通过这个视角来看待：

以“有组织的方式”使事物故意永久存在的想法相当模糊。 我认为有些事情通常很重要（尽管并非所有事情都适用于每种情况）：

Other related practices

在本节中，我将提到其他人的几个实践，这些实践在我看来也符合这种短暂性策略。 我不会将这些实践强加给自己（尽管在一种情况下我正在考虑它），但它们是相关的。

Corporate records management: scheduled deletion of email

一些公司有一项内部政策，即删除所有超过指定期限（比如一年）的电子邮件。 据我了解，通常的原因与诉讼的“发现”阶段有关，在该阶段（在某些情况下），对方公司获得相当广泛的权利，可以从您的公司内部挖掘东西，比如内部电子邮件，并试图找到支持他们案件的证据。 即使他们没有找到他们想要的证据，他们仍然可以从这些电子邮件中找到很多_不相关的_东西，即使他们输了实际的诉讼，也可能对您不利。 出于这两个原因，他们最初可以挖掘的东西越少越好。 当然，如果您在诉讼开始_后_匆忙删除所有电子邮件，那将是明显的非法销毁证据行为。 因此，这个想法是提前制定一个固定的政策并遵守它，以便您拥有删除相关电子邮件的可辩护理由：“我们一直以相同的计划这样做，这是我们的标准政策，与您起诉我们无关”。 即使如此，您可能也必须在特定诉讼进行期间暂停您的一年删除政策。 但至少这样，当诉讼开始时，他们只有_在_开始日期之前一年的污点可以挖掘。 我不知道我是否普遍赞同这一点，无论是从伦理上还是从系统设计的角度来看。 （当然，如果发现规则的范围过于宽泛，或者无论如何，这都是一个应该解决而不是规避的问题？） 但就像我上面的许多习惯一样，出于一个原因而采取的政策可能会带来不相关的附带好处。 如果您所在的组织使您受到此政策的约束，您会怎么做？ 您的电子邮件存档可能包含实际有用的信息，如果您必须在一年后删除它，您将丢失您想要保留的东西。 因此，您养成了_知道_电子邮件中的内容是临时的习惯，如果您在电子邮件中收到任何特别有用的信息，您会努力将其放在其他更合理的地方。 而且，就像上面的所有其他情况一样，您将其放置在一个经过深思熟虑的位置，直接与其主题相关。 这使得它实际上_更容易_在以后找到，而不是通过模糊地记住是谁发送给您的来在您的电子邮件中挖掘它。 （我不认为这违反了公司观点的记录管理原则的精神。我在这里考虑保存的那种东西更多的是“有用的编码和调试技巧”或“如何使用该内部 Web 系统做一些复杂的事情”，而不是“关于谁声称谁侵犯了谁的知识产权的有趣的八卦”！） 在公司环境中，您可能（或应该）关心的另一件事是减少“巴士系数”：不应该有任何只有一个人可以完成的重要任务，或只有一个人知道的重要信息。 这也是将有用的东西保存在您杂乱无章的电子邮件存档中是一个坏主意的另一个原因：如果您在有人需要知道那个关键事实的那天休假，或者已经完全离开了公司，也许没有其他人将该电子邮件保存下来以查找它。 因此，当您从刚刚收到的电子邮件中复制有用的信息时，您也可能会努力将其复制到_共享_的地方，比如您团队的 wiki，或一个包含文档的 git 存储库，或者您的组织用于此类事情的任何东西。 定期删除策略有助于鼓励这样做，因为一旦它迫使您将有用的信息移动到_某个地方_，那么将其放置在共享的地方比放置在私人的地方花费的精力不会多很多。 （甚至可能_更少_努力。） 但我不会为我的个人电子邮件采用这种做法！ 让雇主强加给您，并寻找一线希望是一回事，但我不会主动这样做。

Automated operating system setup from a recipe

另一种组织不完善且持续时间长的数据是特定计算机的配置。 在 Linux 上，我想到的是所有您在 /etc 中找到理由编辑的文件，在多年的过程中，可能在您每次更改后一周就忘记了您所做的一半更改； 您安装的确切的发行版软件包集，以及原因； 您使用 update-alternatives 或类似工具所做的事情； 等等。 在 Windows 上，这将是控制面板设置和注册表调整，您从各个地方安装的应用程序集（在 Windows 上，不太可能所有这些都来自同一个地方，除非您只使用应用商店中的内容）。 在这两个操作系统上，应用程序本身可能会在 /var 或 Windows 模拟的任何地方维护某种持续状态。 当然，如果对您很重要，您可以备份整个系统。 但这似乎是一种浪费的方法。 原则上肯定可以_描述_我的任何一台计算机的配置在一个小的文本文件中，例如“从 [发行版] 的版本 [n] 开始，安装 [软件包列表]，对配置文件进行 [这些] 更改，运行 [这] 组 mkdir、chown、chmod 命令等和 [那] 组 update-alternatives”。 像这样的文件将包含系统状态的所有重要细节，您可以更轻松地管理它。 它将占用 Kb 而不是 Gb； 您会将其保存在版本控制中； 并且您可以以易于阅读的方式布局文件本身，每个相关更改集群（即使它们位于不同的配置文件中）都与解释它们用途的注释一起保存。 在容器世界中，有一种完全像这样的东西：Dockerfile。 （就我个人而言，我更喜欢使用 Podman 而不是 Docker 本身，因为它具有非常好的无根模式，但 Dockerfile 格式在两者之间是通用的。） 我以 Dockerfile 的形式保存了一系列很少使用的操作系统配置，用于各种目的，例如我偶尔启动以测试 PuTTY 的 Kerberos 集成的非常小的 Kerberos 安装； 方便的是，不必让该系统的完整安装版本一直占用空间，而且每次我重新制作它时，我知道它与配置文件匹配，并且多年来没有逐渐偏离意外且未记录的调整，这也很不错。 但我不会以这种方式运行我的_物理_机器。 它们以更传统的方式安装，并且会遇到这个问题——如果我确实遇到完全备份失败并且必须从头开始重新安装我的其中一台机器，我确信在我停止绊倒缺少软件包或令人困惑的不同行为并将系统恢复到或多或少与最初开始时相同的情况之前，需要几个月的时间。 如果我什至能记住。 （我主要在这里谈论_系统范围的_配置。 主目录是一个单独的考虑因素，尽管单个用户的点文件集合具有一些相同的属性。 我更了解这方面的事情：我确实有一个有组织的 git 存储库，其中包含我的一些标准点文件，以及用于在其他文件中设置我喜欢的配置的脚本。） 我认为这与我时不时听到的将计算机系统“视为牛”的隐喻有关——相对可互换且有些可支配——而不是“视为宠物”，您与单个计算机系统建立持续的关系，如果它死了，就像失去了一个家庭成员。 我模糊地知道_有_通过某种配置文件管理物理计算机系统的方法。 “Ansible”和“Puppet”之类的词语浮现在我的脑海中。 但我从未费心学习一个并将其部署在我的个人计算基础设施中。 我一直在考虑这个想法。 特别是我的防火墙机器已经从头开始重新安装至少两次以上是不合理的（尽管是因为它改变了 CPU 架构，而不是因为备份失败）。 即使我只将_那台_机器转换为某种小型配置文件，那也将是一个胜利。 像桌面盒子这样更大的东西可以在以后出现。 以这种方式管理机器的另一个优点是，以后更容易重新安排角色。 如果我有一台机器目前执行两个独立的作业，而后来我决定应该为每个作业都有一台单独的机器，那么遍历一个注释良好的 Dockerfile 或类似的东西并找出哪些部分与哪些任务相关联并找到两台新机器的安装脚本不会太难。 因此，我_目前_不会这样做，但我受到了这个想法的诱惑，并且有一天我可能会开始！

Exceptions to the policy

我不会将这种短暂性策略应用于我生活的_所有_部分，甚至不会应用于我计算机使用的所有部分。 这不是我早期就决定并围绕它规划我整个生活的事情：这是我逐渐_注意到_似乎是我行为方式中一个始终如一的主题的事情。 但它不是普遍的。 正如我已经提到的那样，最大的例外是我永久保留了我所有的个人电子邮件——我不会像担心诉讼的公司那样对它们进行记录管理。 另一个例外是我的 Web 浏览器_历史记录_。 我使我的打开的选项卡集合非常小，并且我使我的书签井井有条并且受到版本控制； 但是我访问过的页面的历史记录是以一种我不希望我的 shell 历史记录的方式持久且不受控制。 当我想挖掘出我上周某个时候出于我无法提前预测的原因访问过的页面时（比如有人刚刚问我关于它的问题），我确实会使用它。 为什么这两件事是我通常策略的例外？ 我不能 100% 确定，因为我不是故意这样做的。 但我有一个想法。 电子邮件和浏览器历史记录有两个共同点：

  1. 它们是由其他人创建的内容，而不是由我创建的内容（或者至少不是_大部分_由我创建的内容）。
  2. 很难提前预测其中的哪些部分以后会变得有用。

我的 shell 历史记录（举一个我_确实_视为临时的例子）没有这些属性。 它几乎_全部_是我自己编写的命令——所以如果我偶尔从我的历史记录中丢失一个有用的命令，我不太担心，因为我上次是从头开始创建它的，并且我有信心我可以再次做到这一点。 一项严厉的丢弃历史记录的政策可能会偶尔浪费我一些时间来重写一些东西，但它让我丢失一些_不可替代的东西_的情况要少得多。 大多数 shell 命令都非常无聊（通常是 cd、mv、rm，以及永无止境的 ls）； 甚至_可能_值得保存的那些命令很容易被发现，因为它们跨越我的终端的三行，并且尝试了十次才能正确。 但是来自朋友、家人和前任恋人的电子邮件（例如）具有情感价值，如果我以后从头开始重写它们，显然会完全不同。 （甚至我_发给_那些人的电子邮件也不会。）而且关于技术内容的电子邮件以后可以派上用场，因为各种难以预测的原因：例如，有人报告我的程序中出现一条奇怪的错误消息，我发现它之前曾报告过一次，现在我可能可以看到这两个案例的共同点是什么——但可能是_任何_那些过去的错误报告，而重要的线索可能是消息的任何部分。 与我的浏览历史记录类似：其中的许多 URL 是我在跟踪链接时由网站提供给我的，没有我故意输入它们，而且同样，很难预测_哪一个_我突然意识到下周会帮助某人。 但我至少会将浏览器历史记录中的内容提升到我的书签中，只要我注意到我已经多次回忆起相同的内容。 我会查找我无法提前知道我将来需要的东西的历史记录，但只要我可以合理地预测我将来需要某样东西，就值得将其变成书签。 因此，这两件事不受我通常的短暂性策略的约束。 我对此感到模糊的不满（特别是浏览历史记录），但目前没有任何改变它的计划。

Conclusion

正如我一开始所说，我无意_说服_任何人以这种方式行事的正确性。 它对我有效，但不同的事物对不同的人有效。 但我认为许多相反的习惯被视为“默认值”，而没有真正考虑它。 因此，可能有些阅读本文的人甚至没有_考虑_过其中的一些可能性，并且可能正在做相反的事情（例如，_增加_他们对 shell 历史记录的依赖，而不是减少它），仅仅是因为这似乎是唯一一种可能性。 因此，我仅将所有这些作为思考的可能性提供。 如果其中的任何一项对您有用，那就太好了——如果您考虑一下并决定您