看这个帖子：/t/800024

@Mr1 #19 已经不能买断了

@nangdiea 8 楼给出的是仅收存储费用（即不收流量费用）的方案，并按 1T 的内容存储量列出每一个方案的存储成本。

@gyt95 不清楚码云的，GitHub 的 UI 会在使用 squash and merge 的时候自动帮你生成 Co-authored-by 信息

已举报

可能是因为浏览器定位不准？ https://developer.mozilla.org/zh-CN/docs/Web/API/Geolocation_API#%E5%8F%AF%E7%94%A8%E6%80%A7

@USDT 现在有支持的方法： https://developer.mozilla.org/en-US/docs/Web/API/FileSystem

@ch3n9w 不敢苟同，如果你看到的内容都不是实际的网站内容（指被浏览器修改了），你还能信任他们所谓的隐私保护吗

Web 性能的重要性： https://developer.mozilla.org/zh-CN/docs/Learn/Performance/why_web_performance#%E4%B8%BA%E4%BB%80%E4%B9%88%E5%85%B3%E5%BF%83%E6%80%A7%E8%83%BD%EF%BC%9F

@luodaoyi 杭州电信好像看地区？我家里能跑 70M 上行，下行 300M 的

举个简单的例子，比如我现在主进程里面使用 pipe 创建了一个管道，然后将输入端的文件描述符传递给 fork 出来的 A ，并在 A 中重定向输出到 pipe 的输入端，关闭 pipe 的输出端文件描述符。但我没有在主进程中关闭输入端的文件描述符并直接 fork 出了进程 B ，在 B 中重定向 Pipe 的输出端到标准输入，也在这里关闭 pipe 的输入端。那即使 A 退出了，B 中调用 read 也是会阻塞的（读不到 EOF ）。因为主进程里面没有关闭输入端的文件描述符。

正确的做法是在 fork 出 A 后在主进程直接关闭输入端的文件描述符，再 fork B ，然后再在主进程中关闭输出端文件描述符。这样能保证输入端和输出端的文件描述符仅由两个 fork 出的子进程持有。

fork 得到的文件描述符可以当作引用吧，如果不是所有的引用都断开了，并不会关闭所指向的文件描述符。（不确定是否完全正确，这两天有踩过没在主进程关闭文件描述符的坑）

@yanzhiling2001 不需要有 gui 输出，https://developer.chrome.com/blog/headless-chrome/

@spongeboBoy 找个别人分享的阿里云盘文件，转存一下，就能点亮第二个图标了（备份电脑文件可能是有 bug ，我没试过）