这不是 yarn 早就解决了么？为什么要用一个不能锁版本的软件包管理？

成本低没问题，但是成本太低的东西，成本是很高的。

而且你电信上传带宽多大？ 30M 有吗？ 200M 的宽带上传给多少来着……

太正常了。这就是真实世界啊。

@FS1P7dJz 你想想看，为什么没有考虑到全屋的网络需求？
因为 2003 年的时候连宽带都没有普及。
IPTV ？光纤接入？价格低廉的笔记本电脑？智能电视？智能手机？
一个都没有。
你说「可预见的将来」，那时候全民拨号 56Kbps 调制解调器上网，少数运气好的人用上了 2Mbps 的 ADSL，可预见的未来你是绝对不会想到房间里竟然还会出现多个上网设备的情况的。家里埋了一根 8 条线颜色都不同的网线，不就是觉得「妥了」，「稳了」，2Mbps 的宽带铺了 100M 的网线足够胜任了么。

你说抽线替换，这个如果你不预埋光纤的话，是没法直接抽的，你的管子可能根本不符合抽换的要求。

Mesh+Wifi6 是可以，但是 Mesh 的另外一台路由器我就得绕开承重墙吊在天花板的某个诡异的地方。
而且，众所周知无线技术再先进，稳定性依然是比不过一根靠谱的网线的。
Mesh 性能最好的还是背后网线互联而不是无线中继，这就又绕回来了。

总之我想说的是，装修这东西生效时间长，推翻成本高，宁愿弄得超前一点，不要被眼前的那些极限所迷惑。

8K 极限，120fps 到顶，这些都是你一厢情愿的想法。现在的高端 VR 设备已经能在 8K 下跑了，我就不信接下去 20 年 VR/AR 技术还停留在 8K120 上。（对了现在日本广播级电视用的是 8K60，就是 2018 年开播的那个台。）

@FS1P7dJz 你可以先想一想一般人多少年装修一次。下一次装修之前需求和技术大概是什么水平。

随便说个我家里的情况。
2003 年前后装修的，预留了一根大概勉强能到五类标准的线，5 米的距离能跑到百兆。
现在什么状态呢，电信光纤明线进屋，路由放在客厅中央，离得远的房间无线信号极差，需要一个无线中继做桥接绕着承重墙放才能勉强覆盖。IPTV 和台式机全部明线订在墙上走。
下一次全部砍掉重新装修会是啥时候呢？我也不知道，可能 15 年 20 年以后吧。

综上所述，你家要是不打算每隔 15 年拆光重装一次的话，还是超前点搞吧。

反正我们这些小 UP 主依然无权上传 4K，慢慢等吧，等哪天开放了再考虑呗。
没内容还谈什么值不值。

「服务器实际功率与服务器上面功率有多大差别」

上面功率是啥？

C++入门怕是要 10 年…

@jingcoco 要看具体项目吧，项目大了的话自动化测试的成本消耗是会下降的。
手动测试我觉得也算技术债的一种吧，欠得多了迟早要还的。

@ByteCat @baobao1270

完 全 一 致

@jingcoco 没有自动化测试，全靠手工测的话，系统做大了以后改动、修复成本会高得惊人。
我司之前就是纯手工测试，整个系统让一个 QA 团队测，一个版本完整测要测 3 周，而一个 sprint 才 2 周，也就是修复完一个问题以后要隔开一个 sprint 才能知道有没有问题，有的话要等下一个 sprint 才来修补。然后还有大量的 bug 没被 QA 团队测出来然后漏给客户的，就不多说了。

刚发布的系统里的版本应该是冻结时候的，没特殊问题的话必须要等发布后（也就是今天以后）才可以更新软件版本。Ubuntu 大约是 2 月 19 号冻结的，所以是 7.4.3 。等过几个星期应该就会导入 7.4.5 了。

用 ORM 的我已经很多年没有考虑过注入问题了。你随便构造数据，我什么都不过滤，能注入算我输。

显示器和电视的调教是不一样的。以前试过拿夏普的液晶电视当显示器用，说实话，感觉眼睛要瞎了。

@dilu 外接精准计时设备，例如铯原子钟，或者北斗或 GPS 时钟同步信号。

既然能写入 /usr/bin，那说明别人已经拿到了 root 权限，那从内核到系统文件，所有的程序都可能会被换掉，你不重装难道留着过劳动节么。

@laminux29 我并没有否认不平等关系。但是不平等关系和羞辱和否决和否定都没有决定性的联系。
考察的目的是找出那些人符合面试官认为的适合公司的候选人，筛掉你当然是因为你不符合面试官心目中的候选人形象。

新手入门我总是建议请老老实实从一个优秀的 GUI 开始。等你知道了 working directory / stash / stage / commit / merge / merge back / rebase 了以后，再要想比如说装个 B，再考虑纯 CLI 的情况。
比如 git pull 这样的命令只能处理最简单的拉取情况。如果你要拉取有冲突的 commit，情况会复杂得多，光一个 add 一个 commit 是远远不够的，需要首先根据场景看要做 rebase 还是 merge，然后根据具体操作去做 3-way conflict resolve 。

你现在的情况是 working directory 有更改，没进 stage 也没上 commit，更没 stash，于是产生了 local change conflict 。然后你做了 add 和 commit，这时候如果你有图形界面的话你可以看到状态是这样的。

origin/feature-init20200401 -> 7bb0b5eb --- 60 多个提交 ---> ae21cc9d
feature-init20200401 -> 7bb0b5eb -> c3c59ecc

然后你又做了 pull --merge，和一个 commit，变成了

feature-init20200401 -> 7bb0b5eb -> c3c59ecc -(merge ae21cc9d) -> 9e87e2c6

先不论结果怎么样，中途这条分支叉出来叉进来再叉回去，会让人无法看清每一个提交的用处和每一处修改的位置，万一提交后出了问题，也很难去单独隔离出某一段提交然后回滚。比如你这里，一处修改分了两次提交，一次在 merge point 之前，一次在之后，就很难去隔离测试。

比较好的做法是，先 stash，然后签出 ae21cc9d，然后 stash pop 并 resolve conflict，然后再做一个单独的「去 log 」提交。
另一种做法是，先 commit，然后做 pull rebase，在 rebase 过程中 resolve conflict，然后把 rebase 过的 commit 给 push 上去。
两种做法的结果是完全相同的。

如果你司没有针对 git 的学习过程的话，建议大家聚在一起好好学一下。瞎基尔用 git 是对 git 强大能力的一种浪费。正确使用 git 会大幅提高源代码管理效率的。

至于你说把同事代码删了是怎么回事，这个也只需要开个 GUI 工具，往上回溯一下看看每个提交的 diff 就知道怎么回事了。无非是 merge 的时候出了问题吧。