谈个别的：允许非专业的人讲话、提问死不了，不会玷污科学。我觉得用没有专业背景来阻止大家的提问与讨论是和科学探索精神向违背的。真理经得起推敲，也不看出身。
确实大把的研究资料就在那，但不是每个对新冠疫苗好奇的人都愿意或者可以花那么多时间去研究的。要达到“专业”的程度，零基础开始怎么说也得研究几年吧？即便不谈问题的实效性，那我不愿意花几年研究我就没资格了解下原理了？
如果别人的推论有问题，那就指出问题予以反驳，至少有一方能够意识到自己的某个认知或推理方式有问题；如果有常识性错误，更大可以指出；或者是针对性地给出一些研究成果及来源，也能让对方和参与讨论的人都有所学。

如果说闭嘴就是对科学的敬畏，那这种科学不要也罢。如果对正常的提问（指它讲道理）发表“民科”、“不专业”、“你是错的我是对的”之类的评论时，还是建议能给出一点点的支撑性论证，否则就真是毫无营养的废话了。

https://gist.github.com/ihciah/3fa05d09955355cba67f89c53698be2f
没开 unattened upgrade ，但搞了个 ansible 脚本一键升级所有我管理的机器。相比自动升级，万一升出严重问题立刻就能意识到并且修掉。

常规业务: axum/rocket
thread-per-core: actix-web

我搞过一个仿核心价值观编码器，也是阴阳怪气专用=.= https://github.com/ihciah/byte-style-encoder

A:
这个需求本身推荐直接 atomic 。锁的话你也可以自己实现，常见需求用 parking_lot 就好。
channel 内部往往也有锁或 CAS 。
涉及等待，thread 的话标准库有信号量等，async task 的话可以用 tokio/futures 等库提供的实现。
反正实在不行，自己搞 syscall 总能做。
B: 可控且性能要求高的循环引用可以直接 unsafe 手动来，比如实现双向链表。或者引入 Rc/Arc 等智能指针走引用计数。

就我个人的经验，应当尽可能的 thread local ，减少不必要的线程同步(当然这个和 rust 本身已经关键不大了)。也不用太慌 unsafe ，为了性能该 unsafe 还是要 unsafe 的。

vscode remote 吧

@curoky 楼主字节的吗🌚

一年多前入的 R720xd ，2U + 8HDD 空载 160W ，最近换成 1U + 2HDD + 2SSD 降到了 80W 。
买的时候是 裸机器+E5-26xx*2+2T*5+96G=¥3500 。

缺点是没法换新款 U 、内存频率低、吃电。
好处是 U 便宜、内存便宜、12 个 3.5 硬盘槽、带 raid 。

如果现在让我重新选，我可能会选 1U 的新款一些的服务器。

大佬 dddd

路上遇到辅警的小电驴都比解锁后的小牛快。。

都用这种机器了肯定不在意性能，那 swap 记得拉满。

本地 Macos 远程 arch ，很舒服

楼主不是字节的吗？

我这边也是常年国内 /新加坡 /美西 /日本跳（无机场，全是自己的 vps ip ），账号快十年了，没出过啥问题。
不过这也只是我自己的 case ，风控策略往往是个很多因素的黑盒

片头动画挺有创意

实名卖梯子，这也太勇了

@duke807 再厉害的大佬也会犯错，并且很多是不注意导致的低级错误。所以用一定的机制来收敛可能导致内存错误的代码段是有用的，无论是对小白还是老手。
c 写出问题之后查错成本高，但对于生产环境来说错误本身导致的代价更大。所以能形式化证明代码没问题很重要，这样会降低很大的潜在成本。