@geelaw
> RSA 这个名字既可以指代使用 RSA trapdoor 的加密方案，也可以指代使用 RSA trapdoor 的签名方案。

RSA 这个名字还可以指代 RSA 算法本身。或者说，这里列出来的几个基本操作 https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Operation

> 首先你需要定义“本质”。

我原本的意思是，可以任选一个密钥来加密，用另一个密钥来解密，在加解密的过程中不需要区分哪个密钥是哪个密钥。

> 为什么不能把 RSA 加密的公钥、加密算法当作 RSA 签名私钥、签名算法，把 RSA 解密的私钥、解密算法当作 RSA 签名公钥、验证算法？

这是四个问题，其中一个是，为什么不能把 RSA 加密的加密算法当作 RSA 签名算法。
这就是楼主问的问题
对于任何一个教科书上有答案的问题，你都可以回答说“教材上是这么写的”。所以我说你的回答是正确的废话。

> 你想象中的攻击并不一定能够成功。

你好像完成不懂密码学上的攻击是什么。一个攻击成功的概率高于暴力破解的概率，就算作一个攻击了。
你可以自己写代码去试试这个方法的成功概率有多少，当然不写代码也应该知道这个方法成功的概率大约是什么水平。
如果你认为这个方式能起到签名的作用，那你真的“需要阅读密码学的教材”了

某个东西是 “ private class member ” 就不继续往下深究了，我不认可这样的学习方式。

@geelaw
你有没有意识到自己回复的内容是正确的废话?
楼主问不混用的原因，你回答说这东西就这么规定的

在 RSA 里面，公钥和私钥没有本质的区别，公开的那个叫公钥，不公开的叫私钥。用公钥做加密是加密，用私钥做加密是签名。
至于怎么规定的，那是另外一件事。规定的那个方法当然是正确的方法，但楼主问的是为什么另一种不正确。

楼主问的问题其实很简单
如果用私钥加密得到密文，然后把密文改掉，再用公钥解密。这样也可以解出来一个结果，但是这个结果和原来不一样。签名的目的是确保收到的消息正确，所以这样做不可行

这事和性能毫无关系。
类似的情况在对称加密里也有，confidentiality 和 integrity 是两件事，要用完全不同的方法来做，看看 AEAD 的实现就懂了。

@suiterchik
楼主都回帖说能用了，那当然是能用的
你加的那个 ROWS BETWEEN ... 是默认值，加不加都一样

WITH data AS (
SELECT created_at, id AS card_id, total, total AS amount FROM card
UNION ALL
SELECT transaction.created_at, card_id, card.total, -transaction.total FROM transaction INNER JOIN card ON card_id = card.id)
SELECT created_at, card_id, total, sum(amount) OVER (PARTITION BY card_id ORDER BY created_at) FROM data;

重点是 window function，sum(amount) OVER (PARTITION BY card_id ORDER BY created_at)

@trait
“不信任这些新人的内存管理水平”

1. 不是信任不信任的问题，而是手动管理内存要付出更多的开发成本，很多项目不乐意花这个钱

2. 你好像把内存管理想得太简单了。在某些情况下，即使是老人也一样管理不好内存，或者手动管理内存的运行时开销不比 GC 小
比如
https://software.intel.com/en-us/forums/intel-moderncode-for-parallel-architectures/topic/295279

这样可行，应该会比之前快。前提是线程不共用 MySQL 的 connection，并且你的 MySQL 支持这么多的连接数

更好的方法有
1. 写一句 SQL 把这 100 个操作做了，大概率会快很多
2. 不要每一句都开一个新线程，而是用一个线程池。你可以用 4 楼给的方法自己写线程池，也可以用 ThreadPoolExecutor
3. 用 aiomysql 来并发操作数据库，这样不需要开线程，但是需要大改之前的代码

顺便一说，“ mysql 不是线程安全的” 这句话 表义不明而且不对
正确来说应该是，MySQL 的 driver 给你返回的 connection 不是线程安全的（也可以是线程安全的，但线程安全的 connection 没有道理，应该不会有人去写那样的代码）
但这又是一句废话，程序里的变量几乎都不是线程安全的

在 Linux 上，这事要用 cgroups 给包加 classid，再用 iptables 加 mark，再用 ip rule 去改路由表
Windows 上应该也有类似的方法，但是做这种事情肯定比 Linux 更麻烦，如果你找不到现成的工具就只能自己去翻 msdn 写代码了
一楼给了一个工具，我没用过

我觉得在两个路由器上建两个代理服务器然后用 Proxifier 比较简单

高考的本科线通常在及格线附近，高考的题目也不属于很难的那种（比如研究生考试算是比较难的）
考及格真不是一件难事

另外一个很少有人注意到的点是，相对来说，高考对智商的要求比较高
像一般 985 这个档次的学校，通过高考考更多地需要智商，通过研究生考试考上更多地需要努力学习
所以拿本科学校 /本科专科来做筛选会很好用

YAML 好像是一个比较早出现的这种格式，看起来本来是想做得比 JSON 好写
因为出现得早，大家都在用
但是显然缺点太多了，我也觉得还不如 JSON，所以现在更多用 TOML 了

1. 原来那个 repo 里的算法毫无新意，就是自己建了一个 Hash Table 来计数
2. 楼主的 SQL 写得很怪异，建议认真学一下 SQL
3. 楼主的 SQL 写错了，原来的算法是 1|2|3-1|2 的相关性大于 1|2|3|4-1|2，这条 SQL 的结果应该是反的

1. 在理性的情况下，知道更多的信息只会有好处
2. 如果员工是理性的，公开工资对员工只可能有好处
3. 如果给定蛋糕的大小不变，那么员工得到好处意味着对老板有坏处
4. 如果员工不理性（不患寡而患不均），显然公开工资对老板有额外的坏处
所以一般来说老板不希望员工互相知道工资

上面这个推理只用到了一个假设，蛋糕的大小不变
所以这里的关键问题是
如果公开了工资，员工的产出能增加多少？

LeanCloud 的老板认为产出能增加很多，所以公开了工资
但这不是一个共识，所以这种制度没有被广泛采用

再往后继续讨论就复杂了，现实情况是
LeanCloud 经营了好多年了，没听说员工都心里不平衡而走掉
要求工资保密的那么多公司里，嫌工资倒挂心中不平应该是常见现象

对于楼主的情况来说，明显是招聘方占理

这道题的最简单的解法是写两个循环，毫无技术含量。显然存在更好的算法，而且更好的算法也不难
如果一个应聘的人只会这个解法，那我觉得这是一个初学编程的人，不是一个有五六年工作经验的人

如果像另一个帖子一样说让手写 SHA1 算法，应聘的人写不出来，那当然是应聘方占理了

这种事情在 Ubuntu 上搞是 Hard 模式了，你到 Gentoo 上或者 Arch Linux 上来做容易得很
比如用 Arch Linux 的现成的脚本
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/linux

"微信通过基金资金进出容差赚取到了利润覆盖了还款成本"

除了微信，我就没见过信用卡还款要收手续费的地方
比如跨行异地在自助机器上的现金操作几乎一定有手续费，但如果是信用卡还款就不用
显然微信只是不想让大家把钱取走，和成本毫无关系

@passerbytiny

这个我也可以复现，看起来像一个 curl 的 bug，他的网站还专门写了 “ When the set time has elapsed, curl will exit no matter what is going on at that moment ”
V2EX 说“请不要在每一个回复中都包括外链，这看起来像是在 spamming ”，所以没有加上链接


可以给你另找一个

```
package main

import (
"context"
"log"
"net/http"
"time"
)

func main() {
req, err := http.NewRequest("GET", "url", nil)
if err != nil {
log.Fatal(err)
}
ctx, _ := context.WithTimeout(context.Background(), time.Second)
req = req.WithContext(ctx)
_, err = http.DefaultClient.Do(req)
if err != nil {
log.Fatal(err)
}
}
```
把 DNS 设成不能用的服务器之后，这段 Go 的输出是
$ time ./timeout
2018/09/11 03:56:53 Get url: context deadline exceeded
./timeout 0.00s user 0.02s system 2% cpu 1.020 total