2019.10.13 Update：还是需要更新一下使用体验，因为我发现这个方案有两个致命缺陷。
- 播放列表能分享的部分只有 500 首，也就是说不管原来的列表多大，都只能分享前 500 首。
- 播放器体验不好。比如，没有办法直接随机播放，一定要先播放第一首，然后才随机。
综上，寻找音乐存储解决方案的旅程看起来还会继续下去。。。
原文
多年以来，我一直在寻找满意的的音乐解决方案。三年前写过一篇文章《可以好好听音乐了》，从那时起我就不再依赖云平台。当时正好有一台实验室的服务器，于是我自己架设了 Subsonic 作为 streaming server。随着毕业，我把所有音乐搬到了 Google Play Music。我会把歌下下来，传到 Google Play Music，这是我近两年来听音乐的方式。
我满意 Google Play Music 的大部分功能，UI 算不上好但够用了，自动匹配封面也不错。唯一唯一的缺点，就是无法分享歌曲/播放列表。确切地说，分享功能是有的，但只有那些 Google Play Music 拥有版权的歌曲才对你的朋友可见。
最近我实在不想继续将就，遂又开始找新平台。这次试遍了市面上几乎所有服务，最终选定了 pCloud。先来说说我的需求吧：
- 能上传音乐并收听
- 无需自行架设服务
- 无需为流量付费
- Win、Mac、移动、网页版支持
- 不会移除、替换音乐
- 能分享播放列表
其它平台有哪些不足呢？
先说国内御三家，QQ、网易、虾米。QQ 和虾米无法上传，直接否定。网易倒是有个音乐云盘，但不知道怎么回事 Mac 版无法使用(有入口但点了没效果)。而且据说网易云会自动替换无版权音乐，这是我绝对无法接受的。
国外有什么呢？Spotify 用的最多，但它也没有上传功能，并且得付费。我还试了一大堆别的，都不满足需求。值得一提的是 Sound Cloud，我很喜欢它的 UI，上传分享功能也都有，问题和是它会自动移除检测到无版权的歌曲。
Streaming server 倒是很多，但是我不想自己维护，所以也不行。
再来就是云盘了，Google Drive 对音乐支持极差，百度网盘我不信任。Dropbox 据说还行，但是免费套餐只有 2GB 太少了。
然后我搜到一篇文章：Best Cloud Storage for Music 2019，其中推荐了 pCloud，正好我之前也偶尔用，就试了试。没想到居然完全满足需求。
播放器长这样：
不好看，但是够用了。
播放列表长这样：
嘛，普普通通。
默认 10G 空间暂时够用，再说我并不介意合理付费。
最关键的是，它能分享啊：
分享播放列表是我多年来的一个心愿。这个列表不是那种神曲选集，是纯按个人口味挑选的，当然其中也有很多大家熟悉的歌。类别的话基本就是 Anisong + 各种OST + 一些英文歌。这个列表我维护很多年了，未来还会持续更新。
最后欢迎大家给我推荐歌曲。那种特别热门的就不必了，我多半已经听过了。
不知道有没有人注意到，Joe Armstrong 最近几个月都在忙着迁移博客到 TiddlyWiki。我很早就关注了他的 Twitter，然而之前并没多想。听闻大师在 4 月 20 号去世，我才反应过来，原来他之前的举动是在未雨绸缪。
TiddlyWiki 是个单文件的 Wiki 系统，但这并不重要。重要的是，你把信息存在哪？如果你希望存储一段信息，让 100 年后的人也能访问，要怎么做？
- Facebook, Twitter, 微博？不要说 100 年，我都怀疑 20 年后它们还在不在；
- Google Cloud, Amazon, 阿里云 + 个人域名？他们大概会存在地更久一些。但没有人能保证不出事故，比如之前的腾讯云事件，比如万一服务器被入侵，黑客把文件删了。还有，你怎么让信息能一直被访问？域名会过期。到某个时候，跑着旧版本操作系统的机器也可能被强制下线或升级，你的服务一定能够在新版本正常运行吗？
- Dropbox, Google Drive, 百度网盘。同样地，这就要看你信不信这些公司一百年后还存在了，哦不对，他们即使还在，服务也可能早关了(望向 Google
- Wiki。Wiki 很好，但并不适合存储个人信息，且可能被删改。
- 去中心化存储，比如区块链。说实话，我对区块链了解有限，但直觉上，我怀疑它能否帮助我们达成目标。对比另一个去中心化的例子：BT。当你要下一些老动画或者电影的时候，拖不下来是常事，因为"死种"了。这才几年呢。当然或许区块链有某种神奇的魔法可以解决这个问题？欢迎了解的朋友们补充。
所以，我们还有什么选择？想来想去，也只有 GitHub 了。
GitHub 已经成为互联网最重要的基础设施之一，有太多人，太多事都直接或间接地依赖于 GitHub，除非人类在未来完全不需要开源代码(这显然不可能)，否则我想不出 GitHub 有关闭的可能。对 GitHub 来说，存在 100 年简直是小意思，500 年也不是不可能。这是我的预言，不一定准确，但我还挺有信心的。
不管怎么说，对我们的目标 100 年来说，GitHub 完全可以胜任。除了服务本身的持久性，GitHub 还有两个独特优势：
- Git。Git 能保存所有历史。
- Fork。就算黑客黑进了一个账户，删掉 repo，他能把所有 fork 都删干净吗？
综上所述，目前来看，我认为 GitHub 是在百年尺度上存储信息并让其能被访问的唯一途径。未来也许会有 option 2, option 3 出现，但 GitHub 作为 option 1 依然会存在。我相信，Joe 用 GitHub 来 host 博客绝不是突发奇想，他一定是在了解自己的身体状况的前提下，思考了一遍现存所有存储方式，然后同样发现只有 GitHub 才能满足需求。
人总想留下某种痕迹，证明自己活过，然而事实上，99.999% 的普通人就这么被历史遗忘了——曾经是这样。我们处在信息时代的早期，同样也处在人类文明的早期。从今往后，被数字化的东西只会越来越多。既然有人意识到了 GitHub 的独特性，随着时间推移，越来越多的人总会意识到。那时候会发生什么？自然是，越来越多的人会把自己的信息搬到 GitHub 上，依托 GitHub 实现曾经人们可望而不可及的"永生"。人有两次死亡，第一次是肉体，第二次是被人忘记。我忘记这句话是谁说的了，但现在我们已经可以回避第二次。只要 GitHub 支持，就一定会有人这么做，至少我是其中之一。几十几百年后，GitHub 将成为世界上最大的数字公墓，注册用户大部分都已去世，然而个人主页，项目，commit 历史 还述说着他们生前做过的事——就比如 Joe 的博客。这虽然是个比较 creepy 的推论，但从另一个角度想，却证明了人类的巨大进步：对抗死亡是人类文明的永恒主题，而我们已经实现了阶段性胜利。现在是文章、照片、视频，也许还有以个人习惯作为输入训练的模型。再往后呢？会不会有基因信息，乃至意识的完整复制呢？依托于稳定的存储，我们能做的事情实在太多了。反例是现在的一些 Memorial Websites，他们把逝者的信息放在自己网站上供亲友吊唁。这不能说没用，但在我看来去使用这类服务实在有些草率——就算他们再信誓旦旦，也摆脱不了某一天关站的风险，那时候还指望他们好好管理这些数据？没可能的。
既然 GitHub 变成数字公墓是一种必然，我对他们的唯一希望，就是保持某种道德义务。我完全可以想象某一天他们出台一个政策，把二十年内没有活动迹象的账户全部 archive，GitHub Pages 全部下线。那就实在太恐怖了。我祈祷那一天不会到来。
许多漫画都能让我大呼过瘾或是沉浸在剧情中无法自拔。相对而言，能触动我的同人本不多，毕竟篇幅和剧情你们都懂，最多也就感叹一句画风真还原或者这 TM 都可以。
然而前几天我看了一本丧女同人，第二天又看了一遍。我想我要写一篇文章。
本子的名字叫《大学生だしルームシェアする》，作者是 sanada。
不夸张地说，这是近几年我看过最好的一部同人。我真的被打动了。
这部作品牛逼在，作者基于对角色的深刻理解脑洞了一些角色之间的互动，其大胆又合理的想象甚至让我觉得可以直接作为原作后传，而且几乎每一页都可以让读过原作的人笑出声。
作品讲述的是临近高中毕业，黑木开始思考以后是要自己租房还是跟人合租。然后就是后宫团成员们纷至沓来，每个人都脑补出了和小丧一起租房的场景。选几页有代表性的图吧。
上图是百合和小丧一起租房的场景。小丧和优打电话，然后百合果断吃醋。
面无表情找小丧一起睡的百合，awsl
接下来出场的是加藤。
作者对加藤妈妈的刻画实在太绝了，后面百合和尼姆的眼神我看一次笑一次。她还画过一个的小丧 x 加藤的本子，也非常赞。
颜文字和尼姆的图就不放了。漫画的每一页都很有意思，每一页。
然后就是让我决定写下这些文字的一幅图：
Y-Yuri-chan, I…
When I'm with you…
I can have fun being myself.
这个理解，真的太太太太太强了，除了牛逼我想不出别的形容词。因为我自己是站百合的，所以我很清楚小丧和百合的相处模式和与其它人不一样。但直到看到 sanada 借小丧之口说出的台词，我才真正明白了区别所在。我可以肯定 sanada 也是站百合的。她对角色的理解的深刻程度，可以说达到了 EVA Re-Take 的级别。
同人本是一类特殊的作品，要从中获得愉悦是有门槛的，因为它要求读者对原作熟悉并喜爱到一定程度。类比一下，就好像只有天才们才能体会到数学的美。我恰巧超级喜欢丧女的原作，这也是为什么我会被本作深深打动。没读过原作或是对原作无感的朋友，很遗憾，你们错过了一份珍贵的礼物。
