256g wifi 够用了。cellular 不清楚。

接楼上的评论，你需要面向对象…（如果你平时积累 c 的数据结构“类”，你照样可以写得很开心。什么你不会写 c 面向对象？！）

@murmur 普通用户也许就忍着不换铃声了…换铃声不是刚需

那当然是因为“流”比“块”更底层啊。

楼主你以为 UDP 是发了多大的块，就接收到多大的块嘛？ IP 协议允许的包大小不超过 64K，但实际中不一定能达标。而且事实上这个 64K 打包会发生分片传输，实际的包传输大小也不过几百字节。

https://en.wikipedia.org/wiki/IP_fragmentation
https://stackoverflow.com/questions/3712151/udp-ip-fragmentation-and-mtu

而且就算 IP fragmentation 默默地帮你搞定了重整，性能也实打实损失了的。
- - - -

总结一下，IP 协议中的“分块”是 IP 协议根据大部分传输介质的性质定出来的 IP 协议实现的标准，本身对于上层应用具有很有限的参考意义。由于 IP 包传输过程中大小不确定、分片机制不明，对于上层应用而言，“流”才是比“包”更底层的模型。

都 8102 年了，为啥不用 Babel 和 ES6 ？完整 class 语法。。。

@sadhen 不过其实我写公式可以一下子写一大串的，频繁上屏反而降低输入速度，感觉 TeXmacs 这点就不太友好了。。。

@sadhen 嗯，我又倒回去用了用 TeXmacs，发现原来触发转义序列上屏的是回车而不是空格，之前一次使用没发现。。。好吧，这样的话 TeXmacs 的公式编辑还行。就是复杂公式不太容易微调，是个问题。

话说我用过 GNU TeXmacs，感觉它不兼容 LaTeX 是致命缺陷。毕竟它自己的排版能力很弱。。。

另外它的公式编辑体验也不算太好。新型工具比如 Typora 的公式编辑体验就能超越它。

看着公式对照 API，可以理解一大部分奇怪的技巧。比如：

为啥用 tf.nn.log_softmax 而不是 tf.log(tf.nn.softmax) ? 因为 exp(x_i)/sum_j(exp(x_j)) 有可能因为 x_i 普遍偏大而 exp 溢出。但 log[exp(x_i)/sum_j(exp(x_j))] = x_i - logsumexp(x)，而 logsumexp(x) = x_max + log[sum_j(exp(x_j - x_max))]。这么一变换，所有 exp 项变成 exp(x_j - x_max) 之后，exp 相都小于 1，就不溢出了。

楼上+1

np.where

@Droi 大哥，楼主他不是 mod 出问题了，是 owner 出问题了。

没救了，重装吧

我和楼上喷楼主的姿势不一样：楼主你都找的什么野鸡代码学习研究，现在 Python23 兼容的库和代码一抓一大把，Python3 新特性的代码也不少。你什么关键词才搜到了只在 2 下运行的老代码呀？

@sunsol 按你这定位才要凉，连 Canonical 都凉了。Deepin 显然是真正奔着办公娱乐去的，才不想窝在社区里面，是想要商业化的。只不过任重而道远。

@cnt2ex 是不是你服务器没配置好。ip forward 开了吗？

sysctl -w net.ipv4.ip_forward=1

这条要每次启动运行。

@cnt2ex 他没说错，你还是脑筋太死，或者没理解透。

路由表不是规则顺序匹配，而是最大前缀长度匹配。你不想某些地址走默认路由，就加一条更长的规则覆盖默认规则呗（比如我上面给的方案）

你先瞅一眼你的 default 和你的 vpn 路由是怎么写的，一般来说像这样：

default via XX.XX.XX.XX dev ethX onlink
192.168.200.0/24 via YY.YY.YY.YY dev vpn0

然后你瞅一眼你的 VPN 服务器 IP 是啥，比如 ZZ.ZZ.ZZ.ZZ

然后：

ip route add ZZ.ZZ.ZZ.ZZ/32 via XX.XX.XX.XX dev ethX onlink
ip route add 0.0.0.0/1 via YY.YY.YY.YY dev vpn0
ip route add 128.0.0.0/1 via YY.YY.YY.YY dev vpn0