是啊，最多就是你免费证书的秘钥被偷。

@zzhzero 连 1909 升 2004 都有问题我也是醉了……
现在就是不想重装，要重配的东西实在太多了（光一个 5 用户的 chrome 我就不知道要怎么迁移过去）。实在不行以后就拆分成一堆虚拟机算了，实在受不了这不稳定性。

@cjpjxjx 是指光盘引导安装的那种么？

告诉我无法完成更新，正在撤销更改。我可去你的吧……

说个笑话，Windows 的升级。今天我试图把 1903 升级到支持的版本，8 个小时过去了没一个是成功的，刚刚用 DISM++强行植入了 1909 的升级 cab 才升到了 1909，现在又找不到安全补丁包了，正在手工植入最新的补丁。试了 2004 20H2 21H1，系统自带升级，易生，全试了，没一个成功的，我已经佛了。

你跟我说升 11 ？

（一个折腾了 8 个小时的苦逼 Windows 用户路过）

@ryd994 我觉得应该还是消费习惯不同。有些人可能是习惯了低价格低标准服务，遇到高价格高标准服务的时候就会下意识觉得用户在坑商家，一边喊着卖得比某并贵狗才买，一边喊着退货无耻（手动狗头

许可证就是放弃权利的意思表示。

如果没有任何许可证，你的代码和你的文档就是「版权所有，保留所有权利」。
现在你把「所有权利」中的一部分权利，例如阅读、修改、制作衍生作品、再分发等的权利，通过许可证主动放弃掉，允许任何其他人在遵守 MIT 许可证的前提下行使这些权利。

现在其他人在 MIT 许可证的前提下行使了这些权利（修改，制作衍生作品，再分发，等），那么就是受法律保护的。
在中国怎么样我不知道，在欧洲或者北美，我合法部署完了以后如果你作者公开指责我，我甚至可以诉你诽谤。

在美国待了很多年的表示，亚马逊本来就是鼓励退货的。曾经有很长一段时间，亚马逊使用的快递塑料袋就是做成方便退货的样式。他塑料袋有两个密封胶，一个用来发货，另一个用来退货。拆开的时候拆第一个封口，如果不满意的话原样放回快递袋然后把第二层密封胶封上，然后寄回就行了。

现在这种快递袋已经不用了，因为亚马逊已经在全国各地铺开了退货仓库。我要退货的时候直接开 10 分钟路到亚马逊的仓库，把货交给工作人员就可以完成退货。

在亚马逊，正常以购买为前提的试用一般不会有问题。退的货一般会返厂或者作为 Open box 来低价销售。我一年交$120 买 Prime 会员，不就是为了享受这个更方便的送货和退货服务的么。

2.5 那不就只能加 SSD 了。总不能整一堆 SMR 数据杀手吧。

为什么要用 dd ？

fallocate -l 3T /mnt/Public/disk01.img

另外这叫做「阵列」，不是「陈列」。

@cainiuwow #5 看对应负载的转换效率。
你这全加一起大概 60w 左右功耗吧，500w 等于是 12%左右的负载，这时候转换效率可能只有 89%，如果是 40%负载的话有些电源可以上到 94%效率。
不过具体还是看你买的型号，质量好点比什么都重要。

几乎是唯一靠谱的方法是走 cgroups 管理进程树。你 nohup 启动的程序开出来的进程也不保证就是在这个程序旗下的。只有 cgroups 可以追溯到所有的子进程。
所以用 systemd 来管理吧，多省事……

因为你把 develop 的根基改变了。

Rebase 的中文翻译，变基，其实算是比较贴切的。

第一次运行的时候，
develop 上是 1 - 2 - 3
my_feat 上是 1 - 2 - 3.5
你在 develop 上变基 my_feat，就是说，my_feat 作为新的根基，在这之上，把 develop 的提交追加上去。
那么 my_feat 的 1 - 2 - 3.5，到这里不变，后面加上 develop 里多出来的 3，自然就是你说的结果了。

第二次运行的时候，
develop 上是 1 - 2 - 3.5 - 3
origin/develop 上是 1 - 2 - 3
你现在是让 develop 去变基 origin/develop，就是说，origin/develop 作为新的根基，在这之上，把 develop 的提交追加上去。
那么 origin/develop 的 1 - 2 - 3，到这里不变，后面加上 develop 里多出来的 3.5，这就是你最终看到的结果了。

关键点在于，变基时，基是不会改变的，所以第一次你的根基是 my_feat，那么 my_feat 是什么样，就是什么样，3 是不可能插入到 my_feat 的中间去的。

并入更改用 merge，散播更改用 rebase 。

人人都懂 Git 的小公司 merge 的时候可以用普通的 merge commit，不是人人都懂 Git 的公司（特别是参差不齐的大公司）或者合并非常频繁的大公司，可以善用 squash merge 。（我司一般都是 squash merge，因为合并太频繁了，经常 Rebase 不现实。）

https://i.imgur.com/dG0EM7G.png

↑ 理想的 timeline 应该是类似这样的。

https://i.imgur.com/U54T03C.png

↑ 大多数公司代码的 timeline 是这样的。

单次运行用 nohup，长期反复运行用系统服务。

@justaname URE 会导致阵列最终数据丢失一个扇区的内容。但是这不是重点，重点是 RAID 需要拿去手动恢复的时候就等于这个阵列报废了。一来系统必须离线然后用软件去恢复，二来恢复出来的数据已经不可靠了。比如你阵列里存着网站的数据库，现在告诉你数据库里有一个扇区的数据是坏的，你怎么想。

唯一索引然后条件插入就行了。

顺带一提，用 nobody 也不算是很好的做法。
好做法是每个单独的权限个体拥有自己的账号。
如果你一台服务器就一个网站，那网站应该跑在 www-data 或者 www 下。
如果你放了很多个独立的网站，那他们应该分别跑在自己的账号下。
nobody 因为是无权限用户，那就应该以无需读取任何私密信息作为前提。
当你把文件 chown 到 nobody 或者 chmod 给 all，仅仅是为了给 nobody 读写的时候，这做法就已经不对了。