关于 RSS 订阅器，以及推荐自建 tt-rss

RSS 订阅器，大致上分三种：

现有的网络服务，如当年的 Google Reader
单机版的订阅器
自建网络服务

从 Google Reader 停止服务，到现在快 10 年了。之后的所谓「老牌」订阅服务，如 feedly、inoreader，都限制了免费用户的订阅数量，不能超过 100 或 150 条。倒不是非要坚持用免费的，只是：

首先，这些服务并没有如当年大家期望的，在用户与用户之间，发展出推荐阅读之类的社区功能；
其次，如果有一天，它们也像 Google Reader 那样倒闭了，在这些订阅器里镜像的 blog 文章也全都消失，才是最大的损失。

单机版的订阅软件有很多，一些邮件客户端甚至手机浏览器，也有这方面功能。所以问题还是

抓取的文章能不能长久保存？哪怕重新装机，原来的文章也还在？有很多免安装的 RSS 订阅器，但其中大部分都是十几年前 blog 时代的作品，早已停止更新，对新的操作系统以及新的 rss atom 协议，支持都不好。Windows 下我在用 QuiteRSS，感觉不错。免安装，数据保存在 sqlite 文件里，似乎也有 Mac 版本。
以及，这类本地订阅器，有没有可能，通过网盘同步数据，从而实现多台机器或手机同时使用？我还没有见过这方面靠谱的方案。

自建 RSS 服务里，很多人推荐界面简洁的 Miniflux，我以前试过，感觉还行，但似乎有因为过于简化而不适的地方，忘了具体是什么了。/ 最终选择了 tt-rss （Tiny Tiny RSS），界面确实要比 Miniflux 臃肿一些，响应慢一些，但是它有一个非常亮眼的功能：你在 tt-rss 订阅器里，可以选择「发布」某些喜爱的文章，而这些发布出来的文章，是能够生成一个新的 RSS 地址，让别人订阅的！把这个 RSS 发给好友，对方就可以通过订阅这个地址，收到你向他推荐的文章。这就很有当年 Google Reader 的味道了！！

点击顶部「已发布文章」旁边的图标，就可以得到带密钥的 RSS 地址，发送给好友。

不只是「已发布文章」，加星的文章、你标记的某一个 tag、甚至管理 feed 时的每个目录，都是可以生成 RSS 地址的。地址的格式类似于：

https://website/public.php?op=rss&id=50&is_cat=0&q=&key=00secret0key00

除非你公开，外人无法得知。你也可以把不同的 tag 生成各自的 RSS 地址，向不同的人群公开。总之可以玩出很多花样。

其实 tt-rss 只是简单的 php+sql 架构，和 wordpress 放在一起就行了。但最近官方的文档，只推荐用 docker 安装。分成了 5 个 containers，总共需要约 180MB 的内存。

Docker Containers	Memory Usage
ttrss-docker_db_1	87.38 MiB
ttrss-docker_app_1	32.07 MiB
ttrss-docker_web-nginx_1	8.49 MiB
ttrss-docker_backups_1	1.98 MiB
ttrss-docker_updater_1	50.68 MiB

[php] 将多个 RSS 地址合并成一个

弄了个 php 程序，可以把自己的（or 别人的）多个 blog 的 RSS 订阅地址，合并成一个，供人订阅。例如，现在本站的几个 blog 的统一订阅地址为：

https://feed.fivest.one/

程序基于 DigitalFreelancing 的代码，略作修改，调用了 SimplePie 处理 RSS 的项目库，为每个原始的 RSS 地址生成缓存，避免了频繁读取。我修改后的版本，可以从【这里】下载。

使用说明

配置支持 PHP 的网络服务器，过程略；
下载源文件后，解压到新的 RSS 地址相应的文件夹里；
编辑 index.php，修改如下部分：

$feedlink = "https://feed.fivest.one/"; // 这个新的 RSS 的网址
$feedtitle = "fivestone"; // RSS 名称
$feedhome = "https://fivest.one"; // 你的网站地址（在 RSS 阅读器里点击 Title 可以进入）
$feeddesc = "fivestone's posts aggregation"; // RSS 描述

$feeds = array( // 需要合并的 RSS 网址列表，以引号和逗号分隔
    'https://a.fivest.one/feed',
    'https://b.fivest.one/feed'
);

$time_zone = 'Asia/Taipei'; // RSS 使用的时区
$item_number_limit = 20; // 新的 RSS 显示的文章数上限
$creativeCommons_license = 'https://creativecommons.org/licenses/by-sa/4.0'; // 你选择的知识产权协议（可以自行修改或为空）

根据你的网络服务器的权限配置方式，可能需要把 cache 文件夹设为群组或全部可写

chmod g+w cache 或者 chmod a+w cache

也可以把 index.php 改名，或者复制到其它位置，分别配置，生成多个这样的聚合 RSS。注意要调整文件中的相对路径：

include_once('./simplepie/autoloader.php');

箭术或禅心 – 1

箭术或禅心 – 1、2、3……

1920s，德国哲学博士赫立格尔（Eugen Herrigel）在日本讲课期间，学习弓道，后来把他的感悟写了一本小册子《箭术与禅心》¹。多年之后，这本书，作为「一位西方哲学家的禅悟」，渐渐火了起来。

在书里，作者重点描述了「禅」在撒手放箭这一瞬间的体现：并不是拉弓的人主动地把手松开，而是在进入禅意之后，让箭自己射出。

我问师父：「如果我不去放箭，箭怎么会射出去呢？」
：「是它射的。」「那一箭完全与你无关。」

在一个现代射箭爱好者&器材党的眼里，射箭的准确度，大概受这些因素影响：

器材质量：不要松动。

箭的质量（不要弯）和一致性：重量、均匀度、弹性（挠度 spine）……

弓对箭的干扰：箭是否从弓的中心射出？箭羽会不会蹭到弓？
解决方法：
- 中心箭窗
- 箭台（arrow rest）、箭侧垫（button）

瞄准的方法：
- 没有瞄准器时的替代参照物，或某些「直觉」瞄准法
- 使用各种瞄准器（sight）
- 复合弓使用窥孔（peep）更精确瞄准

每次拉弓的幅度，也就是弓的拉力，是否一致？
解决方法：
- 更稳定的姿势
- 弓弦和拉弦的手靠在脸的固定部位，
- 信号片（clicker，更精确地提示箭头和弓身的相对位置）
- 复合弓（拉到固定位置就无法再拉）

手指对弦的干扰：撒放的瞬间弓弦蹭到手指。
解决方法：
- 撒放姿势的改进
- 使用指板（finger tab） – 似乎这只是让手指不痛，而不是降低手指触弦干扰
- 复合弓使用撒放器（release），彻底避免手指和弦接触。

人在拉弓和瞄准时的手臂晃动
解决方法：
- 更稳定的发力方式
- 稳定杆（stabilizer）：力臂越长，晃动越小
- 复合弓（拉满弓时用力更少）

手感 – 主要是弓的设计和调校方面
- 弓的重心和质量分布
- 搭箭点上下两部分的力是否均衡，几根手指之间的受力分布

在追求准确性的现代射箭运动中，同样考虑到了，放箭一瞬间手指触弦造成的干扰。很多经典射箭教材中都提到了这一点，如何避免松手时肌肉僵硬，体会在若有若无之间撒放的感觉。——在上述的诸多因素中，手指对弓弦的干扰，只占很小的一部分；而且远不是最重要的那部分。而弓道，则在基本不触及其它因素的同时，把手指撒放的因素，放大到了超级重要的位置。

btw，弓道中也有很大一部分，是关于开弓的姿势，但似乎更集中于如何更平稳、有力地把弓拉开，而并没有在动作一致（以提高准确性）上，涉及太多。

另一方面，弓道强调手指撒放，并不是为了提高准确性。——事实上，相对于其它射箭运动，弓道已经把对准确性的要求，降到了最低点。在弓道低段位的审核中，只看射箭者的姿势和气质，完全不管箭有没有射中；高段位的审核中包括了对准确度的要求，然而，并不是要求射中多少环，而是……能射到靶子。

于是，手指撒放、乃至整个弓道本身，成为了一种媒介，让人通过它来感受「禅」。在这个过程中，感受「禅」，和技术提升，甚至是互斥的。《箭术与禅心》中，作者曾通过改进技术动作，来使自己达到和禅意类似的平滑撒放。师父发现后，立刻就翻脸了……

但在对「禅」的描述中，仍然能看出结果导向的痕迹。在师父的描述中，尽管会经常说能否中靶不重要，要「无所求」；但对禅的境界的描述中，箭自己射出后，箭也会自己命中。——所以「禅」仍然是一种导致准确率的神秘技术？

D 问我：那么，体育运动中的「技近乎道」，到底是说的什么呢？

我：呃……我觉得是，肌肉动作的协调性，超过了意识的控制能力和描述能力。就像乒乓球，初学者如果一直想着「入射角等于反射角」，再考虑重力、摩擦力，如何在空间中用二维平面去冲击一维矢量……肯定打的乱七八糟。而熟悉了之后，用什么角度击球是不需要思考的，击球者也无法把他的动作解释清楚。

而如果击球者，在达到肌肉自发动作之后，在回头来品味这个动作形成的过程，在自省中，重新构建无意识动作和意识本身的连接，这也就是一种「禅」了吧？

赫立格尔的这段经历，轴心国的味道十分浓郁。查了一下，果然作者在二战开始后不久，就成为纳粹党员，并且一直试图在学术领域，用禅来阐释纳粹思想²。在书里能看出这种苗头：弓道师父让徒弟进行的，很多不明就里的强硬单调指令，我们今天看来，是很典型的规训，当时却被描述为让徒弟自行开悟禅意的必要行为……

以及，弓道在日本，直到今天，仍然是右翼的重灾区。整个弓道机构，基本是上层阶级垄断的沙龙，内部等级制度十分严厉。甚至，有学术认为，在赫立格尔的小册子之前，日本箭术和禅道之间，根本就没什么关系，一切都是轴心国商业互吹的结果……³

1. Herrigel, E., 1953. Zen in the Art of Archery. With an introduction by DT Suzuki. New York: Pantheon.
2. Scholem, G., 1961. ZEN-NAZISM. Encounter, 16(2), pp.96-96.
3. Yamada, S., 2009. Shots in the Dark: Japan, Zen, and the West (Buddhism and Modernity)..

WordPress 使用 SQLite 数据库

之前写了一半的，如何在轻量级个人 VPS 上搭建各种服务的帖子。一时懒得去把坑填完了。但前几天突然发现自己落入了思维误区：为了配合 Mastodon 或 Pleroma，总想着如何把 WordPress 从 MySQL 迁移到 PostgreSQL。——但是，其实完全可以用 SQLite 啊！对于偶尔才更新一篇的个人 blog 用户，把数据库放在一个 SQLite 文件里，不需要另外安装数据库服务，完全是可行的。

用 Docker 观察内存开销。对于新建的 wordpress 站点，wordpress 本身（包括 php-fpm、nginx）占用内存大约是 40-100M（使用缓存插件后会减少）；MySQL 数据库占用内存 200M，随着渐渐使用，有着近千篇文章和评论的 blog 站点，MySQL 占用内存会达到 500M 甚至更多。 ——数据库的这部分内存，使用 SQLite 后，完全是可以省下的。

可以通过 SQLite Integration 插件，安装基于 SQLite 的 WordPress。Wordpress 官网的插件页面，因为作者失联而停更。但隐藏的插件下载链接，一直都还有效：

https://downloads.wordpress.org/plugin/sqlite-integration.1.8.1.zip

最新版本的 WordPress 也仍然可用。Github 上也有这个插件的分支。

使用非常简单，就是把 db.php 复制到 wp-content 目录里，同时确保你的系统安装了 php-sqlite3 模块。这里有篇攻略。现有的站点，可以通过 Duplicator 之类的 wordpress 备份插件，或者 wordpress 自身的导入导出功能，进行迁移，不需要进行数据库级别的转换操作。

注意事项：

1. 最重要的，数据库的文件的存放位置，这个一定要改！默认的数据库位置是在 wp-content/database/.ht.sqlite，是会被人通过浏览器从 http://website/wp-content/database/.ht.sqlite 直接下载的！虽然插件在 database 文件里添加了 .htaccess 权限控制，但对于如今大家用的 Nginx，是默认无效的。

在 wp-config.php 里添加设置：

define('DB_DIR', '/absolute/custom/path/to/directory/for/sqlite/database/file/');
define('DB_FILE', 'custom_filename_for_sqlite_database');

可以更改数据库文件的存放位置。强烈建议把数据库文件，放到无法直接用网址从外部访问的目录（记得给那个文件夹授权可写）。

2. SQLite 不适合多线程的高并发使用。如果网站会有多个用户同时在后台编辑，那么网站不适合使用 SQLlite；如果只有一个写作者自己编辑 blog，就很合适。但要避免使用那些，在一般访客浏览网站时，也会导致对数据库进行写入的插件，如：

WP Statistics 这样的访客统计插件，会把来访者的每一次点击，都记录到本机数据库里。建议使用 Google Analysis 之类的外置统计软件（Google 给 wordpress 做了个官方插件 Site Kit by Google），通过在页面嵌入 js ，发送访客数据到 Google 服务器，不会写入本地数据库。

官方的防垃圾评论插件 Akismet Anti-Spam，其实也是先把每条评论写入本地数据库，再判断是否垃圾的。如果被机器人大量发送垃圾评论，也会造成数据库写入的压力。建议使用 WP Captcha 之类的验证码插件（可以单独使用或配合 Akismet 一起用），把大多数垃圾评论在写入数据库之前就过滤掉。

3. 使用 WP Super Cache 插件，为网站生成缓存文件，可以极大地减少对数据库的读取操作。个人用户完全可以在插件设置里，关闭默认的 Garbage Collection 功能。

网上搜到的 WordPress + SQLite 的 docker images（1、2），Wordpress 和 php 的版本都有些过时了，本身也有一些小问题（如数据库文件夹的权限设置），建议修改 Dockerfile 然后自行编译。回头有时间我去改个试试。

WordPress 的 ActivityPub 插件

试用一下 WordPress 的 ActivityPub 插件（官网 / Github）。

主要功能，就是在 wordpress 上，建一个 Fediverse 账号，Mastodon / Pleroma / Misskey / Honk……的用户可以 follow 这个账号。新的 blog 文章发布时，这个账号会发一条嘟文，大家可以转发这条嘟文。followers 对这条嘟文的回复，会自动同步到 blog 文章的评论区。

就像我为这个 blog 建的 fedi 账号：@[email protected]

需要指出的是，并不存在 blog.fivest.one 这样一个 fediverse 实例。陌生人搜索这个账号，看不到任何历史嘟文；这个账号不能去 follow 别人，不能对别人说话，不能回复别人对自己嘟文的回复，也不能看到多少人转发点赞了自己的嘟文。——这些功能也许以后会有，但目前，这个插件所做的，只是在新 blog 发布的那一刻，向所有 follow 这个 id 的账号，push 一条嘟文。这条嘟文，在 blog 服务器上，并没有保存；而只存在于 follow 它的那些实例上，再被人转发到更多实例。

当 blog 的文章被删除时，这个插件也会通知所有的 followers，从他们的实例上删除对应的嘟文。但是就像我说过的，这个机制并不能把那些，被转发到其它实例的嘟文，也一起删除。所以，当你在 blog 按下发布按钮的一刹那，带着你所写的全部内容（或者摘要，可设置）的嘟文，就可能会永远飘在 fediverse 世界里，无从反悔。所以，写完这篇文章后，我还不确定自己是否会继续用这个插件……

所以我只是觉得这个插件运行的机制很有趣，向大家介绍一下而已。它仅仅是通过 ActivityPub 协议，和其它实例通信，而本身并没有创建实例。这个插件在 wordpress 的数据库里，甚至没有新增一个 table，而只是把 followers 的公钥，存到了 wp-options 里（我觉得这么折腾 options 表，有点过犹不及了……）。总而言之，这是个超级轻量化，在 wordpress 基础上，完全不产生多余开销的东西。

我之前吐槽过，目前所有的 Fediverse 引擎，都是用软件工程模块，匆匆拼出来的臃肿怪兽：开销巨大，数据结构不美观，依赖的技术模块未必有长久的生命力，安全性抗冲击性都很差……其实我很期待，一个单用户版的，完全没有 local 功能，支持 ActivityPub 协议的引擎。结构的简洁程度，和资源的开销，要比现在这些要好很多。从这个插件可见一斑（虽然这个插件和完整的个人版 fedi 实例，是完全两回事……

测试了一下。好像只有 follower 的回复（公开 or 私密）才会同步到 blog 的评论区；陌生人的不可以。但目前还没有做 follow 的审核通过机制。所以理论上是可以用这个功能发垃圾评论……

以及目前还没有让用户修改个人简介的功能，图片上那些简介，都是我在插件 templates/author-json.php 里手动改代码的。

关于 fediverse 的删除机制

在当前的很多 fediverse 服务（mastodon、pleroma…）里，当 A 站的用户 a 被另一个实例（譬如：B 站）的用户关注时，他所发的嘟文，会在 B 站的服务器上储存一个副本，B 站的用户，通过访问这个副本，来阅读这条嘟文。当原本的嘟文被删除时，A 站会通知 B 站，删除相应的副本。但这个时候，这条嘟文未必像人们期待的那样，从 fediverse 上彻底消失。

假设存在如下情况：

A 站的 a 用户
B 站的 b 用户，b 在关注 a
C 站的 c 用户，c 在关注 b，但 C 站没有人关注 a

a 发了一条公开嘟文，此时 b 可以看到这条嘟文，而 c 是看不到的。
b 转发了 a 的这条嘟文，此时 c 可以看到这条嘟文了。C 站的所有人，在查询 a 的时候，也都可以看到 a 的这条嘟文。
如果这个时候，a 再把这条嘟文删除，那么 A 站会通知 B 站这条嘟文已删，而 B 站也会把这条嘟文在 B 站的镜像删除。于是 b 就看不到这条嘟文了。

——然而，似乎并没有一个机制，去通知 C 站，这条嘟文已删？也就是说，这个时候，c 和 C 站的所有人，都仍然可以看到 a 已经删掉的这条嘟文？

如果这个时候 C 站有人再转发这条嘟文，而 B 站甚至 A 站有人关注这个人，那么，B 站和 A 站的人，就又能看到这条嘟文了？甚至连 a 自己，也能看到的？（这个有待验证 — UPDATE：不可以的，见评论区）

听起来似乎很不靠谱，但也不是不能接受。就像 twitter 还没有官方 retweet 的时代，所有的转发，都是由用户手动复制一个副本。而最初的推文被删除，完全不会影响这些副本继续存在。所以这里只是提醒大家，有这么一个机制。具体的隐私控制，还要由创作者自行把握。你曾发到网上的东西，可能永远不会真正消失。

Mastodon 的「去中心化」所导致的……？

看到 @[email protected] 写的论文导读。在 Mastodon 的去中心化网络里，用户之间的关联状况，其实比 twitter 更加高度集中。

Raman, Aravindh, Sagar Joglekar, Emiliano De Cristofaro, Nishanth Sastry, and Gareth Tyson. 2019. “Challenges in the Decentralised Web: The Mastodon Case.” Pp. 217–229 in Proceedings of the Internet Measurement Conference, IMC ’19. New York, NY, USA: Association for Computing Machinery. download

研究人员爬取了在2017年4月到2018年7月期间的1750个实例，涵盖了23.9万用户和六千七百万条嘟嘟。基于这些数据，构建了用户相互关注的网络，以及实例之间的连接网络。

通过分析这些网络，论文发现了长毛象的中心化趋势。以下结果是基于搜集到的样本，不是全长毛象数据。

1. 用户方面，大约50%的用户都集中在10%的实例里面，因此少数的管理员在长毛象联邦中拥有过量的影响力。开放注册的实例拥有的用户比邀请注册实例里的更多，但是，邀请注册实例的用户平均嘟嘟数量差不多是开放实例用户嘟嘟数量的两倍（187嘟/人 vs. 95嘟/人）。不管哪种实例，都有中心化趋势，服从幂律(power law)，前5%的实例容纳了约95%的嘟嘟；

2. 内容方面，只要关掉最大的10个实例，跨站时间轴上62.69%的嘟嘟都会消失。有些实例带有话题标签，研究发现，科技相关实例占据了55.2%的实例，却只容纳20.8%的用户和24.5%的嘟嘟。相比之下，虽然只有12.3%的实例是跟色情相关，但是却吸引了61%的全网用户；

3. 服务器方面，大部分实例都集中在少数的自治系统（Autonomous System， AS）上，主要在日美法德四国。最大的三个AS就有62%的实例。比如亚马逊AS上集中了62%的用户，尽管上面只有6%的实例。关注网络上，92%的用户是连接在一起的，但在极端情况下，只要五个AS崩坏，就会把相互连接的用户数量减到46%。

作者还分析了网络结构的强度。虽然长毛象分成了很多独立的实例，但是用户之间是高度连接的，跟推特相比，长毛象的连接更加脆弱，只要破坏少量的重要节点（高关注用户）就能够极大破坏原本的连接，相比之下，推特的关注网络就比较稳健。

伦理声明：研究通过了大学伦理审查，只收集了公共嘟嘟，并进行了匿名处理，论文结果不包括任何的嘟文内容分析。

实际使用中，也有类似的感觉，Mastodon 用户互相 follow 所形成的网络，比 twiiter 更加纵向化。大家相对更集中关注一些较活跃的用户，而在用户网络的末梢，横向的互相关注相对较少，尤其是不同实例之间的关注，更是如此。

但我觉得这种状况，是和 Mastodon（以及整个 ActivityPub）目前的设计机制有关。最近自己架设实例时，看了一下 Mastodon 和 Pleroma 的后台数据库，架构上有一些莫名其妙的地方：

（ btw，我的新帐号： @[email protected] ）

在当前实例里访问其它实例的文章时，系统要先把其它实例的文章（以及图片附件）复制到当前实例的服务器（而且是和本地用户的文章放在同一个数据表里……），才能被本地用户读取。本地用户所看到的，并不是其它实例的原始数据，而是被保存在本地实例的镜像。

当一个实例的用户 follow 其它实例的用户时，两个实例的数据库把外来实例用户的信息和 public key，保存在各自的数据库里（也是本地用户和外来用户存在同一个数据表里……）。当外来实例的用户发布新文章时，外来实例的服务器会把这条新文章，主动 push 到订阅了它的那些服务器里存起来。

我能看出这样做的一些好处，譬如减少了实例之间的重复通信、避免最终用户和外来实例间的翻墙屏蔽、增强安全性……etc。然而，一切外来实例的文字和图片，都要先保存到本地服务器，才能被阅读，由此导致的，就是用户在随意浏览外面实例的历史文章时，体验非常不友好。

界面里显示的外部实例用户的 following 和 followers 数量，也仅仅是当前实例里和这个用户有关联的用户的数量，而不是这个用户在所有实例的真正总关联数。

不仅是外面实例陌生人的信息，不能直接看到；连已经 follow 的用户，在 follow 之前所写的文章，也不能在系统里直接看到。一定要再打开一个浏览器页面，访问对方在其自己实例上的页面，才能浏览。对历史信息的转发和回复也非常不便。

当用户在 Mastodon 界面中，点开一个陌生人的帐号时，有三种情况：

陌生人也在同一个实例。此时用户可以直接看到陌生人的所有历史文章；
陌生人在其它实例，但之前曾经被用户实例里的其它用户 follow 过。此时用户可以直接看到，从这个实例里第一次有人 follow 开始，陌生人发过的所有文章。再之前的文章，则必须打开外置浏览器才能查看；
陌生人在其它实例，之前用户所在实例并没有人 follow 过他。此时用户完全不能直接看到陌生人的任何历史文章，只能通过打开外置浏览器查看。

不能方便地查看一个人以前发过的文章，也就自然没有兴趣去 follow 他。这就导致了两种「集中化」的关联：

在同一实例内部的人，由于可以互相看到历史文章，所以更方便互相 follow；
一些已经被实例里其它人 follow 过的「热门用户」，他们的文章更容易被这个实例里的其它用户看到，从而更容易被 follow。

而与之相对的，就是不同实例之间从没 follow 过的陌生人之间，其横向关联度急剧下降。

如果换一种架构模式，每个实例把自己用户的文章都做出静态缓存；然后用户访问外来实例时，直接访问对方服务器的页面，这样的话，情况会不会好很多？

我的技术水平不够，不能再深入分析对比这些机制的优劣了。但这些，其实和「去中心化」本身，并没有直接的联系。「去中心化」和「中心化」的区别，其实仅仅是后台服务器由谁去建，以及随之带来的审查和信息自由度方面的不同。普通用户在使用中，其实是不应该感受到 Mastodon 和 Twitter 的差别的。我们所面对的，并不是「去中心化」带来的问题，而是在做一套新的「去中心化」架构时，所没能解决好的技术问题。那些「中心化」的服务，也有很多因为设计的不如 twitter 理想，而最终倒闭了。目前而言，Mastodon 的架构还远称不上完美，有很多不足，或者让用户觉得不习惯的地方。但这些问题，其实只属于某个产品设计上的问题，而不应该归咎于「去中心化」。

个人 VPS 上的服务安装（未完稿）

这篇文章要讨论的是，如何在一台轻量级的 VPS 服务器上，基于自己的域名，同时安装如今各种流行，去中心化的网络服务：

个人博客：Wordpress
ActivityPub 社交网络：Pleroma 或 Mastodon
Matrix 聊天服务器：Synapse 或 Dendrite
个人网盘和在线办公套件：Nextcloud

然而，原本我一直在用 Linode 每月 5 美元，1C1G（1个CPU，1G内存）的服务器，打算安装的服务，也是基于这个级别的配置。然而弄到一半，突然被乔乔推荐了 Contabo 每月 5 欧元（要一次缴一年，不然有额外费用），4C8G 的服务器。虽然实际速度和网速，并不比 Linode 或 Vultr 好多少，但 8G 内存，选择各种服务的余地可就大多了。所以我整理出来的 1C1G 方案，自己并没有在用……原因我后面会说。

之前也犹豫，既然同样价钱都能 4C8G 了，那为啥还要写 1C1G 的方案？很快大家的配置也都会变高级了吧？但想想也未必，还是整理一下吧。

这篇文章讨论如何在轻量级服务器里塞进各种服务。——前提是这台服务器，假定只会有你一个人在用，最多加上你的闺蜜和男朋友。我并不知道几十个用户的 Mastodon 会有怎样的开销，至少在 1C1G 上这样做非常不靠谱。我所面向的，只是两三个好友自用的私人 VPS 而已。

这篇文章不是写给小白用户的。整个系统还是很复杂的。指望有一个教程，或者一个 docker-compose，能够让完全不懂 Linux 的用户，通过逐行复制命令，就能搞定所有的安装，目前还不现实。你至少要有在完全理解的基础上，用 LNMP 搭出 Wordpress 的能力。所以我也没必要把用过的每一条命令，都放在这篇文章里。——对于每一项服务，我会尽量给出相关靠谱攻略的链接，并且讨论一下里面的坑，和我个人所作的选择。

所以，其实这篇文章本质上就一句话：

是的，这些服务都可以装到一台机器上，不冲突。我弄过了，没问题，你们放心慢慢弄吧。

安装环境：一台 1C1G（或更好的） VPS 服务器，一个你自己的域名。

Continue reading →

Macbook Pro 三系统 Mac + Win + Linux 安装攻略

Macbook Pro 三系统 Mac + Win + Linux 安装攻略
前几天把笔记本清空重装，顺便整理一下 Macbook Pro 装三系统的攻略。这个应该是最简单的方案了，不用装 rEFIt 引导分区，也不用再手动运行 GRUB 修复 Linux 或 Windows 的引导。
0.1 技术思路，简要地说，就是 Macbook 用 GPT 管理硬盘分区，但 Windows 的 MBR 只能识别 GPT 的前四个分区。所以先在 Mac OS 下用 BootCamp 划出 Mac 以外的分区，然后先用 Linux 安装盘的工具把整个硬盘分区，把 Win 装到第四个分区，再安装 Linux 顺便用 GRUB 自动引导 Win 。
0.2 Win 和 Linux 都是用光盘安装，没有光驱的机器，请去自行查询如何用 ISO 制作 Macbook 的 USB 安装盘——其实满复杂的，新人建议去找个外置光驱……
0.3 安装环境：
Macbook Pro 5.5（2009年款，另外附上作为非果粉当年的吐槽评测）
Mac OS X 10.8 Mountain Lion（10.6 Snow Leopard 之后的都可以，之前的没试过）
Windows 7，XP 也可以
Ubuntu 12.04 LTM —— 推荐新人和懒人用这个版本。最新的12.10安装盘内置的 partman 分区软件在 Mac 下会报错。也可以用其它发行版如 Xubuntu 12.04 之类，但 Xubuntu 安装盘自带的 GRUB 包好像不全，安装过程中建议把网络连上自动更新，否则引导程序可能会自动安装失败，可以事后手动安装，但不叫做简单了。
1 安装 Mac OS，安装前用 Mac 安装盘里的【磁盘工具】，把要安装的硬盘设成一个分区（Mac OS），分区方式选择 Guid 。 / 没有安装盘的，也可以找个移动硬盘，Guid 分区后把现有系统映像过去，用移动硬盘启动，Guid 现有分区后，再映像回来。——总之就是确保 Mac OS 所在硬盘是 Guid 格式的分区，不然 BootCamp 不能通过。已有 Guid 系统的可以直接到下一步。
2 Mac OS下，放入 Windows 安装盘（ BootCamp 要检测到 Win 安装盘才工作），【应用程序 – 实用工具 – BootCamp】，选择安装 Win ，划分区，系统重启时按【Option】键进入 Mac 引导界面，按退出键退出 Win 安装盘，插入 Linux 安装盘。
3 从 Linux 安装盘启动，不要直接安装，选择【Try Ubuntu】，打开【终端 Terminal】，输入【sudo gparted】，在 gparted 中将现有硬盘分区：

如图，sda1 和 sda2 是 Mac OS 的系统分区，不要动，后面有1个（BootCamp做的 Win 分区）或2个（可能有的 Mac 会留个系统恢复区）分区，把这些全部删除，重新添加分区；
sda3 是我硬盘中最大的分区，作为三个系统共同的数据分区，可以格式化成 ext2（推荐，Mac和Win都要装驱动识别、后期还要在Linux下调整权限）、NTFS、或者FAT32（其实这个最方便，但有单个文件4G的限制）；
sda4 是给 Windows 留的分区，建议格式化为 FAT32，在Win安装界面下再重新格为 NTFS（如果直接格 NTFS，安装Win时可能不识别）。另外传说 Win 一定要装在第4个分区，装在第3个会引导失败，我以前试过一个好像也没问题，懒得多试了；
sda5 是Ubuntu分区，这后面的分区Win都无法访问了。随便你格式化成 ext2/3/4、ReiserFS 都可以。如果不需要数据分区的话，把 Linux 装到 sda3 也无所谓；
sda6 是Linux的交换分区，内存够大的话，没有也可以。
点击【√】确认所有修改，退出系统，关机。
4 开机，按【Option】，换碟，从 Win 安装盘启动，安装 Windows 时选择高级自定义分区，分区界面里只显示前四个分区（后面的显示未分配，不要动），把第4个分区格式化，安装 Win 到第4个分区。和一般装Win时一样，过程中会重启几次，直到 Win 全部装完。关机。
5 开机，换 Linux 安装盘，安装 Ubuntu 。安装类型选择【Something else】，打开分区软件，挂载要安装的 Linux 分区（ /dev/sda5 → / 、 /dev/sda3 → /home or /data ）。最下面的Boot Loader安装位置，确认是 /dev/sda 。

安装完成，每次开机时按【Option】键，选择启动 Mac OS 还是 Windows（可以在 Mac 或 Win 的 BootCamp 设置默认），选择 Win 后进入 Linux 的 Grub 菜单，选择进入 Linux 还是 Windows（可以在 Linux 里更改默认项和等待时间；另外从 Grub 里启动 Mac OS 似乎不管用的，以后可以研究或者直接删掉）。
好久没写技术帖了。