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 不拿事，研发和运维扯皮，还没个人能断案···好惨

你试试养芦荟吧，我深圳那堆芦荟必须定期压制他们的繁殖，否则逆天

@echo1937 对的，不过这种会议会开得想革委会的会议那样。
发挥各自所能去提意见和建议是很好地事情，但主持会议和做协调决定的人特别重要。

所以说，兵怂怂一个，将怂怂一窝。

有个叫 a2 什么的，有 gui 的，上次在某呼上看到过，可是我一直用迅雷就没记下来

CTO 可以不懂技术细节（毕竟技术日新月异），但应该懂技术选型和方案规划，还有架构，当然最重要的是协调能力和沟通能力。最后终极的是业务能力（对业务的理解和对业务给出的解决方案）。还要考虑 TCO （总拥有成本、维护成本）。
所以 CTO 是一个很综合的产物，不是什么人都能干的，技术人员有部分甚至大部分都存在一个问题就是技术思维， CTO 就不能有这种思维，不能只从技术层面考虑问题，也不能不考虑技术问题， CTO 就是个桥梁，就是个中间件；还有就是技术（比如开发人员）就是要精专的，难免会一根筋，这是正常的，但是 CTO 就不能这样，如果 CTO 一根筋了，就容易钻牛角尖，团队和产品就容易出问题。

哦，说运维呢·····不好意思
运维，提意见很好啊，很棒，有些 [ [ [ [ [主管 /主观] ] ] ] ] 偏向也是可以理解的，只是需要一个更棒的人，从大局角度去说服他，去反驳他，最后拍板选择一个合适的方案出来。

CTO 可以不懂技术细节（毕竟技术日新月异），但应该懂技术选型和方案规划，还有架构，当然最重要的是协调能力和沟通能力。最后终极的是业务能力（对业务的理解和对业务给出的解决方案）。还要考虑 TCO （总拥有成本、维护成本）。
所以 CTO 是一个很综合的产物，不是什么人都能干的，技术人员有部分甚至大部分都存在一个问题就是技术思维， CTO 就不能有这种思维，不能只从技术层面考虑问题，也不能不考虑技术问题， CTO 就是个桥梁，就是个中间件；还有就是技术（比如开发人员）就是要精专的，难免会一根筋，这是正常的，但是 CTO 就不能这样，如果 CTO 一根筋了，就容易钻牛角尖，团队和产品就容易出问题。

哦，说运维呢·····不好意思
运维，提意见很好啊，很棒，有些主管偏向也是可以理解的，只是需要一个更棒的人，从大局角度去说服他，去反驳他，最后拍板选择一个合适的方案出来。