学海无涯
最近工作需要安装了一台运行 Debian 11 系统的电脑，不知道是不是很久没安装 Debian 系统的原因，惊讶地发现 root 用户的路径少了很多，比如 /sbin, /usr/sbin 路径等。这些路径都是一些系统管理员级命令所在，不清楚什么原因没有加入 root 的默认路径。
不想影响其他用户，因此只要单纯修改 root 用户 HOME 目录下的”.bashrc”文件，在该文件尾加入以下语句即可：
export PATH=$PATH:/sbin:/usr/sbin:/usr/local/sbin来自雪球球友的整理，请点击链接访问。
家里有台 Raspberry Pi3， 日常做点小任务，比如做 samba 服务器当 NAS、做 web 的功能测试、学习点 Linux 知识等，基本都是一些负荷不大的任务。不过由于我是死忠的 GUI 党， 因此总是喜欢进入 Pi 那个巨丑无比的界面里进行操作，这也导致 Pi3 的内存会逐渐显得有些捉襟见肘，时间长了，就不得不使用 swap 。这可能会有损 microSD 卡的寿命，因此希望 Pi 能定时清理、释放内存。
网上搜了搜，也比较简单，而且效果比较明显。简要记录一下：
在 /etc/cron.daily 目录下，创建一个 gilson-clearcache 文件，内容如下：
#!/bin/sh
sync
echo 3 > /proc/sys/vm/drop_caches将这个文件设置为可执行文件即可：
sudo chmod +x ./gilson-clearcache
设置为可执行文件后，可以手工执行一下，可以看到 “free -m” 显示的结果里，“buff/cache available”等项有明显的改善。
不过考虑到 Pi3 可怜的 1GB 内存，这种内存回收方面的改善，估计不能从根本上解决问题，上 Pi4 （2GB或者4GB）或许更好。后续继续观察一下，如果实在不行，就换 Pi4 或者等 Pi5 吧。
这是早期的一些公开信，收集、综合到一个 PDF 文档中，以便下载、打印、学习。请点击此处下载。
目前在伯克希尔官方网站上，公开的信件是从 1977 年开始的，其他更早年份的信，虽然可以在网络上搜索到，但是没有官方的认证，很难辨识。因此以官方提供的资料为准，没有收录 1977 年之前的公开信。
这些信件受制于当时的排版、网络等技术，采用了非常粗糙的 HTML 格式，极为不方便打印，这也是我收集并整理成一份 PDF 文件的初衷。同时，将原 HTML 文档中晦涩的表格，转换成了 word 的排版方式，会更有利于阅读。
1997 年之后的公开信都提供了 PDF 文档，已经很适合阅读和打印，因此暂未收入这之后的公开信。后续如果有时间，再考虑整理成一份 PDF 文件。
本次只整理了英文原版信件，后续将陆续整理中文版信件。老实说，我低估了整理的工作量。先前整理、翻译 2020 年信件时，以为每年大概就15页左右的内容，加上一、两个小表格，轻率地决定着手前面这些年信件的整理工作。事实证明我还是太年轻。四十几年前，巴老就已经是“话痨”了，而且热衷于变着花样弄表格进行炫耀……
PDF 文件里可能会有一些错误，毕竟整理了太多表格后，我时不时会头晕，并产生错觉：“我是谁？ 我在哪里？我在干什么？” 如果有朋友发现了错误，请联系我进行修改，谢谢！
原文链接，请点击这里。
新浪网翻译链接，请点击这里。
个人的吐槽、更新：
我一直很奇怪这信（英文版）的排版格式，例如段落没有顶格、各种奇怪的分割符、字体严重过小（这是为了把 S&P500 对比表格完整放在一页内吗？）。 信的内容当然毋庸置疑的珍贵，就是有点太不讲究格式了。
“Two strings to our bow”在新浪的翻译文中，简单粗暴地翻译为“我们弓上有两根弦”，太硬邦邦了。另一位译者翻译成“两条盈利的线路”，稍好一些。但其实更合适的翻译，应该是“两手准备”的意思。老巴在这节中主要想表述伯克希尔对待好的商业、好的企业的两种方式（1）100%控制 （2）非控制地拥有部分权益。两种方式都很好，关键是企业本身，而是否完全掌控这些企业则不重要。
2021-03-01 更新： 关于英文版的格式，老巴的秘书应该是采用英式的格式，即每段开始处都缩格。数了一下，正好是缩进 8 个字符。从 IT 人员的视角分析，这位秘书是用 Tab 键进行缩进。更有可能她以前习惯用打字机，这大概能解释其他古怪的格式 ……
2021-03-06 更新：这周抽时间阅读了原英文版，并根据网络的一些现有翻译，整理出了一份PDF格式的中文版，方便打印出来学习，也欢迎同学们来信斧正。谢谢！
新闻链接，请点击此处。
这个其实不算复杂，但是经常看到一些小白对此有很大的误解。比如某天在雪球上看到一位朋友，宣称自己从2017年到2020年，四年间收益增长了160%，因此年复合增长率是40%（160%/4，就是这么简单粗暴）。
当然这样是错的。小朋友都知道“国王和棋盘”的故事，第一个格子放一粒米、第二个格子放两粒米、第三个格子放四粒米…… 这样才叫复合增长，计算公式是：
(1+x)^N
其中，x就是增长率， N是计算周期值（例如年份数、格子数）。在小朋友的故事中，x=1，N=棋盘格子数（难怪最后国王要斩了狡诈的棋士）。
对于上述朋友的示例，其实是知道计算结果（即总值 2.6=1+1.6），N=4（年份数），反过来计算 x 是多少。可以用 windows 自带的计算器快速计算，如图采用”科学“面板计算：
由于这位朋友的收益率是160%，总量最后是 2.6，年份数是4年，在计算器面板操作如下：
输入2.6，点击xy，输入4，点击1/x，然后点击=，得到1.27 （这就是开根号的过程）。
然后 1.27 – 1 = 0.27。
即，这位朋友四年的年复合增长率是 27%，远远低于40%。不过从投资角度讲，能做到 27% 的年均增长率，也很厉害。如果后续仍然能保持这个增长率，那就相当惊人了。
主机是Window 10， 运行在 VirtualBox 中的客机系统是 Debian （testing）。当初估计不足，只划了 8G 空间给客机系统，因此面临着容量不足的问题，迫切需要扩容，要不然就要重新构建一个客机，实在过于麻烦了。
从网上搜集了一些信息，有各种问题。绝大部分的资料其实不能算扩容，无非就是增加一个盘，然后 mount 到新的分区而已。而我希望是将现有的虚拟硬盘直接扩容，无需改变或者 mount 特定的分区或者目录。最后通过安装 GParted 软件，加上修改部分配置，终于解决了问题，从8G 扩展到 28G， 如下图所示：
系统只有两个分区： 主分区 和 交换分区。目的就是扩大主分区（/dev/sda1）的容量即可，其他无需改变（至少在使用者的角度是没有任何变化）。
VBox 新版都支持给虚拟介质扩容，操作简单。在“管理 – 虚拟介质管理”里找到客机的虚拟介质，直接增加容量即可。比如，将介质从 8G 直接调整到 28G。
但是客机系统不是直接就使用了扩容的硬盘容量。新增加的部分对客机系统而言，属于“未分配”的容量，因此需要进入客机系统（也就是 Debian）中进行磁盘管理，让系统能识别、管理这部分新容量。
牛人直接用 fdisk 大概就可以搞定。作为一名无可救药的图形界面党， 我当然还是倾向于使用图形界面的软件来解决问题（非常不 linux，非常不 geeker），也就是 GParted。
GParted 很像 Windows 的磁盘管理工具，因此使用起来油然而生熟悉的感觉。启动 GParted 后，很容易就看到未分配的磁盘容量。可惜不能直接移动或者扩容/dev/sda1，原因大概是中间有个 swap 分区。刚开始我被困住了，后来想明白：
既然 swap 分区阻挡了主分区的扩容（移动），那删除掉 swap 分区，那主分区和未分配分区不就连起来了吗？ 试试后发现果然如此：（1）删除 swap 分区， （2）调整主分区（/dev/sda1）的大小，（3）然后再重新将剩余的分区设置为 swap 分区。
千万别格式化主分区！只需要重新格式化 swap 分区即可。
GParted 有个bug：在上述步骤中，重新删除、创建了 swap 分区，可是 GParted 并没有修改 /etc/fstab 里对应的 UUID 值！导致每次重启后，发现 swap 区都没有激活使用。
解决这个bug也简单，在 GParted 中查询 swap 分区的属性，获取其 UUID 值，然后修改 /etc/fstab 中对应的 swap 分区的 UUID 值即可。
本次扩容过程中，被 swap 分区困扰了很久，有各种问题。要么是 swap 分区阻挡了主分区扩容，要么是 swap 分区的 UUID 更新（这个算GParted的bug）。
如果不设置 swap 分区呢？ 修改为采用 swap 文件方式，只保留一个主分区，这样就灵活很多。当然，实际部署 Linux 系统如果采用这种方式，可能会有问题（比如崩盘导致数据丢失等），既然是客机系统，倒是无所谓。
正在看一本投资方面的书《段永平投资问答》，相当好的一本书，居然是免费的。里面谈到关于长期投资的一些观点，据说段永平是两三年才有一个好想法、两三年才出手一次。
书中也提到：芒格说伯克希尔成立57年来仅仅10个好点子，去掉这十次，整个就是笑话。
打开证券软件，看了一眼2020年的操作记录：
交易股票100次、交易股票12只！
不禁流下了贫穷且没有格局的泪水……
传统的 DNS 基于 UDP 协议，并且采用明文方式传递请求和结果。在互联网早期，这样做没什么问题。而现在网络越来越复杂，网络实体越来越多，各种看得见、看不见的手都可能修改 DNS 的结果。
简单的解决方式就是对 DNS 进行加密。 Mozilla 联合 Cloudflare 通过 HTTPs 来传递 DNS 消息，也就是 DoH （DNS over HTTPs）。这种方式从设计上看，不如 DNS over TLS 高效，但是胜在简单、无需过多更改网络设备和软件。
Firefox 已经内置了对 DoH 的支持，而且非常简单。问题是默认的两个 DoH 服务商：Cloudflare 和 NextDNS，在国内由于某种不可描述的原因，访问速度都很受影响。实际上国内腾讯和阿里的公共 DNS 服务也支持 DoH，以腾讯为例，它提供的 DoH 访问地址是：
https://doh.pub/dns-query
Firefox 的网络设置中，按下图进行配置即可：
另外，阿里提供的 DoH 访问地址为：
https://dns.alidns.com/dns-query