我觉得我的魔力鸭的带灯茶轴蛮好哒 ：）

Parallels 只做 Mac 上的虚拟化 估计也没有什么业级的产品~ 光靠普通消费者领域的产品在这个相对小众的领域维持估计也蛮难的~ 所以只能一遍一遍割肉了 ：）

VMware 是靠企业级的虚拟化产品赚钱，只 workstation 和 fusion 一年也不挣什么钱~

我觉得IT行业就应该在这些地方发展啊~ 无污染，能耗低，高产值~~

应届硕士这个时候不是应该在使劲刷题，看算法，看面试宝典神马的么？不然那些大公司的笔试都过不了，这简历有毛线用~

@n0o0a0h0 然后了？

《血族》
《美国谍梦》
《终结者外传》
《权力的游戏》

看了这个帖子突然感觉世界变化快，若干年前，希腊这种也是老牌发达资本主义国家，如果移民去，那肯定是一边倒的支持~

lz 求指导如何搞到妹纸~

两个都买好了~ 加起来也不过一个 肾六 左右~

@matsuijurina
深有同感。。。

面试的时候碰上大雨，还没拿伞，幸运的是正迷路的当口，碰到一个很好的妹纸给指路；湿漉漉的赶到面试公司后，面试官还帮忙拿了纸巾擦水，蛮感动的~ 哈哈

@est 这是计算RTT（超时重传时间）的方法，似乎也有可能，sender第一次发包，接受者没收到，然后超时重传了一遍，接受者就收到了，但是这个情况偶尔一次 两次还可能，可lz说了“并且一旦出现该现象，之后的数据收发，即使发送数据量很小，也会存在 200ms 延迟”，感觉不像啊~

@flewover 还是截个包最清楚，debug 网络的issue，截包是最直观的方法~

@flewover
感觉是发送端23:40:19.833才把包发出来~

@flewover
看文档确实不会超时~~

那或许需要wireshark之类的东西截个包看看~

@flewover
你这跟tcp栈没关系吧~ 看log
2015-05-20 17:34:44.418 [DEBU] ac05 [handleTCPConn] before read
2015-05-20 17:34:44.621 [DEBU] ac06 [handleTCPConn] end read
这两条记录中间应该是
rlen, err := rd.Read(rbuf[:])
吧？

我不懂golang的这个接口， 猜想bufferReader在等数据填满它然后返回或者超时（200ms）返回。所以你发包小的时候，它总是需要超时才能返回~ 于是就有了200ms的延迟

哈哈 这个帖子太搞笑了~
不过我是真的从“程序员穿什么衣服”帖子里得到了很多有用的信息，比如现在基本一身优衣库。。。。
所以有的月经贴还是蛮有意义的~

看着很靠谱啊！

支持remote的职位~