@lysS 这楼里说的不都是 Mb 吗？带宽又不用字节做单位。

@d5 惨。
我是生产服务器的 zsh prompt 会加上醒目的警告样式，然后任何生产服上的破坏性操作都需要反复确认才执行。

@d5 向来是新服稳定跑了才关老服。

@evilic #11 「同样配置的 ECS 」是说有 ECC 内存、志强 CPU、双路冗余电源、恒温恒湿环境、UPS 和发电机双备、冗余网络的 ECS 吗。
如果你不介意稳定性，当然可以放在自己机器上跑了。
但是为什么又要问怎么保证稳定呢……

而且跑服务的机器，最少也要上个 UPS 吧。
ECC 内存，志强 CPU，冗余电源，恒温恒湿，冗余网络什么的咱们都先不提……
一个 UPS 才几百，至少能保证断电的时候不丢数据或者损坏文件系统。

我们公司有个很小的自建机房，跑一些不重要的东西，比如测试机。4 个机架零零散散放了一堆志强，插了总共 3T 多的 REG ECC 内存，9 台 2200VA 的 UPS，一台小功率柴油发电机，8 个简易 PDU，两台空调。属于够不上生产环境但是拿来玩玩还是可以的机房设施。

你要把机房里的设施搬到家里，那不就是把家里搞得和机房一样吗。

恒温恒湿，双路市电，PDU 接 UPS，再配一个柴油发电机组，最好再弄个人 24 小时值班。

（机房这么可靠的环境为什么要选择在家搞呢。）

@hanyceZ 按理说私人设备公用，公司是要给补偿的。要强制安装软件的话让 IT 部门提供电脑啊。

我们是 GS324 给工位用，GS752 系列给服务器用，路由用的 pfSense。

市场行为嘛，没怎么办啊，你给自己定一个不会后悔的心理价位，然后等对方出价。
对方出的高于你的价位就卖，低了就不卖嘛。

@ericgui 什么怎么算？ Android 是基于 Linux 的没错，但 Linux 可不是纯粹的 GPL，而是带有附加豁免条件的 GPL，对于通过 API 调用的用户态程序不感染协议。所以安卓的内核态代码都是 GPL 的，而用户态代码可以是任意许可证。

同理对于已经自成一体的独立内核模块也不会感染 GPL。比如显卡驱动，本身就不是基于 Linux 的功能，不是衍生作品。zfs on Linux 是从其它操作系统上移植过来的软件，自然也不是 Linux 的衍生作品，可以用 CDDL 合法发布。

你说得对，我不是法律专家，但是这不意味着我不能指出明显的错误。法律上对此问题的描述很明确，每个软件工程师都应该仔细研究学习，免得哪天不小心就给公司带去几百万的官司赔款。至于具体的结果，是法律专家也没有用，最终还是法官判决。甚至法官判决也不一定就是对的，还有上级法院可以上诉。上级法院也不一定就是对的，还有最高裁呢…

@softempire
用了 GPL2 的库，你当然需要开源你的软件。
但是你不需要 向全世界 开源你的软件。
GPL 的要求是，你需要向你分发二进制的目标提供源码。

所以比如说这个软件你拷给了你的同事，那么他如果问你要源码，你有义务给。
但是我问你要源码，你完全不需要给，因为你没有把软件分发给我。

但是同样的，你不能剥夺你同事分发你的软件和你的源码的权利。
如果你的同事把软件拷给了我，那么我问你同事要源码，他就必须给。
（但是我不能问你要，你也不需要给我，因为分发给我的不是你。）

所以简而言之，你需要开源，但你不需要公开。

@ysc3839 @ericgui 完全错误。
GPL 传染性和是否通过接口和怎么调用完全无关。
传染性看的是你的程序是否是一个「 derivative work 」衍生作品，或者说你的程序是否依赖了原始作品的功能。
比如你的软件 A 引用了类库 B。类库 B 实现了软件 A 中的某个需要的功能，缺少了类库 B 会让软件 A 无法正常使用，那么一般认为软件 A 是类库 B 的一个衍生作品。

不管他们是静态编译的，还是动态编译的，还是通过操作系统的其他手段调用的，都没有关系。

比如有一命令行程序 A 是 GPL 的，你为 A 编写了一个图形界面 B。显然 B 必须要 A 才能正常使用，那么 B 就是 A 的衍生作品，也受 GPL 约束。（实际的例子，比如你为 GPL 许可证下的 ffmpeg 写了一个 GUI，那么你的 GUI 受 GPL 约束。）

又比如有一命令行程序 A 是 GPL 的，你写了一个很复杂的软件 B，其中一个功能可以调用 A，但没有 A 也能实现主要功能，用户可以自行下载软件 A 与你的软件 B 一起工作，那么一般认为 B 不是 A 的衍生作品，不受 GPL 约束。（实际的例子，比如你为 Adobe Premiere 写了一个开源的视频导入插件，调用了 GPL 许可证下的 ffmpeg，那么你的插件受 GPL 约束但是 Adobe 软件不受。）

@ternary 同代产品能耗比基本差不多，像是牙膏厂的几代都是同工艺，肯定无脑选性价比高的 8250u 啊。
或者上新的 10nm 也可以。

@AndyBlocker 满地都有的裤子表示不服。

大文件加密为什么要传完了再加？

@ternary #12
发热是跟着性能来的，同代工艺的产品性能越高发热越高，你要发热低那就只能买低端低速产品了。

说实话我不太懂为什么要纠结发热量大。

随便找个游戏主机 DIY 硬件贴，去掉显卡改用集成，或者换成亮机卡，应该就差不多了。
或者像是 DELL 3010/7010 那种 i5 的机器，加点内存换块 SSD，也没多少钱。

待机功耗差不多 30W 吧，一年电费$30 左右。

当然具体还是要看你跑的软件到底吃多少资源。

@takemeh #35 充分测试有什么用呢。
现在那么多软件没有经过充分测试吗，哪个软件敢说经过充分测试以后就没有 Bug，就不会炸？
如果你不能为用户的选择负责任，那就不要想着控制用户的选择。
像 RedHat 这样的大公司，出着 RHEL 这种企业级的软件，都不敢强制用户去升级呢。
万一强制升级一下，炸了，一个官司过去你算算得赔多少钱。

Staging 应该是上线前的最后一道门槛。如果要上线的 feature 改了，那么就应该重做 Staging 分支，只包含要上线的 feature 来测试。

Git 是很灵活的，不要把他用得那么死板。如果一个分支不适合当前需求了，就重建这个分支。

不说你写的这个软件，就说普遍意义上的各种软件。
你凭什么强制用户去用新版本？

最简单的问题：新版本里就没有新引入的 Bug 吗？用户更新完发现炸了怎么办？