@loveour 但是 IPv6 最根本的地址长度扩展，其实就是 255.255.255.255 + (255.255.255.255)*3 然后再从“点分十进制”换成了“冒号分十六进制”（这个名字我随口现起的），关键在于这两种写法都只是为了方便人类阅读的 *表示方法*, 它们实际上就只是一串 32 位和 128 位的二进制数而已，所以你如果非要把 IPv6 按 IPv4 的点分十进制方法写成 16 段地址也没什么不行的，翻着花变换 *表示方法* 并不改变协议的本质；所以楼主说了这么大一堆只能暴露出他并不知道 IP 地址实际是什么东西，想当然地就往上“扩展”了，然而 IPv6 不仅完美符合他设想的扩展方案，还一并解决了很多别的问题

前东家有个面试策略是（当然，在面试官自己会的范围内）不断追问技术细节一直到候选人答不上来，这样才能知道你知识的边界在什么地方
另外简历上写了的东西必然是被抓着问的，所以如果不是足够熟悉的东西不要往简历上写，想让人知道你会某个特定技能的话在面试的时候主动提到都可以，但口头说你就可以是“有一些经验，但不太熟练”

你可能需要考虑下高性能台式机+轻薄便携本的组合了

@ant2017 这种速度下需要考虑的不是撞到东西，而是自己会不会变成黑洞，因为速度越快质量就越大

高级搜索+1
包括项目内的代码全文搜索，和 repo 列表中搜索，提供更多筛选选项，以及在搜索结果页面实现更方便的上下文查看
如果能对全站搜索做更丰富的选项 /功能就更棒了

另外如果在代码查看页面能加上简单的索引 /项目内跳转（相当于部分实现一些编辑器的辅助功能）也是很有意思的

xps13 9360 w/ ArchLinux 用了半年多体验非常好，唯一毛病是 killer 网卡支持，前一阵自己换了个 intel 彻底解决
另外之前用过半年左右 ThinkPad X1C 2016 款，指纹传感器不能用，其余完美

对应系列的新型号想必也是很香的

你这个需求用 0.0.0.0/0 再排除掉所有的保留地址是不是更好一些啊，全网路由几十万条...
保留地址： https://en.wikipedia.org/wiki/Reserved_IP_addresses

我隐约记得好像是内核里面 adjtime() / adjtimex() 的实现有区别，不确定，也没核实；
我自己搭的在局域网内可以达到 ~1ms 的精度，我觉得非工业 /科研用途已经完全足够了，如果要做真正高精度的授时得上原子钟，视情况换 PTP，以及可能也不能用 tickless 的平台
至于要不要买别的设备，如果你现有设备可以 fix 并且正常用，我觉得必要性不大，多收几颗星主要好处是精度和稳定性高一点

（抱歉顺手翻了旧帖子 23333, 以及引流一下 https://blog.atr.me/NGC437 ）

看来 #23 楼没有看到我的后面提问，我说一下我的理解。
对于 #19 楼的观点“ NTP 就是针对不稳定网络的”我认为是不正确的，NTP 针对网络授时，协议 /算法中巧妙地排除了节点间的网络延迟，但它并不是针对 *不稳定* 网络的，或者说 NTP 在不稳定的网络下表现并不是足够好。

NTP 中客户端与服务器时钟偏差 offset 的计算方式是：

offset = ((服务器收包时间 - 客户端发包时间) + (客户端收包时间 - 服务器回包时间)) / 2

（具体可以看 [Wikipedia]( https://en.wikipedia.org/wiki/Network_Time_Protocol#Clock_synchronization_algorithm), 有很清晰的图解）

不难看出这里隐含了一个假定的前提条件：客户端发包和服务器回包，往返双向的网络延迟是相等的。

但事实上在公网传输的流量，双程的延迟并不一定相等，可能因为双向路由不同，也可能因为中间链路的抖动，总之 rt 这个东西是经常都在变化的，这种变化给获取到的 offset 值带来了持续的随机误差。NTP 中有一个专门的值用来衡量这种误差的影响程度叫 jitter, 其数学含义是客户端计算出的过去一段时间内和某个服务器所有 offset 值的均方差。

在理想情况下，jitter 应当是 0, 意味着客户端与服务器之间的网络一直稳定可靠，实际使用中，不难观察到距离越远（此处指 rtt 高）的服务器，其 jitter 也就越大，意味着客户端计算出来的自己同这台服务器之间的 offset 值越不精确。并且在网络繁忙的时段 rtt 可能频繁变化，jitter 也会升高。

这个就是我说 NTP 并不是针对 *不稳定* 网络中授时的原因，也是很多大公司会在自己内网架设 NTP 服务器来进行授时的原因（之一）。当然一般家用或 VPS 上面使用不需要考虑这种问题，误差并没有大到不能忍的地步。（个人经验是中美之间授时 jitter 可能在几十毫秒的量级）

回到楼主的问题，手表是一个需要随身移动并经常出入各种复杂物理环境的东西，首先显然不可能使用有线网络，能通过 wifi 联网的时间不一定稳定或者足够长（ NTP 是需要一段时间来完成时间校正的，offset 越大需要的时间越长，和系统内核也有关系），通过移动数据网络的话稳定性应该也不难想象，所以这种情况明显精度高不到哪里去。

而且因为市场上早就有了比较成熟的无线电授时甚至是 GNSS 授时技术，这两者只需要设备在户外或者其他能接收到无线电或者卫星信号的地方，被动接收信号计算偏差，不需要在手表上额外加装信号发射装置，也不要求手表处在有网络覆盖的地区（所以野外也可以使用），显然是更好的选择。

不过话说回来，以上这些除非特别极端情况，一般误差都不会超过 1s, 日常使用多半是感受不到的。

@CEBBCAT 希望能解答你在 #14 楼的疑问。

@julyclyde 那如果网络环境不稳定，rtt 抖动频繁，或者说 rtt 的值频繁改变的时候会怎么样呢？

@julyclyde 来源请求？

我曾经尝试过在我校某社团推动使用邮件列表无果，国内多数学校，或者说学生和教师从来就没有养成过使用邮件进行正式沟通的习惯，非常无奈

ps, 这样也造成了一些人毕业工作后需要专门耗一段时间来适应通过邮件流转信息的工作模式 or 像楼主说的这种整个公司不用邮件拉一堆微信群╮(￣▽￣")╭

另外同意 #22 楼的观点，这个就是钉钉，以及类似的企业 OA 厂商的生存空间

手表用无线电授时比 NTP 靠谱吧，NTP 受网络质量影响非常大，可以想像手表不会有多稳定的网络...
另外电波表是好多年前就有了的技术，也不存在什么太新不成熟的问题，就差钱了（

每隔十年把数据转移到新的硬件里面一轮你都嫌麻烦？？？是十年不是十天啊喂？？？

多谢，在网页端 Google 日历直接添加了订阅，其他设备跟着同步就能看了

bird 里面 show route all 可以看到每条路由的详细信息，另外如果是直连的 iBGP, 去掉 multihop 加上 direct; 试试 https://bird.network.cz/pipermail/bird-users/2011-August/002357.html

因为曾经有一段时间遍地都是免费或者接近免费的 LAMP 架构虚拟主机，刚开始玩 VPS 的那帮人干的第一件事情基本上也是装 LAMP 然后放个博客或者论坛

光猫到路由，路由到电脑，如果有交换机之类的设备也算上，中间每个链路都看下是不是协商成百兆了...

有编译 autoconf / m4 的功夫不如换个新点的系统