是不是那种特别细的一丝，亮屏下有彩虹纹的那种划痕，我 ipad 之前也是。ac+还在的时候寻思换机来着，一看要 600+还不一定能换就把这事忘了，后来 ac+没了后想起来了。

不基于硬件普遍的软件革新，大多都是营销策略的没活硬整，

翻了下 gnu 的 bash 文档，这个行为应该叫 quote remove ，是 bash 处理表达式的最后一步，删除'，''
https://www.gnu.org/software/bash/manual/html_node/Shell-Expansions.html

想起来去年一哥们用 gitee 的静态资源下载练剑当作自己开发的设备的更新下载地址，被封了之后设备全都宕机，客服也不好使，最后废了老鼻子事才解决。

6 小时达成 100 回复，这速度 v2 技术领域里前端独一家了。

主要是人少的时候秒匹，人多的时候反倒匹配时间长了，按照正常的逻辑人多应该是把一部分挤掉，然后匹配很快吧，很难不让人觉得是不是真是屎山 bug 。

这软件好像有年头了，我记得 16 年就用过

我是感觉阳光才是最重要的条件，假如你能做到凌晨四点睡觉的时候没接触日光入睡，起床后立刻可以接触到充足的日光，就可以减少短期不规律作息所带来的身体损伤。

@bli22ard 关键是你要明白，为什么你 Arc TcpStream 配合对&TcpStream 实现的 Write trait 可以实现 split 以用来实现一个线程读一个线程写抽象。
是因为对 Linux 来讲，fd 对应的 socket file 或者普通 file 本身就是可以多个线程/进程并发读写的，因为这个能力所以才有了 Rust 可以抽象出来的可 Send TcpStream 以及&TcpStream Write Read ，进而可以通过 Arc TcpStream 实现 split 。

查了一下 c40 ，是我孤陋寡闻了，一个手动磨豆机都要 1.5k ？

有钱有稳定又流量大的代理就用 mega 网盘。

@bli22ard 我不是让你用 dup 实现 split ，我是指 dup 之后两个 fd 也是指向的一个 vfs 这个概念，再结合你上个问的&File 问的问题你应该理解为什么有 impl Write for &TcpStream 了吧。

@PTLin 最后有口误，是让不同的 fd 对于的 fdtable 里的条目指向同一个 file 。

别钻牛角尖了，本来 os 上的 socket 就没有可以设定只能只读/只写的接口，介于这个原因标准库才没搞什么像是 tokio 里 split 那种只读只写的结构，和你上一个问的为什么&File 可以读写数据一个理由，就是更贴近 os 端的设计导致的。
所有什么只能读或者只能写的接口全都是上层语言或者库的抽象，你要想搞什么只读只写自己包一下就完事了，try_clone 在 Linux 就是 dup 系 syscall ，让多个不同 fd 指向同一个 fdtable 里的 file ，操作 clone 出来的新 TcpStream 和你操作原先的没有任何区别，两个指向的都是一个 socket file 。

你的想法也没什么问题。标准库没提供，只能手动 clone ，但是 tokio 提供了你想要的功能。
https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.split

这个属于 api 设计问题，我举个例子。
假如有个文件 test.txt 内容是 asd
```rust
let file1 = OpenOptions::new().write(true).open("test.txt").unwrap();
let file2 = File::open("test.txt").unwrap();

(&file1).write_all(b"zxc").unwrap();
let mut buf = String::new();
(&file2).read_to_string(&mut buf).unwrap();

assert_eq!(&buf, "zxc");
```
两个变量打开了同样的文件，本来 file2 读取出来的东西应该是 asd ，但是由于打开的是一个文件，file1 修改文件后 file2 就读出来 zxc 了，就是有这种副作用，file2 在根本没有操作的情况下改变了内容，这种性质在语言层面没有办法限制。
介于 os 中 file 的这种特性，设计成非要 mut 才能 read write 就失去了意义。