正则应该是 Automata theory 的演化。这货还演化出了编译原理这玩意儿。所以没有正则的话，连编程语言也就一起没了。

@taobibi 重建阵列本身是一个危险操作。
你作为一个运维，通常进行危险操作之前，你会做什么？
对，备份。
但是热备盘的重建是自动的。也就是相当于阵列卡会自说自话在你还没有任何备份甚至任何防备的时候，就帮你去执行一个危险操作。你说是不是做大死。
这个之前看到过文章特地讲过这个问题的。

如果一定要做这样的设计，可以做成冷备，出故障提醒运维，运维上去安排好维护窗口，做好备份以后，再重建阵列。

其实热备还不如直接做 RAID6。

远程 wmi ？

盖章+签字，生效了啊。三方本来就是约束公司和学生的，违约当然要付出代价。

@southwolf 和品控没关系吧，就是用了辣鸡元器件。
比如说我这 M570 （美版）里用的是国产微动 d2fc-f-7n，额定寿命 500 万次，淘宝上卖 7 毛 5 分一个。
而一般选用的 d2f-01f-t 日产金合金微动，额定寿命 1 千万次，淘宝上卖 4 块钱一个。
更好的 d2f-f37 额度寿命 2 千万次，要 5 块多一个。

其实就是罗技贪便宜。

@chenyx9 #64 这我倒是不清楚，因为我这不是换的，都是罗技直接给我寄新的，花钱买了 2 个，售后又送了 3 个。

@CLOT 今天刚下单了一包 D2F-F37，准备把手里的 5 个 M570 的双击微动全给换了。
@chenyx9 等过保了就得自己换喽

VM 设置的 CPU 选项找找。就是让你选核心数的那块地方。

后面加个$拦截一下。

想办法绕开专利。

@taobibi RAID5 热备做大死。

硬盘是可以修的，但是原则上还是以保修返厂为主。
硬盘是存储数据的介质，数据是主要的，硬盘只是消耗品。你要靠谱的可以买企业级，但是凡是硬盘都有可能坏，没有保证多久不坏的硬盘。硬盘的寿命也是平均寿命，没有保证寿命的。再贵的硬盘也有可能半年一年坏掉，便宜的硬盘也有连续跑七八年不坏的。

对于影音内容，考虑单盘+SnapRAID 结构。这种结构下就算损坏多块硬盘也不至于整个阵列一起完蛋，没坏的盘上的数据都是完整可读的。
对于备份，可以考虑 GSuite Drive，月付 12 美元，无限空间，虽然国内速度不快，但是好歹用作备份，只有硬盘坏了才会用得到，平时只要用 rclone 增量同步即可。

M570。顺便请自备微动、电烙铁等工具，过保以后可以自己换。

Git 包含两部分，一个是底层的文件结构，也就是 .git 目录和里面的数据。
另一个是上面跑的命令行程序。
Git 强大就强大在他的灵活性上，也就是前者强大；而后者功能虽然强，但是结构非常乱，适合被脚本、软件调用，而不是直接面对用户。

他的对手 Hg 则正好相反，Hg 命令行功能很清晰，但是底层 .hg 功能太弱，基本概念照搬 SVN，分支不方便，Rebase 不方便，适合那种一锤定音一次提交就再不用改的人。Git 则是允许用户犯错，错你随便犯，反正都能修回来；代码尽管随手提交，反正后期都能 Interactive Rebase 回来。

我怕的就是把 Git 当高级版 SVN 用的。

@rockyou12 Git 这么好用的工具，出错了又怎么样？ push -f 又不会丢数据，覆盖了有用提交直接从 reflog 里挖出来 push -f 推回去就行了，为什么要个个是神 100%不出错？出错了才能吸取经验才能进步，就是因为怕犯错才天天这也不敢用那也不敢用，Git 用了 10 年也就和刚上手一两年的人一个水平。

而且相反的，不允许-f 来纠正错误，让程序员提心吊胆生怕不小心推错东西一失足成千古恨，才是所谓的「你团队个个都是神能 100%不出错」。

至于你说的 reset revert merge rebase 瞎瘠薄命名的问题，我只能说，找个好点的客户端吧。不要让工具去限制人的发挥。

命令行 Git 功能参数太乱 -> 复杂 Merge/Rebase 容易丢代码 -> 不允许 push -f -> 程序员怕推错提交而自裁提交数量 -> 不再频繁提交与推送

不知道别人怎么样，反正要是哪天不让我用 push -f 了，怕是我连维护手头的那堆开源软件都不知道怎么操作了。

穷举本来就是最后一种方法，哪有防穷举这种东西。
比如我问你，我一年工资多少钱，精确到分。于是你从 0.01 开始穷举，一路往上到几百，几千，几万，总有一天能穷举出正确答案的。
你说的可能是防规律遍历。

敏捷开发快速迭代对设计的要求有所降低，不画 UML 不做详细设计方案但是大体上的思路还是要有的，否则写代码就像无头苍蝇一样乱撞也不是个办法。

后端拿掉就等于没有了后端权限控制，拿到 ORM 就等于可以往数据库里随意写数据了。不知道这个怎么解决。

@rockyou12 我们就是这么管理项目的。Rebase 了 Push 上去是为了做 Merge Request Peer Review。不做 Peer Review 直接 Squash 成一个 Commit 然后就往主干上塞？我可谢谢您了。
而且我们要求组员都要频繁提交频繁 Push，完成一处修改就 Commit+Push，以避免本地副本意外丢失。
不知道这些被很多人推荐的项目管理实践怎么到你眼中都变成没必要的东西了。

对我们来说，绑着程序员不让他们自由地利用工具来完成项目才是个项目管理问题，有啥好说的。