看你是哪里人了，带点地方特色的饰品摆件。
比如北京的京剧脸谱就不错

或者你了解一下对方家庭的环境和氛围怎么样，有没有特殊爱好，去买一两本有中国特色或者有纪念意义的邮票。

家里人一起，给录一段视频，表达一下谢意和婶婶的祝福，『假假』得邀请他们来中国玩等等都可以嘛。只要有心就好啦

你是用串口跟单片机通讯是么？
波特率和奇偶校验设置对么？

还有要确认一下单片机的串口是不是 TTL 电平？如果是 TTL 电平的话你可能要用转换器转一下。

如果都确认没问题，那你就先别用 pyserial 了，用 minicom 之类的先测试一下。

甚至你可以试试用 cat /dev/ttyUSB0 ，看对端有没有数据过来。

如果 minimum 没问题，你再回来检查这个 pyserial 写入数据的时候是不是跟对方协商了结束符，就是对方在等待你输入结束的约定符号，只要没有这个符号，就会一直处于接受状态。比如很常见的用换行符作为结束开始收发切换。

缩进问题，没法判断你的 py 的执行逻辑， read 是在循环内还是循环外啊？

@matthewgao 可别的网站很正常，一点不卡不顿，下载也够快。
hosts 里也没别的设置，也换过 DNS ，奇了怪了

同花顺，新版的看着还行，不过开发速度有点慢，目前只支持行情，不能交易

LZ 你 cat /proc/cpuinfo 看看是什么平台的，然后去网上找一下这个平台的开发包，一般 arm 的话如果是方案板一般都会有标准开发包和内核配置文件的。（这个开发包就是一个 tool chain ）

@LioMore 可能不是空间不足，应该是只读文件系统，挂载的其实是一个 ramfs 之类的。
你看看它有没有系统更新系统升级功能，弄一个系统镜像来分析，最后你要改东西也得改好了让它自己更新，跟刷机差不多。

调他去电信就是为了这个事儿啊。
把他调走就可以做联通的清查审计了，只要找到证据就可以拿人了。

能传东西进去么？自己建立个交叉环境，静态编译，扔上去。
不过你用着踏实么？

客户忽略 USB ，因为对你来说就是一个串口，你用 pyserial 去操作串口就行了。

上面这个方式，还有一个好处就是可以在 MQ 和 WORKER 这两个地方加插件，比如做统计分析、安全检查、数据拦截之类的。

蛮好的，对外，特别是大项目，对程序员的要求就低了，拿文档一看，甚至那 json 一看就知道这个接口怎么用。
而数据结构和对象关系只需要那个读写数据库的 ORM 去维护就可以了，别人不用管。

至于这个读写数据库操作的东西其实还可以加一个 MQ ，前段 NGINX 之类的带一个动态语言去处理 HTTP 请求（这部分是不是可以叫做 CGI 了），然后丢到 MQ 里，后面一堆 worker 从 MQ 听消息存取数据，然后反馈到 MQ 里，前面 HTTP 拿到反馈就给客户端。
这样这个 worker 就可以横向随便拓展了，谁负载低谁就先拿走消息去处理并反馈。
处理 http 的 nginx 也可以随便横向拓展，用 DNS 轮训或者其他 HTTP 负载均衡技术就可以解决。


DB<----->WORKER<------->MQ<------->HTTP （ CGI ）<------->NGINX


这个 HTTP （ CGI ）主要是轻量级，它不操作数据库，只负责做 MQ 的消息转发，所以很轻量化，甚至可以用静态语言去写，或者封装到 NGINX 里面去，所以这部分性能可以压榨出来。

后面的 WORKER 压力会比较大，所以让它能支持横向扩展才行，不过会有一个数据库锁的问题，如果碰上了锁，性能就不好办了，所以后端数据库优化要根据业务具体情况来做。

@SpicyCat 大公共的排放真心不达标，别说具体去测，就是看烟尘排放就能看出来，如果是经过过滤处理的，绝对不可能黑兔兔一团冒出来的。
其实大公共早该改成电动的，部分远的线路没办法。

限行，在北京交强险之类的是有折扣的，会把限行的天数扣除掉。

确实整体看来就是个懒政。

Redhat 7
Fedora （那天晚上发布 alpha 版的时候在线等着，然后 BT 做种）
debian
ubuntu
Gentoo
LFS
然后就 uboot 嵌入式了

太长，我就不参与了。

1 、你的路由器做 NAT 转去、或者能做透传
2 、拿个笔记本直接连网线


我家光猫是 root 过的，下面有 4 个设备，并且都各种拨号，所有有时也需要上光猫去做一些设置（因为有 IPTV 在），我通常是选择拿个笔记本去接网线。（其实我那个光猫支持 WiFi ，但我不希望打开它。）

@echo1937 嗯，支持。
不过还有一个现象，就像那句，铁打的营盘流水的兵。最初技术部门成立的时候，第一任 CTO 就已经决定了这个技术部门的风格和作风。 CTO 天天忙到咳血，谁不主动自觉完成自己任务再回家，等这个 CTO 咳血死了，殉职了，再换 CTO ，那这个作风应该是会被延续下去的。因为大部分人都已经养成了这个习惯和思维，新人是会被同化的。

至于前期不规范，每个团队都会有这个过程，但是格局一定要有，就像我们现在的网站就几万 PV ，那我们的架构规划也应该考虑到日后上亿的 PV 的情况，我们要提前去考虑将来要过渡到那个架构怎么能更顺滑，有经验的架构师就知道怎么做伸缩预留，就知道用虚拟化之类的手段去提前布局对吧？所以讨论环节其实 CTO 就可以把架构定得更高，预留更多空间，以免扯皮。

哈哈，他们这也够逗的， CTO 不拿事，研发和运维扯皮，还没个人能断案···好惨