不稳定都是因为硬件设计不佳（比如散热问题、供电稳定性问题），或者是第三方编译的全家桶固件的 bug ，或者是梯子网络波动，且没有配置 fallback ，导致 DNS 等挂掉。
最近一直用老 microserver gen8 当软路由，自己编译等固件，开机以来 120 多天没出过问题

手机的话 16G 估计真够了，手机上不会进行太多多任务行为
（后排提醒，这个帖子在 Android 节点）

可能需要对大规模（分布式）训练 /推理有了解吧

kexec 挺有意思的用法，不过服务器不能直接用 bmc 装系统吗？按说和物理上机操作是一样的，就是通过网络挂 iso 比较慢

填 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 如果要适配一个设备的话，对于部分平台，会有个设备树或者别的一个配置文件，需要在里面定义好机器的网卡

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