我就问问有几家国外 vps 提供商不是双向流量计费

昆明电信正常

xubuntu

@XGHeaven 算是个约定俗成，就像 c/c++/java 中的缩进，就算你不遵守也不会怎么样

@XGHeaven 在任何系统下，代理设置都是由应用决定是否采纳，所以要想真正的全局代理要不然劫持系统 socket api 要不然就是用虚拟网卡 tap/tun 来做
而 pac 一般情况下只会影响系统自带应用以及 chrome，其他程序基本上不会读取 pac 设置，而在终端下，几乎任何程序都不会理睬 pac 设置。

@Hellert 很正常，很多程序根本就不会检测 http_proxy 和 https_proxy 这两个环境变量的，这个是取决于程序用的 http 类库，很多语言集成的 http 类库，以及一些人自己写的小 http 类库是完全不会理这两个环境变量的

@hp3325 除了 5.5×2.1/2.5 的接口，那玩意从 5v 到 19v 各种电压的都有，万一插错了爽歪歪

@xiaoz dd 容易发生硬盘大小不完全匹配就蛋疼了

然后楼主的 mac 就蓝屏了😎

为什么用 rsync 的话，“后续还的重新配置、编译”？
你直接 rsync 根目录不就行了，然后等你的新阿里云服务器好了安装一样的系统，再 rsync 回去不就得了

有没有打算支持一下直接编译到 c 或者汇编。

前排支持

@xinhugo 你需要买高通 cpu 的机型会更新的快一些

@ryd994 个人感觉 vla 算是对 sizeof 的一个特例（也是有些编译器死活不愿意支持的原因），在排除 vla 的情况下，sizeof 的结果应该就是一个编译期间可以确定的参数。
这个情况就类似于 c++的虚函数导致了需要编译器必须实现一个虚表来间接获得函数入口地址，而正常情况下函数的入口地址应该在编译或者链接期间是一个确定的值

@zhicheng 你这个代码在不同的平台上不一定内存占用的一样，因为 long*和 long[0]占用的内存并不永远是一样的

试试 /t/401630

@LeonLi
@XiaoxiaoPu
对于你们说的 sizeof 的问题插个话，这个地方完全是编译器实现的问题，在你用 int arr[10]这样定义的时候，sizeof(arr)编译器是完全能推断出来 arr 的 size 的，而如果你用动态分配的话，编译器只能知道这个指针本身多大，根本没办法知道这段内存地址的结尾在哪里，因为那个只有 malloc 的实现（ glibc/msvcrt/...）才知道
sizeof 运算符本质上就是一个预处理，在最后程序编译完了之后就消失了，被直接替换成具体的值了，所以 sizeof 所能得到的大小一定是可以静态推断的，这也就是对 std 容器进行求 sizeof 基本上毫无意义的原因

@billion 你就不能装一个 iptables 么……………………

@billion 你要在能上外网的那台机器上配置 iptables 转发的