如果买过维护服务，找维护厂商，如果没有，看 GPL:

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

99 日元已入手，感谢提醒

Google Photo + OneDrive 自动在线备份
DAEMON Sync 装在 NAS 上本地备份

准备啥时候心情好再搞个 ownCloud 之类的往服务器上备份一份

我用 HDD 组的阵列瓶颈就已经在网络了，除非上万兆内网不然我觉得没啥必要...

http://blog.scoutapp.com/articles/2009/07/31/understanding-load-averages
粗糙地说就是单位时间内处在运行状态的进程个数的平均值

基本同意 #2 楼
不过我觉得你直接一步到位上 Arch 就好啦～

反正都是折腾，我当时就是从 vps 上装 Arch 开始的...

这年头可以考虑下 n3450/n4200 系列的，集显支持硬解 10bit 视频

ESR 用户表示短期没有升级意愿，也许啥时候闲了会找个虚机装上试试看

标题里大大的“足以形成孕育生命的条件”怎么理解成“有地外生命了”的？这句话哪里有歧义？

啊楼主这个应该就是路由器没有千兆口的锅，顺便想起我自己折腾的时候遇到的一个问题，线有瑕疵造成光猫到路由器之前偶尔协商成百兆，所有硬件都是千兆的，从路由器的 kernel log 里面才看出来问题，然后调整线和链接之后就稳定多了

Source Code Pro

领完发现我的库里面已经有了 233333

另外如果你用的 root, configure 时候没指定 prefix 然后直接 make install 怕是把系统的给覆盖了？

第一件事，发信用卡照片的时侯把姓名、卡号和有效期都涂掉

既然是公司内控，这就不是个技术问题，所以解决当事人才是正确办法
比如发个通知说清楚情况并辅以相关管理措施之类的

想过自己做，但讲真就算做出来了也不敢把数字直接放出来，到时候一句没有资质违法 XX 就能怼死...

哦不错苹果也有 pool 域名

$ ntpdate -q time.apple.com
server 17.253.82.125, stratum 1, offset -0.118363, delay 0.32236
server 17.253.68.253, stratum 1, offset -0.087254, delay 0.28787
server 17.253.84.253, stratum 1, offset 0.031281, delay 0.12460
server 17.253.68.125, stratum 1, offset -0.092504, delay 0.29269
server 17.253.82.253, stratum 1, offset -0.125195, delay 0.34073
1 Oct 15:43:08 ntpdate[29096]: adjust time server 17.253.68.253 offset -0.087254 sec

这个延迟和标准差自己看吧...公网授时这个精度差不多就到头了，高精度要求的只能自己想办法在内网搭建时间源

@mengzhuo 我没有说阿里的钟一定是准的，不，我并没有这个意思，将来宣传出现了偏差...

用 GPS 做时间源常见的系统误差来源，可以认为闰秒也算一个，但闰秒是常量所以加上偏移就搞定，而且像你说的，GPS 本身就会下发闰秒信号，不需要接收端特意设置；另一个是从信号接收到内核这一段的传输&软件处理的延迟，这个值在一般设备上很容易达到几百毫秒，而且不同设备不一致，所以需要在架设部署的时候和别的时间源进行校准来确定

还有一块误差来自运行过程中机器自身走时速度不均匀造成的漂移，但阿里用了原子钟守时，原子钟输出的 PPS 频率是足够精确的，不会存在这个问题

如果阿里的钟不准，多半就是这个校准没做好，或者校准后在运行中（软件 /硬件）环境发生变化造成原有的系统误差变大或者变小，而没有再次校准所以偏掉；我随手测了下，和 cn.pool.ntp.org 确实存在误差，分别差大约 -13ms, -45ms, +19ms, 和 +16ms，但 pool 里面这几台延迟都在 200~300ms 水平，会明显影响校时精度，所以实际误差肯定比这个再小一些，你看，pool 的机器自己互相之间误差就这么大了...

$ ntpdate -q time.pool.aliyun.com
server 120.25.108.11, stratum 2, offset 0.001602, delay 0.05620
server 115.28.122.198, stratum 2, offset -0.000663, delay 0.04390
server 182.92.12.11, stratum 2, offset 0.001149, delay 0.05899
1 Oct 15:05:50 ntpdate[28719]: adjust time server 115.28.122.198 offset -0.000663 sec

$ ntpdate -q cn.pool.ntp.org
server 5.79.108.34, stratum 2, offset -0.013887, delay 0.22470
server 108.59.2.24, stratum 2, offset -0.045969, delay 0.37437
server 163.172.177.158, stratum 3, offset 0.019065, delay 0.34531
server 203.135.184.123, stratum 1, offset 0.046475, delay 0.32439
1 Oct 15:06:00 ntpdate[28727]: adjust time server 203.135.184.123 offset 0.046475 sec

另外补个苹果的

$ ntpdate -q time1.apple.com
server 17.254.0.27, stratum 1, offset -0.038363, delay 0.30672
1 Oct 15:20:01 ntpdate[28892]: adjust time server 17.254.0.27 offset -0.038363 sec

$ ntpdate -q time2.apple.com
server 17.254.0.28, stratum 1, offset -0.063057, delay 0.32030
1 Oct 15:20:11 ntpdate[28906]: adjust time server 17.254.0.28 offset -0.063057 sec

$ ntpdate -q time3.apple.com
server 17.254.0.31, stratum 1, offset -0.024707, delay 0.21799
1 Oct 15:20:22 ntpdate[28916]: adjust time server 17.254.0.31 offset -0.024707 sec

$ ntpdate -q time4.apple.com
server 17.151.16.20, stratum 1, offset -0.003465, delay 0.21930
1 Oct 15:20:37 ntpdate[28926]: adjust time server 17.151.16.20 offset -0.003465 sec

$ ntpdate -q time5.apple.com
server 17.151.16.21, stratum 1, offset -0.033497, delay 0.23425
1 Oct 15:20:47 ntpdate[28936]: adjust time server 17.151.16.21 offset -0.033497 sec

$ ntpdate -q time6.apple.com
server 17.151.16.22, stratum 1, offset -0.007614, delay 0.22504
1 Oct 15:20:57 ntpdate[28946]: adjust time server 17.151.16.22 offset -0.007614 sec

时间一致性比 pool 的要好一些，但自身之间还是有 10ms 数量级的误差（股沟家的我这边查都是 v6 给数据 v4 没结果，多半是墙，考虑到之前曾经遇到 v4/v6 不同栈误差高达 100ms 的情况，就不贴了，原因怀疑是骨干网路由走向不同）

我想表达的是，你贴的那段原文只是讲了 UTC 时间和 GPS 时间有个闰秒的偏差，和阿里的钟为啥不准完全是两个事情，至于你认为可能来自硬件实现的系统误差，且不说这个误差在初次校准的时候就会被改正回来，以及阿里显然用的商用授时硬件而不是几百块的玩具，这样直接猜测对方硬件实现不精密和你指责 @refactor 报 bug 不写补丁有本质区别么？

讲真，想要精确授时，搞个（最好两个） GPS 接随便什么 ARM 寨版装随便什么 Linux 发行版，放在内网拿时间戳，再用 GPS 自带的 PPS 信号守时，初始校准随便找 pool 之类的公网机器观察几小时就行，授时精度通常都在 1ms 左右，1u 上因为有 PPS 信号可以达到 100ns 级别的精度甚至更高，jitter 可以直接是 0 ；和隔开几百毫秒的网络时间源同步，光本地 ISP 线路抖动带来的随机误差就差不多能有 10ms 量级了，你看 ntpq -p 的输出里面 jitter 是不是经常都好几毫秒甚至好几十毫秒......

ps, 我原来以为报 bug 只要把现象说清楚就行了，原来还要修复彻底的？

@xierch
@mengzhuo 你贴的那个是闰秒，现在应该是差 37 秒还是多少来着，和这个几十毫秒的误差两回事

#12 楼 @refactor 说的问题我觉得楼主可以看一眼...