本想说可以支持一下多链，但转头想到现在 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 上报就完事了

我的系统盘 500 ，不过爆红快满了，之后准备换成 1T 。

chezmoi 比较多人用。我是 git 加自制 bootstrap 脚本，自由度高些，不过我已经很久没切系统了。
https://github.com/chawyehsu/dotfiles

问题还是 backup 和 syncing 的概念之别。

MSA 只是单向 backup ，如果习惯了同步方式当成 syncing 来用则指定悲剧。其实 MSA 这点上帮助文档里有清楚说明，但我觉得还得大字加粗警告才行。backup 就是 back up ，点启用直接覆盖。牢记要获取最新的远端 backup 时，不管新旧设备，先确保操作机本地没有已登录态，旧设备可卸载重装 app ，再进行恢复即可。这其中还有一个要点是，要时刻确保远端的 backup 是最新的，因为 backup 不是 syncing 不会自动更新！

https://i.imgur.com/MTGHynF.png
想想还真是小霸王

@JayYoung2021
Luke 基本不参与维护了，Scoop 各个核心仓库迁移到 org 后已经是社区维护的项目，还是时有更新的。

@cosette
Homebrew 的 JSON API 模式对于 homebrew-core 这样几十万 commit 的仓库来说效率提升确实大。目前 Scoop 的两个核心主桶 commit 数在五万，按这量级短期内应该不会改，而且 API 模式大概也只能像 Homebrew 那样只对 homebrew-core 和 casks 这样巨量 commit 数的仓库有用。不过确实是个发展方向。

我个人体会是西瓜霜粉短时间高频使用才快好，掉了就补。一天保持一段时间都有才行，喷了不动不进食能保持几十分钟，然后隔一会又喷，不然可能得疼一个星期。我正畸复诊时要是被钢丝扎到基本上就逃不了溃疡，都用这招。

@DemoJameson #6
我估计你这里说的是不能左右拖动改变垂直标签页的大小，隐藏标题启用垂直标签页后点击左上角后退键下方的按钮就可以，这个就是 #4 说的。

@wyllan #4
可以。
@hackpro #2
我用过几个都不太喜欢，给不了你推荐。
@chenzhekl #1
就我个人而言，竖排带给我一个最显著的体验改变就是定位标签页更随意了，得益于竖排状态下「无论标签页数量有多少，标题都固定可见」。横排在标签页数量增加时压缩标签页，要在一个很小的地方定位标签页，负担就上来了。日常打开标签页数量不多的用户其实难以感受这种情况的，这就是 Preferences ，毕竟不是每个人都失控般地打开着一两百个标签页。垂直标签页还有可能会反过来加重这种失控 XD 。
至于空间嘛，本质上竖排就是以显示空间换来标签页标题的稳定可读。现在的网页多少都以居中展示内容为主，左右区域利用率不高，所以这个影响也还好（对小屏幕影响挺大，小屏幕本身就放不下多少内容）。而且竖排也还是能收起来的，收起来后空间占用跟横排也没什么差别了（虽然我觉得会浪费一点点点点效率）。

对跟集成有关，顾名思义给「服务账号（ Service Account ）」访问保险库的权限，比如通过自动化脚本、CI/CD 访问的场景。

提示下，$125 礼品卡已经被下架掉了。

@libook #9 就是社区中的一些 drama ，从 MultiMC 到 PolyMC 再到 Prism Launcher 大致上可以看

https://polymc.org/news/moving-on/
https://www.youtube.com/watch?v=FyS8ELbafN0

作为 MultiMC 老用户看到发展到现在这样，还是觉得有点感慨。用户始终是选择满足需求为先。