刚入了一台 skylake i3 nuc ，性能挺令我惊讶的，当然与四核心的差距还是有的。

6100U 的集成显卡还不错，能 1080p 30fps 中画质跑不少游戏了。

这作者也是挺没劲的……

通篇都是在讲背景是中国公司，关键的为什么不能用中国公司的产品一点都没说，你就是列举一些中国公司的黑历史也行啊。

https://news.ycombinator.com/item?id=11107740

我其实挺喜欢看进度条的，反倒是觉得 splash 比较麻烦，最多能接受云音乐那种吧。

微信勉强算是没有 splash 的吧，那个地球换 logo 也没问题。

分两种情况：

如果要全盘加密，包含 boot 的话，只能通过 IPMI 一类的旁路管理来实现，常见的有 iDRAC/iLO 等等。
这种情况相当于你无限信任 IPMI 管理模块。

如果可以不全盘加密，可以在 boot 部分加入 sshd 。
对于有物理接触能力的入侵，这种做法会降低加密的可靠性。


如果你真的非常在意托管服务器的数据安全，还有很多东西可以参考：

箱体入侵检测，一旦机箱被开启，就关闭系统或者删除数据；
禁用外部接口、外部显示以及外部媒介；
使用 TPM 模块，敏感密钥存储在 TPM 模块中。


严格意义上，如果有人可以无限制物理接触你托管的机器，你就没办法再信任这台机器了。

如果从零开始构建信任链，那么可以考虑某些商业产品，比如 PrivateCore vCage 。

机器硬件配置挺好的，大概问题是品控不行，现在有成色好的应该还不错，我那一台没几天就花屏了

本科阶段的 CS 其实非常局限，除去美国的少数名校，欧洲平均水平与美国相比应该差距不是特别大。

http://www.csfieldguide.org.nz 这里有关于 CS 的领域介绍可供参考。多数领域只有到了 phd 阶段才会深入。如果你的追求不是科研而是就业，研究生阶段就足够了。

我最初到法国的时候选的是 CS ，后来通过学分转换和 prepa 转到了 EE 专业。随便说说我的经验吧。

语言方面如果你英文非常好，法语会简单很多，德语的话和英语基础关系不大。

法国的教育模式下，能读工程师 Grandes écoles 就优先选，没什么好说的，教育资源生源质量都好太多。跟国内你考 985 一个意思。但直接申请难度很大，绝大多数要 prepa 来考。

不过由于传统工程师学校都是数理化土木等等专业基础上建立的，开设 Informatique 专业的学校数量有限，现在有没改善不太了解。

CS 专业最好的两所应该是 Polytechnique 和 ENS Paris 。其他工程师都差不多应该。非工程师里本科阶段都不太好，研究生阶段 Paris 6/13 可以考虑。

就业方面，工程师必要非常好，非工程师毕业比较一般。安全方面，巴黎中等偏下，比不上大部分国内城市。

前段时间在魔都看过，这话剧十多年一直在演进，很是经典，值得一看。

如果你不是特别需要 X ，也不依赖 nv/amd 的私有驱动，可以考虑用 Wayland 换掉 X 。

swaywm 就是 i3 的 Wayland 版本。配置文件兼容。

好处是不会再有蛋疼的键盘布局以及按键捕捉问题，不依赖 OpenGL 实现垂直同步，安全的用户和进程切换，独立的字体渲染，等等……

@Tink
屏幕不够大只要每个应用都全屏好了，切换很方便。我用 12" MacBook 就是这样。

大概是单纯的映射，如果只是单纯编码数字到字符串的话，说不定可以逆推出来。

做 replay 存储的 databank 已经死了……

dotamax 的致敬对象 dotabuff 盈利状况似乎一般，不过创建者似乎不太在乎。

能详细介绍下演讲的内容吗？另外演讲的时间是怎么安排的？

@liuxl8964
信号的角度上关心的是信噪比， SRC 是个数学问题，和数字音量调节一样并不会改变信噪比。
如果定量地来看 SRC 的“影响”，只有二进制表达的区别，而不具有音频重现意义上的差别。


PS
Win10 某个测试版之前也是数字输出，正式版推送驱动更新之后才启用了系统级的音量控制。这是个选择问题而不是技术问题。

楼主说的大方向没有问题，只是需要进一步定量分析，所以结论会有所偏差。

关于延迟（ latency/delay ）：无论哪一种现代系统级音频处理，延迟都在 10ms 数量级以下，人耳对于音画不同步或者声音间断的容忍程度在 25~50 ms 左右。整个声音输出流程上的其他延迟才是大头。

关于动态范围（ dynamic range ），如果中间过程的位宽（ bit depth ）高于音频位宽一定程度，数字音量调节并不会损失动态范围。

我说个解决办法吧。

先开新的 Tab 访问一下 google.com/ncr ，然后在网页中间的搜索框里随便搜点什么；

关闭 Chrome 进程；

重新打开 Chrome 并在地址栏里面做一次搜索，这时会提示你选择继续使用 google.com 还是切换到 google.co.jp ，选择即可。

http://www.redhat.com/en/about/blog/why-red-hat-acquired-ansible

这是红帽的自问自答。

@est @raingolee

毕竟这么高的价钱，没有些技术含量是不可能的。 Ansible 的强项在于对设施、架构和网络环境的抽象管理。这点上毫无疑问是同类产品最优秀的。

我前面提到 Ansible 是适合大规模部署应用场景的，因为它整个的设计思路和实现方式都是从 Ops 的角度着手的。红帽的 OpenShift 是 PaaS ，所以它对于运维的定义是，用户是 dev ，平台是 ops 。从这个角度上说，它解决了运维的大部分问题。不过就我个人的观点，使用 Ansible 而不使用对应 PaaS 平台的用户来说，一定要 Dev 参与才称得上运维，仅仅有 Ops 是不够的。

Ansible 的终极愿景大概是任意的集群只要跑起来应用，加载相对应的配置就可以了。不过现实里， Dev 关注的更多的是软件环境，而 Ops 提供的是资源的调度，这中间还差得远。不是说我用了 Ansible ，我就不需要关注软件环境的细节了，而 Ansible 的开发方向恰恰又是以简洁为目标，尽量隐藏细节，更加不利于 Dev 参与到 dev/staging/prd 的流程中。

Idempotency 在硬件上很好实现，在软件上，短期内应该是看不到希望。（ Ansible 用 py 脚本把 unix 中不具备幂等特性的 primitive 等等做了封装，但这仅仅能帮助代码重用，实际上换个环境并不能确保功能上的可重现性。）关于偏软件环境的运维，我在 V2EX 发过帖子，谈得就是 Ansible/Chef/Puppet 等等无法解决的问题。

买去是要集成到 OpenShift 平台里。

个人感觉 Ansible 的目标是自动化“数据中心”级别的解决方案，大概正合红帽的胃口。不过目前这类配置管理、运维自动化方案都只是用一个盒子把之前的问题包装起来了而已，没有真正解决运维的问题。

被监控的应用本身向监控服务主动汇报自身状态（服务级别）， supervision 类应用只负责被监控进程的启停（进程级别），即不以 supervision 应用的汇报状态作为判断应用是否正常的依据。

单纯的二次监控是没有意义的。

真正有意义的是创业公司在国内而目标市场在国外，根本原因就是低人力成本和高收益。

我也做过类似的事情，比如国内招人做国外项目。我知道的欧洲大部分针对国人的产品或者服务都是这种模式。

除此之外，所谓的优势不一定就真的是优势，因为和你竞争的同行也享有同样的优势。