Roastidio.us Tagged with 技术

静态网站的托管方法

Mon, 07 Sep 2026 14:35:05 +0000

我之前一篇博客曾经推荐过各种发表过个人博客的方法，最终推荐的是github pages. 最近，我又做了一番研究，发现其实有很多种方法，每种方法都免费，无广告，包含自动SSL证书，自动使用全球性CDN保障速度和可靠性。事实上，在这个网络年代，小数据量，低流量，静态内容服务的市场价格就是零！

Github Page

Github Page上次已经提过，这里再复述一下。使用github page，你可以轻松创建一个静态网站服务全球：

使用 XXX.github.io 二级域名
1GB 存储空间
每月 100GB 流量
每小时更新10次

虽然github的目的是给托管在github上的软件项目提供一个主页空间，但github目前并不限制内容范畴，个人博客是明确在允许范围内的。

Netlify

Netlify是一个startup，提供比github page更高级的静态网站服务。按照它的理念，所有网站都应该是静态网站，使用各种 serverless 的API服务，在客户端通过Javascript 平台集成在一起，即所谓JAMStack (Javascript, API, Markup) 设计. Netlify 提供了：

大量可随意使用的网站模版
高级web console，一键式首次部署，git驱动CI／CD (Continuous integration / Continuous Deployment)
大量可订制的 API 服务
全球性CDN确保速度和可靠性
内建CMS (Content Management System)

而且网站是你的，网站上全部内容都由你控制，Netlify 没有也不能嵌入广告或种种获取网站访问者隐私的方法。初阶服务仍然是免费！

Vercel

Vercel/Zeit Now

Vercel和Netlify比较类似，也是一个startup. 它之前叫做Zeit now, 今年初重新融资后改成现在的名字，可能觉得新名字更像个公司意思吧。它的服务范畴与Netlify相似，也是JAMStack 平台网站托管部署。Vercel 是目前最热门的 javascript 框架 Next.js 的核心开发者，提供的服务虽然没有netlify这样包罗万象，但在技术深度，和服务质量上恐怕更胜一筹。

Surge.sh

与 Netlify 和 Vercel 不同，Surge.sh 提供的服务相当基础，甚至不包括 github 集成和CI/CD. 但也覆盖了：

快捷命令行部署
CDN 服务
自动 SSL
内容 100% 控制
无明显空间，流量，更新频率限制

评价

首先声明的一点是我对 JAMStack 的了解相当粗浅，Javsscript 环境用的也不多，甚至带有一定畏惧和鄙视情绪。我只能评价作为一个静态空间托管服务的优劣。

Github page

github page 理论上来说不是让你做任意网站的，也没有CDN功能。当然对于个人博客这么小流量的应用其实也没有什么所谓。github page自己不提供任何API端点，但可以使用github内部的API，或者第三方API，但本身不提供任何集成服务，一切都要自己来。

Netlify

netlify提供的功能最为强大。使用它的各种模版，CI/CD流程，以及网页集成CMS，理论上你无需在本地安装任何软件，单凭一个浏览器点几下就能生成功能强大的网站，并能从网页CMS上持续维护更新内容。真正做到了零代码。但是，昨天我鼓捣了半天，发现：

某些模版其实不是很靠谱
网页CMS功能对于技术人员来说比较鸡肋
功能太过强大，其实提供了很多方法割伤自己

是的，你是可以做零代码网站，但一不小心搞坏了还不得钻进去debug，这个落差就大了，对模版网站技术栈不是很了解的人，包括我自己，其实挺难搞的。

Vercel

Vercel 不提供CMS之类的傻瓜式功能，对非javascript 框架的支持有限。如果你对 Javascript, Next.js 等技术深有了解的话，这可能是一个很不错的服务，可惜我不是，所以我也没有继续尝试下去。

Surge.sh

surge和以上几家不同，它完全不提供CI／CD，甚至不需要git存在。它的网站上完全没有任何功能，但它提供一个相当简洁的命令行工具，注册用户，上传内容，简单管理都在这里面了。我上手没有任何壁垒。几秒钟后，我的整个博客就镜像到它的CDN里了：derekzhou.surge.sh，包含二级域名，SSL，合理有效的缓存管理。即使从我本地来看，速度也比我本来的VPS快一点。所以，surge是最适合我的。

缺点也很明显。surge.sh并不是一个startup, 我强烈怀疑它其实后面就只有一个人。免费服务虽然好，但它的付费层要一个月30美元，和netlify与vercel的付费层比起来完全没有竞争力，毕竟在那里有更多更丰富的服务。从盈利能力来说，我相当怀疑surge的长期生存可能。当然，从历史来看，surge也有四五年历史了，在互联网业界已经相当不错，我姑且相信它能存在更长时间。

我的推荐

surge的免费服务相当简便，对于个人博客来说也完全够用。surge目前还不限制容量和流量。以我的个人博客而言，目前有七十多篇，一共未压缩才13MB多点，全部上传到surge才几秒钟时间，实际流量也很小。如果你的网站体量超过几百兆大小，估计就不是很好上传了。其实到这个体量，不管surge还是其他几家都不适合，付费不付费也一样，这些服务不是给你存大量文件例如如影集用的。

Netlify和Vercel其实也有命令行工具，剥去它们的层层功能，其实也可以当surge来用，只是还稍显复杂一点。它们的CDN无论如何只可能比surge的好，所以虽然是牛刀杀鸡，其实也是不错的选择。

Github page相比起来就稍显逊色，对于静态网站来说，最主要的是缺乏CDN功能。它其实也可以做到单条命令部署，但目前珠玉在前，只能向后挪挪了。

感谢技术进步，让构建自己的平台发表言论这件事变得完全免费，并且向所有人开放。

可惜世界上有些地方还有良民证 (ICP许可证) 这件事。

后记

经过一番挣扎，我终于搞定了vercel的命令行工具。现在我觉得vercel是目前最好的选择：

vercel的网络明显比surge快点
vercel在免费层已经支持客户提供的域名，并帮你做了非共享的SSL证书。surge不行
虽然我的博客在它那里build不起来，但可以绕过去直接上传，花的时间不比surge慢几秒。请看这里: blog.3qin.us

对于一个不是很懂技术的普通人来说，Hugo + Atom + Github + Vercel 已经是很方便的博客平台，免费，安全，无广告，保护用户隐私，不用写一行代码。wordpress的意义已经接近于零。我下一篇博客会做一个较详细的介绍。

Erlang 中的字符串

Mon, 31 Aug 2026 09:04:38 +0000

在所有编程环境中，字符串都是非常常见常用的数据结构，在Erlang也是一样。但是，主要字符串经验来自perl和c的我一头撞进了Erlang的世界，撞出了满头的包。这里我总结一下我过去一个月的经验教训，希望对读者和未来的我有所帮助。

Erlang中的各种字符串

在大多数编程环境中，字符串只有一种，或者最多少数几种。但是在erlang中，字符串的表达方式有很多种，甚至可以说无穷种。

单链表字符串

Erlang是一种函数式语言(FP). FP和OOP的区别我之前已经写过。Erlang深受函数式语言的鼻祖Lisp影响，最基本的数据结构是单链表。所以，最传统的字符串表达方式是单链表：[$h, $e, $l, $l, $o] ，简化写法就是 "hello". 每一个字符用一个整数表示，放在一个单链表（不是数组）里。这个链表的头是包含字符h, 和一个指针指向下一节，这下一节包含字符e, 和指针指向再下一节，直到最后，尾指针指向空表nil. 如果是ASCII可以表示的字符，则这个整数小于128，用一个字节表示。复杂字符用unicode表示，其数值大于255.

单链表字符串是最方便处理，也是最方便用常量表示的字符串，erlang核心库函数大多要求单链表字符串，例如文件名什么的。

二进制字符串

单链表字符串有个最大的毛病，就是占内存。以上述”hello”字符串来说，包含5个小节，每个小节包含一个整数，就是八个字节，和一个指针，又是八个字节。加在一起有89个字节，还不包括一些其他代价。在c语言中，同样的字符串能被6个字节表示，即五个字符和一个\0空字符。这样看起来不是太浪费了一点？

二进制字符串 (binary) 就是为了解决空间效率问题。Binary在这里其实应该理解成无结构字符串。在erlang常量写法中，表示为 <<"hello">>. 如果要表示复杂字符，例如汉字，则要加编码标记如： <<"周溱"/utf8>> . 它的意思是字符串 "周溱" 用utf8编码，写成紧密的一堆字节。这和其他编程语言就非常类似了。erlang只需要维护内存分配的元数据，例如长度等，就可以用最空间紧凑的方式表示任意字符串。

erlang核心库函数中做字符串处理的部分，例如string和re模块，都在支持单链表字符串的基础上，还支持二进制字符串。

高级字符串

二进制字符串虽然空间紧凑，但和单链表字符串比起来，用函数式语言处理相对不方便。例如，我们要把两个字符串接起来，如 "hello" ++ "world", 用单链表只需要做链表操作，而用二进制字符串则必须做内存分配和内存拷贝。假如binary长的话，这代价不小。所以，还有高级货。在erlang中，广义上字符串的定义是：

整数，代表单个字符
Binary，代表编码后的一段数据
单链表，其中每节都是字符串

注意，这个定义是递归的。所以，"hello" 是字符串，<<"hello">>是字符串，["he", <<"llo">>]也是字符串，等等。同一个字符串，可以有无穷种表示方法，甚至空串也有无穷种表示方法！erlang核心库函数中做字符串处理的部分，例如string和re模块，其实支持的是高级字符串，这些模块中函数的返回结果，有可能不是简单串，完全取决于你输入的是什么，输出是怎么方便怎么来。

所以说，如果你不是自己构造的字符串，你不可以用erlang模式匹配或者==来判断，而必须使用string:equal/2, string:is_empty/1 等等库函数来做判断。否则就是隐藏很深的bug.

iodata

iodata不是字符串，但和字符串深度相关。它的定义同样是递归的：

整数，代表单个字节
Binary，代表一段任意数据
单链表，其中每节都是iodata

和字符串很像，对吧？但是一个字符串未必是iodata，因为可能包含大于255的整数字符，一个iodata也未必是字符串，因为可能包含unicode中不包含的非法字符。erlang中所有输出函数支持的其实是iodata，而不是字符串。因为输入输出凭什么一定是unicode合法字符串呢？

规范化处理

当然，erlang提供标准库函数来把各种奇形怪状的字符串规范化成字符链表 unicode:characters_to_list/1，或单一二进制串 unicode:characters_to_binary/1. 这函数名字有点长。有时候你可能会倾向使用 lists:flatten/1，但这也是bug：因为它不能展开binary：

1> lists:flatten(["he", "llo"]).
"hello"
2> lists:flatten(["he", <<"llo">>]).
[104,101,<<"llo">>]

规范化处理其实也是有相当代价的，所以要谨慎使用。

怎么办

为了防止程序员精神错乱，我强烈建议在程序中遵守一定的规则：

不要使用大于127的零散字符

就是说，"abc" 没问题。但 "周溱" 有问题，一定要写成复杂一点的 <<"周溱"/utf8>> . 只要你遵守这条规则，字符串就成为了iodata的子集，因为你总会有一天试图把处理后的字符串当作 iodata 来用的，到时候你的程序就会崩溃。其实，任何零散字符对于输出来说很不经济，但少量ASCII字符无伤大雅；零散长字符就不仅是效率的问题了。

松输入，紧输出

Be conservative in what you send, and liberal in what you accept. – Jon Postel

你的程序提供的接口不要对输入做过多假定。假如你的输入是字符串，那么只要你保证使用 unicode, string 和 re 模块中的函数来处理，那你一定是安全的。假如你的输入是网络或文件，则erlang库函数可以保证读出来的是不定长度的binary，你把这些bianry放在链表里当字符串也没错。

但你程序的输出接口越规范越好。假如你的程序直接面向网络或文件输出，那么只要你能确保没有大于127的零散字符，就不用规范化处理。其他所有情况，请规范化成binary，这也就是Elixir的实际规范。

总结

Erlang有35年的历史，这历史带给erlang无以伦比的强壮性，和一定的历史包袱。elixir是erlang的简化增强版，例如在字符串处理和输入输出上大大方便了程序员的工作。在大多数情况下我们应该使用elixir。但是elixir程序员必须了解erlang，读懂erlang, 然后写一点erlang，这样才能更深入理解erlang/elixir体系的所以然，才能更好武装自己。

创作者经济里的经济学

Mon, 13 Jul 2026 15:01:49 +0000

近两年有个词挺火：创作者经济 (creator economy) 。它指的是独立的内容创作者，在各大社交媒体平台上有偿传播自己创作的内容，从而获得经济收入。社交网络上绝大多数的内容都是用户辛苦创作而来，其中不少都颇有价值。创作者创作需要花时间和精力，所以他们理应得到一定的经济补偿，不是吗？今天，我们就从经济学角度来分析这个现象，看我们能找到什么本质。

经济学原理回顾

有些朋友没有学过微观经济学，有些朋友虽然学过，但可能也忘的差不多了。我先回顾一下几个基本概念，自由市场，供求关系，和市场价格。在一个自由市场中，有很多个供应商，有更多个消费者。一个商品的价格由供求关系决定。供应曲线和需求曲线如下图。一般作图X轴是数量，Y轴是价格。所以，需求曲线是一个单调下降曲线，因为每个消费者自己对这件商品的心理价值定位不同，价格越低则愿意购买的消费者越多，所以商品的需求量也越多。同理，供给曲线是一个单调上升曲线，愿意供货的供货商随价格上升而增加，所以，供应量也就越多。两条曲线的交点就是市场价格。

Total Surplus

以市场价格作一条和X轴平行的直线，这条线和供给曲线之间的面积就是供货商们总体获得的收益 (Producer Surplus). 反过来，这条线和需求曲线之间的面积就是消费者总体获得的收益 (Consumer Surplus) . PS和CS的总和就是这个市场活动的总体价值，我们常常听说某某厂商“创造价值”，其实就是开创了市场，带给供求双方以收益。

独立的内容创作者们当然创造了价值。但传统上，社交媒体上内容不收费，所以他们获得不了他们应得的生产者收益 (PS) 。在创造者经济的概念里，就是要改变这个现状，给创作者以合理的回报。这件事有道理吧？

错，创作者经济是一个骗局，独立的内容创作者不应，也无法获得经济回报。 这不是什么道德或法律的约束，而是经济学决定的。

价值 =/= 价格

看到这里的朋友可能不理解了：是的，价值不等于价格，但创作者并没有要求拿到他们创造的价值的全部啊，拿一半，留给消费者一半，不是很合理吗？比如说这篇文章吧，假如对于你带来的知识性娱乐性价值为一块钱，那么你给我五毛不是很合理吗？

回到上面的供求曲线。可能大家有个误解，就是供给曲线的Y值是什么含义。是的，它是成本，但不是总体成本，而是 边际成本 。举个例子就好理解了。假如你是一个汽车厂，造一辆车的成本是十万。今天市场价格是十万零一块，你卖还是不卖呢？你当然卖。供货商有很多，你的行为对市场价格影响很小。挣一块钱总比一块钱不挣强吧。就算你已经花了一千万研发这个型号的车，这个研发成本花都已经花了 (Sunk cost)，和你现在的市场行为已经无关了。所以说：

自由市场上价格等于活的最惨的供应商的边际成本。

好，回到我们的话题上。数字媒体上内容创作者里活的最惨的人，他的边际成本是多少呢？

零。

事实上所有数字媒体内容创作者的边际成本都是零。就算我花了两个小时写这篇文章，时间成本五百块，也不能摊入边际成本。既然我愿意写，就不应，也不能收费。上图里的供给曲线在数字媒体范畴里，其实紧贴X轴。所有数字媒体上内容消费者都应该心安理得地享受100%的消费者收益 (CS), 千万不要心有愧疚。这不是你想占便宜，而是经济学决定了的。

谁把钱挣了？

看到这里，你可能不理解了。不对呀，谁谁谁不是搞直播，vlog什么的挣了不少钱吗？

没错。这里的区别在于，他们所在的不是自由市场，而是垄断市场。他们面对的消费者，就只想消费他们的内容，对别的内容完全不感冒。换言之，王思聪搞直播有粉丝团，你有吗？

不管什么时代，内容创作者里的绝大多数 (99%+) 都注定没有粉丝团的。这不是因为他们的内容不够好，而是粉丝这个事物的供给就是这么多，远远不够分的，何况粉丝团有很强的正反馈倾向, 所以创作者经济里最后一定是有的人挣大把钱，绝大多数人挣不到钱。从风险分析和潜在收益来说，想靠这个挣钱，还不如去赌，毕竟赌场的抽头比社交媒体平台的抽头小多了。

那谁低风险地挣到钱了呢？只有平台。收费内容它们抽 15% (Google Play), 20% (Twitter Super Follow), 30% (Apple Store), 免费内容它们还能靠流量剥削用户的隐私，不管怎么样都能占到便宜。所以说，它们才会想尽办法宣扬挣到钱的极少数创作者的成功，蛊惑其他的内容创作者去它们的平台发布内容。天真的朋友，你看清楚了吗？

还要不要创作

看到这里的朋友可能会想，都是骗子，得了，我还是啥都不创作了，静静地享受我的消费者收益 (CS) 吧。有大局观的朋友可能会更悲观地想，既然经济规律不能给创作者以合理的回报，长此以往，就没有创作者了，开放数字媒体完了。

要知道这世界上除了钱，还有别的东西。我今天先不多讲太高级的 Maslow 金字塔什么的，就讲点民间哲理：

嘛钱不钱的，乐呵乐呵不完了。

你创作的目的是什么？每个人的目的不同，但钱只能是手段之一，它不会是你的目的。在开放数字媒体上创作虽然无法给创作者以经济利益，但给了创作者更大的自由和更广阔的空间。我们确确实实创造了价值，虽然这价值不是那么好量化，也捕捉不到。而且，数字媒体是史上第一个，也是目前唯一一个完全避免了公共草原的悲剧的社会经济领域，即使有再多的人来索取，池子也不会变小，但你放进去任何一点点内容，就永远在池子里了。

物质生活里我们做不到的事情，精神生活里我们做的到。这就是：

共产主义

安卓电脑应用

Wed, 06 May 2026 23:39:35 +0000

现在每个人口袋里都有智能手机，每个人的智能手机都有充裕的流量。除了通信，娱乐等功能外，其实Android手机是一台全功能电脑，理论上电脑能做的事情它都能做。本文介绍一系列手机应用，能让你的Android手机变成全功能移动电脑，让你在无聊刷屏的时候可以做些有意义的事情。

SSH 终端

ConnectBot

有没有字符界面是真电脑和假电脑的根本区别．下面这个应用叫ConnectBot，是全功能ssh/telnet/local终端仿真器，除了本地使用之外，用public key用户认证功能后，你网上的主机都能一键联通。你可能会问，在小小手机屏幕上，还没有键盘，用这个终端不是虐待人吗？其实你的手机屏幕也不是那么小啦，ConnectBot在键盘扩展上也有一系列贴心功能，能让手机终端在一定条件下还挺好用的。除了把它当做紧急备用管理手段之外，我还还常常用它来查看长时间运行的工作进度 (通过连接远程主机的screen) 或浏览日志。

RSYNC 备份

Syncopoli

有了ssh之后，你恐怕还想通过ssh拷贝数据吧。比如备份一下手机数据什么的？没问题，这个应用Syncopoli能满足你的需求。它是全功能rsync客户端，支持ssh和原生rsync两种协议，能让你轻松做增量备份或同步大量数据。当然，它也支持public key用户认证。举例而言，我用Syncopoli备份我的手机相册，一回到我家上了wifi之后，我的相册就会自动和我家里的电脑同步，再也不用手动传照片了。

git 版本库管理

Mgit

对于少量更重要的数据，你恐怕还不满足于简单rsync。在电脑上我们会用版本库管理来实现多点编辑，比如说git? 没问题，只需安装Mgit这个应用，全部git功能都会来到你的指尖。你可以clone, pull, edit, commit, push… 只要你愿意，你可以真的把电话当成工作电脑了．当然，屏幕小，没键盘，不好编译不好运行，编程序还是有点麻烦的，但我至少可以阅读代码，或者写一些文档什么的．例如，你目前看的这份 blog post 主要就是在电话上写成的．对了，它当然支持 github.

笔记同步

SyncOrg

常常你需要写一些笔记，todo list，或者随便剪贴一些文字或链接什么的．灵感随时发生，手里只有手机，只能记在手机上．对于这些零碎文字，你恐怕需要能搜索，能同步到电脑上，能在电脑上进一步整理，然后能再同步回来？看了上文你已经有 git了，所以同步一些文档并不难．但你还想再简单一点，或者你象我是 emacs 用户，已经用 org-mode 在电脑上做类似的事情了？这个应用 SyncOrg 恰好满足这个需求．它通过 git 同步一些 org 文件，并且在电话上提供一部分特定的 org 结构编辑功能，当同步回电脑后又和 emacs org-mode 上的整理功能相结合，成为一个有机的整体．

总结

以上四个应用全部是自由软件，在F-Droid可以下载．美中不足一点是虽然它们全部是基于 SSH public key 做身份认证的，但密钥管理不统一，你需要生成四套公钥并安装四套公钥．另外，某些用户界面也不象商用软件那么人性化．这些也是开源软件的共同特点：更注重内涵功能和安全性而不是表面功夫．不是所有人都欣赏的来的．但对于象我一样，愿意多动一些手脚的人，本文应该能带来一点帮助．

用Linux, 开手动车，自己做饭自己吃． – 周溱，大约2001年

在家里运行网站

Thu, 19 Mar 2026 23:06:06 +0000

更准确的说法是web应用。现在大量的应用，例如办公包括G-suite，Office 365，Reddit，Grammarly等其实都是web应用，你只需通过新一代浏览器，无需安装任何客户端软件即可使用。个人可不可以自己架设web应用呢？当然可以。一些web应用是自由软件，可以自行安装架设的。当然，需要做一番手脚。

基础设施

首先，你需要注册一个域名。例如本博客使用的域名 3qin.us 就是属于作者个人。这其中涉及一点费用，但相当廉价，大概每年十几美元左右。在这个网络时代，没有域名都不好意思说自己是网络公民了。

第二，你需要有一个公网IP，包括v4+v6，和一台公网服务器。最廉价的方法是购买一个vps（虚拟主机）。例如我使用的hostwinds就是一个小规模的hosting公司，当然，大公司例如Amazon也提供hosting服务。我这里不建议使用web hosting，不如使用更底层的主机hosting，是因为价钱差不了很多，但你能做的事情多很多。以我使用的hostwinds VPS为例，最低档每月费用五块美元，而基本web hosting费用也要三块多。当然网上还有完全免费的web hosting，但请记住，hosting总要有成本，成本总要有人来负担。长久之计，这点成本还是自己来承担为好。

第三，你需要有SSL证书。没有证书，人家根本不会上你的网站。好处是在有了域名，VPS之后，可以完全免费地获得SSL证书。不是刚说免费的东西都有问题吗？但在大规模部署，完全自动化的情况下，证书的生成及校验成本已经很低很低，公益机构Let’s Encrypt完全包下来了。所以，任何有域名，有VPS的人都可以享受免费SSL证书，相当简便的初始安装，和完全自动化的更新。

有了以上三点，你可以架设数量无限的http virtual host，每一个都是正规网站，包括域名和SSL证书，例如本博客。

进阶服务困境

以上仅是基础服务。廉价vps的问题是资源受限。例如我的5块钱vps来说，只给我单CPU，1G内存，30G SSD存储，每月流量上限1TB。我用它运行emacs和邮件服务没问题，流量也够了，但CPU，内存，存储都很差，想运行大型全栈web app总力不从心。正规的做法是升级你的VPS，大致到每月20块的水平就比较像话了。当然小农如我，是不舍得花这个钱的。怎么办？

和vps可以对比的是家里的电脑资源。我已经付了家里的宽带费用，家里还有CPU，内存和存储相当不错的台式电脑。可惜，家庭宽带是有问题的：

没有固定IP。动态IP处于居民区段，也没有信用。
ISP端有防火墙，限制很多网络行为。
现在的ISP甚至控制你家里的接入设备，连端口转发都不能搞。
上下行带宽不均衡。主要限制在上行比较差。

可见，VPS有的问题家里没有，但家里有的问题VPS也没有。二者要是能结合起来就好了。

VPN

vpn tunnel

一个自然的想法是架设VPN打通家里和VPS。有了VPN之后，我可以在家里运行大型服务，通过VPS做端口转发，展现在公网上，如下图所示：

一个相对好用好安装的VPN软件是openvpn。但这样也有自己的问题：

VPN导致家里内网门户大开，你还需要周全的防火墙来保证安全。
所有服务运行在家里，这样家里一旦断网，所有服务全部下线。
所有服务运行在家里，大大加重了家庭网络的上行负担。
最后，VPN相对安装维护复杂一点。

其实我并不需要IP级网络沟通，我所需要的所有网络服务其实都是web服务，全部走HTTP协议。针对这点，有没有更好的方法呢？

container + ssh tunnel

ssh tunnel

我最后使用的方法是用container + ssh tunnel + proxy caching. 这个架构比较非常规，解释不如看图：

下面分三部分分别讲述：

前端

前端在VPS上运行nginx。每一个应用对应一个nginx 上的 vhost。资源要求小的静态网站，例如本博客，直接运行在vps上。资源要求大的应用使用reverse proxy向后端传递。为了尽量降低家庭网络上行瓶颈，在前端的nginx内使用proxy cache来暂存后端响应，主要针对静态资源。

后端

后端在家里的电脑里。最好使用固网连接的台式电脑，并使用Linux，防止无线网络不稳定，或电脑自动休眠等问题。每一个应用对应一个lxc container。每一个container都是完全自洽的，包含所有数据库等应用的支持在内。这样有利于迁移管理。由于前端已经有nginx和ssl部署，后端直接暴露非SSL的应用服务器，应用服务器直接服务静态资源。

隧道

从每一个后端容器，向前端vps分别做ssh隧道，打通本服务所需要的端口。映射的端口仅通到vps本机，向外的服务完全由nginx再proxy出去。由于家庭网络断线的概率不小，这里每一个tunnel都有自己的守护进程，一旦断线立刻重连。

分析

这种部署方式兼顾了安全性和易维护性，同时不需要额外成本。当然缺点还是有：

系统瓶颈还是在家庭网络上行带宽上。nginx的proxy cache不理解应用逻辑，只能求稳，对带宽的节约有限。
家庭网络断网，断电等可能性多，整个系统在线率不高，最多99%。网络断线后只剩有限的静态服务。

由于带宽受限，视频或网盘之类应用恐怕效果不佳。如果想运行更可靠更高速的服务，还是购买高档一点的vps服务为好。

在这个架构上，我已经可以做一些在廉价vps上做不到的事情。例如我的discourse。

2020改版通知

Mon, 16 Mar 2026 21:01:34 +0000

大家可能已经注意到本博客近期做了改版。速度是不是快的好像要飞起来一样？改版的主要目的是清爽易用，希望大家喜欢．下面逐条这次的改动介绍．

RSS2 feed

过去本博客只有JSON Feed. 但是，JSON Feed支持的客户端比较少，所以增加了更流行的RSS. 注意，只支持RSS2.0, 1.0版本不支持．目前所有常见的Feed aggregator 都应该可以直接使用，有问题请及时通知我。

放弃后台加载

过去，本博客列表是后台Ajax加载的，其本意是提高用户体验，避免长时间等待．但评估后发现我的内容还很少，后台加载实际上是画蛇添足，并没有提高用户体验，反而增加了复杂度．现在我改成全嵌入在主体HTML里，一次性加载，简化了前后台程序，提高了兼容性．

新 CSS

这是最大的用户可见改动．过去我出于习惯，一直使用bootstrap. 但是，本博客使用到的bootstrap功能恐怕还不到1%, 反而带入一个非常大的CSS及Javascript包. 这次改版我改用了精简很多的Pure CSS. 正如其名，Pure CSS并无javascript部分，仅包含CSS, 而且这个CSS只有Bootstrap十分之一大．排版功能对我来说也够用了．这加快了加载速度．

新 Javascript

对于前端来说，重头戏永远在Javascript, 虽然用户不可见．过去出于十几年的习惯，我一直使用JQuery. 但本博客使用到的JQuery功能其实也不到十分之一．由于近几年浏览器的演进，实际上JQuery提供的常见功能如DOM查询修改等等，都可以用标准Javascript API来做了，只是稍微繁琐一点而已．我主要参照的是这篇文章, 有兴趣的朋友可以参考一下。

在去除了Bootstrap, JQuery之外，我已经完全去除了对第三方Javascript库的依赖，所有Javascript只有一个文件，2KB大, 相当于之前1%大小．

当然，只是做减法也没意思．我又在Javascript层加入了Turbolinks. 它的原理难以用几句话描述，但只需要加入这个库，再写几行代码，你所有的站内页面跳转都变得很快，简直就是瞬间变脸，不信你试试. 当然，这也不是没有任何限制．你写的Javascript需要遵循一定的规范．具体内容请阅读文档．

加入turbolinks之后我的总体Javascript包大小涨回了40KB, 但与获得的跳转性能来相比，这是相当值得的．

总结

现在本博客主页加载在有cache情况下，应该不到500ms, 无cache情况下总加载大小一百多KB, 大多数网络情况不到一秒．页间跳转时间基本忽略不计．新版面相对之前个人觉得更自然清新，操作也直观．希望能听到你的反馈．

通过吐槽俱乐部留下并找回你的话题

Sat, 14 Mar 2026 02:11:57 +0000

我认为, 比制造谎言更恶劣的行为是删文章。可惜，今天不仅有平台以种种名义删除用户上传的文章，还有一些作者自甘堕落，自己删自己写的文章。在微信公众号上，这类现象比比皆是，一些链接等下再点，就再也点不通了。我其实一点也不喜欢微信公众号这种传播方式, 但我的朋友还有不少依赖于类似平台来获取信息，所以，今天我介绍一下吐槽俱乐部的一些用法，可以帮你找回消失的文章，甚至可以作一番整理归纳。你挖坟也可，打脸也可，也可以用来治疗社交网络上常见的失忆症。

文章记录

你所有发到吐槽俱乐部的任何链接，吐槽俱乐部都会在数据库里记录原文文字。你无需发表吐槽，甚至无需无言以对，提交链接就有。提交链接有多种方法，详见吐槽俱乐部文档. 你发的任何话题都会生成一个唯一的站内链接，在站内话题链接内点击标题可以展示或隐藏当时抓取的原文。展示原文的直接链接形如：https://roastidio.us/topic/518108?fulltext=t, 在浏览器内点击可直接阅读数据库内的原文。原始链接附后，你也可以点进去看看文章是否还在，或跟当初有什么不同了。

使用上需要注意以下几点：

站内链接只对登陆用户开放。这是为了保护本站不被恶意攻击，或被长城屏蔽。
数据库空间有限，只保留文字，不保留图片。公众号等平台对图片外链有相当限制，所以即使原始文章还健在，抓取的原文里图片可能无法展示。
只有用户主动提交的文章才会被保留。这是因为微信公众号不提供开放接口遍历文章。

文章找回

吐槽俱乐部目前收录了数十万篇文章，全部来自用户的直接和间接行为。你如何找回几天前，甚至上个月看过的文章呢？或者你如何在吐槽俱乐部的数据库内，自主浏览，找到你想看的文章呢？吐槽俱乐部提供若干种方法，在几个维度下提取数据库内已经存在的文章。

你的吐槽记录

过去一个月你的吐槽记录会直接显示在你登录吐槽俱乐部的入口里，并作时间和参与度排序。这个列表也可以匿名分享给别人，分享的方法是点击你的头像，选择打开公众空间, 然后就会有一个公众空间的链接显示，例如我的是 https://roastidio.us/user/KjQKkQVg。点进去和你的主页类似，只是没有你的任何个人信息。本页也可以作为一个RSS推送被订阅，订阅者可以收到动态更新。通过RSS订阅无需登录，但推送里只有摘要没有全文。如果你对RSS订阅工具还没有太强的偏好的话，我这里强烈推荐使用吐槽俱乐部的姊妹应用 Airss 来订阅，这样可以更方便和吐槽俱乐部交互。

全文搜索

吐槽俱乐部对数据库内所有文章提供全文搜索功能。你可以到这里通过关键字找到对应的文章。使用中文搜索目前还存在一点技术难题：断词困难。目前断词靠的仅仅是空格和标点符号。所以除非你查找的短语在文中彻底被空格或标点完全隔开，否则是找不到的。例如：光靠三国 是无法找到包含 三国演义 的话题的，你需要输入完整的 三国演义, 而且文章也必须存在单独的 三国演义 字符串，前后没有其他未隔开的文字。

单一网络空间文章列表

每一篇文章都对应一个网络空间，在话题主页内有对应的网络空间文章列表链接。以微信公众号为例，对应的文章列表在这里. 微信公众号的链接无法细分，所以所有文章都混在一起。文章数量也不是很多。这是因为目前只有我自己可能会向吐槽俱乐部提交微信文章，而我又不常阅读微信公众号。同样，本页也可以作为一个RSS推送被订阅，订阅者可以收到动态更新。

短文字标记

对于中文读者，尤其是微信公众号平台读者来说，使用全文搜索功能受上述断词困难制约，公众号等网络空间又无法通过链接格式细分，所以这个短文字标记功能可能更有用。每次你吐槽的时候，都可以给话题添加短文字标记（hashtag), 形如#新闻, 用过推特或微博的朋友应该不会陌生。短文字标记从# 号开始，到空格或换行结束。有了短文字标记之后，你可以根据标记做相关查询，例如：铁链女. 同样，本页也可以作为一个RSS推送被订阅，订阅者可以收到动态更新。

短文字标记依赖于用户自行提交。所以我恳请用户们在提交文章的时候，尽可能加上有效的标记。

微信里的链接

微信说到底也是一个浏览器。但是，它完全隐藏URL，网站安全证书，也没有任何调试手段。虽然我们不是100%知道它在背地里干嘛，但我们明确知道，它至少在做很详细的用户行为记录，和针对内部公众号和外部网页很复杂的选择性屏蔽. 由于微信的垄断和网络效应，我们离不开微信，但我恳请大家：

不要用微信打开网页！！！
不要用微信打开网页！！！
不要用微信打开网页！！！

不管你用不用吐槽俱乐部，从你和他人的权益着想，在微信里看到任何链接，请第一时间用浏览器打开。分享链接的时候，不要用微信直接分享，请用浏览器，而且最好把链接的URL用文字方式粘贴到微信里。这样，你的下游可以剪贴URL直接回到浏览器里，而不再受微信的监控，数据分析，以及由此可能带来的屏蔽。诚然，如果是微信自己控制的公众号文章，微信可以把它认为不和谐的内容从源头删除，但至少吐槽俱乐部的存在，给用户们提供了一个保留文章的可能。这点微小的功能，或能给想挣脱互不联网束缚的朋友一点帮助。

你愿不愿意牺牲一点点方便来获得一点点自由呢？

通过网络来剪贴

Sun, 01 Mar 2026 20:08:20 +0000

我前文提到，我基本只用两个应用，一个是ssh到远程主机上的emacs, 另一个是本地的浏览器。另外，我目前常常用的一个数字设备是平板电脑。这种工作环境就带来一个问题，就是如何在这两个平台下剪贴文字，主要是从emacs向本地浏览器剪贴。你当然可以用android系统剪贴板，但有两个问题：

在终端窗口选择大量文字，尤其是超过一屏幕的文字相当困难，而且常常换行，空白等无法精确传递。而换行和空白对于我常常需要剪贴的源代码片段来说相当重要。
在一个平板电脑上，你没有精确的鼠标，只有手指。终端里文字通常还会相当小，我的笨手指无法有效地选择文字区间。

当你足够痛苦的时候，就是需要创造力的时候了。

现有方案

当然，有这个痛苦的不止我一个。苹果刚刚推出的iPad pro主要推的创新点就是自带track pad，能解决精确选中文字的问题。iPad pro确实诱惑很大，可惜799美元的价格让我望而却步，这个价格可以买不错的笔记本电脑了。相比之下，我日常用的平板售价仅79美元，花十倍的价钱解决技术问题并不是我的风格。

emacs平台下现有附加组件webpaste，可以让你用键盘选择要选择的文字区间，然后发到网上，以便于别人或你自己再用浏览器下载。但这个组件的目的是在聊天室快速传递大片文字同时不过分刷屏的，并不很适合我个人使用。第一它依赖第三方网上服务，第二到了网页上还要选中剪贴一次，虽然比终端窗口方便一点，但还是麻烦。

我的方案

我的灵感来自webpaste。我其实需要一个个性化的网上服务，能够暂时存储文字信息，而且能够快速选中剪贴。公网服务器我有，我日常使用emacs的主机就是。但我不想在上面安装任何服务端软件，毕竟日常维护和安全隐患都是需要考虑的。通盘考虑后我把问题分解成三个部分：

一个命令行工具读入要剪贴的文字，归档存入特定目录，并生成html索引以便查询。
一个网页脚本通过前述索引方便选中剪贴归档的文字片段。
一个emacs脚本来把选中的文字传给命令行脚本，并绑定快捷键。

命令行工具

对于处理文件并生成网页的命令行小工具来说，最适合的就是perl了。整个工具一共只需50行，包括注释。这里全文抄录如下。

#! /usr/bin/perl -w
#
# organize text from stdin to files so they can be pasted in browser

use strict;
use warnings;
use v5.14;

use File::Slurp;
use Template;

# configs
# max items to keep. oldest is removed
our $MAX_ITEMS = 5;
our $SCRATCH_DIR = $ENV{'HOME'} . '/public_html/scratch';

my $text = read_file(\*STDIN);
# let's assume we do not call this script every second
my $name = time();
my $text_size = length($text);
write_file("$SCRATCH_DIR/$name" . ".txt", $text);

my %scratches;
opendir(my $dh, $SCRATCH_DIR) || die "cannnot open folder";
while(my $file = readdir $dh) {
    next unless (-f "$SCRATCH_DIR/$file");
    next unless ($file =~ /\.txt$/);
    my ($dev,$ino,$mode,$nlink,$uid,$gid, $rdev, $size, $atime, $mtime) = 
	stat("$SCRATCH_DIR/$file");
    $scratches{$file} = {
	mtime => $mtime,
	size => $size,
    };
}
closedir $dh;
my @sorted = sort {$scratches{$b}->{'mtime'} <=> $scratches{$a}->{'mtime'}} keys(%scratches);

for(my $i = $MAX_ITEMS; $i < scalar(@sorted); $i++) {
    my $file = $sorted[$i];
    unlink("$SCRATCH_DIR/$file");
    delete($scratches{$file});
}
@sorted = @sorted[0..$MAX_ITEMS - 1] if (scalar(@sorted) > $MAX_ITEMS);

my $tt = Template->new({
    ABSOLUTE => 1,
    });
$tt->process("$SCRATCH_DIR/index.tt2",
	     { list => \@sorted,
	       data => \%scratches },
	     "$SCRATCH_DIR/index.html") || die $tt->error(), "\n";

say "Copied $text_size byte to easypaste"

网页脚本

从网页上可以运行脚本，根据索引自动下载选中文字片段，并粘贴到系统剪贴板上。网页加载的时候自动下载选中最新的一份，用户可以多按两下按钮来选中之前的几份。这份javascript也不长，全文抄录如下：

var last = null;

function fixAllItem() {
    document.querySelectorAll("li.scratch-item").forEach(item => {
	var mtime = new Date(parseInt(item.getAttribute("data-mtime"))*1000);
	item.querySelector("span.scratch-mtime").textContent = mtime.toLocaleString();
	item.querySelector("button.scratch-button").addEventListener("click", (e) => {
	    loadContent(e.target.parentElement);
	});
    });
}

function loadContent(item) {
    var file = item.getAttribute("data-name");
    if (last == item) {
	// loaded
	document.querySelector("#target-text").select();
	document.execCommand("copy");
	item.querySelector("button.scratch-button").textContent = "Load";
	last = null;
	return;
    }
    if (last != null) {
	last.querySelector("button.scratch-button").textContent = "Load";
    }
    fetch(file)
	.then((res) => {
	    return res.text();
	})
	.then((text) => {
	    document.querySelector("#target-text").textContent = text;
	    last = item;
	    last.querySelector("button.scratch-button").textContent = "Copy";
	});
}

document.addEventListener("DOMContentLoaded", function() {
    fixAllItem();
    loadContent(document.querySelector("li.scratch-item"));
})

emacs脚本

最后，我需要从emacs内调用命令行工具，把文字传递进去，并绑定热键。我一共做了两个热键绑定，一个传送当前高亮区间，一个传送已经剪贴到emacs内部剪贴板内的文字。利用emacs现成函数，一小段lisp代码即可：

;;; send current region to easypaste
(defun my-easypaste-region (&optional b e)
  (interactive "r")
  (shell-command-on-region b e "easypaste"))
;;; send top of kill ring to easypaste
(defun my-easypaste-kill ()
  (interactive)
  (shell-command-on-region (current-kill 0) nil "easypaste"))
(global-set-key "\C-cpr" 'my-easypaste-region)
(global-set-key "\C-cpk" 'my-easypaste-kill)

总结

三个小功能模块，我一共用了三种不同的编程语言，如果加上html是四种。每段程序都很短。最终我用最经济的方法实现了我需要的功能。

这个工具目前只负责从emacs向浏览器之间粘贴，但我只使用网络主机上的emacs，而浏览器在所有平台都可运行，我实际上可以方便从我的网络主机向所有平台搬运文本数据。反过来，即从本地平台向网络主机emacs剪贴现在我还只能依赖系统粘贴板，目前我还还并不觉得特别麻烦，留待以后再改善吧。

自由软件，开源软件还是免费软件

Sat, 21 Feb 2026 07:57:52 +0000

我生活中用的绝大多数软件都是无需付费，源代码开放，采用保护用户和作者双方权益的版权许可的。最近在软件圈子里出了两件事情：一件是Log4J重大安全漏洞, 还有一件事情是colors/faker作者自己注入Bug，不少人对自由软件生态的健康产生了深深的疑虑。未来软件生态向何处去话题太大，今天我先要澄清一下名字，名不正则言不顺嘛。

有人管这些软件叫免费软件，有人叫开源软件，还有人称它们为自由软件。那么那种称呼对呢？不讲究的话三者都对。但如果要细究，三者是不同的。它们其实是三种不同的发布和使用模式，之间的区别不在于授权许可文件规定了什么，而在于作者是谁，和使用者什么关系。

自由软件

我在这里把自由软件专指主要作者和控制者都是志愿者的软件。这也是三种软件的开端和根本。许多知名的自由软件诸如Linux，OpenSSL等都是自由软件。所谓自由软件，就是有人在不求任何回报的情况下，把自己写的软件开放给世界上所有人使用和修改。他们为什么没事自己写软件呢？一开始肯定是给自己用的，后来觉得别人可能也可以用，就开放给大家了。这种行为的本质是慈善，或者说是给全人类的礼物。既然是礼物，则以下成立：

作者不对这软件负任何责任。他们自己觉得好用，别人是否这么认为对他们没有任何影响。
假如使用者觉得有可改进的地方，可以自立山头去改，或者试图劝说作者去改。
劝的方法必须是能落实到作者身上才有用。

最后一点我详细说一下。假如这个使用者对作者说：

改成这样吧，对我会有用。

这毫无意义，因为作者对使用者不负任何责任。所以只能这么劝：

改成这样吧，不仅对我会有用，对其他人，包括你自己也会有用。

这才可能给作者作改进的动力。

所以说，在自由软件范畴里，作者对使用者的关系是施主对乞丐的关系，使用者可能可以通过一些方法策略来对作者的发展路线有所影响，但没有任何保证。

开源软件

所谓开源软件是九十年代末产生的新事物，其作者主要是一个大公司的雇员，软件受这个公司控制。这其实也是一种产品，这软件通常也不是公司针对自己的需求开发的，但它或者不容易商业化，例如Firefox，或者可以商业化，但不商业化对公司利益更大，例如Java，所以最终公司选择开放给大家使用。开放对公司有间接的利益，例如名声，推动生态圈向这个公司希望的方向发展等等。

使用者呢，也不是通常意义上的客户，最多叫用户。假如使用者觉得需要在某方面改进，出来向这公司进言，绝大多数情况下也是没用的。仅在以下情形有用：很大一部分用户有一致的需求，一起发出同样的呼声。公司权衡利弊，觉得为名声，或从生态圈建设起见，改比不改更有利益，这才会去改。用户的这种行为从另一个角度看是一种起哄行为，反正要闹出动静出来才会有用。

所以说，在开源软件的范畴里，作者和使用者的关系是明星和粉丝的关系。明星能对粉丝造成大的影响，反之，粉丝对明星影响从个体来说微乎其微，但拧成一股绳的粉丝还是颇有影响力的。

免费软件

免费软件早就有，但开源的免费软件是二十一世纪开始后才有的。其作者通常是一个起步公司，产品线比较单一。其产品的最低阶彻底开放给大家使用。公司虽然也求名，或也想建设生态圈，但更直接的目的是给用户一点甜头，争取使一部分用户被捆绑，最终成为付费客户。付费未必是升级为高阶版软件，收费客户支持也是一个常见的产生效益的方法。免费软件著名的例子包括MongoDB，ElasticSearch 等等。

免费软件的用户群通常不会太大。公司通常也能积极听取用户的反馈，毕竟改进产品对公司发展至关重要，还可能转化免费用户为付费客户，直接提升效益。由于公司的低姿态，很多免费用户也常常以客户自居，对公司指手画脚。毕竟客户是上帝嘛。只要不是太过分，公司也就忍了，就算不挣钱，也至少有点公关的作用。

所以说，在免费软件的范畴里，作者和使用者的关系是乙方和甲方的关系，甲方更强势，乙方忍气吞声，只为求财。

总结

虽说三种事物产生有先后，但到现在，三者之间已经有紧密连接：不仅相辅相成，甚至相互转化。自由软件的作者如果创业，自由软件就成了免费软件。创业公司如果被并购，免费软件可能就转化为开源软件。到后来公司觉得无利可图，放弃产品，虽然这款开源软件大概率是黄了，但也可能被社区里的志愿者捡起来，就又变成了自由软件。

从自由软件到开源软件到免费软件，作者的地位越来越低，但使用者的地位越来越高。从另一个角度，作者的收获越来越大，使用者的使用代价也就越来越高。所以说吃亏就是占便宜，世上没有免费的午餐。

软件业界的种种纷争其实都是双方认知不对等造成的。比如，假如作者觉得我做的是自由软件，是慈善，但使用者自居甲方，提出没完没了的需求，或者使用者觉得我用的是自由软件，用得心安理得，但作者总想从使用者身上捞好处，求捐赠。认知不对等就会产生矛盾，是矛盾总有爆发的一天，到矛盾爆发的时候，谁还记得当年美好的相遇呢？

人世间的种种不平莫不来源于此。

Perl中的缺省变量$_

Wed, 18 Feb 2026 07:14:27 +0000

用过perl的人对缺省变量 $_ 都一定相当熟悉．由于有了缺省变量，许多写法可以相当简化．例如：

while (<>) {　print; }
tr/a-z/A-Z/
chomp

但使用不当，你可能也会碰到相当费解的 bug. 下面我们仔细探究一下使用 $_ 的内在细节，希望能避免 bug, 更高效地写出正确的程序．

案例

我前一段写了个小程序，大致如下：

foreach (@filenames) {
	my $fh = open($_);
	while (<$fh>) {
	    s/good/bad/g;
	}
	close($h);
	say "$_ fixed!";
}

有人看出问题了吗？我估计 perl 要六级以上才能看出问题．提示：打印出来的东西完全不是你一开始想的，更严重的是 @filenames 内的数据被破坏．究竟是怎么回事？

variable scopes

Perl 提供丰富的 variable scope 规则：

global variable
dynamically-scoped variable
lexically-scoped variable

搞懂这些scoping rule, 不仅对 perl 程序员有用，对所有程序员都有用．

global scoped

其实就是没有scope, 即全局变量．这最简单，可以理解成有一个全局的字典，通过名字指向静态分配的内存地址．在程序中的任意地方你都可以通过同一个名字读写同一块内存．perl 中的 our 变量就是全局变量.

dynamically-scoped

global scoped 简单，但导致程序各部分相互干扰很大．于是发明了局部变量，和 scope 关联．dynamically-scoped 的方法是维持全局字典，但在进入一个 scope 的时候，把全局字典中一部分另行保存，改成这个 scope 自定义的新值．离开这个 scope 的时候再恢复回去，保证对外界没有干扰．在 perl 里, local 变量就是 dynamically-scoped 局部变量．

lexically-scoped

还有另外一种方法．就是每个 scope 自己定义自己的一个小字典．先查自己小字典，查不到了，再查全局大字典．这也实现了局部重定义变量．在 perl 里, my 变量就是 lexically-scoped 局部变量．

dynamical vs lexical

假如你只有一个全局 scope 加一个局部 scope, 那这两者没本质区别．但如果再多，就有区别了．lexically-scoped 永远只作用在本 scope 内，和你程序如何执行没有关系．但 dynamically-scoped 和程序运行路径相关，会影响之后你程序运行遇见的所有新的 scope. 例如:

our $a = 1;
our $b = 2;
sub inner_print {
    say "a=$a, b=$b";
}

say "a=$a, b=$b";   # a=1, b=2
OUTER: {
    my $a = 3;
	local $b = 4;
	say "a=$a, b=$b";   # a=3, b=4
	inner_print();      # a=1, b=4
}

在之上的例子里，由于 $b 在 OUTER scope 是 dynamically-scoped, 而 $a 是 lexically-scoped, 导致在 inner_print 里一个用全局值，一个用 OUTER 里的值．

通常而言，静态编译的程序更适合使用 lexically-scoped, 而动态解释的程序更适合使用 dynamically-scoped. 例如，在 C 语言里并无 dynamically-scoped 的方法．但 perl 及其他高级语言给了你更多的能力，相应的，也就有更多的可能性．某些功能用 dynamically-scoped 变量更方便，但对于大多数情况, lexically-scoped 更不容易出错，也更容易被编译器优化．所以在你不清楚该用什么的时候，请先考虑 lexically-scoped.

$_ 是什么

我们再回到一开始，理解一下 $_ 究竟是什么．它的使用分为大致两个方面：

提供者．包括 iterator (例如 foreach) 和 stream 输入 (例如 while(<>) )．perl 的术语叫：topicalizer
缺省使用者．包括 regular expression matching, 一些系统自带函数等．

由于以上因素，可以推理出：

$_ 是全局变量
$_ 无法做 lexically-scoped 局部变量
$_ 可以做 dynamically-scoped 局部变量

很简单，假如 $_ 做了 lexically-scoped 局部变量, 它就无法自然传递到下层函数，那它的方便性就没了一大半，也就没意义了．让我们再考虑一下在 while(<>) 和 foreach() 两种用法下，究竟发生了什么．

while (<>) 里的 $_

当我们写：

while(<$fh>) {
	}

实际上 perl 会给我们自动扩写成：

while(defined($_ = <$fh>) {
	}

这里，全局变量 $_ 会被赋值，会影响到外面．在我们最初的例子里，内循环的 while 改写了它. 同时由于下面 foreach 的性质，改写了外循环遍历的数组 @filenames．由于 while 循环的结束条件，最终它和 @filenames 全都变成了 undefined.

foreach 里的 $_

当我们写：

foreach (@filenames) {
	}

实际上 perl 会给我们自动扩写成：

{
	    local $_;
		my $i;
		for($i=0; $i<scalar(@filenames); \$_=\$filenames[$i], $i++) {
		}
	}

这里和上面 while 有两个显著区别：

$_ 并非拷贝了数组里的数据，而是一个 alias, 指向数组里的真实数据
perl 自动生成一个外层，并将 $_ 做成一个 dynamically-scoped 的局部变量

为什么 $_ 必须是一个 alias呢？第一避免了内存拷贝，第二保证把它当作 l-value 可以直接修改原数组里的值．下面代码才成为可能.

foreach (@filenames) {
		s/good/bad/g;
	}

上面这段代码会修改 @filenames 里的内容，这是预期的结果．这和 while (<>) 不一样，在 while (<>) 里数据拷贝是天然且合理的，输入流并无修改的需要．

由于 $_ 必须是一个 alias, 所以 perl 必须再做一个外部 scope 把它做成局部变量．假如不这样做的话，foreach 循环结束之后，它将是一个无效的 alias，对它的任何操作都会导致内存越界．这和 while (<>) 结束之后残留一个无效数据不一样：无效的指针比无效的数据危险性大的多．

怎么避免

从上面的分析来说，foreach 不污染环境，但可能受污染，while (<>) 污染环境但不容易受污染．问题出在 while (<>) 上．那为什么 while (<>) 不也使用自动外层和 dynamically-scoped 呢？我想这主要是历史原因，而且从上面的分析来说, while (<>) 的污染是可预测的．对于我们程序员来说，为避免这个坑，你要记住以下两条就够了．

不做内循环

while (<>) 只能做最外侧循环．如果要做内循环，可以改成 lexically-scoped, 不用 $_:

while (defined(my $line=<$h>)) {
	}

这样做的缺点是没有缺省变量了，不够方便．或者也可以用内部 dynamically-scoped $_:

while (1) {
	    local $_ = <$fh>;
		last unless (defined($_));
	}

这样做的缺点是感觉罗嗦一点．

保护外层

除非你的 while (<>) 已经在程序顶层，即不在任何函数内部，尽量在 while (<>) 之外把 $_ 定义成 dynamically-scoped 局部变量来保护你函数的上层调用：

sub my_func {
	    local $_;
		while(<$fh>) {
		}
	}

如果你的程序的 while (<>) 在最顶层最外侧循环，则无需做任何改变．这其实也就是 perl 原来简化写法的初衷．

总结

perl 让你写出精简方便的代码，但这后面的原理并不简单．理解 dynamically-scoped 和 lexically-scoped 的区别不仅让你能更深的掌握perl, 对其他高级语言的学习也很有帮助．

There is more than one way to do it. — Larry Wall

三个命令行工具

Thu, 08 Jan 2026 02:18:29 +0000

UNIX命令行的美丽之处是虽然每个工具只做一件事，但把它们组合起来，你可以完成所有复杂的工作。下面介绍的三个工具可能不太出名，做的事情其实也有点复杂，无法用简单几句话说清，而且感觉和UNIX的哲学也有点背离，但对于程序员和系统管理员的日常工作确实非常有用。我这里一并介绍，希望能给大家以启发。

stow

如果你像我一样，手动编译安装不少软件，肯定会和我有一样的烦恼。这就是安装容易，卸载难。在一个UNIX环境中，所有执行文件，所有库，等等都是混在一起放的，你很难分清楚什么文件是什么源包安装的，所以并没有统一的，干净的卸载流程。有时候你甚至觉得可能像 OS X 一样，所有安装文件完全分开才简单．但一起放有一起放的好处：路径设置简单．如果路径过于复杂，那先后顺序也很有影响，你也很难发现各个软件包之间的有没有冲突．stow 这个工具解决的就是多软件包安装卸载的问题，你为什么不可以同时得到分开放和一起放的好处呢？通过管理 symlink, stow 把多个目录下的文件形式上合并在一起，并可以随时拆除更换．下面举例：

packageA
   |-> bin		
      |-> commandA
   |-> lib
      |-> libA

packageB
   |-> bin		
      |-> commandB
   |-> lib
      |-> libB

合并之后成为：

local
   |-> bin
      |-> commandA -> ../stow/packageA/bin/commandA
	  |-> commandB -> ../stow/packageB/bin/commandB
   |-> lib
      |-> libA -> ../stow/packageA/lib/libA
	  |-> libB -> ../stow/packageB/lib/libB

正如传统 UNIX 的扁平目录组织形式一样．而且还有其他：

扁平目录里只有 symlink, 并不占什么磁盘空间
提供工具分 package 拆除/更换/检验 symlink
自动检查冲突

事实上，这个工具不仅可以用于管理软件安装，任何你又想分目录管理又想扁平管理的地方都可以应用它．我已经开始用它管理文档，图片，音乐等等．现代的文件系统在一个目录里放几万个文件毫无问题，所以尽情把它们 stow 到一起吧，你会获得短路径，易搜索，好遍历的好处，同时不放弃分项目管理的干净整洁．

ack

我想人人都用过 grep. grep 来自 UNIX 的哲学，只做一件事情，就是字符串匹配．但任何尝试过在一个不是很简单的目录结构下 grep 过的人都和我一样受过伤害．你先来：

find . | xargs grep derek

发现没有跳过目录．然后你再来：

find . -type f | xargs grep derek

然后你意识到有些路径名包含空格，所以你再来：

find . -print0 -type f | xargs -0 grep derek

然后你找到一大堆二进制文件，只好重来：

find . -print0 -type f -name "*.c" | xargs -0 grep derek

然后你意识到还有 .h 文件，.cpp 文件，… 还有假如某些脚本并无固定后缀呢？快崩溃了吧？

当然一些老手会说，你可以 git grep. 但如果你 grep 的目录没有用 git 管理呢？但如果你想一起 grep 多个 git repo 呢？

ack 是 grep 在 DWIM (Do What I Mean) 哲学下的重新实现. 你只需要：

ack derek
ack --perl derek
ack --noperl derek

你猜猜看上述命令都干了啥？简单总结一下 ack 的好处：

自动跳过你其实不想 grep 的文件和目录
普通人可以记住理解的命令行
高亮显示匹配结果
集成到 emacs 和其他编辑器之内

parallel

这个年代每个人的电脑都是多核的．但可惜的是很多任务其实只能利用一个CPU. 如果你一个一个地去做，即使写成脚本，也是大大浪费时间．例如你有一堆图片，需要转换成另一个分辨率，有或者你有一堆 regression test 等着去做，你当然想并行地去做不是？parallel 是一个并行多任务 scheduler, 它有以下好处：

自动识别你有多少CPU, 来达到最好的效率
自动缓存打印信息，这样在并行运行的时候屏幕打印仍貌似串行运行的一样可读
当某个任务异常退出的时候，不再提交新的任务但让已提交的任务正常运行到结束
清晰合理的命令行语法
还有很多很多高级功能

下面我给一个简单范例是我常常使用的：

ls -d * | parallel -j+0 make -C {}

它的含义是：对于当前目录下所有子目录，每一个都进入运行 make, 并发数受限于 CPU 的个数．怎么样？让电脑满负荷运行吧，我自己要回家睡觉了．

总结

以上三个命令行工具其实都有十年以上的历史了，算的上久经考验．它们的目的并非直截了当，但都是程序员为了解决自己的痛点，为自己和同行自发设计的工具，从一个非常简单的开端逐渐演变到一个相对复杂和完备的现状，没有任何商业背景．

最后，它们都是用 perl 写的哦．

Make the easy things easy and the hard things possible. – Larry Wall

文本通讯录

Mon, 05 Jan 2026 07:48:07 +0000

手机上最重要的数据就是通讯录了．当然，现在人们手中不止一个数字设备，在我前文中说到，我日常使用四个数字设备，台式电脑，笔记本电脑，手机，平板．当然，很多人还不止一部手机．所以，通讯录的维护，备份，同步就成了一个问题。你可能会问，难道不是有云端备份同步吗？我今天就要讲一下云端通讯录同步的使用问题，以及我为什么抛弃了云端方案，回归简单文本。

现有方案

其实，我早在没有使用智能手机的年代就开始使用云端服务来管理通讯录了，到今天已经超过15年。但是这个过程中我碰到了许多问题。下面我一一介绍一下现在存在的解决方案。

LDAP

LDAP是上世纪90年代的最新科技，其实并不是一个同步手段。你的通讯录只存在于云端，不存在于本地，由系统管理员统一维护。当然，Exchange也类似。这个方法其实仅适用于组织机构而不适合个人使用。一旦断网，就什么都没有了。

CardDAV

CardDAV是一个开放标准，有很多自由软件的服务端及客户端。利用这些，你可以在任意客户端保持通讯录同步。但这也有问题。第一你需要一个服务。当然可以使用一些开放的服务，但他们总有一些可靠性问题，还有隐私问题。当然，你也可以自己架设服务，毕竟现在VPS这么便宜。但这有一个技术门槛，而且感觉为了这么点事不值当。第二，你需要在各种平台，各种软件里安装插件，记得更改密码等等，这些都是维护成本。

手机自带服务

OPPO手机有OPPO云，华为手机有华为云，都可以轻松一点在多机同步通讯录。但这些都是私有服务，使用非开放标准。OPPO云华为手机用不了，华为云OPPO手机用不了，而且PC端都用不了，更不用提自由软件平台了。

Apple

如果你生活在Apple世界里，当然可以用Apple服务。可惜我不是，而且我不能想像被一个厂商永远束缚是什么样的生活。

Google

当然，也可以使用第三方服务例如Google，协议开放，支持所有客户端。但可惜的是，中国国内用不了。而且，你真的那么愿意信任Google吗？

小众服务

也有第三方小众服务，而且在雷达屏幕之下，尚未被中国长城屏蔽。国内原生的，使用开放标准协议的小众服务我至今没有找到过。另外，可靠性和隐私都是问题。

我的处境

之前，由于历史原因，我同时使用三到四种服务。可惜的是，这多种服务之间是互相隔离的，我在手机上看到的是所有服务的并集。如果一不小心几个服务之间的通讯录条目有重叠，结果就很有意思了。我在手机上输入新的通讯录条目也要谨慎小心，要输到我真的想输的子集里。否则同步之后，在不同服务中迁移条目相当困难。还有一次我在异国他乡，一段时间没有数据连接，突然间一部分通讯录条目蒸发不见，好几天都没有发现。

我终于意识到唯一可靠的就是本地存的通讯录。我需要的不是同步，而是能够简单把整个通讯录拿出来，整理，再放回去。毕竟，通讯录数据量很小。我经过一番整理后的通讯录不到一千个条目，其中大多数人我都不知道是谁了。总体通讯录vCard文件输出只有100KB，在这个年代这个数据量可以忽略不计了，我就是每天拷贝一次，消耗的时间和数据流量仍在噪声里。增量同步完全没有经济意义。

最后，目前我使用的所有平台所有软件都支持vCard文件导入导出，这已经是业界通用的标准了。数据格式已经不存在兼容性问题。

新的方法

现在，我的通讯录的标准版本保留在我的云主机上，以org-mode文本格式存放。我之前介绍过Org-mode，它的一个功能是在文本文件中维护一个小型半结构数据库，并提供结构化编辑和快速查询的方法，这正是我对通讯录的要求。我用git对这个文件做版本控制，并把它和我云主机的所有文件一同备份。我另外写了一个简单perl脚本，把org文件转换为通用的vCard文件，拷贝到我所有终端。在终端上我不定期的把本地的通讯录清空，然后一股脑把整个通讯录导入。

目前，这个方法运行良好，我已经停用了所有通讯录同步服务。还有几个小问题：

要尽量避免在手机终端上编辑通讯录，所有数据录入在云主机emacs上完成。当然我所有平台，包括手机都可以ssh我的云主机。
手机导入过程不是完全自动化，还需要手动选中所有条目，删除，再从文件中导入。要是能脚本控制的话就好了。
手机导入速度有点慢。我导入前通讯录全空，但手机导入速度仍只有每秒几条，速度不够理想。好在一旦开始就不需要管了。

行事历呢？

通讯录和行事历是个人信息系统里的哼哈二将。理论上，行事历也可以做与通讯录同样的处理。行事历的iCalendar文件的格式和vCard文件类似，各平台兼容性也很好，而且数据量还更小。但是，行事历的变化比通讯录快的多，稍稍过时的通讯录问题不大，但稍稍过时的行事历问题就大了。但行事历有一大好处，就是它其实不需要多平台同步，一直留在我手机里就好了，反正我也离不开手机不是？所以不需要同步，只需要备份。能常常把iCalendar文件导出再备份就好，这实现很简单，也不需要云服务。

结束语

我的方法不一定适合别人，看起来也像回到了80年代。但是技术上不一定越新潮越好用，鞋子合不合脚只有自己知道。

中文网页资料的分享

Fri, 19 Dec 2025 22:04:05 +0000

互联网的一个重要作用是信息发布和分享。你只要有一个链接，任何人点这个链接都会分享到同样的信息。当然，有些信息受到保护，需要登录才能看到，这也可以理解。本文谈的只包括对公众开放的信息，即可以链接分享的公开信息。今天我调查了四个常见中文信息来源：

今日头条

今日头条到今天已经是巨无霸级别，上面有海量的信息，某些颇有价值，相当一部分在别的地方找不到。这些海量信息你无需使用APP，也无需登录，只用浏览器就可以看到，链接简洁明了，例如：https://www.toutiao.com/i6853032117417443840/.

下面说缺点。

用户跟踪

这是我见过所有网站中，cookie用量最大的之一。一次访问，你的浏览器就被植入11个cookie，还不包括少量第三方cookie。你就是匿名访问，头条也很努力地想弄清楚你是谁。

无标准meta

在社交媒体分享的时候，假如网页有若干标准化meta标签的话，渠道和对方可以先期了解链接的一些信息，例如缩略图，标题，摘要，媒体格式等等。业界两个标准一个是来自facebook的Open Graph, 另一个是来自Twitter的Twitter card. 头条都没有。就算你放弃标准，试图解析头条HTML内容，也找不到任何有用的元数据。所以，在非头条支持的社交媒体上，例如whatsapp，telegram等，头条链接都是干巴巴的链接。在微信上当然不是，这是由于微信和头条的协作关系，用api生成的。

javascript超强依赖

我自己写了个爬虫，试图分析一下头条链接内容。但是，我很快放弃了。因为什么都没有 . 头条链接内容虽然在浏览器里打得开，但在程序自动抓取情况下，什么都没有，一片空白。我一开始还以为是某种网络限制，或user agent检查，但后来我意识到，这全是javascript的魔法。你点的任何头条链接，包括头条主页 ，其实给你传的都是一样的一个javascript程序，所有内容，包括标题，都由javascript二次下载。你如果不信，可以在浏览器里禁用javascript试试。当然，在今天javascript是网上浏览不可或缺的东西，但一般网站，尤其是信息发布性网站，至少会有一点文字信息不依赖javascript，只有头条做的够绝。

这个后果之一就是所有搜索引擎，除了头条自己的之外，都无法索引头条上的信息。我知道头条在推自己的搜索引擎，但是作为用户来说，在头条发布信息，就是断绝了其他一切流量可能，你所有的流量都来自头条自己。头条网站根目录的robots.txt说的够直白：

User-agent: *
Disallow: /

爬虫请靠边站。

微信公众号

微信公众号也是规模庞大的信息发布平台。在一些领域，其实已经是垄断级别，而且和国内唯一最大的社交网络深度绑定，你不可能忽略它。公众号的文章内容除了在微信内部可以阅读，其链接也可以分享，通过普通浏览器匿名访问。当然，和微信的互动，如订阅，微信内分享，运行小程序是不行的，这也是可以预计到的。

下面说缺点。

超长链接

微信链接通常长这样：https://mp.weixin.qq.com/s?__biz=MzA4NjMzNTEwMw==&mid=2653630285&idx=1&sn=fc50fe1d1fbf56a1bc1a0784cfe980a1&chksm=8415c45db3624d4ba56273c3d2af0d1e70b5f405d51d6f2bd3768bbe6be114efd2de140c53f7. 带劲吧？实际上，如果你看的懂query string，这里最后的参数chksm其实是不必要的。但你分享出来就是这个鬼样子。当然，微信后台也会在浏览器里植入cookie来试图跟踪你，但貌似跟踪的力度不如头条。

meta不标准

微信公众号文章其实包含 OpenGraph 和 Twitter card, 但是是有问题的。例如：

<meta property="og:url" content="http://mp.weixin.qq.com/s?__biz=MzA4NjMzNTEwMw==&amp;mid=2653630285&amp;idx=1&amp;sn=fc50fe1d1fbf56a1bc1a0784cfe980a1&amp;chksm=8415c45db3624d4ba56273c3d2af0d1e70b5f405d51d6f2bd3768bbe6be114efd2de140c53f7#rd" />
  <meta property="og:image" content="http://mmbiz.qpic.cn/mmbiz_jpg/ibvjqYe1KOjBwFAj7MXVhGat6icJuyNefugzAtDw88tiaRCc2DqkEbLet3PU2sewCRfJmKvexVJYsWTvm8yicMSx0A/0?wx_fmt=jpeg" />

这个问题就在于链接是http而不是https，虽然我用浏览器访问的方式是https. 根据互联网规范，https网页不能内嵌非加密信息。搞笑的是假如你通过http去加载这个图片的话，微信服务器会返回HTTP301，把你再重定向到同一个服务器，同一个路径下的https链接上。所以说，微信的这些meta是写错了。

Javascript 强依赖

和头条一样，微信公众号文章不开Javascript也读不了。但稍微好一点的是，虽然内容没有，但是标题，和 opengraph meta 还是有的，所以你至少不是在看一个白板。对于爬虫分析来说，也有点信息，不至于什么都看不到。我估计各种搜索引擎还是有所覆盖的。

百度知道

百度知道是百度自己的公众问题解答网站，有些解答还是不错的。何况是百度自己人，所以在百度搜索排名都很高，不管你搜个什么，前几名必然有百度知道链接。当然，你分享链接后别人匿名访问，其实也不是那么匿名。除了百度cookie之外，百度知道自己还有自己的cookie。

先说优点：

不依赖 Javascript

你就算关掉Javascript，百度知道还是一个样子，所有内容都呈现。这里必须给个大大的好评。关掉javascript，百度就完全不能跟踪你是谁了，最多知道你的IP什么的。另外，这对搜索引擎也是大利好。毕竟百度是开这个的。

再说缺点：

无任何标准meta

和头条一样，百度知道完全没有Open Graph, Twitter Card之类的一切都没有，连link rel=canonical都没有。假如社交分享这种链接就肯定什么都没有了。分析meta的时候我还发现了一个重大信息：

GBK charset

光用浏览器一般看不出来，但百度知道所有网页都还是GBK编码，而不是国际通用的UTF-8编码。有点不可思议，毕竟百度旗下其他几个网站，包括搜索都早就是UTF-8的了。这里简单介绍一下，GBK是GB2312的扩展，包含中英文还有日文假名之类字符。UTF-8是现在的国际标准，包含一切。这意味着百度知道不能使用例如：😓, 💔 之类的字符，也不能用一些小众一点的语言。

这还不是最关键的。GBK支持在各种新型编程环境中基本不存在，当然，在古典语言例如C里也不存在，但那里毕竟可以用古代的第三方库，而二十一世纪的快捷编程环境通常已经假定字符串是UTF-8了，也没有什么库可以用。我写的爬虫程序自然也无法支持。

黄页88

黄页88是国内流行的B2B信息发布平台。样子虽然有点九十年代，但信息量还是不小，主要是各种中小企业广告，无需登录就可以浏览。所有链接都可以自由分享。

先说优点：

相当完备的 Opengraph meta

这是我见过除了facebook自己之外，对Opengraph支持最全的信息网站了。你分享的链接一定很漂亮。例如这个：

huangye88

上图来自iframely.com的demo. 我没有付费，不好意思直接链接。

不依赖 Javascript

关掉Javascript，你唯一失去的就是第三方广告，整个网页甚至更漂亮了。各种搜索引擎想必都能轻松接入。

再说缺点：

Opengraph 有瑕疵

这似乎也不仅仅是opengraph的问题，黄页88有大量的图，大多数的图来自https, 仍有少量来自http, 没有端到端保护。opengraph meta里的链接也都是http 的。我试了几个图和链接，把链接替换成https 其实是照样工作的。和微信类似，但不同的是没有自动http -> https 跳转。在这个年代，加密已经是主流，既然已经做到九成了，何必不做到十成，图个干净？

总结

一句话总结以上网站：

黄页88：我很土，但我很努力
百度知道：还活在2000年
微信公众号：制霸中国，节操尚存
今日头条：不是我的人，就是我的敌人

WEB1, WEB2 和 WEB3

Fri, 19 Dec 2025 21:19:24 +0000

WEB3 最近是一个热点词汇。什么是 WEB3 呢？要回答这个问题，我们要先了解什么是 WEB1 和 WEB2。解释了什么是WEB1，2，3之后呢，我还想尝试一下预测未来，虽然我的预测通常很不准。

WEB1

WEB1 就是最原来的，上世纪九十年代的互联网。在WWW的发明人 Tim Berners-Lee 的最初构想里，互联网是一个全球化，分布式的一个信息发布和相互引用的平台，每一个有能力的人或机构都可以自己运行一个网站，自由地发布信息，而访问者也可以自主选择信息来源。用户和网站之间，网站和网站之间互不统属，采用业界的开放标准互相沟通。除了WWW之外，以下的一些应用也是同时期，并基于同样的开放，标准化，分布式的精神，所以我们也把它们归结到WEB1:

电子邮件
BBS, IRC, XMPP 等即时通讯工具
个人博客和 RSS 汇集

Yahoo at 1997

为了方便广大用户在性质各异，种类繁多的网站中挑选自己需要的内容，先是出现了不少门户网站，然后出现了搜索引擎。但它们还是主要做流量分发，算是从属于WEB1 的应用模式。

如果要总结一下，WEB1 是以内容为主的WEB，内容的提供者自己建网站，直接和内容的消费者接触。除了要遵守法律之外，没有中间人的规则需要遵守。

WEB2

Twitter at 2007

WEB2 大致发端于2004年，来自于三个技术革新：智能手机，社交网络，和云服务。这时候出现了平台，平台上运行应用，应用再吸纳原来用户自主发布的内容。它解决了WEB1 的一大痛点，就是自己建网站不仅有经济代价，还有不低的技术门槛和长期维护所需要的人力成本。内容的发布者大大降低了内容发布的成本，并可以借助平台和应用的网络效应快速吸引用户流量。平台之间一开始有激烈的竞争，不惜代价让利给内容发布者和消费者，但不出几年，增长快的平台通过规模效应和网络效应迅速打垮或吃掉小一点的平台，几次兼并之后，只剩下为数不多的几个，个个都在自己的领域有很强的垄断性，如苹果，谷歌，和脸书。我上文提到的几个 WEB 延伸应用也有了本质变化：

邮件被几个超大型邮件服务商事实垄断
即时通讯工具更加如此，而且摒弃了开放标准，成为互不联通的几大孤岛
个人博客渐趋式微，网民被社交媒体收编

如果要总结一下，WEB2 是以应用为主的WEB，掌控权和盈利被平台把持。内容的提供者和内容的消费者中间隔着平台，大家都被平台所绑架了。

WEB3

WEB2 演进到现在，从内容提供者搞消费者都越来越不满：费用越来越贵，广告越来越多，隐私越来越少，还无端删帖屏蔽。没办法，垄断嘛。

天下苦秦久矣。 —- 司马迁《陈涉世家》

于是现在有人提出了WEB3 的概念，就是利用区块链技术，让WEB 重新变成分布式的样子，打破平台的垄断。区块链技术最成熟的应用就是加密货币，其中最古老最有名也是市场总量最大的就是比特币。其实，明眼人都看的出来，加密货币就是一个庞氏骗局. 但很多人不知道的是，主权货币，例如美元，人民币之类，不也是庞氏骗局吗？现在主权货币的发行者，也就是各央行，手里根本没有真金白银，所有的资产95% 以上是国债，或者比国债更无聊的东西。国债本身又是以同一个主权货币来计算，这货币绕到最后还不是一张纸。都是骗子，就看谁能骗到底了。

窃钩者诛，窃国者为诸侯。 —- 孟子

Coinbase

主权货币靠的是国家信用，加密货币靠的是加密算法和世界各地的参与者，谁说没有国家主权就不能发行货币了？

区块链说到底，是一个分布式的数据库。而数据库，就是所有林林总总的WEB 应用的核心：任何内容说到底不还是数据。所以，以区块链为基础做的互联网应用，就是WEB3。理论上万物都可以做，实际上有一个重大的问题：作为一个数据库，区块链的效率非常低。所以直到现在，WEB3主流的应用还是一些附加值非常高的应用，如加密货币交易，NFT交易等。提高效率的方法不是没有：

链外数据汇总。但这会大大降低安全性
中心化管理。但这不是回到WEB2的老路上了吗？

预测

我的看法是WEB3并不是 WEB1 或 WEB2 的取代品。区块链解决了两个很重要的问题：

在分布式数据管理情况下的各方互相信任问题
在法律够不到的情况下权力和义务认定的问题

这扩展了WEB应用的领域，但不是所有的问题都适合用用区块链技术来解决的。WEB2 大规模取代 WEB1 是一个偶然，这个偶然不会再重复。

WEB2的问题是垄断，但这是一个经济学问题，或者说是一个社会学问题，不是一个技术问题，也不应该用技术来解决。我估计只会有少量WEB2应用会迁移到WEB3技术上，另会有少量WEB2应用会回归到WEB1，例如第一方内容发布。

WEB1 的技术也在发展。在今天，在自由软件和虚拟化的加持下，自己设立网站的技术门槛已经大大降低，我就有好几个，不算本博客，还有吐槽俱乐部, Airss 推送阅读, 还不去开房，我还自己运行自己的邮件服务

其实WEB1，WEB2，WEB3之争最终争的是用户。作为用户，你的回答是“别人用啥，我就用啥”，还是“我爱用啥，我就用啥”呢？我希望是后者，但不少人的实际选择是前者。

清空你的收件箱

Wed, 17 Dec 2025 23:19:34 +0000

看邮件在这个时代已经成为一个负担。一般认为，清空收件箱(Inbox Zero)是保证Email处理及时的最佳策略。它指的是保持你的收件箱接近于空，所有邮件都看过，该回复的回复，然后归档保存，以便于全文搜索。但是你会说：

臣妾做不到啊！

与之对应的是无限收件箱(Inbox Infinity), 就是完全放任自流，除非有人提醒你要看邮件了再看，而且也只看想看的那几封。我估计现在大多数人都是采取第二种策略，毕竟是懒人的方法。

一屋不扫，何以扫天下。

我今天我就来清一下我三个web mail账户: https://outlook.com, https://mail.yahoo.com, https://gmail.com。已经放任自流很久了。还有救吗？

我的账户

先大致看一下我都有什么：

https://outlook.com

hotmail是web mail的先驱。我1997年注册，当年还尚未被微软收购。这个邮箱多年废弃不用，信噪比极低，目前收件箱邮件一万左右。
https://mail.yahoo.com

Yahoo是当年互联网老大，我自然也有账号。我在2001年左右注册，曾长期使用。现在也基本废弃。目前收件箱邮件五千以上，有一定的有效邮件。
https://gmail.com

Gmail 2004年横空出世，让web mail发生了革命，如大空间，全文搜索，但也从此带来了无限收件箱的恶果。我注册于2006年，长期使用，一直没有废弃，但最近看的比较少。目前收件箱邮件不知道有多少（gmail提供的数字很不准，只能做参考），当在一万以上。

现在，yahoo，outlook也早已提供足够大的存储空间，让我也堕入无限收件箱的深渊。还记得很久之前，看邮件可积极了，但是如今呢？

Now email feels like a chore, rather than a joy. Something you fall behind on. Something you clear out, not cherish. Rather than delight in it, you deal with it. Your relationship with email changed, and you didn’t have a say.

– hey.com

我的目的是清空以上三个收件箱，垃圾扔掉，剩下全部归档保存在我自己的云主机上。做的到吗？

工具

工欲善其事，必先利其器。对于海量邮件的处理，我需要强悍的工具：

getmail. 超多功能的命令行邮件迁移工具，但我只用POP3功能下载邮件。
我自己写的perl脚本，利用了CPAN上三个主要邮件处理相关的包：
- Mail::Internet, 负责提取，转移邮箱里的邮件
- Mail::Message，负责结构化处理邮件
- DateTime::Format::Mail，负责弄清楚邮件日期
mutt. 我目前日常使用的邮件环境是mu4e, 好处是和我工作环境emacs紧密集成，但特殊情况还是要祭出更快速更强悍的mutt

我的步骤是：

用getmail一股脑把邮件通过POP3全部下载
用脚本把有用的和没用的分开
用肉眼把没用的再过一遍，以免有遗漏。
有用的归档，没用的扔掉。

有用和没用的定义很简单：我回复过的都是有用的，我信任的人发来的都是有用的，其他都是没用的。这是我长期总结出来的经验，这些判断也都可以通过我的脚本做到。

清空过程

一个账户一个账户来吧。

outlook.com

empty outlook

Outlook.com 几经沿革，现在已经和当年大不一样了。说实话并不难用。打开pop功能需要在网页设置里点一下，提示简单明确，但第一遍会失败，要再回网站里确认一下。之后就能一通到底，让getmail一口气把所有邮件下载，用时不到一小时，下载一个G左右。网页inbox清空如下：

由于这里基本都是垃圾，所以我的分类脚本相当成功，运行十分钟，找到不到200有用邮件。我又肉眼把垃圾箱里近万封邮件再扫一遍，没发现什么有用的。手工扫描不到半小时，再清空垃圾箱，收工！

mail.yahoo.com

empty yahoo

Yahoo! 已是过眼云烟，现在已经属于Verizon。现在网页做的也还行，就是广告稍微多了点。和微软谷歌不同，Verizon无法集成什么应用，当然就算有别人也不会去用。在这里打开pop功能还费了一番手脚，不仅要打开一个开关，还要设定专有app password，网页文档也不甚明确。好歹是有惊无险，总算通了。最后一个问题是无法一口气下载，下载一次只搞到一两千封，还要手动再来几次，直到彻底清空。Yahoo下载速度明显比outlook.com慢不少，虽然总体量比outlook小不少，但下载了一个多小时，才总算清空了：

这里有我不少早期私人邮件。我的脚本还是几分钟搞定，找到两百多封有用邮件。但肉眼扫描之下，发现不少遗珠。我昨天晚上花了一个多小时，常常迷失在阅读老邮件上。最后又找到几百封有用邮件。总算搞定，再清空垃圾箱，收工！

gmail.com

ongoing gmail

多少年了，Gmail仍然是web mail的老大。但是当年革命性的创举已经被outlook.com赶上，各种应用集成别人也有了。在这里打开pop功能也需要在网页设置点一下，还要打开所谓insecure legacy app访问。好在网页文档还是比较明确。Gmail下载速度比yahoo快，但比outlook要慢。但最大问题是每次仅能下载五六百封就没了，比Yahoo还要糟糕。我今天上午我写博客过程中，一直在手动继续下载，有几十次了，但现在邮箱里还有至少好几千：

Gmail里估计至少有几千我的私人邮件。今天晚上有的忙了。

空箱以后呢

空箱之后，还要继续保持空箱。其实，只要做到以下几点这并不难。我在非web mail账户中已经做到了，并维持了数年。现在要把这个习惯延伸到web mail上：

只有一个收件箱，跨越所有账户，保存过去一个月所有往来邮件。目前我这里邮件数量不到一千，绝大多数都看过。
只有一个归档箱，跨越所有账户，保存所有有用邮件直到永远。目前我这里邮件已经接近十万。只靠通过搜索来访问。
关闭新邮件提醒。我每天在碎片时间主动浏览收件箱里的新邮件，能快速回复快速回复。需要后续操作的邮件先标记下来。
每一到两天抽空把标记出需要耐心回复或额外操作的邮件耐心处理，防止越积越多，待处理邮件最多不能超过一周。
对于次要邮箱，例如这三个，不再使用网页或app。每天午夜用脚本通过getmail自动下载新邮件到统一收件箱，第二天一起处理。
最后，最关键的是：在99%的时间，只使用字符界面工具处理邮件

由于我绝大多数时间仅使用字符界面工具处理邮件，这完全避免了病毒，恶意网站，用户跟踪，图片，声音等负面影响，可以放心去看。而且处理速度大大加快。在合理防御下，我每天收到的垃圾，广告，无意义提醒加在一起不到一百。我相信，这已经比大多数人多。但我处理每封时间不到半秒，总耗时不到一分钟。相比如果漏看一封有意义的邮件对你带来的机会成本来说，这一分钟绝对值得。

邮件在诞生的时候就是一个字符界面工具，现在是时候让邮件彻底回归本源了：

And yet, email remains a wonder. Thanks to email, people across cultures, continents, countries, cities, and communities communicate every day. It’s reliable. It’s simple. There are no service provider incompatibilities, technical hurdles, or gatekeepers. If you have an email address, and they have an email address, email just works, every time.

– hey.com

后记

empty gmail

最终，我从Gmail下载了两万封邮件，总体量超过两个G。用脚本自动检测出六千多有用邮件，再用肉眼找出不到一千。把Gmail也终于清空了。

你有电子邮件邮箱吗？

Wed, 17 Dec 2025 19:32:16 +0000

这个问题好像是白给：Email是互联网最古老的通信方式了，是人都有啊。但是，我在这里大胆说一句：在读到我博客所有读者中，拥有自己的电子邮件邮箱的人不到1%。

邮件是做什么的？

我们先探讨一下，邮件是干什么的。到二十一世纪今天，通信方式多种多样，通信的需求也非常细化了。用邮件沟通最适合做什么呢？

实时通知？

假如我想请你今天晚上出去小酌一番，提前一小时发你邮件了，然后你放了我鸽子。错在谁呢？显然，错在我这里。对于实时性比较强的通信，邮件是一个很不好的手段。我可以微信你，短信你，打电话Call你，就是不应该发邮件。同理，任何通知性的信息，例如开会提醒，上课提醒，交作业提醒等等，你都不应该发邮件了，发了也是白发，徒增烦恼而已。

文件传递？

常常有人给我发邮件，邮件里最多一句话，但有一个不小的附件，常常是文档，电子表格之类，意图通常是让我看看，改改，再发回去。老实说，这是一个非常糟糕的工作方式。除了上面说过的实时性不够的问题，还有：

邮件有比较严格的大小限制
邮件是Base64编码，你发4MB的附件，实际要存5MB
你发来，我发去，同一个附件交流无数次，没版本控制不说，浪费的存储空间是惊人的。

少量文件应该用即时通信工具，最好有端到端加密的工具如Signal等传递。大量文件应该用项目管理工具来管理。

讨论问题？

很多人，尤其是在工作中，喜欢用邮件来回讨论问题。但是这也是很有问题的。问题之一是在outlook影响下，绝大多数人回邮件是top post, 导致上下文是逆序的，除了当事双方，别人相当难以理解。而且邮件越回越长，下面从来没有人修剪，最后无法阅读。问题之二是当气氛有点不友好之后，你抄送我老板反映，我抄送你老板反映，再有第三者出来搅浑水，最后通常变成骂战，没一点建设性了。

对于大多数人来说，讨论问题应该在恰当的论坛，BBS或讨论组里。这里有用户权限控制和归档功能，更容易达到文明理性讨论的目的。

邮件还有用吗？

既然以上都不适合用邮件，那我们干脆不要邮件了不是更简单？那我们现在来探讨一下邮件不可取代的地方：

留作证据

假如你老板跟你面谈的时候承诺这个项目完成之后给你加薪升职，我建议你立刻写个邮件给他，敲钉转角，而且一定要留个问题问他，让他不得不回复一下。同理，会议记录，备忘录等等也是这个目的。

备份渠道

邮件虽然在各个专项都不是最好的通信手段，但却是在各个专项中最好的通信手段不能用或不够可靠的时候，不可或缺的一个备份渠道。

永久归档

你收到的邮件其中99%最多过一个月就一点用都没有了。但剩下1%你却希望能永久保留下去，不仅十年，二十年之后可以再看，平时也可以搜索关键字什么的来回顾，找到对有用的信息。

我们有什么？

现在我们回到刚开始的问题：我们有没有自己的电子邮件邮箱？

绝大多数人有的是只不过是以下两者：

工作邮箱

工作邮箱其实不太好用作证据留存，尤其是可能和你的工作单位发生争执的时候。除了你入职签的保密协议会对你不利之外，公司的工作邮箱其实是有后台可以被管理员任意修改的。

工作邮箱其实也不是一个好的备份通信渠道。通常工作邮箱会有一些不近人情的过滤机制和纪律约束，也不建议你用作工作之外的私人联系。

最后工作邮箱不可能永久。或者你走，或者开你走，或者关门，有多少人能在一个地方干超过十年？枉提一辈子了。

免费邮箱服务

当然，你还有自己的个人邮箱，来自诸如Gmail，hotmail，或国内的QQ邮箱，网易邮箱什么的。可惜的是，这些也不是你的。坦率的说，这些服务是针对你个人的广告投放平台和隐私搜集工具，其邮件功能只不过是引你上钩的诱饵罢了。我们先不提广告啊，隐私啊什么的，就只考虑邮件功能，它们都很欠缺：

数据下载相当困难。详见我之前博客。普通人根本做不到归档。
借反垃圾邮件的名义，设置不近人情的门槛限制正当邮件进入，却对广告商大开方便之门。电子邮件成了最不可靠的通信手段，谈何做备份渠道。
留作证据倒是不假，但恐怕是服务商留作针对你的证据吧。真正有信息量的邮件，你放心让QQ收吗？

怎么办？

我能想到的只有两个办法。

有节操的付费服务

任何服务都是有价值的，你不是花钱买，就是花了别的什么东西。当然，花钱未必能保证不被虐，但不花钱则一定被虐。可惜的是，这个市场被贪图蝇头小利的屌丝们裹挟，有节操，踏踏实实挣用户钱的服务商不容易生存。中国国内我暂时没有见到针对个人的靠谱服务。国外有一些，例如今年新出的比较火的hey.com。年费99美元，我认为这个收费标准还是合理的。

自己搭

我就是这样，用自己的域名，自己（租）的服务器，自己做管理员。邮件服务都是非常成熟的自由软件，归根到底没多难搞，我的精力其实主要花在跟垄断型邮件服务商斗智斗勇上了，争取我发出的邮件别人能收到。对自己搭邮件服务有兴趣的朋友可以和我交流。

我不会再丢任何一封有意义的邮件了。你呢？

我的电子邮件处理流程

Wed, 17 Dec 2025 19:32:15 +0000

几个月前我写过一篇你有电子邮件邮箱吗？，阐述了电子邮件在这个时代对于个人来说不可取代的地方。我自己对邮件的处理流程经过很多年，在很多个工具上的逐步提炼，形成了一个我自以为比较简练合理的流程，在这里总结一下，希望对读者有一定启发。我这里描述的流程主要适用于个人邮件。工作邮件出于你的公司基础架构的种种限制，可能不一定可以适用。

极简组织

邮件归根结底，是很多很多个文件，它们的主要内涵是文字，相互之间也有一定的松散关系。为了方便处理，我认为邮件一定要完全保存在一个你可以快速访问的主机上，可以绕过所有工具，直接用脚本处理。否则，这些数据就不是在真正意义上属于你。

我的邮箱组织只有两个文件夹：Inbox (收件箱), Archive (归档箱). 此外没了。我所有的邮件，不管从什么地址收下来的，都在这里。收件箱保留最近一个月的往来邮件，通常数量在一千左右，归档箱保留所有有意义的长期保留的邮件，目前超过七万。其他所有的文件夹都没有：

没有草稿箱。简单邮件不需要打草稿。复杂邮件我草稿不打在邮件界面里。何况我的云主机永不掉线，草稿在人机界面 (主要是Emacs) 上几天也不会丢。
没有发件箱。我所有自己写就的邮件都Bcc自己，这样在收件箱里自然形成完整会话，不需要另行保存。
没有垃圾箱。我从来不手动删除邮件。我会用脚本自行归档邮件，剩下的自然而然就最多保留一个月。
没有自动检测的垃圾邮件箱。在我的邮件服务器上有相对宽松的垃圾检测机制, 这些彻底的垃圾会直接拒收。其他我全部收下来。
没有任何分类箱。不少人，包括我自己以前，总想着分门别类地把邮件收集好。最后我发现我坚持不了几年。如果三天打鱼两天晒网地去归类，还不如不做。何况，一个长期有效，合理科学的分类方法也近乎不可能。

另外，我也不使用高级一点的标签，标记，优先级标注等功能。首先它们对我用处不大，再者我也无法坚持。有些事情要给自己留余地。题外话的一个例子：比如说跑步，我每天其实可以跑5公里。但跑了五公里之后我回家要瘫坐在沙发一段时间，也做不到持之以恒。后来我减半到2.5公里，过去一年的时间我天天都在跑，一年下来也有不少里程了。

线索第一

我重度依赖的邮件功能就是线索管理。我必须明确知道，哪封邮件是回复哪封的，这样邮件们形成一个树状组织结构，这样我才能追本溯源，上下贯通。我完全不可以接受Gmail或Outlook的线性会话结构。当然，目前在手机客户端也没有什么选择余地，所以我尽量不用任何手机上的邮件app。有必要的时候，我会手动修剪甚至嫁接邮件树，来应对一些乱回复，或者使用不当邮件客户端的人。当然，这些树操作功能有热键方便操作。

任何有意义的邮件线索，我都会回复。如果实在无话好说，一句谢谢也是可以的。如果一定不能回复给发件人，想保密的话，那我也会回复，但会把回复的对象删除，只保留自己。这其实是假回复，我有快捷键来保证秒级处理。当然，假回复也并不常见。我自己的回复自然而然就形成了标记，而这标记不依赖于任何特定邮件平台的特定功能。

有了线索之后，我可以利用线索来加强搜索能力，和简化自动化归档。

搜索访问

我的归档箱中邮件几万，唯一可行的访问方法是搜索。所以，一个针对自己邮件的定制搜索引擎是必不可少的。我用过两个：一个是notmuch, 一个是mu. 目前我使用后者。它们都是本地安装的软件，而我直接把搜索安装在我的云主机上。查询语法很丰富，我不能完全记忆，还需要时常参考文档。我通常先根据一定关键字，发件人，时间段等信息先做搜索缩小范围以便快速人工浏览，然后再通过邮件线索信息做细化搜索找出依赖关系来弄清楚上下文。

有了一个强大的搜索引擎之后，这几万封邮件才成了真正有意义的个人数据；否则这些只是无用的堆砌而已。

自动归档

我的收件箱保留最近一个月所有往来邮件，也方便常规非搜索的邮件客户端软件使用。但我整个邮件处理流程的核心是归档。归档的意义有两个：

去芜存菁
节约空间

我收件箱中的邮件中完全垃圾大致10% ~ 20%左右。剩下的至少60% ~ 70%都是广告，群发邮件，各种通知，或者其他信息量很少的邮件。只有10% ~ 20%需要长期保留。那我是如何把这些需要保留的邮件找出来的呢？我多年以来总结出的算法如下：

归档的单元是线索。
所有仍有未读邮件，或者最新回复在一个月内的线索保留在收件箱内。
所有有我回复参与的线索归档。
所有我不参与的线索删除。
归档线索中，所有附件删除。

这个算法简单明了，容易实现，没有任何模糊空间，而且也不依赖于任何邮件内容。我之前提到的主动回复，假回复，线索剪裁嫁接等操作都是为归档服务的：

主动回复标记了有用线索，同时也是网上礼节。
假回复在保密情况下也标记了有用线索，在热键定义下方便快捷。
线索剪裁和嫁接保证了线索的合理性，剪掉了垃圾分支，对于归档之后的搜索访问也是大有帮助的。

另外，我在归档过程中自动删除了所有附件来节约空间。我归档箱中七万多邮件，总大小不压缩只有两三个G。附件不参与全文检索，所以对搜索没什么意义。这些附件可能也有部分有意义，但是，它们信噪比低，又很难用搜索找出来，全盘考虑下，我还是选择全部删除来简化算法。少量实在有用的附件我会另行保存。

未来

目前我的邮件流程已经比较固定了，但是定制化的部分比较多，不是很容易推广。今年我会争取把适用性强的部分抽取出来，发表成自由软件，方便其他用户使用。我也希望能多了解其他邮件用户的独到心得，进一步完善我的流程。

安卓手机上的Emacs

Sun, 14 Dec 2025 20:40:47 +0000

我上个月的博客有一篇关于 Emacs, 有一篇关于 Android手机. 自然而然，会有人希望在手机上运行 Emacs, 是不是? 我当时以为不行，但其实我错了。Emacs 可以在 Android 手机上运行，而且不是 ssh 到远程主机上，不是什么简化版，不是什么仿真器，而是真的 Emacs 直接运行在 Android 系统上，包括一切你在电脑上的 Emacs 所拥有的高级功能，例如 org-mode, magit, eww 等。Emacs 在手机上不打折!

Termux 终端

Emacs on phone

我说过，有没有字符界面是真电脑和假电脑的根本区别．我之前介绍过 ConnectBot，是手机上的全功能 ssh/telnet/local 终端仿真器。但手机上本地应用时各种字符界面工具不够，所以通常我只用它 ssh 到远端。下面介绍的这个应用叫 Termux，是完全针对手机本地使用的终端仿真器。它的软键盘扩展类似 ConnectBot, 但真正把 Termux 和其他终端仿真器区别开的是相当丰富的网上应用库，直接用大家熟悉的Debian系的 apt 工具可以访问! 换句话说，这是安卓上的 cygwin, 而且比 windows下的 cygwin 更好用。刚安装上app的时候它仅是一个极简系统，但我们可以:

$ apt install make git perl emacs

termux

然后不到200MB流量之后，这些基础软件就安装到你的手机里了。Termux 本身可以从 google play 或 f-droid 安装，而且无需 root 你的手机。如果有一天你不想用它了，卸载 app 就会把 Termux 以及你通过 apt 安装的所有软件，以及你用这个环境产生的所有文件一起清除，不留痕迹，安全环保。

CPAN 及其他

cpan on phone

当然，Termux 毕竟不是一个完全的 Linux Distribution，各种软件总会有些缺失。但它有 gcc 和基础库，实在不行可以自己编译。但在此之前你还有相对简单的方法安装软件。假如你所需要的软件是 perl 写的，你可以用 CPAN 来下载安装。我用 cpan 安装了 template toolkit 和 ack, 都是比较复杂的 perl 软件包，都能顺利安装成功测试通过。当然，也不仅限于 perl 和 cpan, python 上也有类似的软件发布平台 pip, ruby 和 node.js 也有类似的基础设施，这些平台都能在 Termux 上找的到，有点遗憾的是 Haskell 平台暂时还没有。CPAN 证明了一点，有了 Termux, 安卓已经是一个真的通用操作系统了。

Emacs

melpa on phone

Termux 已经包含 emacs 26，相当新了。其中，org-mode 和大多数你用的到的 emacs 组件都已经自带，另外，和 perl, python, ruby 等一样，emacs其实也是个编程语言以及应用发布平台。通过 emacs 自带的 melpa 平台，我们可以很轻易安装其他附加软件包，例如常用的 markdown-mode 和我之前介绍过的magit (git 前端)。安装了几个包之后，这个手机上的 emacs 已经达到了和我工作电脑上完全一致的功能。你目前看到的这份博客其实是完全在手机版 emacs 上写作完成的。而且，当你有了真的 emacs 和 git 之后，其实我上个月介绍的几个安卓应用，例如 syncorg, mgit 等对我也基本失去了意义，何必不用全功能并且和电脑一致的软件呢？

用途

Magit

让我再分析一下在手机上安装命令行环境，emacs 及其附加软件的意义。它带给我们很多功能，但不是所有功能都很有意义。比如，如果我愿意的话，我其实可以在手机 emacs 上读写邮件，但这恐怕不能给我带来什么价值，毕竟手机环境下有更好用的邮件客户端。在手机上用 emacs 和 git 的真正价值在于它提供了一个分布式的写作平台，而且手机环境和电脑环境完全保持一致，让我能无缝地在电脑和手机之间切换，当没有电脑或使用电脑不方便的时候可以继续写下去，而不是仅仅刷屏微信什么的。相比之下，wiki 不好用，Google doc 不能离线，用邮件把 word 文档传来传去? 还不如把我杀了。

总结

文字界面的历史超过我的年纪。很多人认为，文字界面不方便，不人性化，在1984年第一代 Mac 诞生的时候，苹果为了标榜革命，甚至完全去除了它的文字界面。但十几年后，Mac OSX 又加上了标准的文字界面，承认了当年的错误。Emacs 在我心中是文字界面的终极大 BOSS, 通过对文字的极致处理，衍生出种种周边功能，从而俯瞰其他编辑器。在智能手机成为现代人身体的一部分的今天，在 Termux 的帮助下，手机终于打通了关，见到了 BOSS. BOSS 其实从来未变，他一直在这里等待。

VI 和 EMACS 之争

Tue, 16 Sep 2025 02:02:41 +0000

我自己是一个忠实的 emacs用户，但在 emacs 不存在的地方也常常需要使用 vi. vi 和 emacs 之争贯穿 UNIX 和 LINUX 的几乎全部历史，不知道引起过多少口水。在21世纪的今天，有人为它们都过时了，但我觉得未必。今天我试图用尽可能中立的态度回顾一下我所知道的全部历史，不仅有一定科普意义，对自由软件从何处来，到何处去这个问题也能提供一些思考的原材料。

史前时代

Emacs vs VI

很久很久以前，这世界上即没有 vi 也没有 emacs. 1970年带给人类 UNIX 和阴极射线管 (CRT)终端，但人机交互仅限于严格意义上的命令行，即你敲一条命令，电脑回一些结果。那程序是怎么写的呢？也是一行一行敲进去，用其他命令一行一行改。你并不能在看到多行程序上下文的情况下，移动光标到位置，然后插入或修改文字。这个一行一行敲，一行一行改文件的工具在 Unix 下叫 ed , 当然也是 unix 之父 Ken Thomson 的杰作。Ken 是一个真正的大拿，他直到后来也不是很理解，你为啥要看到程序上下文才能写程序? 不都在你脑子里吗？

1976: 原始 emacs

在 MIT AI 实验室有另外一个操作系统 ITS, 上面的类似 ed 的程序叫 TECO. TECO 在技术上比 ed 高级一些，它已经是一屏一屏显示，然后有一个命令行界面可以再输入命令，比如在第三行第五个字符后面插入字符串 “hello” 什么的。当然这样也不方便，但它还有一个功能，可以定义宏 (macro)，把某个命令序列绑定到一个热键上。于是许多人就写了许多宏，让 TECO 变的好用很多。机房管理员叫 Richard Stallman, 就是后来大名鼎鼎的 RMS, 他搜集整理了大家的有用的宏放在一起并持续维护，最后大家都用他的了。RMS 把这些宏的总和起了个名字: Extended MACroS，简称: emacs

1977: VI

在大致同时期，美国西岸的加大伯克利分校有个研究生叫Bill Joy. 伯克利是最早的 unix 使用者，Bill 也买了二手 CRT 终端拨号连到学校上机写程序。他发现， ed 太他妈难用了，于是就找出源码一阵改，改的新版叫 em, Ed for Mortals. 后来越改越来劲，并利用到终端的新特性，添加了全屏模式，新程序叫 ex. 这个程序迅速得到了同学们的一致好评，Joy 发现人人都用全屏模式，没人用保留的兼容ed的行编辑模式了，于是他再改名，叫 VIsual, 命令仍只取两个字母: vi. 随着 BSD 攻占全美大学机房，这个程序也被 AT&T 采纳，进入 unix 主流。

1981: Goosling emacs

随着 unix 的流行，ITS 逐渐式微。大家都用 unix 系统和 c语言，但不是所有人都喜欢vi。很多人怀念 emacs 的强大功能和用户可扩展性，出现了几个 emacs 克隆版本, 其中最著名的是 James Gosling 的版本。Gosling 10年之后以 JAVA 之父闻名天下，但初露头角时靠的是重写 emacs. 他的版本在技术上有不少创新:

核心用 C 语言写就，运行在 UNIX 上
主要应用逻辑用一种自带的 lisp 实现
麻雀虽小，但已经有原始的 VM 和 GC

很快，这个版本就在学术圈流行开来，成为高端编辑器的代名词。当然， vi 的地位也无可撼动，有人形象地说:

Vi is like masturbation: it is not as good as the alternative, but it is always there.

1985: GNU

RMS 在这一年重操老本行，在 Gosling 的基础上，重写了一个更强大的 lisp 引擎，整理了所有代码，作为他实现一个完全自由的操作系统 GNU 的奠基石。第一个版本就叫 GNU EMACS 13. 从技术角度而言，这个 emacs 并无太大创新，但它的政治意义非常深远。我这里提过的所有软件，从 Ken 到 Joy 到 Gosling 写的，都是开源的，但并非自由的。原因有二: 一，虽然这些软件是自发写的，但他们都有雇主，软件著作权属于雇主；二，个人开发者源码互相借鉴抄来抄去，说不清根源了，所以， AT&T 和其他公司的著作权在法理上难以挑战，最后这些软件的新版本连开源都做不到了。RMS 对软件权益有切身之痛，一年前就辞了职，成为完全自由职业者，gnu emacs 虽一开始基于 Gosling 版本，但不到一年的时间，彻底重写了每一行代码，而且全部著作权交给刚成立的自由软件基金会。这样，gnu emacs 成为史上第一在法理上无可辩驳的自由软件。这个版本也迅速取代了 Gosling 版的江湖地位。

这里再着重提一下 RMS 这个人。RMS 以圣徒自诩，人们也通常以为他是唐吉柯德式的傻瓜。从技术水平和贡献上他比不了 Ken, Joy 或 Gosling, 但他创立了自由软件基金会和 GNU 项目，并身体力行，一直以身做则，为我们今天蓬勃发展的自由软件事业奠定了基石。从这个意义上说，他比这些大拿们更伟大。

1991: vim

事实上今天我们用的 vi 并非 Bill Joy 的 vi，如果想体验一下老 vi 朋友可以尝试在 debian 下安装 nvi (BSD vi), 当然这也不是老 vi, 但毕竟接近的多. 老 vi 正如 RMS 所预料的一样，从开源的共享软件变成了厂家的商业软件。当 FreeBSD 要发布的时候，必须把所有和 AT&T 有关的代码移除，所以只能重新写了 nvi. BSD 的朋友们比较保守，整出的 nvi 和老 vi 相当接近，但另一批人就没这么多历史包袱。

vim 起源于 Amiga 平台，但在新兴的 Linux 平台迅速找到了自己的家。自称 vi improved，它迅速成为 linux 上最主流的 vi ，并大胆添加了语法高亮，用户程序扩展等贴近程序员使用的功能。和之前的 vi 或 emacs 不同，vim 的开发团队并无够分量的大拿坐镇，但赶上了 linux 和互联网的爆发，兼收并蓄的吸纳社区里各种贡献，虽然从软件工程学上不一定严谨，也没有什么特别值得一提的技术独创，却走进了 Linux 社区的心里，和 linux 一起在90年代病毒式扩张。同期的另几个重要软件如 apache，mysql，php 莫不如是。

1992: lucid Xemacs

再说 emacs 这边。90年之后，RMS 的主要精力放在社会活动上，FSF 请了新人继续开发 emacs. 但 FSF 没什么钱，光靠情怀请不到什么牛人，何况上面还有一个要求甚高的原作者 RMS 指手画脚，所以 gnu emacs 开发陷于停滞。此时有个公司 lucid 要做基于 emacs 的IDE, 自己搞了一套 lucid emacs, 主要贡献者是 Jamie Zawinski(JWZ). 此人在 lucid 94年关门后又去了 Netscape，然后又在三藩市开了个夜店 DNA Lounge, 非常值得一去。JWZ和 RMS 在技术路线上有严重分歧，自由软件早期最著名的一次分裂和骂战上演了。回头看实际上双方都是好人，但矛盾不可调和。Lucid emacs 演变成了 XEmacs, 在 GNU 体系之外独立发展。90年代中后期实际上有三大编辑器，vim, emacs 和 Xemacs.

Vim 在编程功能上渐渐追上来了，到96年左右实际上在程序员需要的功能上超越了 emacs。emacs 一直以来都有个劣势，就是比较慢，占内存，毕竟是基于高级语言的。当时有个说法：

EMACS: Eight Megabyte And Constantly Swapping.

早期 pc linux 用户都穷，没多少内存，结果你功能还不行，所以 gnu emacs 比起 vim 就不受欢迎了。 Xemacs 倒是功能更强，但更耗资源，还有个乱臣贼子的骂名，也没有大火。

2001: 新世纪

2001年，xemacs 和 emacs 相继推出了 v21, vim 也推出了 6.0。编辑器功能的进化放缓，emacs 在编程功能上终于基本追上了时代，21世纪的电脑也都够快有够多内存，emacs用起来也不觉得比vim慢多少了，我自己也是大致在这段时间成为 emacs 用户的。

那边厢 xemacs 问题逐渐暴露出来。它其实一直没有找准定位，一个更新更潮的 emacs? 问题是真正追求新潮的人也不会去用可以追溯到1976年的软件了不是? 用 emacs 或 vi的人要的是 get the job done. 所以 xemacs 一直没有足够大的社区来好好维护这么大这么复杂的程序。它还坚持了近十年，但最近一个正式版本发布已经是十年前了。

但不管怎么发展，vi 和 emacs 还都坚持着自己的原则． vi 的哲学就是 unix 的哲学：每个工具做好自己的事．emacs 的哲学则更古老一点：别让贫穷束缚了你的想像．这两个哲学对立而互补，驱动着自由软件不断进步．

总结

vi 的历史非常平稳，在两个关键的时间节点上搭上了历史的快车．而 emacs 的历史相对就跌宕起伏了：emacs 所瞄准的目标远比 vi 的高，摔的也比 vi 狠的多．其实，vi 和 emacs 并不是敌人，而是在不同层面上互补的伙伴．大家共同的阵营叫自由软件，而对于自由软件阵营里的程序员来说，什么又比我们手中用来写代码写文档的工具更重要呢？

Emacs新应用

Sun, 07 Sep 2025 22:02:20 +0000

Emacs作为一个面向程序员的编辑器，已是久负盛名。但正如巴塞罗那不仅是一家俱乐部，微信不仅是一个通信工具，Emacs也不仅是一个编辑器，而其实是一个应用平台，有着丰富的第三方应用。下面我介绍一下最近几年比较热门的一些应用。

浏览器EWW

EWW

用emacs浏览网页可能是疯了。要知道浏览器是目前最复杂的客户端应用，连微软都搞不定，emacs在一个文字界面上能搞出什么名堂? 说老实话，我个人经常在文字界面上使用浏览器，主要是阅读一些API文档，或者程序自动生成的html报告日志什么的。在这些情况下，可以在文字界面下快速浏览是一件很有意义的事情：这时候也不需要JavaScript或图片什么的，要的就是能快速打开，搜索和跳转。我曾经用过lynx和w3m, 在emacs内也曾用过其他方案，都比不上w3m好用．但是，emacs里最新的浏览器组件EWW在速度和兼容性上已经达到或超过了w3m的水平，而且在emacs内部可以借助其强大的文字表现和搜索功能，完美的实现了有限的文字html浏览。大家不妨一试。

邮件客户端mu4e

mu4e

Emacs可以读邮件至少有二十多年的历史了。mu4e已经是我自己用过的第四种emacs内置邮件客户端，但在前三次尝试中，我最后总是回到mutt。题外话夸一下mutt, 和它的前身pine一起，真的是历史上最杰出的文字界面邮件客户端，可以轻松应对每天几百封邮件狂轰滥炸．但我用过mu4e之后，已经渐渐不再使用mutt了．为什么？

mu4e 在基础邮件客户端功能上已经很逼近mutt了
mu4e 使用了和 EWW 一样的 emacs 内建 shr 引擎来表现 html 邮件，渲染速度超越了 mutt + w3m
mu4e 是完全基于搜索的，类似 gmail, 或命令行下的 notmuch. 比起常规邮件客户端它更适合当今海量邮件的现状．
最后，mu4e 和其他邮件客户端做到了完美共生．不管文字界面多出色，你总会需要用到图形界面客户端，webmail和手机客户端的，对不对？

git客户端magit

magit

现在所有程序员都要用git. 但我之前有一点小小的偏见，认为各种封装后的 git 客户端都是给菜鸟用的，是阉割版，傻瓜版，用了跌份，直到 magit 扭转了我的偏见．其实 magit 也不是第一种 emacs 下的集成 git 客户端，但之前的种种源于更早的 RCS/CVS 系统界面的改造，用起来总是感觉怪怪的，而 magit 应该是第一种完完全全为 git 开发的 emacs 客户端，不仅适合菜鸟，也适合进阶用户：

magit 和emacs内其他组件，例如ediff完美结合，提供更方便一致的用户界面
magit 提供可探索的用户界面，老git用户例如我，甚至学到了以前不知道的窍门
magit 并不屏蔽原生git命令界面，你能清楚知道它要做什么，做了什么，也不会久而久之不会用git命令行了

org-mode

把 org-mode 放在这里我其实有点犹豫．一是因为 org-mode 历史长的多，十几年了，另一个原因是很难定义 org-mode 究竟是什么．但如果不讲 org-mode 又感觉对不住大家，毕竟这是 emacs 近10年最牛的应用，没有之一．从某个角度来讲，org-mode是 emacs 里的 emacs, 它什么都能做，还可以进一步扩展．它可以用来写文档，写程序，做项目规划，做展示胶片，做电子表格，做网站，还有手机客户端．下面我从几个方面简述一下：

个人项目管理

org-mode

这是 org-mode 的初衷，stay organized. 用 org-mode 你可以记笔记，列待处理事项, 生成日程表，让你在千头万绪的日常工作生活中不会迷失线索，忘记事情．尤其是对于我这种已经整天对着 emacs 看的，又容易忘事情的人特别有用，相当于一个高效的数字助理在你的指尖．

结构写作

由于 org-mode 的强大功能和文字表现能力，很多人也把它当作通用写作平台．你可以把它理解成 word + excel + powerpoint: org-mode 能让你做结构性写作和表格演算，并通过 html 或 latex 后端生成专业级别输出．坦率地说我自己其实还没有习惯这么做，个人还是偏好于使用 markdown + pandoc 来做这类事情．

文学编程

英文原文是 Literate Programming, 我可能翻译的不好．这个概念是把注释嵌在代码里这种常见编程模式反过来，把代码片段嵌套在文档之中，运用 org-mode 强大的结构写作功能和可扩展的后处理能力，实现一套源文件，一边生成专业级文档，一边生成程序．目前看来在学术界或数据分析行业用的比较多，我暂时还没有这方面需求．

总结

我一开始说过，Emacs其实是一个应用平台．在 http://www.melpa.org 上目前列了4051个安装包, 全都可以在emacs内部一键式安装．当然，大多数应用不独特，也比不上其他平台上的类似应用．但是，这些应用中不乏亮点，除了我列出来的这几个之外，还有不少等待我去发掘．应该说，这是一个相当成熟健康的生态系统．Emacs在快40岁的年纪仍然生机勃勃，这是自由软件才能创造的奇迹．

Vi is like masturbation: It is not as good as the alternative but is always there. – Annonymous commentor

手机应用还是信息监狱？

Fri, 05 Sep 2025 04:53:47 +0000

读过我向手机应用说不一文的朋友们应该了解我对手机 app 的态度：99% 的手机应用都是无理取闹。但是，我对手机本身是没有什么负面态度的。智能手机和随处可见的数据网络大大加强了这个时代人类的连通性，确实为我们带来了很多的便利。如果不用 99% 的 app, 只用手机浏览器，我们是否还能享受智能手机的大多数便利呢？为缩小讨论范围，我这里把应用缩小到适用于 PC 端浏览器的网页应用范畴，主要是阅读和音视频类信息接收。这也是手机应用的一大领域。

手机网络世界

用手机浏览器，在中文网络世界基本寸步难行。

百度

知乎

虎扑论坛

hupu

小结

以上三个网站在 PC 端都是相当可用的，但到了移动端，它们都无时不刻试图诱使你下载移动 app, 甚至用户界面故意做成你会一不小心点错跳转到下载界面的样子。我浏览了一段时间之后只好放弃，再也不在手机上访问这些网站了。

英文网站这个情况也存在，但没有这么严重。

Washington Post

小结

这些英文网站在手机上基本可以正常使用，虽然也有提示下载 app 什么的，但容易拒绝，不给我带来过多烦恼。

它们想干吗？

在明面上，它们的理由是手机 app 能提供比网页更好的用户体验。这貌似正确，但值不得推敲：

手机界面最大的问题是屏幕小。但手机 app 也无法克服这个问题呀。何况，我用10寸安卓平板访问各种网站，它们还是会各种提示下载 app
以上我选的应用都是不需要过度用户交互的，常规 app 上能用的用户界面手段，网页照样做的到。其实这些网站也已经做到了。所以说，并不存在必须使用手机 app 不可的用户体验问题。
手机网页界面上最严重的用户体验问题，恰恰是人为的，就是这些随处可见，试图诱导你下载 app 的提示本身！

所以说， “手机 app 能提供比网页更好的用户体验” 是一个循环论证。手机网页版其实可以做的够好，但是服务商们偏不，更有甚者，它们故意往不好的角度去做，其目的就是把用户往 app 上去带！这件事的核心理由并不是从用户角度出发的，而是从应用提供商角度出发的。联系到我之前向手机应用说不一文，很简单，在手机 app 上有更大变现的可能。钱不是从天上掉下来的，所以，羊毛一定出在猪身上，这猪就是受蒙蔽，被洗脑的用户们。

当然，以上这些应用，至少在 pc 端还是可以通过浏览器使用的。现在还有不少应用压根就没有网页访问的可能，例如微信，今日头条等。它们彻底放弃了不那么挣钱的网页用户，一心一意地向手机 app 用户提供 “免费” 的服务，即使冒着被苹果，谷歌，和政府政策强制应用下架的风险也在所不辞。这里猪们如果没有足够的利润空间，这些厂商是不可能做活雷锋的。

互不联网？

在传统互联网的时代，每份信息的标示是链接，你只要有链接，就能顺藤摸瓜，跨越多个服务商来寻找根源。到了移动互联网时代，链接已经没有意义了，实际上已经成了互不联网。每个服务商都推自己的 app, 试图把用户抓在自己的手心里，不让自己的有价值信息，其中大多数还是用户创造出来的，让别人自由访问，就算想付费访问也不行。这篇文章互联网完蛋了，已经。写自2017 年，讲的是同一件事，说的比我深，内容在今天仍然有效。

我个人仅在迫不得已的情况下使用手机 app. 在有可能的情况下，我会尽可能使用网页版应用。关于这篇文章，我自己其实有一个矛盾心理，这是因为估计各种服务商在我身上挣不到什么钱，但我确享受了互联网，和移动互联网的大部分红利。我这种人能逍遥在外，主要靠的是大多数天真用户，即所谓的猪们，为服务商提供利润。但是：

如果大多数用户醒悟过来，像我这样谨慎使用各种应用的话，服务商挣不到钱，服务下线，所有人，包括我在内也就享受不了了
如果用户都被服务商彻底洗脑，一心一意用 app 的话，服务商也就不需要再在乎我这类异端，而变成纯 app 访问模式，那我也逍遥不下去了

任何真相都值得了解。每个人都只能为自己打算，但最好是了解了真相之后。

吐槽俱乐部

Mon, 01 Sep 2025 06:10:19 +0000

我的初衷是为我的博客做一个留言板。但是我又想，为什么不为所有人的博客做一个免费使用，尊重隐私和言论自由的留言板呢？然后我再想，为什么要局限于博客，而不是开放给所有人，能对所有对公众开放的网页留下你的评论，并且看到别人的评论，然后再进一步评论下去呢？

于是，吐槽俱乐部诞生了。

留言板？

留言板的作用主要是互动，让读者和作者互动，读者和读者之间互动。但是，拥有一个好的留言板并不容易。目前的解决方案主要是两种：

使用博客平台自己的留言板
使用第三方的留言板服务

方案一的问题是不够开放。你博客的读者未必是本平台的注册用户。而且平台为了防范恶意攻击，散发广告，灌水等行为必然采取一些限制措施，而这些限制措施常常使读者觉得过于繁琐，导致本来想留言的人最后很可能就不了了之。对于我的博客来说，由于我并没有使用任何公共博客平台，所以本来也就不可能。

方案二是指在你的博客内嵌入第三方提供的代码，从而集成留言服务。提供商包括Discus等等。这些服务通常比常规博客平台的留言板功能做的强大，都会有一定的信用审查等功能，防止恶意灌水，同时又方便读者使用。但是问题也有：广告或付费，你只能二选一。在你博客网页上内嵌代码，有安全和隐私问题，最后，在中国大陆互联网生态下，它最终必然被屏蔽。Discus已经被屏蔽了。

如果不考虑钱的问题，现有留言板主要的困境是：

尊重隐私和聚集人气的两难
言论自由和维护气氛的两难

roastidio.us

读过我前文温和派的困境的朋友应该了解，人间的最大问题是正反馈，富者愈富，穷者愈穷。在网上社区的反应就是网红的博客被恶意灌水，普通人的博客无人问津。假如有一个负反馈系统，这些问题就都不存在了。当然，没有正反馈，就不会聚集人气，也就不可能挣钱，但是我不在乎。且看在一个负反馈的游戏规则下，这个俱乐部能发展到什么地步。

俱乐部的宗旨

信息安全

吐槽俱乐部其实也是一个第三方网络服务。但和其他第三方留言板服务不同，它不需要做javascript 代码嵌入，而只能链接访问。留言并不能直接展示在博主的网页上。从缺点来说，博主无法向访客展示人气。但我也就不可能在博主网页上打广告，或者盗取流量信息等。

从评论者的角度来说，虽然你必须是俱乐部的注册用户才能发表评论，但本网站只需要用一个邮箱地址就可以注册，而且不向用户索取任何个人信息，包括用户名，密码等。你的邮箱地址也不会向任何人展示。在俱乐部里你甚至没有名字，只有一个由你控制的头像。大家不知道你是谁，也不在乎你是谁。你说的话不比任何人有份量，也不比任何人没份量。话的份量来自于你说的话有没有道理，而不是来自身份。

言论自由

作为用户，你可以任意发表评论。这里没有政治正确，也没有新闻审查，反正别人不知道你是谁，最多对你不理不睬，或者奋勇反击。但你既然敢说，就应该有被反击的心理准备不是？你可能会觉得这里会变成硝烟弥漫的战场，但其实不会。这里和社交媒体不同，最大的区别是没有旁观者，或者说不鼓励围观。网上吵架其实都是吵给别人看的，没有人围观，还吵的起来吗？

当然，你的言论自由不能侵犯别人的领域。你可以随便写，但别人没义务看，而且你也不能频繁骚扰别人。假如你对我吐槽，我不喜欢，我也不能删你的帖子。但是，被吐槽的人有权利对第三方屏蔽你的发言。这里的每个帖子都是独立控制的领域，谁的地盘谁做主。

自力更生

这里没有推荐排行，没有热搜，没有流量统计。热门与否，跟我无关。如果想看点人云亦云的东西，还是回到社交媒体吧。我刚才说过，这里没有正反馈。每个人都有自己的信息获取渠道，社交媒体也罢，草根论坛也好，吐槽俱乐部只接收吐槽，不提供槽点。

不推荐，不灌输的宗旨甚至包括你或别人发表在吐槽俱乐部的言论。这里不是发表平台，所有帖子都不会自动向任何访问者展示。想看帖，你必须自己发言，然后就能看到槽友的帖子了。先奉献，再索取，不是吗？何况大家一起吐槽过一个东西，才会有共同语言，要不然你怎么知道不是鸡同鸭讲？

结束语

这只是一个开始。吐槽俱乐部不适合所有人，但至少适合我。2021年，我希望自己能更主动搜集各种信息，而不是被动接收填鸭。我希望自己能更主动发表言论，其中系统一点，光明正大一点的写在博客里，而碎片一点，临时动念的写在吐槽里。而且我要做一些相关的软件工具和平台，分享给大家。在这年关将近的时候，也是给自己立一个旗子吧。

吐槽俱乐部的详细游戏规则在这里

吐槽俱乐部的专用博客在这里

LIV: 我自己的网页邮箱

Fri, 29 Aug 2025 12:56:59 +0000

年初的时候我写过一篇我的电子邮件处理流程，详细描述了我是如何处理我自己的邮件的。简单的说，我主要是利用字符终端工具来浏览，回复邮件，从而达到高效，省时，安全的目的。但是，字符终端总有时候不尽如人意：很多邮件都是基于HTML的超文本邮件，在字符终端工具下展示总是欠缺。何况，有不少时候我还需要点击邮件中的链接，进入网页应用，在字符终端下基本上所有的网页应用都是打不开的。所以，我还是需要一个网页版邮箱。读过我你有电子邮件邮箱吗？一文的朋友知道我为什么不愿意用Gmail之类的应用，而要自己搭建邮件服务器。那么，在自己的邮件服务器上，能不能实现类似Gmail的功能呢？

现有的开源工具

我曾经使用过两种开源网页邮箱工具，都是可以安装到自己的服务器上的。一个叫Sogo, 一个叫roundcube. 这两个软件包都可以在自建的邮件服务器上实现网页邮箱功能，其功能接近常见基于IMAP的邮件软件例如Thunderbird. 但是，我用了一段时间后都闲置不用，而重新回到字符终端工具了，即使字符工具有上述种种不便。这是因为这两个应用都是在IMAP上再包装的一层，所以：

IMAP做不到的事情，它们也做不到。例如有索引的全文检索
IMAP做的到的事情，它们才有可能做得到，但只可能更慢
它们在设计上面向一个小型机构，服务于几十上百用户。而我只需要服务几个用户，主要是我自己，再加上我的家人，所以有不匹配的感觉

web mail

我逐渐意识到，类似Gmail之类的云端邮件应用相当不简单。邮件这个应用虽然很古老，但是和其他网页版应用相比，要求其实很高：

邮件是数据量相当大的应用。我邮箱里有7万封邮件，数据量超过几个G。这个应用必须和相当大的数据有紧密联系。
邮件是和用户交互比较复杂的应用。假如点个什么按钮都要等个半秒一秒，你的耐心很快会被消耗殆尽的。

在一个网页应用的范畴下，数据在服务器端，交互在客户端，这就形成了一个两难：假如主要逻辑在服务器端，客户端通过HTTP请求与服务器端则会造成不可忽视的交互延迟，导致用户体验不好。假如使用类似React之类的前端框架，把逻辑功能尽量往前端迁移，则和后端的数据有带宽和距离上的割裂，这样就是一个相当复杂的分布式系统，一些重型数据应用，例如全文检索就不容易实现。

那么还有什么办法？

Phoenix LiveView

Phoenix LiveView是近几年涌现出来的新型网页应用框架。它是一个后端框架，但绕过了相对比较慢的无状态HTTP协议，而使用长时，有状态的WebSocket协议，使得客户端和服务器端的专有进程深度绑定，从而大大削减了交互延时。对于上述的邮件应用非常适合：所有应用逻辑运行在服务器端，和数据零距离，访问无阻碍。后端通过一个有状态的WebSocket连接和轻量的网页前端进行频繁交互，即时反馈加超文本邮件展示没问题！

compose

问题只有一个，就是没有现成应用。自由软件的世界里，没有枪没有炮，我自己造！我的应用栈分三层：

搜索引擎。这一层是现有的：mu: Maildir Utility. 我常用的字符终端工具 mu4e 即是基于此。
我在mu 的基础上封装一层，实现一个Erlang API，并补充一些mu没有的功能，把独享的mu界面改造成可共享界面。这一层我管它叫mc: Maildir Commander
最上层的网页应用基于Phoenix LiveView + Surface，用Elixir实现。这一层叫LIV: Live Inbox View

mc 和liv 是站在自由软件巨人们肩膀上开发的，它们自然也是自由软件。

LIV

threading

LIV才刚刚发布，只实现了我最需要的基本功能，目前只能认为是一个MVP (Minimum Viable Product):

只有一种邮件列表方式，就是按线索，时间倒序排列
不能删除邮件。这是因为我是用脚本自动删除无用邮件的
不能打开附件，写邮件也不能加附件。我对附件不太感冒

但是，LIV有其独特的功能，你在其他任何地方都找不到：

每封邮件，每个查询，都可以添加到浏览器标准书签
用线索智能展示邮件，即使在一个很窄的手机屏幕都可以用
使用Markdown格式来写邮件，并做即时HTML渲染

phone view

在家庭宽带+WiFi环境下，LIV使用如丝般顺滑。如果使用LTE网络，则会略感延迟，但不会比Gmail差。我自己已经是95%以上的时间使用LIV阅读回复邮件了。当然，LIV的目的不是100%取代字符终端邮件工具，而是与之共存。毕竟在字符终端上，使用快捷键定制操作其效率是网页应用比不了的。

LIV现在没多少文档，也暂时不太适合终端用户使用。如果你像我一样，自己运行自己的邮件服务器，并且不怕自己编译安装软件的话，不妨一试。我期待收到你的反馈！

如何让微信清静起来

Fri, 29 Aug 2025 10:53:41 +0000

我前文详细分析了微信的种种问题。作为一个用户，我还是非常依赖微信的聊天功能，但我每天花在微信上的时间过多，总是分神看一些其实完全没有意义的东西，不仅浪费时间，还泄露很多不想泄露的个人隐私。微信作为一个一体化平台，其功能用户无法裁剪。我当然可以选择不看一些内容，但我既然都用微信聊天了，总忍不住到各处点来点去，自制力不行怎么办？有办法。

禁用定位功能

我不认为微信有必要要知道我的地理定位。好在手机操作系统可以单独订制每个app的权限，GPS定位恰好在其中。跟我有一样想法的朋友可以到 Settings -> App Management -> 微信 -> Permissions -> Location Info 勾选 prohibit. 各种手机菜单有所不同，但大致相仿。

我还另外禁止了微信使用后台数据网络，这样除非我正在使用微信，微信都不能上网。

删除所有公众号

我早就下决心不看公众号，但今天一看，我居然还有几个公众号订阅。不如彻底删除干净。有类似想法的朋友可以打开微信，到 通讯录 -> 公众号，把它清干净。

删除所有小程序

如果在国内生活，一些小程序其实方便生活不少。但是，你可能没有意识到自己用了多少小程序。十个？二十个？今天我发现，我其实用过超过五十个小程序。我不是很了解小程序的的隐私保护机制，但安装小程序很方便，扫个码就是了。所以我本着宁可杀错，不可放过的原则，一口气删除了所有小程序。有类似想法的朋友可以打开微信，到 发现 -> 小程序, 主动删除。

删除朋友圈

所谓朋友圈其实是卖人设圈。但包括我在内，时不时总想发个啥博一下关注，没事也乱看一通朋友圈。我更由于家传的好为人师毛病发作，总忍不住用我的毒舌点评一番，并因此失去了几个美女朋友。其实我下过几次决心不再打开朋友圈，但看见红点在那里，总管不住我这手指。怎么办？

我的方法是把所有的联系人加入到 仅聊天的朋友 列表中。请打开微信，到 通讯录->仅聊天的朋友，到屏幕底部点击 添加->通讯录。然后你可以选择你想添加的联系人。微信这里没有全选功能，更恶劣的是每点选三十人之后，就不能再选了。而我通讯录里有五百人之多。我只好花上十分钟时间，把所有人都加进去了。

这样做的后果是我看不到所有人的朋友圈，所有人也都看不见我的朋友圈了，现在朋友圈上再也没有红点，点进去也不会再有什么东西，整个世界清净了。

需要声明的一点是这种做法和隐私无关，唯一禁止的是朋友圈汇集功能。我的朋友们还是可以主动点到我头像到我朋友圈里看，同理，我也能点朋友头像进去专看他的朋友圈。（以上不正确，从别人角度看我朋友圈为空）你既然都发朋友圈了，就不要再想着隐私什么的了。你发的任何东西，都在腾讯的对象存储里面，腾讯可以看，并做数据挖掘，世界上所有人理论上也能看到，只不过大家没有直接链接而已。

相对快捷方法

经朋友指出，其实微信有相对快捷的方法来关闭朋友圈显示。

方法一

设置->新消息提醒->朋友圈->关闭. 这样做之后发现页及朋友圈不会再有红点，但点进去一切照常。

方法二

设置->通用->发现页管理->朋友圈->关闭. 这样做之后朋友圈将暂停推送，发现页点进去将不会再有朋友圈条目。但你还可以点朋友头像主动查看朋友圈。

比较

我之前的方法相对复杂一点，但属于釜底抽薪，更加彻底。请朋友们自行选择如何处理。

关于本博客

今后，我的博客内容也不会同步发链接到朋友圈了。我的主页链接写在了我的微信个性签名里，在我的朋友圈头像下面就是。可恨微信无法做超链接，只好麻烦大家手敲，好在链接不长。我的博客支持RSS feed 汇集，长期读者请用RSS工具订阅。想和我博客内容做互动的朋友，请点击每篇博客文章下面 吐槽俱乐部 链接，我会及时回复。

最后声明一点，我的做法和任何政府的政策无关，我也不会离开微信，聊天总找得到我的。

博客平台对比

Fri, 29 Aug 2025 04:26:54 +0000

我之前文章介绍过如何免费无广告地创建一个个人博客。虽然过程不算复杂，但我承认还是需要一定的专业技能。很多人或者没有专业技能，或者就是不愿意操心，所以一个托管的博客平台可能更加适合。本文分析了几种常见的博客平台，分析它们的优劣，希望能对想踏入博客领域的朋友有所帮助。

分析范畴

四个平台

首先要说明的是我分析的角度来自中国境外，确切地说来自美国。在中国境内由于ICP许可的原因，能被个人自主使用的博客平台基本不存在了。另外，我今天故意不包括最常见的 wordpress.com, 它已经日薄西山，和 blogspot.com, 它已经沦为谷歌内部的弃子。最后，我也不包括以社交为主，博客为辅的专业技术平台如 dev.to 和 hashnode.com, 因为它们不是通用性博客平台。

medium

确切地说，medium.com 也不是一个通用博客平台。它的主要目的是通过内容发布来吸引读者阅读，从而获得用户付费以及时间投入，进一步榨取利润。在这点来说，和中国国内的今日头条有一定的相似性。可惜，由于它没有合适的环境来建立垄断地位，所以至今挣不到钱。我们今天不谈付费内容也不谈个性化推荐，其实在 medium 上每一个人，包括未付费用户例如大家，都可以随便写，随便上传免费内容，其实也相当于一个博客平台了，相当于一个文字版的YouTube。

优点

medium的写作界面可以说是对菜鸟最友好的了：

所见即所得的超文本编辑器，功能简洁直观。
鼠标拖动的图片上传并自动调整大小。

medium还提供点赞 (medium的说法叫拍手applaud) 和留言功能，访问量也可以直观统计。如果你写的好能成为它的 partner，还可以统计阅读时间，精确到15秒，甚至挣钱。这就类似微信公众号或头条号了。当然，那就不再是个人博客，而是出来卖的软文了。想发财的人可以先别激动，据说medium上的写手80%一个月挣不到100美元。

缺点

medium作为一个博客平台缺点也很多。最重要的一点是不支持自主域名，你就算付费也不支持。另外，网页加载相当慢，而且不是网络不好，而是它上面乱七八糟的脚本实在多，目的是全天候检测记录读者的行为。最后，medium被中国大陆屏蔽，虽然这不是它的错。

小结

如果你是菜鸟中的菜鸟，一个月写不了一篇博文，并且文章里面有不少照片，而且你已经偶尔会上medium阅读的话，它也不失是一个选择。

svbtle

svbtle.com 的历史不比 medium 短，到如今也有八年历史了。和medium不同，svbtle的目的不是增长，而是维持。它完全没有社交功能，踏踏实实靠收博主月费过日子，一个月六块，童叟无欺。

优点

svbtle是一个傻瓜型博客，你能控制的只有一个头像，一个颜色，其他什么都管不了。你负责写文章，它负责发在网上，仅此而已。唯一的和读者交互的功能是点赞，甚至不能留言。所有人在svbtle上的博客基本都长得一样，其实还挺顺眼的。网页设计是个技术活儿，我见过太多自以为是的博主把自己博客搞得花里胡哨，看的人眼睛疼。在这里完全没有这个问题。

svbtle的写作界面就是一个文本框，你用markdown写文章，鼠标拖动上传照片。markdown是博客界通行格式，人人都懂，也很容易迁移文章。

svbtle的加载速度相当快，网页上很清爽，没有什么莫名其妙的东西。涉及读者隐私的包括google analytic和一个cookie，横向比较是很有良心了。它也支持SSL和自主域名。

最后，svbtle最大的优点是它的永久承诺。只要它不垮，你发表的文章会永不下线，就算你不再付费了, 它也会始终保证链接不断，永远有效。

缺点

svbtle的缺点和优点一样：太少控制，功能太简单。markdown虽好，对于菜鸟还是要有点学习时间的。还有就是月费，虽然只有一顿麦当劳钱，但也是钱啊。

小结

到目前为止，中国大陆尚未屏蔽svbtle。但这可能是因为用户不多，内容不够争议，尚未触发GFW而已，以后不保证。我只能说，由于月费的关系，它用户不可能多。如果你是一个懒人，不愿意管博客上的闲事，但又愿意写，愿意花一点小钱，svbtle是一个不错的选择。

write.as

write.as 只有两年多的历史，是一个比较新的平台。它有一个免费层，但免费层不能发图，所以基本没用。再上一层月费也是六块。但六块是年付的价格（每年72块），月付的话要九块。

优点

write.as 也算比较简洁的博客平台了，功能比svbtle多不少，但也不是太多：

tags.
themes. 可惜不是很多，又基本大同小异。
newsletter. 我认为RSS更有效
命令行界面工具。
部分页面密码保护。

另外，标准化的markdown，RSS，SSL，自主域名当然也都是支持的。最后，write.as 是全开源软件，你可以自己搭建平台。

缺点

write.as 的编辑器和svbtle类似，都是简陋了点。也不能留言，甚至不能点赞。

小结

同样，到目前为止，中国大陆尚未屏蔽write.as. 以后不保证。write.as 的历史短，架构新，功能比svbtle丰富。如果你觉得svbtle功能太局限，可以尝试 write.as. write.as 目前用户数不多，由于月费的原因，以后我估计也不会太多。月费理论上应该能保证其长久运作。

gonevis

gonevis.com 历史也不是很久。它的免费层不支持自主域名，但其他功能基本都支持，只是存储空间有限制，但对个人博客，除非你以图为主，也是够用了。这点相当有吸引力。第一级付费也只要每月5块美元，然后你就能使用自主域名了。

优点

gonevis 即使在免费层也提供相当丰富的功能，包括比write.as 更丰富的themes，以及：

一个相当丰富的控制面板
内建留言板
访问量统计
gonevis 内部有一点社交功能例如加好友等。

另外，标准化的RSS，SSL功能也是支持的。

缺点

gonevis公司和服务器在俄罗斯，从美国访问感觉有点慢，但慢不是很多。目前我认为它最大的问题是不支持markdown，而是使用所见即所得超文本编辑器。当然，对于菜鸟来说，这可能是优势。最后，作为一个比较新的平台，它还没有import/export功能，导致迁移比较困难。

小结

gonevis的免费层已经相当够用，付费层也不贵。但这是双刃剑。会不会有大量无聊人等抢注账户，占用免费资源，导致公司商业上比较难以产生利润呢？我对它长久的商业模式有一点疑惑。如果你对功能比较在意，又不担心我上面说的风险的话，gonevis是一个非常不错的平台。目前，gonevis也没有被中国大陆屏蔽。

结束语

对于准备开始博客之路，或者对自己目前平台不满，准备迁移的朋友们来说，我的这篇文章只是提供参考。鞋子合适不合适，只有脚知道。我今天提请大家注意的主要是商业模式：平台的产品是什么？卖给谁？如果都不付费的话，你就是那个产品，平台卖的就是你。

我上面提过好几次留言板功能，但这其实也未必重要。首先，留言板可以像我一样通过吐槽俱乐部来实现。更重要的是，博客归根结底是你自己想写，而不是想讨好读者。我们选用一个好的平台，尊重读者的隐私，提供好的阅读感受，说出我们的心里话，这是我们能做到的。读者喜不喜欢，我们作为博主真的无法太在乎。