h404bi

直接买 fanless 设计的就没有风扇声音了，但是性能上必然有妥协

https://www.ultrabookreview.com/6520-fanless-ultrabooks/

本想说可以支持一下多链，但转头想到现在 Ethereum 主网的 Gas 不再像几年前经常几十几百 gwei 让执行个 Transfer 都要一杯咖啡的 fee ，于是好像也没那个必要。

「 100%可靠性」其实是对 ipfs 有些误解，ipfs 存在着与 BitTorrent 同样的 p2p 局限。所谓「 100%可靠性」只对资源生产者而言（除非自己删掉了最后一份备份），在消费端非热门资源的可访问性一直不太行，很多情况下访问一个 cid 就卡在那里了很长一段时间（梦回 BitTorrent 挂着很长时间找寻 peer ），极大消耗耐心。

尤其是个人博客图片，绝大多数都是非常冷门低访问量的资源，这种劣势会被放大。这时候提高可靠性，无非就是让消费端访问固定一个 gateway （背后是生产者自己/代理的 Pinning ，消灭掉寻址过程），这样又回到了自托管/代托管方式。使用 ipfs ，只是多了一个广播到网络上其它 peers 的功能。对于博客图片这样的场景，换来的可能是比用传统图床更差的用户体验（尝试 gateways 的 overhead ）。

把 https://gateway.ipfsscan.io/ipfs/QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm 换成
ipfs://QmNr8Ffhb7GbtPE2YVsK8MAeULyuKd71W9JMdhnYgxA3qm 让 IPFS Companion 去挑 gateway 立马就能体验到这个 overhead

IPFS 很好，但就这个使用场景而言，我觉得 IPFS 是不如传统图床甚至于 Arweave 的。

说句实在点的话，Arc 要真是没心思做 Windows 版本的话就不会费力去做那些 Swift on Windows 推动的事了。只能说他们给自己搞了个大坑，估计一时半会儿填不平。

我文档目录里一直有软连接，OneDrive 不支持同步，因此逃过一劫。不用 OneDrive 可以直接卸载掉，用的话可以在不想同步的目录创建一个软连接，避免后续再乱来被修改同步设置。

你不喜欢 conda 拖家带口可以选 Linuxbrew, vfox, vmr 都支持直接拉二进制产物，不过 vmr 背后一样还是 conda-forge 的源。
vmr: https://github.com/gvcgo/version-manager

另外 Junctions 是必须用绝对路径的，重装系统或者更换硬盘时如果盘符有变化那可能会失效。SymbolicLink 倒是可以用相对路径创建，但得看软件支持了。

SymbolicLink 相对 Junctions 比较新，有些软件不一定有增加对它的支持，所以可能不被识别到。你可以先弄个测试数据试试吧。

稳定通道的三月累积 patch 都有 bug ，这 Dev 通道遇到这样那都不是事😄，insider 上报就完事了