填 aaa 111 的你给他个期限让他改不好吗？很多人都没这意识吧，因为这个把付了款的账号直接封掉，很难不让人联想

无解，有些网站 Safari 本身就不太行，换 Firefox 了

这是正常现象吧，系统（包括一些后台服务和内核）在空闲时会做一些后台操作，就会产生这种毛刺
所以建议关掉功率抖动的通知，它跑东西的时候功耗会高点也是没办法的事，要去定位的话费时费力，且不一定能解决（比如如果是内核在做一些操作，你也没法控制）

读过第一版，支持一下

有没有一种可能，chatgpt （ instructgpt ）的关键技术之一就是 RLHF （ Reinforcement Learning from Human Feedback ）
有没有一种可能，一个很重要的研究点就是 fewshot 、oneshot 乃至 zeroshot 的表现

与其发表“形而上学”的观点，不如先去了解一下现实吧

「 P(文身|坏女孩)>P(文身|好女孩) 不代表 P(坏女孩|文身)>P(好女孩|文身) 」
这虽然是正确的，但“ P(坏女孩|文身)相比 P(好女孩|文身) ”这件事没有任何意义，值得关心的是：

由于 P(文身|坏女孩)>P(文身|好女孩)，可以推导出 P(好女孩|不文身) > P(好女孩|文身)，也就是说，如果不接触纹身的女孩，遇到好女孩子的概率更高

证明如下（ chatgpt ）

首先，我们可以根据全概率公式知道：

P(纹身) = P(纹身|好女孩)P(好女孩) + P(纹身|坏女孩)P(坏女孩)

P(不纹身) = P(不纹身|好女孩)P(好女孩) + P(不纹身|坏女孩)P(坏女孩)

接着，根据贝叶斯定理：

P(好女孩|纹身) = [P(纹身|好女孩)P(好女孩)] / P(纹身)

P(好女孩|不纹身) = [P(不纹身|好女孩)P(好女孩)] / P(不纹身)

我们要证明 P(好女孩|不纹身) > P(好女孩|纹身)

即：[P(不纹身|好女孩)P(好女孩)] / P(不纹身) > [P(纹身|好女孩)P(好女孩)] / P(纹身)

两边同时乘以 P(不纹身) * P(纹身)：

P(不纹身|好女孩)P(好女孩) * P(纹身) > P(纹身|好女孩)P(好女孩) * P(不纹身)

将全概率公式代入上式得到：

[P(不纹身|好女孩)P(好女孩)P(纹身|坏女孩)P(坏女孩)] > [P(纹身|好女孩)P(好女孩)P(不纹身|坏女孩)P(坏女孩)]

化简后即得：

P(不纹身|好女孩)P(纹身|坏女孩) > P(纹身|好女孩)P(不纹身|坏女孩)

因为 P(纹身|坏女孩)>P(纹身|好女孩) ，所以 P(不纹身|好女孩) > P(不纹身|坏女孩) 成立

只是游戏吃不满，因为贴图什么的都会提前加载，也几乎不用做什么 DtoH （显存向内存）的内存拷贝。
但如果是跑科学计算的话，可能会更频繁的有 HtoD 和 DtoH 的内存拷贝，大多还是阻塞的，这时候自然是越快越好。同时在一些 HPC 系统中，节点间互联网络都是 100G 、200G 以上的，那么 GPU 的 pcie 带宽自然也不能低

对于 crud 是筛选
对于高级岗位或者底层岗位是入门（前提是靠谱学校）

另外也可以试试直接改现有系统的配置文件，/etc/config/network ，手动把接口加进去

记得 openwrt 如果要适配一个设备的话，对于部分平台，会有个设备树或者别的一个配置文件，需要在里面定义好机器的网卡

确实，住的不舒服也就算了，卖的还那么贵

macos 下很早以前就是这样，挺烦人的

很现实的一点就是作为筛选机制。同时对于一些偏低层的岗位还是很有用的，对于纯 crud 岗且性能要求宽松时可能就没啥用了

幼儿园读的本，保研到学前班，正在申小学的博士