非常支持.
之前就是产品运营软肋, 各种临阵抱佛脚也没用.

@nicai000
C程序员Go, C++程序员Rust +1

@whatisnew ... 不好意思, 我是开玩笑的 ... 请无视 ...

不要 b 格你为什么不买神州?

哈哈哈哈, 看到结尾释然了, 第四题的时候, 我也突然心中一凉...

英语, 不开玩笑.

嵌入式在深圳大概比较好, 做硬件创业的多一些, 生态链成熟一点,
等你搞几年出来, 智能家具之类的概念大概会比现在还要火.
(大环境都是捕风捉影, 不过可以确认一点, 嵌入式要比运维好玩..)

没主意你发在 java 节点, 那就是 android 移动端咯...
"不太适合"之类的当我没说吧...

如果你要插入一个 md5 到最前面, 那确实是不行的.
不过你可以考虑传结构体, 想设计一个流芳百世的接口, 就是传单结构体...
你看微信 sdk 接口那样...

另外, 我现在说 thrift 不太适合做客户端到服务器端通信还来得及吗?
https://semicircle.github.io/blog/2015/01/19/thrift-get-away-from-pitfalls/

@dwztom 我也母鸡啊~

@wy315700 什么样的 DNS ? 我这总是烧流量也不是办法.

@riaqn 我的基础知识也喂狗了, 不是 .data...我的意思是所有运行时数据, 包括 heap, stack 这些...

说宽带问题要说你所在的城市, 不同城市是完全不一样的...

做一家韩式料理, 请个顶级欧巴代言, 开在南京, 大约是靠谱的.

正在用北京移动 700+ 2年. 真实体验是:
国际出口爽到爆, 国内出口烂成渣.
因为国内烂, 所以像新浪这样的网站, 我都在路由器上配的 shadowsocks.

@riaqn
@tabris17
1. 线程切换不需要切 TLB, 至少 Linux 是这样, 如果 Windows 不是这样, 那就太颠覆了...
2. 对进程而言, 不同进程的数据段(.data)肯定不在一起, 增加各种 cache invalid 的概率, 甚至到虚拟内存. 线程的数据段肯定是尽量拼在一起的, 会减少这些发生的几率.
3. 两者相同的开销也有很多, 比如都要陷入内核, 保存寄存器状态等. 所以究竟上述开销能不能"忽略不计", 我觉得需要量化评价了, 不同处理器架构肯定不同. 而且, 要面向具体问题, 比如说 内存, CPU Cache 超大, 原超应用所需内存的场景, 在这种极端情况下, TLB 什么的也根本不重要了.

主观上, 我觉得这个两种的区别一般是不能忽略不计的.

同意太低频，必须是整合在某些其他基础服务里其他的一项。
比如是一整套宠物healthy解决方案，一个智能项圈，加上手机上一个app, 检测心跳，血压，每日运动量什么的。这样定位找回只是其中一个功能。高频比低频容易成功。
第二点是还要有fun, 毕竟很多人自己都不太在意healthy的，集成个go pro, 加个夜间遛狗跑马灯什么的，狗狗一跑起来，各种酷炫。
最后，还可以加点刚需，比如犬吠的时候电一下什么的。
楼主你为什么不牵好狗？？？！

@rommelji 未来就大众啦 https://gigaom.com/2015/02/23/microsoft-is-building-fast-low-power-neural-networks-with-fpgas/

和osm系那些是一路的吗？包括，mapbox之类，我看到的也是个类似GIS的东东

和openstreetmap系