你们这些发软文的，不仅软文翻译得不专业，连基本的职业道德逗没有，来 V2EX 不发原文链接，还全文转载，是不是该叉出去？

@adrianzhang

Splunk 一样需要暴露文件系统或者有宿主权限才好做日志管理，与 docker 相关的部分只有一个 splunk forwarder 转发。

Splunk 更接近 Elasticsearch + Logstash + Kibana 的组合，而这里提到的问题是怎么把日志从容器导出到 Splunk/ELK 之中。至于导出之后如何做处理那是另外一回事。

Building a CustoMac
http://www.tonymacx86.com/building-customac-buyers-guide-august-2015.html

严格意义上的“驱动”和性能无关。 CPU/GPU 的性能上限是制造时决定的，实际使用当中的性能是不会超过理论上限的，无论使用什么“驱动”。

CPU 不需要驱动：操作系统和应用软件都是以 cpu 特定指令集构建而成，不需要“驱动”进行中间转换。

GPU 需要驱动：图形芯片的指令集与 cpu 不同，需要“驱动”进行中间转换。

影响使用时性能的是驱动之外的部分，比如内核中的 cpu 调度器，或者 gpu 控制面板的附加功能。


平常说的更新显卡驱动提高性能，实现方式是针对特定渲染任务，采取不同的渲染参数和策略。

类比到 cpu 上，就是升级内核调度器，或者更新到新的操作系统。

我小时候也是左撇子，后来上小学被强制改了右手写字。

不过这么多年下来，除了写字已经是左右互博了。个人感觉由于文字方向是从左到右，右手写字，特别是写汉字，好处还是比较多的。写拉丁文字的话其实没什么影响。

@xvimer
看你说结巴这事，我突然也感觉这事可能在我身上也有。我倒不结巴，但是说话比较慢，经常会有一两个个很熟悉的词想不起来，同学都叫我唐僧，头像也就是这么来的。

我猜当前 cdn 服务器的缓存失效了，通过增加 _vv 参数指向不存在的内容实现重定向回源。

我不清楚七牛是如何做 ssl cdn 的，应该没有证书托管或者直接使用七牛的证书吧？具体实现就是全站 https，但是来源有你自己的服务器，也有来自七牛的服务器，各自使用各自的证书。

这种使用模式是有安全隐患的，具体可以参考我在另一个帖子 #12 的回复。

https://v2ex.com/t/201769#reply12

@remaerd

Keys 和 1Password 都用了 Core Framework，不代表两者在关键信息的内存管理方式上就是一样的。

1Password 不一定不存在数据暴露的问题。

直接使用 CommonCrypto 也可能存在数据暴露的问题，但可能性远远小于二次封装的使用方式。



内存的分配和回收不是重点，重点是数据在内存中的映射方式。有太多的方式获得内存的 Raw 数据，但这样的数据并没有实际价值，只有在其基础上获得每一块内存的数据定义才有意义。



比如 Wrapper A 的实现，某个 key 在内存中是连续 32 Bytes 存储的，应用访问它的方式是通过某个指针获得起始内存地址。对于该应用本身而言，它是不关心 key 到底在内存的哪个位置，它只要知道访问它的指针即可。

对于另一应用 B 来说，如果通过某种手段获得了对 A 内存空间的访问权限，它获取的是某个内存页面的完整信息，但并不知道该 key 到底在哪个地址上。连续 32 Bytes 有太多可能性。



对于依赖操作系统进行内存管理的应用来说，对于确定的执行流程，数据在内存中的分布有很大可能性是“可预测的”。

更大的漏洞来源于非人工内存管理带来的多重副本问题。原则上如 key 这样的敏感信息，在内存中应当仅存在一份副本，依赖操作系统对应用内存进行管理时，很可能会造成该 key 在内存中存在多个副本。攻击方寻找一份 32 Bytes 的内容很困难，但是当内存快照中存在多个相同 32 Bytes 连续内容时，提取出该 key 的可能性就非常大了。

（PBKDF 的白皮书就推荐 pbkdf() 只通过引用传递而不是值拷贝的方式来传入 passphrase，目的是保证敏感信息在内存中只存在一份）


CommonCrypto/libssl 等底层实现在内存管理上都有特殊之处，就是为了避免当运行时内存被快照化提取后，关键信息不会（轻易）泄漏。理论上内存信息泄漏了，关键信息也随之泄漏了，改变关键信息在内存中分布的目的就是：即使攻击者可以获取内存，也知道关键信息一定在这段内存里，但就是不知道具体哪一部分才是关键信息。

@remaerd

数据暴露（Data Exposure）指代的不是开源或者公开设计导致的“实现方法”泄漏，而是指具体的代码实现在使用时的敏感信息，如密钥泄漏。

密码学意义上有一类叫做 Side-channel attack 的攻击方式，很重要的一环就是根据 Data Remanence 提取敏感信息。

为什么二次封装会导致数据暴露？

以 CommonCrypto 或者 libssl（openssl 实现）为例，二者都自己实现了内存分配和回收，所有的密码学运算都是在它自己的内存空间中实现的。其它应用在调用的时候只会通过 IPC 机制获取结果，而不会，同时也不能，获取任何密码学运算的中间状态信息。即使通过 root 权限访问到相应的内存空间，也无法获知其数据结构在内存中的映射方式，因而就保证了不会有数据暴露的问题。

二次封装 Wrapper 并没有这一机制，当调用 Warpper 的时候，敏感信息在 Wrapper 的内存空间中存在，可以被多种方式获取。

Crypto 相关的代码审计是非常专业的工作，这里可能没有人有相关资质，即使有也可能没有精力关注你的个人项目。

想了解密码学相关的审计工作可以参考 OCAP 对 TrueCypte 做的审计报告。

https://opencryptoaudit.org/reports/TrueCrypt_Phase_II_NCC_OCAP_final.pdf

某种意义上说，最不能重复造的轮子就是密码学相关的轮子。





我简单看了一下你的项目，与 iMessage/1Password 的设计基本无关。二者都是项目意义上的流程设计，而非你实现的密码学方案的设计。

如果让我来描述你的项目，会是“重新封装的 RSA/AES/SHA 接口，基于 CommonCrypto”。




算法层面：

本身是源自 CommonCrypto 的 PBKDF/AES/RSA/SHA 算法，我想没有什么问题。

实现层面：

1. 随机化问题：使用 arc4random_uniform() 仅能保证随机分布，String.RandomString() 依赖外部初始化，但没有严格的 RNG（随机数生成器）。这一点几乎可以从密码学意义上判整个实现死刑了。

2. 数据暴露问题：关键信息的持久化策略，以及关键信息的运行时状态，都可以从外部轻易访问到。在敏感项目上直接使用 CommonCryto 是有原因的，这是因为它不会由于二次封装而造成信息泄漏。

其它层面：

请使用密码学术语。



这仅仅是一个非专业人员花十分钟读了下代码结构发现的问题，如果深入到代码本身上，可能还会有更多问题。



PS

作为 CommonCrypto 的 Swift 封装，这个项目还是有意义的。

如果你需要教程的话，也许这个发行版不适合你，文档就是官方网站上的手册。

这是一个以 declarative 和 deterministic 为设计思路的发行版。前者是说从操作系统，到包管理，再到应用软件都可以通过中心化配置文件来安装和配置管理。后者是说通过配置文件构建出的系统具有一致性。

基于这两个特点，这个发行版最合适的场景是一致性构建和虚拟化。

根据我一年多实验性质的试用来看，作为生产系统还比较难。主要的问题有：核心开发和社区维护都太小众，这一点非常影响稳定性与实用性，某种程度上学习曲线是阻碍其推广的一个原因。另外一点就是中心化配置管理在复杂环境中不如想象之中美好（类比一下 Windows 注册表）。

它有几个特性应该说是在所有现有发行版中最优秀的，比如配置（profile）隔离和回滚机制。另外 nixpkgs+hydra 的自动化构建平台也非常先进。

与 NixOS 最接近的发行版应该是 Gentoo，它与其他主流发行版区别还是比较大的。

@XadillaX

我重新描述下我的问题：

比如某个时间点上，你的数据库结构（schema）是 A，数据库的内容是 db(A)；

之后的某个时间点，业务逻辑更改了数据库，新的结构是 B，对应的内容是 db(B)；

这种情况下，我理解的 binary log 会记录 A -> B 的全过程，但是并不存在某个机制，让数据库事件和版本对应？

我有个两个问题：

原有架构的数据库 versioning 是怎么做的？

利用 binary log 能对 versioning 有什么帮助？（或者说，“备份”和“恢复”的主要目的是灾备？而我完全理解错了？）

irc 作为“即时通信”工具已经没有使用价值和用户基础了。

irc 作为“自动化控制”工具还健在。

以前遇到过类似的事情，现在来看还是个“流程”问题。



Github workflow 强调 master 就是可部署版本。

所以我更倾向于限制 master 的写权限。

在 master 之外建立 test 分支，可以让所有人对 test 可写，此分支的主要用途在于 CI。

只有 CI 每日构建成功的版本才会定期合并到 master，当日构建失败或者发生重大事故可以由 master 恢复，也可以无条件回滚至前一日构建版本上。

还是要坚持 Issue-PR-Merge 流程，去掉前两步看似走得快了，但是步子太大，容易扯着蛋。



我不清楚机器人账号执行写操作的具体实现是什么，但我想到几点由此带来的问题：

需要另一套日志系统记录提交给机器人的指令，或者将相关信息写入 commit log 当中。两套方案各有利弊。

github 更新可能会破坏现有的工作流程。

最后也是最重要的一点：

仍旧不能避免“推送了一个不可部署的版本到 master 分支”的问题。

Gyazo

这种由 spectrum 获取 frequency 的行为对应的数学描述是傅里叶变换，时域和频域转换，应用在音频采样上就是离散傅里叶变换（Discrete Fourier Transformation）。实际应用中的算法叫做快速傅里叶变换即 FFT。


一个 Pitch 通常包含一个最低的 base frequency，同时有多个更高频率的 overtones。求 pitch 的重点在这个最低的频率上面。（印象中这是根据人类心理声学模型得出的结论，同等功率的低频和高频信号，低频信号的心理感知强度更大。）

傅里叶变换的结果是频域函数，求 pitch 还需要对信号做分解。





至于为什么可以获得 pitch 信息，或者说如何获得 pitch 信息，下面是解释。数字信号这部分忘得差不多了，所以可能有不对的地方。


声音模拟信号经过采样和量化之后，存储方式一般都是 Amplitude - Time 形式，比如 PCM 格式。（主要是方便持久化和根据数字信号重建模拟信号）

而频率随时间会变化，根据要获取某一时刻的频率（比如 pitch）的精度，可以确定相对应的采样时长，window 函数负责将原始信号截取为各个独立的采样区间。

解析精度 frequency resolution 由信号的采样率和窗口采样数决定，比如 44.1kHz 的信号，用 8 采样的窗口，只能获得 44.1/8=5.5Hz 的解析精度，即无法分辨频率相差小于 5.5Hz 的信号。

此时的采样时长为 8/44.1=0.18s，提高采样窗口可以提高频率的分辨率，但也会增加采样时长，对于变化快的信号，采样的准确性也会下降。

还是以 5.5Hz 解析精度为例，离散傅里叶变换的结果是离散的映射关系：
F(0) 的值代表 0~2.75 Hz 信号的强度
F(1) 的值代表 2.75~8.25 Hz 信号的强度
F(2) 的值代表 13.75~19.25 Hz 信号的强度
以此类推。

如何确定 pitch 实际上是人为找到一个标准，是找 F(n) 强度尽量大的，还是找 n 尽量小的，甚至还要考虑心理声学模型的修正。不过对于“歌曲识别”之类的应用场景来说无所谓，只要前后标准一致就好了。





第二张图里某些时刻的 pitch 对应多个值，形成了竖线，我猜大概是 spectral leakage 的结果，与窗口函数的选取有关。

@johnsmith123 你这一堆问号描述了什么问题？你真就以为这是运维水平的问题？

对于运维来说，一个终极问题就是，怎么构建 bit-perfect/deterministic/reproducible 的系统。

Debian 什么情况？Debian 目前有个仅仅有个试验性质的系统，还不具备 determinism 的性质。换句话说，基本不可用。其他发行版也半斤八两。

别说操作系统这个级别，就是 chromium/firefox 这种，都很难保证二进制的一致性。

用什么系统不是问题，某些系统相对来说更容易解决某些问题。

至于某些“企业”发行版，多数时候并不是买的企业服务，而是买的硬件于是搭配了对应的企业版系统。



放到现在，多数虚拟化都转移到容器一层了，选什么系统真就不重要了。

（说句题外话，目前 docker 的后端系统官方选择是 aufs 文件系统，而 aufs 并不在 kernel 3.x 的稳定分支上，而是以第三方补丁集合的形式存在，kernel 4.x 确实集成进了 mainline 但只是 latest 分支而非 stable 分支。所以需要 docker 虚拟化的多数要自定义内核。而主流发行版里，提供官方集成 aufs 内核源的……似乎没有，Gentoo 算一个吧，但是 Gentoo 应该不算主流发行版……）



过去的话，无论哪个发行版都面临一个问题，运行时和依赖的一致性。相对来说，Gentoo/NixOS 解决这个问题更优雅一些。主流的发行版在这方面几乎都比较坑。

还是以前面 docker-aufs 为例，既然官方不提供，那么运维的工作就是，拉个官方高版本 kernel 回来，去 aufs git 源拉补丁回来。编译并启用，一切很美好。

但是等过两天，由于业务需要，运维需要在新机器上部署同样的系统。但这时候你再去拉同样的内容时，它们的版本很可能发生了变化。你可以完全忽略这种差别，但是不同机器上的运行时依赖，甚至是你部署的应用本身，都已经发生（二进制）变化了。

也许你觉得我可以拉取某个特定的内核版本，打补丁时追溯某个特定的 git commit，但这并不足够。你的工具链系统可能随着系统的更新而变化，多数发行版的 stable 只是更新比较慢并不代表不更新，更何况很多时候需要及时部署安全补丁，在源一致的基础上，工具链和依赖也要保持一致。