tinyproxy 一点都不 tiny,每条连接起一个进程，每个进程占几兆内存，绝对是吃内存的货。路由器上跑这个，内存小了肯定不合适。

单进程单线程 600 万订单每秒？真的假的啊？

看你对"懂"这个字怎么理解，我的理解是:懂=别人问不倒你=完全掌握

1.有没有定接口协议？
没规范，那是规范制定上有问题。
2.有没有经过测试？
没测试，那是工作流程上有问题。
3.如果问题 1 是 yes,2 也是 yes，那就没这个问题。
如果 1 和 2 都是 no.那就扯皮吧

"粘包"，"惊群" 都是二把刀搞出来的名词。根源在于还没搞清楚特定技术的打开姿势，就自以为懂了，出状况了又搞不清原因，就自己给起个名字。然后被其他的二把刀传播...

平板的 usb 口不能同时充电和通信

K2P A1 和 B1 版本我都有，B1 的要比 A1 的信号强很多

rc.local 第一行运行 export http_proxy=xxxxx

树莓派，crontab 定时 rsync

@whypool 可以编译 就是麻烦点。
可以考虑 linux deploy, root 启动，开个 openssh,相当于在手机上跑 vps 了，debian9 centos7 ubuntu 都有

京东搜 易驱线

我觉得很好看，看搞笑片难道还要看是不是符合现实逻辑么？看电影不就是要离开现实两小时么？

看多大数据了，aws 数据中心传数据是装一卡车硬盘拉到下一个数据中心。

说头文件是接口约定，只是一种方便理解的说法。这些东西完全可以复制到.c 里边，然后扔掉头文件。
但是这个约定还是在的，貌似大家都管他叫叫 ABI。

1.编译过程
把 .c 源代码编译成机器码，名字是.o
2.链接过程
把编译好的各个.o 文件链接成一个可执行文件
3.
每个.c 编译过程都是独立互不相关的。也就是说，编译器编译 a.c 的时候编译器不知道有 b.c 存在，编译 b.c 的时候编译器不知道有 a.c 的存在。

基于以上关系说明，问题来了:
=> a.c 里使用了 b.c 里的一个函数，编译器编译 a.c 的时候不知道有 b.c,咋办？

编译器采取了一个办法:
1.使用一种约定，来描述 b.c 里边 a.c 要使用的函数，编译的时候根据约定生成调用指令。
2.让链接程序根据这些约定把 a.o,b.o 链接成可执行文件。
这个约定是什么？就是.h 头文件里的结构声明和函数声明。

初衷是好的，但是一旦有了这个不受监管的能力，就什么东西都上去了。
所以到最后会演变成另一个黑暗的东西。

你说的东西已经有过了，而且很完善。但是已经变成另一个样子了 ----暗网

随便弄个笔记本，再了解一下 virtuozzo

都周末还不挪，还等几天啊？等夏天过去了？

我的环境:笔记本自带 win10,nvram,uefi 引导。
添加一块 m.2 ssd。
光盘引导安装 opensuse,选择安装到新装 ssd 上。安装完后 uefi 自动从新 ssd 引导，启动时会有 win10 启动项。双系统完全正常。