BRCM裁20% - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>EE - 电子工程

BRCM裁20%

BRCM裁20%# EE - 电子工程

w*o2014-07-22 07:07

1 楼

【以下文字转载自 Stock 讨论区】
发信人: walstudio (午夜未眠人), 信区: Stock
标题: 问个ES保税的问题
发信站: BBS 未名空间站 (Sun Apr 10 13:25:48 2011, 美东)
去年刚开始玩ES，看了一些介绍，好像ES的税跟普通的Stock/Fund是不一样的，
Stock/Fund是用Schedule-D,ES是用Form 6781(Section 1256)按照60%/40%的
longterm/shortterm Split的。
但是TurboTax上好像没有看到怎么处理的，大家报过的是怎么弄得?

s*02014-07-22 07:07

2 楼

在160表上，反签的需要天国内的身份证号码吗？好像早就没有拉阿？

d*d2014-07-22 07:07

3 楼

【以下文字转载自 Fashion 讨论区】
发信人: tongice (猪猪), 信区: Fashion
标题: Re: 闲着没事来贴图
发信站: BBS 未名空间站 (Fri Oct 28 09:13:08 2011, 美东)
9：
淘宝开衫背心，裙子是river island，鞋子在上海的商场买的。
10，11
淘宝的开衫，连衣裙，鞋子
12，13：
淘宝的帽子，蕾丝罩衫，长裙，tory burch拖鞋
14：
淘宝的背心，美国outlet买的BB裙子，tory burch拖鞋
15：
淘宝的上衣，裙子是H&M的，也是淘宝找的代购。

m*62014-07-22 07:07

4 楼

x*i2014-07-22 07:07

5 楼

据说有不少保姆利用职务之便害死了很多老人，真是耸人听闻。他们具体的作案手法是
，通过给老人灌敌敌畏毒死老人，原因是家政行业的有一种惯例：如果在这个月内，老
人死去，那么陪护老人的保姆同样可以获得这个月的工资；于是，有些保姆希望通过杀
老人的方式提前结束工作，而且能够保证这个月的工资可以拿到。经调查，为了拿工资
竟然是保姆杀人的原因。看上去，保姆是杀人犯，应该处以重罚。可是，我们细细想想
，到底谁才是真正的凶手。为了尽快拿到一点儿钱，可恶的保姆居然敢杀人，而且连续
不断地杀人，甚至成瘾。为了钱，他们什么都不顾了，不顾法律，不顾自己的孩子和家
人，不顾尊严。他们宁愿失去所有都敢于去杀人，冒着巨大的风险。因为金钱可以买到
很多东西，可以满足衣食住行，可以买更好的衣服，过更好的日子。可有了这些，人就
幸福了吗?显然不是，物欲横流的时代和商品经济不断把人的目光聚集在金钱上，没有
钱没法活了。没有钱买不到东西，被人笑话。大家都买，我没有钱买看着多不好。保姆
杀人当然有某种个人的情绪色彩，但我觉得从根本上来看是这个物欲的时代惹的祸，金
钱扭曲了人的心理。

p*22014-07-22 07:07

6 楼

今天conference上根本没人用，都用Clojure的Storm。

m*t2014-07-22 07:07

7 楼

基带没找到买家。希望对板上兄弟影响不大。不过可以跳槽到三爽和苹果，也未必是坏
事。

r*y2014-07-22 07:07

8 楼

第一个橘红色裙子挺好。

l*o2014-07-22 07:07

9 楼

可以买啊

h*y2014-07-22 07:07

10 楼

钱的事也得看人

m*t2014-07-22 07:07

11 楼

什么conference? 给个link吧

c*e2014-07-22 07:07

12 楼

我超喜欢啊。

【在 d********d 的大作中提到】

: 【以下文字转载自 Fashion 讨论区】
: 发信人: tongice (猪猪), 信区: Fashion
: 标题: Re: 闲着没事来贴图
: 发信站: BBS 未名空间站 (Fri Oct 28 09:13:08 2011, 美东)
: 9：
: 淘宝开衫背心，裙子是river island，鞋子在上海的商场买的。
: 10，11
: 淘宝的开衫，连衣裙，鞋子
: 12，13：
: 淘宝的帽子，蕾丝罩衫，长裙，tory burch拖鞋

m*62014-07-22 07:07

13 楼

just minutes ago, how many shold we buy?!

【在 l*****o 的大作中提到】

: 可以买啊

c*o2014-07-22 07:07

14 楼

comparison of akka/storm/finagle
http://blog.samibadawi.com/2013/04/akka-vs-finagle-vs-storm.htm

Y*22014-07-22 07:07

15 楼

fuck Japan!

h*e2014-07-22 07:07

16 楼

usmint?

【在 m******6 的大作中提到】

: just minutes ago, how many shold we buy?!

p*22014-07-22 07:07

17 楼

http://www.bigdatatechcon.com/SanFrancisco2013/index.html

【在 m******t 的大作中提到】

: 什么conference? 给个link吧

d*d2014-07-22 07:07

18 楼

不愧是丫头

【在 Y*****2 的大作中提到】

: fuck Japan!

m*62014-07-22 07:07

19 楼

yes.

【在 h***e 的大作中提到】

: usmint?

m*t2014-07-22 07:07

20 楼

多谢

【在 p*****2 的大作中提到】

:
: http://www.bigdatatechcon.com/SanFrancisco2013/index.html

K*a2014-07-22 07:07

21 楼

那我fuck japenese..

【在 Y*****2 的大作中提到】

: fuck Japan!

h*e2014-07-22 07:07

22 楼

恩，好deal

【在 m******6 的大作中提到】

: yes.

w*z2014-07-22 07:07

23 楼

二爷来弯曲指导工作了？

【在 p*****2 的大作中提到】

:
: http://www.bigdatatechcon.com/SanFrancisco2013/index.html

Y*22014-07-22 07:07

24 楼

you wish!

【在 K*a 的大作中提到】

: 那我fuck japenese..

d*j2014-07-22 07:07

25 楼

thanks for the heads-up

z*e2014-07-22 07:07

26 楼

我觉得这篇文章讲得很不清楚，只是单纯滴比较
没有实战价值
不过看评价缺点还是很有启发的，跟我猜的差不多
主要问题就是
hadoop慢
我们用hadoop是因为没有选择
而且hbase存文件容量比较大，能放得多
但是并不代表我们不能自己动手做优化
实际上cap理论里面，hbase就牺牲了a
这个就意味着总是很慢，但是慢没有关系，可以优化
其中一个优化手段是参考传统db建view的方式
找一个db，做预处理查询，把结果存在某一个查询快的角落
比如内森用的elephonedb，db牺牲的是p，没有牺牲a，所以快
然后storm放到前端用来处理最近时间段的数据
persistence这个时候就不能再用hbase了，慢
所以上cassandra，我总是很喜欢cassandra
cassandra牺牲的是c，没有牺牲a，所以快
然后并发存取，并把历史数据存到hbase里面去
这样通过三个不同的数据存储方式hbase，db和cassandra
分别对应历史数据，历史数据视图和即时数据存储
就能解决hadoop慢的问题
绕了这么一大圈就是因为hadoop慢
storm帮忙做了不少事，但是如果换成akka
那你就要从线程写起，效率差很多
storm安装好就能用了，很多工具可以马上用
差别就类似java Execution类和tomcat的区别

【在 c******o 的大作中提到】

: comparison of akka/storm/finagle
: http://blog.samibadawi.com/2013/04/akka-vs-finagle-vs-storm.htm

a*y2014-07-22 07:07

27 楼

腿上好多疤。。。。。

m*62014-07-22 07:07

28 楼

i believe the price can't be further lower, so, it is a good IN opportunity.

【在 h***e 的大作中提到】

: 恩，好deal

c*o2014-07-22 07:07

29 楼

你说的太局限，本来storm 就是专业做那个的。
看这个
http://stackoverflow.com/questions/4493001/good-use-case-for-ak
我们就是
Service backend (any industry, any app)
* service REST, SOAP, cometd etc
* act as message hub / integration layer
* scale up, scale out, fault-tolerance / HA

m*y2014-07-22 07:07

30 楼

那我倒没有看到

【在 a********y 的大作中提到】

: 腿上好多疤。。。。。

h*e2014-07-22 07:07

31 楼

银子回到35以上的话那帮孙子就要涨价了

opportunity.

【在 m******6 的大作中提到】

: i believe the price can't be further lower, so, it is a good IN opportunity.

z*e2014-07-22 07:07

32 楼

你这个，我实话跟你说
我们这边专门搞web service的
rest和soap，随便一个软件都可以做，而且可以做得很有效率
比如ejb，一个annotation就搞定了
不用akka反而更好，更通俗易懂，用了lib，代码也不用写多少
message hub的话，jms其实比web service更有效率
我说的这两个，都跟scale up/out不冲突
无论哪一个选择，都可以实现scale up/out，都有非常多现成的例子
实际上这些东西本身就是用做scale up/out的
否则也不需要这些东西，它们专业做这个的，尤其是jms

【在 c******o 的大作中提到】

: 你说的太局限，本来storm 就是专业做那个的。
: 看这个
: http://stackoverflow.com/questions/4493001/good-use-case-for-ak
: 我们就是
: Service backend (any industry, any app)
: * service REST, SOAP, cometd etc
: * act as message hub / integration layer
: * scale up, scale out, fault-tolerance / HA

r*y2014-07-22 07:07

33 楼

我也看到了。我觉得好奇怪。。
是不是 sm 弄的？

【在 a********y 的大作中提到】

: 腿上好多疤。。。。。

A*t2014-07-22 07:07

34 楼

赞，每天都是最低价。

opportunity.

【在 m******6 的大作中提到】

: i believe the price can't be further lower, so, it is a good IN opportunity.

z*e2014-07-22 07:07

35 楼

jboss做seam提出一个概念我很喜欢
它们认为，将来这些东西，都应该做成一个一个组件
随时可以拆装，而且可以替换
这其实是软件工程最理想的境界，我从进入软件工程这个领域的那一天起
就冲着这个目标在努力
你们集成的系统还不够多，还不够大
慢慢做，做到一定程度，你们会有阵痛

【在 c******o 的大作中提到】

a*y2014-07-22 07:07

36 楼

小朋友知识很丰富捏

【在 r*******y 的大作中提到】

: 我也看到了。我觉得好奇怪。。
: 是不是 sm 弄的？

m*62014-07-22 07:07

37 楼

if there is no major event, i believe this is the bottom.

【在 A*********t 的大作中提到】

: 赞，每天都是最低价。
:
: opportunity.

N*m2014-07-22 07:07

38 楼

这仨都不是一种东西，干嘛橘子比苹果？

【在 c******o 的大作中提到】

: comparison of akka/storm/finagle
: http://blog.samibadawi.com/2013/04/akka-vs-finagle-vs-storm.htm

c*e2014-07-22 07:07

39 楼

嫉妒使女人魅力。

【在 a********y 的大作中提到】

: 腿上好多疤。。。。。

b*l2014-07-22 07:07

40 楼

一下降了50刀，不少啊。

c*o2014-07-22 07:07

41 楼

就是说不一样，根据需要选不同的用
没有替代和可比性
zhaoce就没看眀白
在 Nehalem (Nehalem) 的大作中提到: 】

r*y2014-07-22 07:07

42 楼

我不是小朋友。
哼

【在 a********y 的大作中提到】

: 小朋友知识很丰富捏

A*t2014-07-22 07:07

43 楼

Ok ok.

【在 m******6 的大作中提到】

: if there is no major event, i believe this is the bottom.

N*m2014-07-22 07:07

44 楼

赵策看不明白很正常

【在 c******o 的大作中提到】

: 就是说不一样，根据需要选不同的用
: 没有替代和可比性
: zhaoce就没看眀白
: 在 Nehalem (Nehalem) 的大作中提到: 】

c*e2014-07-22 07:07

45 楼

那我好好再看看

【在 r*******y 的大作中提到】

: 我也看到了。我觉得好奇怪。。
: 是不是 sm 弄的？

c*n2014-07-22 07:07

46 楼

下单入了一块

【在 h***e 的大作中提到】

: usmint?

z*e2014-07-22 07:07

47 楼

谁看不明白，我一开始就说了类比
还是放在最后一句来点睛
但是不可否认的是，很多东西虽然用处不同
但是在某些领域
是可以互相替换的
这个明明是你们没看明白
或者说你们不愿意看明白

【在 c******o 的大作中提到】

: 就是说不一样，根据需要选不同的用
: 没有替代和可比性
: zhaoce就没看眀白
: 在 Nehalem (Nehalem) 的大作中提到: 】

c*e2014-07-22 07:07

48 楼

着白白嫩嫩的。。。。看来全市嫉妒与惠榜。

【在 c********e 的大作中提到】

: 那我好好再看看

l*i2014-07-22 07:07

49 楼

太扯了
hadoop和storm相比，最麻烦的不是慢，而是很难定义连续长期持久任务，另外是中间
文件必须过磁盘IO导致的延时。
hbase和cass虽然确实c/a牺牲得不同，但对存取影响差别不大。没听说过任何一家把
hbase和cass作为上下级存储的，因为性能梯度差别太小。
另外这几者比较的时候扯上hbase+cass就是离题万里啊

【在 z****e 的大作中提到】

: 我觉得这篇文章讲得很不清楚，只是单纯滴比较
: 没有实战价值
: 不过看评价缺点还是很有启发的，跟我猜的差不多
: 主要问题就是
: hadoop慢
: 我们用hadoop是因为没有选择
: 而且hbase存文件容量比较大，能放得多
: 但是并不代表我们不能自己动手做优化
: 实际上cap理论里面，hbase就牺牲了a
: 这个就意味着总是很慢，但是慢没有关系，可以优化

r*y2014-07-22 07:07

50 楼

我觉得是处理没弄好，其实跟水痕差不多。
根本不是该死的橙子说的啥嫉妒。

p*22014-07-22 07:07

51 楼

大牛真是说到点上了。因为hadoop现在有很多工具都可以做到real time了。

【在 l*****i 的大作中提到】

: 太扯了
: hadoop和storm相比，最麻烦的不是慢，而是很难定义连续长期持久任务，另外是中间
: 文件必须过磁盘IO导致的延时。
: hbase和cass虽然确实c/a牺牲得不同，但对存取影响差别不大。没听说过任何一家把
: hbase和cass作为上下级存储的，因为性能梯度差别太小。
: 另外这几者比较的时候扯上hbase+cass就是离题万里啊

c*e2014-07-22 07:07

52 楼

谁会承认自己嫉妒别人呢？谁会？

z*e2014-07-22 07:07

53 楼

你是不是没有看其他人给的链接？
另外我说的就是内森自己写的架构
你是不是又没有看内森写的文章？

【在 l*****i 的大作中提到】

Y*22014-07-22 07:07

54 楼

wi

【在 c********e 的大作中提到】

: 谁会承认自己嫉妒别人呢？谁会？

z*e2014-07-22 07:07

55 楼

说来说去，不还是回到latency上去了么？
不能持久的续航，或者是延时，不就是慢么？
或者说就是大数据时候会慢，总之迟早会回到慢上去
如果你总是做那么一两次操作，自然体会不到这种差异

【在 l*****i 的大作中提到】

Y*22014-07-22 07:07

56 楼

我。。。

【在 c********e 的大作中提到】

: 谁会承认自己嫉妒别人呢？谁会？

z*e2014-07-22 07:07

57 楼

hbase要保证一致性
这中间的过程就会导致延迟
实际上分布式本身的网络磁盘各个层面都会导致延迟
所以预处理是必需的，cassandra则不需要保证一致性
抓到哪个就是哪个，所以比较适合用在即时时候的持久化
我说的就是内森自己写的文章里面写的
你要是“没听说过”那就意味着你不懂twitter现在的架构
没听说过吗？要不要给你听说一下？

【在 l*****i 的大作中提到】

z*e2014-07-22 07:07

58 楼

My post Hive, Pig, Scalding, Scoobi, Scrunch and Spark describes simpler
frameworks built on top of Hadoop, but they are still complex.
Hadoop has long response time, and it not suited for real-time responses.
again，什么简单，什么就会占领市场，当其它条件一样的前提下
storm也开源了

【在 p*****2 的大作中提到】

:
: 大牛真是说到点上了。因为hadoop现在有很多工具都可以做到real time了。

p*22014-07-22 07:07

59 楼

忘记impala了？

【在 z****e 的大作中提到】

: My post Hive, Pig, Scalding, Scoobi, Scrunch and Spark describes simpler
: frameworks built on top of Hadoop, but they are still complex.
: Hadoop has long response time, and it not suited for real-time responses.
: again，什么简单，什么就会占领市场，当其它条件一样的前提下
: storm也开源了

p*22014-07-22 07:07

60 楼

没有。主要是相膜拜一下你们这些弯曲大牛

【在 w**z 的大作中提到】

: 二爷来弯曲指导工作了？

z*e2014-07-22 07:07

61 楼

cloudera的东西要收钱的吧

【在 p*****2 的大作中提到】

:
: 没有。主要是相膜拜一下你们这些弯曲大牛

p*22014-07-22 07:07

62 楼

好像open source呀

【在 z****e 的大作中提到】

: cloudera的东西要收钱的吧

H*S2014-07-22 07:07

63 楼

spray 就是基于akka actor的。现在用scala写rest service基本都用spray做。广义一
点来说，actor也大量用在lift framework里面，其中大量的ajax call都是lift自己的
comet actor完成的。

【在 p*****2 的大作中提到】

: 今天conference上根本没人用，都用Clojure的Storm。

p*22014-07-22 07:07

64 楼

确实没用过。但是大牛能说一下这些跟node比有啥优势吗？

【在 H****S 的大作中提到】

: spray 就是基于akka actor的。现在用scala写rest service基本都用spray做。广义一
: 点来说，actor也大量用在lift framework里面，其中大量的ajax call都是lift自己的
: comet actor完成的。

H*S2014-07-22 07:07

65 楼

普通码农一个。对node没什么感觉，single threaded 始终是个问题。最近组内部的
node server出了个问题，因为code写的failover request 频率太高，导致gc没办法
step in 来回收 heap objects，然后server就直接挂了。。。
Conversation pattern只是server实现的一种，对于我来说最大的优势是actor model
下因为message guaranteed 顺序处理，不用考虑race condition，简化了很多工作。
当然有人继续用jboss netty实现server，这个很难说谁好谁坏。

【在 p*****2 的大作中提到】

:
: 确实没用过。但是大牛能说一下这些跟node比有啥优势吗？