你就一句话，谁能评价出来，起码说说安装的什么软件 / 在什么地方安装的软件 / 运维以什么理由这样安装软件

与其说是后台硬，怎么感觉是真的没有竞品

@Ansen 有一篇字节跳动写的文章试了下，确实可以跑，就是限速不是太稳定以及限速公式搞不明白。https://blog.csdn.net/ByteDanceTech/article/details/120878281

tc 基于 ebpf 的 edt 方案看来可以，直接用 epbf map 管理 ip 。

补充一下，现代的 Mutex 其实内部都会自旋一段时间，获取不到锁并不会直接进行系统调用而休眠，因为现在处理器速度非常快，很多时候自旋的时候锁就被释放了。
tokio 的 Mutex 使用原则基本上是：假如是多 task 操作一个 Vec 那种，临界区非常小，并且不跨越 await （因为 await 点可能出现一个线程加锁，另一个线程释放的问题，所以 std Mutex guard 是!Send ，导致整个 future 都是!Send) ，直接用 std 的 Mutex 就好。但是假如是独占了一个需要长时间使用数据，例如异步的数据库链接，这种才需要使用 tokio Mutex 。

不是 rust 复杂，这个是库复杂，用了太多泛型了

再过个五六年，rust for linux 就成熟了

op 这就是没问对问题，标题应该是《是什么原因让你放弃输出技术文章了》而不是局限写博客。

准确来讲，我理解的 go 中只有所有 goroutine 都因为等待 go 的同步原语（ mutex chan 等）而陷入休眠，这时才会运行时报错。
所以在 go 的角度里，你 main 没有因为等待同步原语休眠，所以没问题。
例如这段代码，只有 sleep 结束才会运行时报错死锁，因为这时的两个 goroutine 都等待同步原语 chan 而休眠。
import "time"
func main() {
ch:=make(chan int)
go func () {
ch<-1
}()
go func() {
time.Sleep(time.Second*10)
}()
ch<-2
}

在 go 的角度，只有这样的代码才算是死锁
func main() {
ch:=make(chan int)
go func () {
ch<-1
}()
ch<-2
}

感觉根本没用可还行，起码 zcat /proc/config.gz 然后 grep 下看看有没有对应选项吧。

好功能，以前写过一个内核模块，刚加载没问题，运行运行发现鼠标点什么都没反应，之后才反应过来是 panic 了，有了这个功能想必在有桌面的物理机上测试内核相关的东西能方便点

@wizardyhnr 还哪里来的长期兼容性了，就不说新的 api ，就 vim 新的 vim script 和 neovim 的 lua 就是完全不兼容的东西了，现在也没有插件开发者会用兼容两者的传统 vimrc 写插件了。

出发点就是错的，你把 ai 比做成了类似机械制造里的自动化生产工具了。
实际上 ai 现阶段仅仅是“高达”，需要一个“驾驶员”来操控，ai 必定可以让这个大环境缩减一些人，但 ai 并不能完全自动化所有过程。
就文中你发的工具，你想要做个产品，你是会用 ai 辅助你生成大体代码之后你调整代码细节和逻辑，进行测试与修改，还是在什么都不会，只会提需求的情况下用这款工具做你的产品？

你要 post [0,1,2]用 reqwest 直接这样不就好了
```rust
use std::error::Error;
#[tokio::main]
async fn main() ->Result<(),Box<dyn Error>> {
let req = reqwest::Client::new()
.post("http://httpbin.org/post")
.body("[0,1,2]")
.send()
.await?;
let req = req.text().await?;
println!("{req}");
Ok(())
}
```

先把问题描述明白，在把有问题的代码发上来，在把你疑惑的点和错误标出来

只有固定主题的群才能不变质，研究固定语言，研究固定技术，配合管理员勤维护，这是不变成水群的唯一途径