#SteamTopSellers for week ending 5 February 2023:
#1 - Hogwarts Legacy
#2 - Steam Deck
#3 - Dead Space
#4 - Hogwarts Legacy
#5 - Undisputed
#6 - Hi-Fi RUSH
#7 - Project Zomboid
#8 - Dead Space
#9 - Red Dead Redemption 2
#10 - Call of Duty®: Modern Warfare® II
最新的vscode 中,自定义的snippets失效了
简单讨论一下将 #IPFS 用于长毛象媒体存储的可行性
如果在用户端用ipfs,要么自带网关,要么走第三方公共网关。前者在站点服务器无法访问时可能用得上,但资源占用、读取速度等还不够理想。后者就称不上是去中心化了。即使实例建网关转成http,那相比现在也没提供什么增益。(如果有其他思路也可讨论)
服务端用ipfs,一种思路是把它当成s3用、直接托管在第三方,另一种则是在已有存储的基础上加入ipfs。前者如果完全依托IPFS交互,延时恐怕控制不住(固定提供商的peers?)。后者是我认为有一定可行性的思路。
现有的机制下,只要媒体文件的路径改了,长毛象就无法自动定位到已清理的外站媒体。如果各服务器的媒体文件都加入了ipfs、缓存外站30d以上或者永久缓存有互动的媒体文件,那么只要该文件的hash记录还在,就能从原站或者有缓存的其他站点找到。即使站点自身的媒体文件彻底灭失,用户找回媒体的可能性和便利性都会大大增加。如果数据库还在的话,重建站点大部分的媒体文件也不是不可能。而且对于寻找旧媒体文件的任务,有一定延时也可以接受。
长毛象对象存储的特点是大量小文件,自建ipfs能否有效应对是个问题。我简单测试了下,参考 https://docs.ipfs.tech/install/run-ipfs-inside-docker/ 建了个docker。通过docker stats查看,平时CPU有一定占用,长时间运行内存会到500MB。加入约10GB(80k)的文件,内存最高到1.6GB。重启并运行一段时间后稳定在600MB左右。已加入的文件通过公共网关访问,未能直接成功。第一次尝试后过一段时间再访问有时能打开,更换默认的4001端口似乎有一定帮助。除了自建,也有 https://web3.storage 这类将文件交给服务商,让服务商加入IPFS的服务。但价格相比已有的s3服务商看起来没有优势。
网关例:https://cloudflare-ipfs.com/ipfs/QmP16cnDGh1NC6DruajXoWvTwFJhgDCDjMsoStYY7e2iBN
顺便一提,对于 Filecoin 这类激励层的设想,我曾抱有人人为我、我为人人模式的期待(去中心化PT)。但目前来看,其挖矿的硬件门槛远超民用级NAS https://lotus.filecoin.io/storage-providers/get-started/hardware-requirements/ ,应该会产生明显的中心化趋势。因此,个人对其前景还有一定疑问。
总的来看,ipfs有望为媒体文件的存储提供一些增益,但暂时还不足以抵消实现中的各种麻烦。期待未来能看到更好方案。
Chinese 🇨🇳 / Dictatorial Admin / Mastodon Code Contributor / 摸鱼技术布道师
Steam: https://steamcommunity.com/id/MashiroBest
Epic: https://store.epicgames.com/en-US/u/d211c824cbd94aaeba898db6bb823ff7
原批交流群:966322309