h404bi

我看你说在用 pixi 了，那有试过用 pixi-pack 直接打包环境么？

https://github.com/Quantco/pixi-pack

A 通过有线接入内网再远程有尝试过么

@a33291
找到了几年前我在 GitHub 上的回复 https://github.com/ScoopInstaller/Main/issues/2894#issuecomment-1125150531 虽然是针对 Scoop 但是情景是一样的。git-scm doc 里那句话 ..tried in turn 很容易错过。这确实挺反直觉，主要是其它设置项都使用覆盖策略。

git credential.helper 的策略是 system->global->local 合并*逐级*测试的，而非你想的*覆盖*。也就是先尝试 system 里设置的 credential.helper ，如果可用就跳过后续 global/local 里的设置。具体可查阅下 git-scm doc 关于 helper 的部分

直接买 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 可以直接卸载掉，用的话可以在不想同步的目录创建一个软连接，避免后续再乱来被修改同步设置。