nanjj

除了花瓣邮箱，我还有三个邮箱：

1. Gmail，
2. QQ Mail，
3. 139邮箱。

我之前主力邮箱是Gmail。Gmail在没有合适代理的情况下在国内很难直接使 用。我把Gmail邮箱配置在QQ Mail的手机客户端里，QQ Mail帮我翻墙出 去，我勉强可以收发信。可谓细若游丝，命悬一线地在用。使用场景也剩下唯一 的一个：发电子书到 Kindle 邮箱。亚马逊有个服务听在那，把附件转化后推到我 的 Kindle 上。

因此在国内Gmail作为主力邮箱是不合适的。

如今仔细看花瓣邮箱，发现其目前只支持手机客户端和 Web 客户端收发信，不 支持任何一种协议包括 POP3，IMAP 以及 SMTP 协议。花瓣邮箱也没有帮助文档， 当你需要帮助的时候，"智能助手"跳出来回答你的问题，是问答式的，经常所 答非所问。勉强从一个问题回答的侧面推断出花瓣邮箱暂不支持第三方客户端， 也就是不支持 POP3, IMAP 以及 SMTP 协议。另外我迟迟收不到确认信。基本打消了 我把花瓣邮箱作为我的主力邮箱，配置在 Emacs 里使用的 x 想法。

QQ Mail倒是支持主流协议，但需要打开一下。在打开 IMAP 和 SMTP 协议支持的 候，QQ Mail提示下载 QQ，做一些安全方面的校验。但我在 Linux 下到哪里去下 载 QQ 呢？链接指向了一个 Windows QQ 下载。难道是要我用Wine将其灌醉，然后 加载运行吗？这种无脑设计让人不知道说什么。最终放弃扶正 QQ 邮箱的打算。

139邮箱提的口号是手机号就是邮箱。但手机号当邮箱使用又有手机暴露的风 险。这也是我一直没有怎么正经用的原因。如今回头重新看 139 信箱，发现它提 供了邮箱别名的功能。选名的过程中发现139邮箱帮助文档非常详实，各种协 议支持完备。打开协议支持也需要一些安全方面的验证，但是使用的是手机验证。 那这就方便多了。

在Emacs配好139邮箱后给Drew DeVault发信，问他确认信没收到的事。他 很快回信，告诉我花瓣可能哪里配置的不对，他发到我花瓣的信被退回来了。这 证实了我的猜测。

这里正告花瓣邮箱:

1. 老老实实把基本功能做好

   邮箱一定要能收发信，收不到信的邮箱叫什么鬼邮箱？！

2. 老老实实去支持基本的协议

   支持 IMAP 和 SMTP 协议，方便第三方客户端配置，而不要贸然以云之名把这些 历史沉淀下来的东西扬弃。

3. 老老实实去写帮助文档

   用一个所谓 智能助手 的东西去糊弄是不行的。

于是重回 Gnus 怀抱。配置信箱，订阅邮件列表，写信，读信。

读 Gnus 的 info 文档，拉倒最后，有一首小诗：

*Te Deum*


Not because of victories
I sing,
having none,
but for the common sunshine,
the breeze,
the largess of the spring.


Not for victory
but for the day’s work done
as well as I was able;
not for a seat upon the dais
but at the common table.

这首诗让我莫名感动。

新闻组已死。国内只剩新帆（news.newsfan.net）一息尚存，也没啥有用信息。 Emacs Gnus 对新闻组里中文的支持，在历次重构过程中给弄没了。有人在开发邮 件列表里提讨论，可能有很好的挽救方案。国外的新闻组感觉也没啥新内容。但 邮件列表的确是很好的沟通方式。

Emacs 开发一直用邮件列表沟通。除此外我感兴趣的，比如：

1. Linux Containers,
2. Rust Lang,
3. Graphviz

等，背后都是邮件列表的运作模式：

1. 一个 Web 前端，满足习惯 Web 界面的用户需求，
2. 可订阅的邮件列表，满足习惯邮件订阅的用户需求。

我觉得对程序员而言，对散布在世界各地的程序员而言，邮件仍然是最有效的沟 通方式。国内常用微信群，有效的沟通很难展开，有价值的信息很快淹没在信息 的洪流里。还有就是微信公众号，是一种单向沟通，离协作差得远了。

因此还是简单干净的邮件，把大家联系起来。通过邮件协作，通过邮件驱动学习。 驱动开发，以至于整个开发流程，可能是一个现实的方向。

邮件驱动整个开发也是 Linux 内核开发的主要模式。为此Sourcehut专门写了个 网站Git Send Email来说这件事。

我按其步骤一步步走下来，基本是工作的，除了最后的发的信被退回。我把退信 扔给 Drew 看，看发生了什么。

=git send-email=是 Git 内嵌命令，虽然是内嵌命令，一般的 Linux 发行版还是会 分开打包，比如 Ubuntu：

apt-get install git-email

=git send-email=可以把需要的变更以 email 的形式发出去，发到邮件列表或者 某个代码仓的维护者。内容基本上是=git format-patch=的生成。因此在 =~/.gitconfig=需要配置（也可通过=git config –edit –global=来改)：

[sendemail]
    smtpserver = <smtp server>
    smtpuser = <smtp user>
    smtpencryption = ssl
    smtpserverport = 465

在代码仓的=.git/config=（也可以用=git config –edit=修改):

[sendemail]
    to = <the git repo's email list or owner's email>

我相信邮件驱动的开发流程是有效的。

这里把邮件驱动的开发梳理一下。

dot process digraph { rankdir = LR D [label = "开发者"] C [label = "Chat"] L [label = "邮件列表"] G [label = "代码仓"] B [label = "构建"] S [label = "网站"] T [label = "TODO"] E [label = "EBot"] D -> C [label = "聊天"] E -> S [label = "发布"] D -> L [label = "补丁"] E -> G [label = "合入"] E -> B [label = "构建"] D -> L [label = "意见"] E -> D [label = "检视"] D -> L [label = "Bug"] D -> L [label = "特性"] E -> T [label = "问题跟踪"] E -> T [label = "特性跟踪"] L -> E[label = "侦听"] C -> E [label = "记录"] E -> B [label = "测试"] E -> L [label = "结果"] E -> B [label = "集成"] E -> B [label = "部署"] E -> B [label = "升级"] }

开发者在聊天室和邮件列表交流，沟通，提特性，发 Patch，相互代码检视，并 不直接操作代码仓。邮件列表和聊天室里有一个 EBot，默默关注这一切。EBot 负 责代码检视流程的推动，负责代码合入，负责调用构建服务来测试代码，负责使 用构建服务来集成代码，完成 CI，负责部署，升级来完成 CI。负责发布文档到网 站服务，负责特性跟踪和 Bug 跟踪到 TODO 服务，负责记录邮件列表和聊天内容， 并归档到网站服务。

这是Sourcehut正在做和正要做的特性。这些特性要以 100%开源的形式做出了。

这些特性深深吸引了 Emacs 的开发者：

站在能分割世界的桥
还是看不清
在那些时刻
遮蔽我们
黑暗的心
究竟是什么

住在我心里孤独的
孤独的海怪
痛苦之王
开始厌倦
深海的光
停滞的海浪

站在能看到灯火的桥
还是看不清
在那些夜晚
照亮我们
黑暗的心
究竟是什么

于是他默默追逐着
横渡海峡
年轻的人
看着他们
为了彼岸
骄傲地
灭亡

一般的公司，都会有一个代码仓服务。一般是基于 Git，要么 Github 企业版， Gitlab 或者自研的一个 Git。这会是个核心。

围绕核心 Git 服务，会搭建流水线，这时候的备选有以下几种风格：

1. Jenkins，
2. Travis，
3. Gitlab CI/CD

有一个需求管理系统，有缺陷管理系统。 这里的备选有：

1. Github/Gitlab Issues，
2. Bugzilla，
3. 工单系统，需求单系统等。

需求、缺陷写到 Git Commit 消息里，会有一些约定，比如#需求号或#缺陷号。这 样需求，缺陷就和代码关联起来了。 这块基本跟随 Github/Gitlab Issues 的处 理办法。

代码检视主要跟随 Github/Gitlab MR 或 PR 的做法。

程序员之间沟通基本靠开会。也有公司意识到会太多会限制开会。会议会有会议 纪要，会议纪要要执行。因此还有一个会议系统。

CI/CD 这些就归到流水线了。而一谈流水线，Jenkins 就又复活了。

Github Pages 也有在用， Wikis 也在用，文档管理工具也在用。信息散布各处， 形成信息孤岛。

程序员基本活在各种流程和系统里，被流程和系统追着跑。

读Drew DeVault博客。读到Getting Started With Qemu。他介绍了他对 Qemu 的使用，阐明了 Qemu 的好处，最后他说：

真没有借口用其他管理程序，和 qemu 相比都是狗屎。

我由此打消了向他推荐 LXD 的想法。

在Rust is not a Good C Replacement 里，Drew DeVault有一些有趣观点，试摘录如下：

Go 是 C 程序员设计的新语言，Rust 是 C++程序员设计的新语言。

这是自然的，近乎于描述事实。但能鲜明地点出，让人不禁眼前一亮。

C++程序员与 C 程序员的价值观绝不兼容。

C++和 Rust 语言有问题就加特性，C语言有问题去加代码。

并给出 C，C++，Go，Rust 语言特性年增长率：

预言 Rust 终将失败：

玩各式花活，啥也不精，和 C++一路货色。

智慧的语言设计者，始于小，并保持小。

得出结论：

Rust 是 C++的接班人，而不是 C 的。C的接班人是 Go。

这结论也没啥问题，甚至有些平铺直叙。但像一般真理一样，当它在你面前袒露 之前，你并不知晓，展开之后，又觉得理所当然。

Rust 语言我也在学，不过我有些犹豫，有些怀疑，Cargo 包管理实在惊艳，因 此没有这么爽快否定。

也有一篇关于中国的。 先分析中美经济形势，中国制造一切，美国贸易逆差严重，美国买中国商品：

只是因为中国的便宜，但便宜为了个啥？

他认为应该和中国切割。为什么应该切割呢？后面的逻辑就理不顺了。因为中国 的人权。中国没有人权。香港，台湾，澳门的自由斗士应该分裂出去。重复耸人 听闻的关于罪犯器官贩卖的谎言。到这里这人已经疯了，从一个单纯善良，甚至 还有点理想主义的程序员，变成一个双眼血红的怪兽。

他有感觉西方的衰落，中国的崛起，他神本的，线性的思维接受不了这些。他深 深的自卑，不自信掩藏在长长的参考文献里。他不再是一个真正的程序员。 也 是可悲，执着于独立思考，被洗脑到如此程度。

我写信给他：

干脆扔 14 亿颗氢弹把中国炸了得了。

他没有回信。

发现一个有趣的东西，Gemini。在 Emacs 下有客户端：Elpher。

Gemini 是一个只读协议，用于超链接内容分发。

那 http 协议不是个只读协议吗？还真不是。 http 的 GET 方法是只读， POST ， PUT 等方法是可写的。但 Gemini 也可以输入，但这输入是作为过滤，用来 输出内容的。

那这个只读的协议有啥好处呢？ 是简单。另外这个协议对图表，图片显示处理 的也不好（或者就没有），因此就只剩下只读的文本，外加超级链接功能，使得 文字非常纯粹。