Redian新闻
>
还是别争了,从旁观者角度看,两个方案没准都能工作
avatar
还是别争了,从旁观者角度看,两个方案没准都能工作# Programming - 葵花宝典
e*d
1
朋友在中国经营比较高端的瓷器和字画,想看看美国有没有销路。不知这里有谁比较了
解这一行?可以站内联系。谢谢。
avatar
i*n
2
和LD在两个不同州,两人的收入可以和到一起file联邦税吗?
如果可以的话,州税怎么办?州税是一定要分开填的吧?
avatar
b*x
3
avatar
J*7
4
一月底买的光脚,二月初种下地。长势喜人,20多个花骨朵,不过还是童工。
Eden真是好品种,花儿娇艳欲滴优雅脱俗却十分皮实。种下后都没怎么管过,想起了才
浇浇水,没想到这么给力。
多谢杯子推荐此花!
整株照片
不比不知道,一比才知小
avatar
p*e
5
【 以下文字转载自 Memory 讨论区 】
发信人: playdate (花落无痕), 信区: Memory
标 题: 如烟版歌征集帖
发信站: BBS 未名空间站 (Sat Jan 23 19:04:32 2010, 美东)
本次如烟版歌征集活动将于美东时间2010年2月1日零点零分零秒结束,请大家推荐(
请勿重复,同一首歌,以最先推荐的ID为准)。
活动完毕之后将开投票,由大家选出如烟版版歌,最终获奖ID将获得200伪币的奖励,
谢谢大家的支持!!
avatar
o*l
6
下个月国内一朋友结婚,给我发了请柬,可是我人在外头,回不去也参加不了,这样的
话礼金还要给么?
这朋友跟我也算认识了听多年了,但关系却说不上亲密,要真是我姐们儿结婚,估计我
愿意飞回去,就算飞不回去也会准备一份大礼。但这种普通朋友,我还真不知道要不要
送礼金。要说送吧,人不去也喝不到喜酒,但现在送礼金又不能太少,而且关键也不是
多close 的关系,最多也就是逢年过节发个祝福什么的,再说我结婚还不知道会不会邀
请她呢,到时候送出去了收不回来多亏啊!可是如果不送呢,好像又有点说不过去,虽
然感情不深,但好歹也是这么多年的朋友,要是不送的话会不会朋友情谊就这么断了?
如果不送的话,估计得做好准备以后老死不相往来了吧。
再说如果确定要送,那送多少比较合适?按比例来算的话,该是我好姐们结婚礼金的百
分之多少才合适?希望自己又不会太肉痛,朋友收到又不会觉得我太吝啬。这个问题我
纠结了好久了。
大家给我点意见吧。这样不亲近也不疏远的朋友,如果没法到场参加婚礼,礼金要不要
送,要送的话该送多少?
avatar
c*3
7
两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
的方案。
NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,
不存在被人撂挑子,没有别人能接手的情况,风险比较少。
从风险控制的角度,选哪种还是很显然的
avatar
s*s
8
你好. 我也有朋友在国内经营高端陶瓷制品,工艺品.
也有问我大概这边的情况.不知道你了解到什么方面,可以交流交流.
我的email: k********[email protected]
Kyle

【在 e*********d 的大作中提到】
: 朋友在中国经营比较高端的瓷器和字画,想看看美国有没有销路。不知这里有谁比较了
: 解这一行?可以站内联系。谢谢。

avatar
S*s
9
同问

【在 i*******n 的大作中提到】
: 和LD在两个不同州,两人的收入可以和到一起file联邦税吗?
: 如果可以的话,州税怎么办?州税是一定要分开填的吧?

avatar
k*5
10
his image is a bit ...not as good as his song ...

【在 b*******x 的大作中提到】

avatar
p*M
11
楼主的EDEN在哪儿买的,一直想买呢,能给个LINK吗?谢谢!

【在 J****7 的大作中提到】
: 一月底买的光脚,二月初种下地。长势喜人,20多个花骨朵,不过还是童工。
: Eden真是好品种,花儿娇艳欲滴优雅脱俗却十分皮实。种下后都没怎么管过,想起了才
: 浇浇水,没想到这么给力。
: 多谢杯子推荐此花!
: 整株照片
: 不比不知道,一比才知小

avatar
x*n
12
memory?
往事随风?
avatar
f*4
13
这里很多新方案也就是科技公司在用。实际的企业用户用得也不多。
国内客户那是根本不让上。。。
魏老师撂挑子的风险我没考虑,因为我默认这就是他自己去招标了 -_-

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
K*7
14
同问

【在 i*******n 的大作中提到】
: 和LD在两个不同州,两人的收入可以和到一起file联邦税吗?
: 如果可以的话,州税怎么办?州税是一定要分开填的吧?

avatar
J*7
15
我在Armstrong Garden Center店里买的。他家的玫瑰质量很好,rose care类的产品也
很齐全。如果local没店的话可以在David Austin网上买。
http://www.davidaustinroses.com
avatar
p*e
16
谢谢,来如烟贴个视频吧,呵呵。。

【在 x***n 的大作中提到】
: memory?
: 往事随风?

avatar
P*l
17
撂挑子? 签了合同就身不由己了.

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
i*n
18
有知道的人可以解答一下吗?
谢谢
avatar
l*t
19
LZ的Eden很娇嫩啊
avatar
q*5
20
如烟 MS是个类似于烟的商品的商标
avatar
P*l
21
魏老师撂挑子的风险我没考虑,因为我默认这就是他自己去招标了 -_-
^^^ 我还以为只有我心理阴暗呢! :)

【在 f****4 的大作中提到】
: 这里很多新方案也就是科技公司在用。实际的企业用户用得也不多。
: 国内客户那是根本不让上。。。
: 魏老师撂挑子的风险我没考虑,因为我默认这就是他自己去招标了 -_-

avatar
G*g
22
File jointly for Federal Tax
File separately for State Tax
avatar
j*2
23
我各种的xmjdh啊!!!我的还在窗台上不敢下地呢 怕给弄死。你在暖和的噶达州?
★ Sent from iPhone App: iReader Mitbbs Lite 7.39
avatar
p*e
24
如烟网事,呵呵
如果是烟,那也是很怀旧的。。。。

【在 q*****5 的大作中提到】
: 如烟 MS是个类似于烟的商品的商标
avatar
T*i
25
其实智者不立危墙之下。除非我完全掌控项目,否则我也不会去趟那混水。

【在 P********l 的大作中提到】
: 魏老师撂挑子的风险我没考虑,因为我默认这就是他自己去招标了 -_-
: ^^^ 我还以为只有我心理阴暗呢! :)

avatar
c*7
26
File jointly for Federal Tax
File separately for State Tax (每个州可能算法不同,但基本上都有married buy
file separately的选项)
avatar
c*p
27
养得真不错!别着急,很快就长高了!
avatar
y*n
28
姜育恒—戒烟如你

【在 p******e 的大作中提到】
: 如烟网事,呵呵
: 如果是烟,那也是很怀旧的。。。。

avatar
l*9
29
所谓nosql风险小,obamacare网站开发者就是这么想的。哈哈

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
i*n
30
和LD在两个不同州,两人的收入可以和到一起file联邦税吗?
如果可以的话,州税怎么办?州税是一定要分开填的吧?
avatar
j*2
31
看起来你的枝条很粗壮啊 为猫我买的在pot里的就像个小苗苗啊???
avatar
y*n
32
我贴过一首了,谁拿去拿包子

【在 y*****n 的大作中提到】
: 姜育恒—戒烟如你
avatar
g*g
33
您老就别打酱油了。他那系统是在原来基础上打补丁吗?他首先完全没考虑出票系统,
也就是legacy系统。然后原来不存在的订票系统,自己手写了一个轮子,还单机的。
我跟他是本质的区别,首先我拿了一个业界验证过的好轮子,Cassandra来对付高订单
并发。其次我懂得把计数和订单完整分开,避免transaction产生的bottleneck。最后
我分析了后台出票系统各种优化的方法。但我完全可以直接使用legacy系统出票呀,能
撑得住最好,撑不住我讨论了怎么优化。
这中间的关键是啥?一个好的架构师,要懂得分析数据的不同特性,用不同的轮子去处
理。比如我把订单和计数分开,这没有对CAP深入理解,是不会想到的。
像他那种,上来就是这么多数据,我就是能单机处理。纯粹吹牛装逼。一个从没写过高
性能服务器的人,他给你设计一个春运系统,你敢用吗?

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
S*s
34
同问

【在 i*******n 的大作中提到】
: 和LD在两个不同州,两人的收入可以和到一起file联邦税吗?
: 如果可以的话,州税怎么办?州税是一定要分开填的吧?

avatar
J*7
35
我在zone 9。不过我种下地后1个多月期间,夜里温度也只有40多度。Eden花看起来十
分娇柔,其实相当皮实。如果没有霜冻危险,还是赶快种下地吧。(我种时用vitB水泡
了根的。)花开了别忘了来show show哦。

【在 j****2 的大作中提到】
: 我各种的xmjdh啊!!!我的还在窗台上不敢下地呢 怕给弄死。你在暖和的噶达州?
: ★ Sent from iPhone App: iReader Mitbbs Lite 7.39

avatar
p*e
36
呵呵。。。

【在 y*****n 的大作中提到】
: 我贴过一首了,谁拿去拿包子
avatar
T*i
37
呵呵,有进步了。这回不敢提我的系统断电就挂了。看来我打脸还是有成效的。

【在 g*****g 的大作中提到】
: 您老就别打酱油了。他那系统是在原来基础上打补丁吗?他首先完全没考虑出票系统,
: 也就是legacy系统。然后原来不存在的订票系统,自己手写了一个轮子,还单机的。
: 我跟他是本质的区别,首先我拿了一个业界验证过的好轮子,Cassandra来对付高订单
: 并发。其次我懂得把计数和订单完整分开,避免transaction产生的bottleneck。最后
: 我分析了后台出票系统各种优化的方法。但我完全可以直接使用legacy系统出票呀,能
: 撑得住最好,撑不住我讨论了怎么优化。
: 这中间的关键是啥?一个好的架构师,要懂得分析数据的不同特性,用不同的轮子去处
: 理。比如我把订单和计数分开,这没有对CAP深入理解,是不会想到的。
: 像他那种,上来就是这么多数据,我就是能单机处理。纯粹吹牛装逼。一个从没写过高
: 性能服务器的人,他给你设计一个春运系统,你敢用吗?

avatar
K*7
38
同问

【在 i*******n 的大作中提到】
: 和LD在两个不同州,两人的收入可以和到一起file联邦税吗?
: 如果可以的话,州税怎么办?州税是一定要分开填的吧?

avatar
g*o
39
真美真美真真美
avatar
p*e
40
谢谢版主包子,呵呵

【在 p******e 的大作中提到】
: 呵呵。。。
avatar
c*3
41
所以说光在架构上讨论没有啥意义,只要架构没有致命缺陷就成了。条条大路通罗马,
从来没有一个项目只有一种方法的。
魔鬼都是在细节上。nosql的东西大部分是开源的项目,在开源上做,必须要有能搞定
细节的人,开源有bug,要能自己去修,不能指望开源项目的人。大部分情况人家根本
不鸟你。
做不到这点,必然死的难看无比。

【在 l*****9 的大作中提到】
: 所谓nosql风险小,obamacare网站开发者就是这么想的。哈哈
avatar
i*n
42
有知道的人可以解答一下吗?
谢谢
avatar
J*7
43
谢谢砖头。今天全开了,天啦,娇嫩柔美得让人心痛。
赶快打电话叫了几个朋友来赏花。谁知个个都说还是旁边那巨大无比的chrysler更好看
。俺当场血喷一地,内牛两滴。

【在 l*t 的大作中提到】
: LZ的Eden很娇嫩啊
avatar
g*g
44
开源跟质量没有本质关系。时间长,名气大的开源软件,只要你不追最新版,都是很稳
定的。
如果你不差钱,大的开源软件都有backing的公司给你提供服务。比如我提的Cassandra,
DataStax就提供服务和维护。

【在 c****3 的大作中提到】
: 所以说光在架构上讨论没有啥意义,只要架构没有致命缺陷就成了。条条大路通罗马,
: 从来没有一个项目只有一种方法的。
: 魔鬼都是在细节上。nosql的东西大部分是开源的项目,在开源上做,必须要有能搞定
: 细节的人,开源有bug,要能自己去修,不能指望开源项目的人。大部分情况人家根本
: 不鸟你。
: 做不到这点,必然死的难看无比。

avatar
G*g
45
File jointly for Federal Tax
File separately for State Tax
avatar
J*7
46
谢谢番茄MM。我好喜欢你的头像。

【在 g*********o 的大作中提到】
: 真美真美真真美
avatar
c*3
47
你说的是常用功能,这种开源项目是比较稳定。
开源的宗旨是用户就是QA,开发人员就不用QA了。所以如果碰到非常用功能,50%以上
的几率都是不工作的。
想春运订票之类的项目,是很极端的情况。肯定很多地方要用到开源项目里面不常用功
能,如果自己没有人搞定细节,死的才难看。
找做开源的人维护,属于投骰子,碰到好的算你运气好,差的态度特别差。你又怎么知
道投骰子的结果

Cassandra,

【在 g*****g 的大作中提到】
: 开源跟质量没有本质关系。时间长,名气大的开源软件,只要你不追最新版,都是很稳
: 定的。
: 如果你不差钱,大的开源软件都有backing的公司给你提供服务。比如我提的Cassandra,
: DataStax就提供服务和维护。

avatar
c*7
48
File jointly for Federal Tax
File separately for State Tax (每个州可能算法不同,但基本上都有married buy
file separately的选项)
avatar
J*7
49
谢谢!看来得赶紧找人把arbor搭起来了。

【在 c***p 的大作中提到】
: 养得真不错!别着急,很快就长高了!
avatar
t*y
50
你错了,你是用开源的东西做产品,你需要你自己的QA测试你的东西,如果开源的有问
题,你可以自己修复,也可以提出来等别人修复。
几十那几个 Debian, ubuntu, redhat, centos 等等也都是有自己的QA的,当然,他们
的QA很多是自愿的。

【在 c****3 的大作中提到】
: 你说的是常用功能,这种开源项目是比较稳定。
: 开源的宗旨是用户就是QA,开发人员就不用QA了。所以如果碰到非常用功能,50%以上
: 的几率都是不工作的。
: 想春运订票之类的项目,是很极端的情况。肯定很多地方要用到开源项目里面不常用功
: 能,如果自己没有人搞定细节,死的才难看。
: 找做开源的人维护,属于投骰子,碰到好的算你运气好,差的态度特别差。你又怎么知
: 道投骰子的结果
:
: Cassandra,

avatar
y*5
51
州税要求起始点是AGI in federal tax return. 如果夫妻联合报联邦税,州税里的AGI
应该怎么填呢,如果分开报?一个人还是两个人?
avatar
g*g
52
在整个设计里,我只用了Cassandra最简单的存储,没有什么非常功能。
整个春运网站,特别的是量大,而不是什么变态功能,或者逻辑很复杂。
而春运的量,在Internet company看来,也不是很变态的量。我前面给的benchmark,
已经超出了设计需要的10倍。
你们微软出来的人,总是成天对开源的东西瞎担心。不是说开源的东西没有问题,但是
开源的东西
要解决,要找workaround远比闭源的容易多了。一个复杂系统,总是会碰到问题。那些
正规backing开源东西的公司,跟闭源公司做服务并没有什么不同。你付钱,他为啥态
度不好。

【在 c****3 的大作中提到】
: 你说的是常用功能,这种开源项目是比较稳定。
: 开源的宗旨是用户就是QA,开发人员就不用QA了。所以如果碰到非常用功能,50%以上
: 的几率都是不工作的。
: 想春运订票之类的项目,是很极端的情况。肯定很多地方要用到开源项目里面不常用功
: 能,如果自己没有人搞定细节,死的才难看。
: 找做开源的人维护,属于投骰子,碰到好的算你运气好,差的态度特别差。你又怎么知
: 道投骰子的结果
:
: Cassandra,

avatar
y*5
53
up.

AGI

【在 y********5 的大作中提到】
: 州税要求起始点是AGI in federal tax return. 如果夫妻联合报联邦税,州税里的AGI
: 应该怎么填呢,如果分开报?一个人还是两个人?

avatar
t*y
54
我喜欢成熟的开源产品,因为免费,被大量使用,有案例,有经验学习。
但是每个人的使用环境是不同的,会有不同的问题,有了问题,因为是开源的,自己可
以解决。
闭源的质量好,但是因为使用环境不同,也会有不同的问题,这个时候你只能是要吗绕
圈子,要吗花钱买支持,等。

【在 c****3 的大作中提到】
: 你说的是常用功能,这种开源项目是比较稳定。
: 开源的宗旨是用户就是QA,开发人员就不用QA了。所以如果碰到非常用功能,50%以上
: 的几率都是不工作的。
: 想春运订票之类的项目,是很极端的情况。肯定很多地方要用到开源项目里面不常用功
: 能,如果自己没有人搞定细节,死的才难看。
: 找做开源的人维护,属于投骰子,碰到好的算你运气好,差的态度特别差。你又怎么知
: 道投骰子的结果
:
: Cassandra,

avatar
m*a
55
可以分别file single吗?
avatar
c*3
56
所以说用开源项目,你自己必须有人能搞定细节,会修里面的bug。即使你的程序在高
层运行,底层的问题也得自己会搞定。
等他们修,等两年没准也没有人理你,人家有其他更重要的事情。到时候你才惨了。

【在 t*******y 的大作中提到】
: 你错了,你是用开源的东西做产品,你需要你自己的QA测试你的东西,如果开源的有问
: 题,你可以自己修复,也可以提出来等别人修复。
: 几十那几个 Debian, ubuntu, redhat, centos 等等也都是有自己的QA的,当然,他们
: 的QA很多是自愿的。

avatar
v*9
57
都married了你还file single?
avatar
m*l
58
更重要的是峰值.

【在 g*****g 的大作中提到】
: 在整个设计里,我只用了Cassandra最简单的存储,没有什么非常功能。
: 整个春运网站,特别的是量大,而不是什么变态功能,或者逻辑很复杂。
: 而春运的量,在Internet company看来,也不是很变态的量。我前面给的benchmark,
: 已经超出了设计需要的10倍。
: 你们微软出来的人,总是成天对开源的东西瞎担心。不是说开源的东西没有问题,但是
: 开源的东西
: 要解决,要找workaround远比闭源的容易多了。一个复杂系统,总是会碰到问题。那些
: 正规backing开源东西的公司,跟闭源公司做服务并没有什么不同。你付钱,他为啥态
: 度不好。

avatar
d*n
59
看要求吧。
有的州要求如果联邦税jointly,州税就必须jointly。如果另一半不是该州居民,选择
non resident/part year resident报州税。
但有的州允许联邦税和州税的file status不一样
avatar
w*r
60
肯定都能跑起来,但大家在意的是能不能做到四个9和能不能应对峰值请求
avatar
y*5
61
在伊州,州税税表的起始点是联邦税表的AGI. 如果联邦夫妻联合,伊州只报一个人的
,另一方是另外一个州的居民。伊州的税表分开报,那起点就不同于联邦税表的AGI 了。
对吗?

AGI

【在 y********5 的大作中提到】
: 州税要求起始点是AGI in federal tax return. 如果夫妻联合报联邦税,州税里的AGI
: 应该怎么填呢,如果分开报?一个人还是两个人?

avatar
c*3
62
我可不是微软的,也不是做数据库这一块的。
不过工作里用到大量开源项目,知道里面的trick,不是表面看着那么光鲜。
用开源产品,用的好能让你的项目节约大量时间,而且有很好的结果。但是前提就是万
一出问题,你必须能从上到下都能搞定这些细节,不能有幻想依靠其他人。
这些都是架构设计的时候没法考虑的不确定因素。

【在 g*****g 的大作中提到】
: 在整个设计里,我只用了Cassandra最简单的存储,没有什么非常功能。
: 整个春运网站,特别的是量大,而不是什么变态功能,或者逻辑很复杂。
: 而春运的量,在Internet company看来,也不是很变态的量。我前面给的benchmark,
: 已经超出了设计需要的10倍。
: 你们微软出来的人,总是成天对开源的东西瞎担心。不是说开源的东西没有问题,但是
: 开源的东西
: 要解决,要找workaround远比闭源的容易多了。一个复杂系统,总是会碰到问题。那些
: 正规backing开源东西的公司,跟闭源公司做服务并没有什么不同。你付钱,他为啥态
: 度不好。

avatar
m*l
63
大牛说的好,我用开源的看法也差不多,
有时候自己也不得不重新做一下

【在 c****3 的大作中提到】
: 我可不是微软的,也不是做数据库这一块的。
: 不过工作里用到大量开源项目,知道里面的trick,不是表面看着那么光鲜。
: 用开源产品,用的好能让你的项目节约大量时间,而且有很好的结果。但是前提就是万
: 一出问题,你必须能从上到下都能搞定这些细节,不能有幻想依靠其他人。
: 这些都是架构设计的时候没法考虑的不确定因素。

avatar
g*g
64
我记得你是微软出来的。有可能记错见谅。
我们工作中用的每个类库都是开源的,事实上,除了服务器这种东西,不开源的是不让
用也没人用的。
我做了十几年java,产品中的非开源类库屈指可数。

【在 c****3 的大作中提到】
: 我可不是微软的,也不是做数据库这一块的。
: 不过工作里用到大量开源项目,知道里面的trick,不是表面看着那么光鲜。
: 用开源产品,用的好能让你的项目节约大量时间,而且有很好的结果。但是前提就是万
: 一出问题,你必须能从上到下都能搞定这些细节,不能有幻想依靠其他人。
: 这些都是架构设计的时候没法考虑的不确定因素。

avatar
c*3
65
象你公司这种,有个现有系统,已经工作很好,就不怕了。其他用开源的项目可以慢慢
试验,这个开源不行,可以换另一个,时间长点不要紧,反正我已经有工作的系统了。
最怕的就是现在的系统不工作,或者工作不好,赶鸭子上架,急着弄出另一个。这时候
开源那点风险,就全冒出来了。没有人是神仙,能事先知道这个开源项目有啥问题,正
好我需要用的功能不工作,或者有毛病。尤其有些问题是系统流量大的时候才冒出来的
,这些开源开发人员,根本自己没有条件模拟或者测试这种环境。

【在 g*****g 的大作中提到】
: 我记得你是微软出来的。有可能记错见谅。
: 我们工作中用的每个类库都是开源的,事实上,除了服务器这种东西,不开源的是不让
: 用也没人用的。
: 我做了十几年java,产品中的非开源类库屈指可数。

avatar
g*g
66
您老不是做java server端这块的吧?除了weblogic, websphere, DB,基本上没有啥有
人用的类库是不开源的。整个生态系统就是如此,如果不开源,根本没人用。

【在 c****3 的大作中提到】
: 象你公司这种,有个现有系统,已经工作很好,就不怕了。其他用开源的项目可以慢慢
: 试验,这个开源不行,可以换另一个,时间长点不要紧,反正我已经有工作的系统了。
: 最怕的就是现在的系统不工作,或者工作不好,赶鸭子上架,急着弄出另一个。这时候
: 开源那点风险,就全冒出来了。没有人是神仙,能事先知道这个开源项目有啥问题,正
: 好我需要用的功能不工作,或者有毛病。尤其有些问题是系统流量大的时候才冒出来的
: ,这些开源开发人员,根本自己没有条件模拟或者测试这种环境。

avatar
t*y
67
一样的,像上面说的,花钱有人干这个,我们请过人,很便宜,修改的代码全给你,挺
好交流,对他的工作有问题,随时问,合作很高兴。
微软的东西我们在用,有要花钱去请微软的人来帮助解决问题,但是每有一个问题,都
有记时花钱,而且那些烙印尽量的赚钱,胡说八道一番,反正10句里面有一半有用就不
错了。小公司,成本有压力。请我们就是来干活的,当然能自己干最好。
曾经和微软一个合作,花钱解决一个问题,一个月下来,给了一个东西,但是有bug,
反复几次,还有问题,告诉我们开发的要去度假了,你们自己搞吧,操。

【在 c****3 的大作中提到】
: 所以说用开源项目,你自己必须有人能搞定细节,会修里面的bug。即使你的程序在高
: 层运行,底层的问题也得自己会搞定。
: 等他们修,等两年没准也没有人理你,人家有其他更重要的事情。到时候你才惨了。

avatar
t*y
68
着急的项目,开源和闭源有区别吗?你说的问题都会有啊。

【在 c****3 的大作中提到】
: 象你公司这种,有个现有系统,已经工作很好,就不怕了。其他用开源的项目可以慢慢
: 试验,这个开源不行,可以换另一个,时间长点不要紧,反正我已经有工作的系统了。
: 最怕的就是现在的系统不工作,或者工作不好,赶鸭子上架,急着弄出另一个。这时候
: 开源那点风险,就全冒出来了。没有人是神仙,能事先知道这个开源项目有啥问题,正
: 好我需要用的功能不工作,或者有毛病。尤其有些问题是系统流量大的时候才冒出来的
: ,这些开源开发人员,根本自己没有条件模拟或者测试这种环境。

avatar
c*3
69
你算幸运的,JAVA的开源有很多大公司的人帮助搞定和修bug
我做通信的。算是Linux嵌入系统的应用层,也做C写的服务器应用。这块就没有那么幸
运了,经常要自己搞定。
不过你说的和订票相关的那些noSQL分布系统,象mongodb之类,基本也是C和C++写的,
项目时间也不长,这块我听同事讲,也是问题多多,不过还算修复及时。

【在 g*****g 的大作中提到】
: 您老不是做java server端这块的吧?除了weblogic, websphere, DB,基本上没有啥有
: 人用的类库是不开源的。整个生态系统就是如此,如果不开源,根本没人用。

avatar
g*g
70
我们比你更惨。一起干得一个小公司,client要写一个windows driver。发现windows
api有bug,
成天扯皮,一直给拖着。client team lead天天打电话催,最后工期误了半年,项目没
卖出去,人直接砍掉了一半。
开源是再没办法,总归自己fix还是个办法。闭源真是花钱还要求爷爷告奶奶。

【在 t*******y 的大作中提到】
: 一样的,像上面说的,花钱有人干这个,我们请过人,很便宜,修改的代码全给你,挺
: 好交流,对他的工作有问题,随时问,合作很高兴。
: 微软的东西我们在用,有要花钱去请微软的人来帮助解决问题,但是每有一个问题,都
: 有记时花钱,而且那些烙印尽量的赚钱,胡说八道一番,反正10句里面有一半有用就不
: 错了。小公司,成本有压力。请我们就是来干活的,当然能自己干最好。
: 曾经和微软一个合作,花钱解决一个问题,一个月下来,给了一个东西,但是有bug,
: 反复几次,还有问题,告诉我们开发的要去度假了,你们自己搞吧,操。

avatar
g*g
71
mongodb是C/C++写的,Cassandra和HBase是java写的。
项目也有几年了,比如Cassandra 0.8起production ready,现在都2.0了。

【在 c****3 的大作中提到】
: 你算幸运的,JAVA的开源有很多大公司的人帮助搞定和修bug
: 我做通信的。算是Linux嵌入系统的应用层,也做C写的服务器应用。这块就没有那么幸
: 运了,经常要自己搞定。
: 不过你说的和订票相关的那些noSQL分布系统,象mongodb之类,基本也是C和C++写的,
: 项目时间也不长,这块我听同事讲,也是问题多多,不过还算修复及时。

avatar
t*y
72
一样一样的。介绍的时候说,这个东西能干什么干什么,一测,不行,开始找人,找了
一圈,确认,不行。
闷头自己写一个。
我们老板话说的,开源,只完成了10%,剩下的90%自己想办法。
闭源,完成了90%,剩下的10%没办法。
各有优缺点。自己喜欢开源,可控。

windows

【在 g*****g 的大作中提到】
: 我们比你更惨。一起干得一个小公司,client要写一个windows driver。发现windows
: api有bug,
: 成天扯皮,一直给拖着。client team lead天天打电话催,最后工期误了半年,项目没
: 卖出去,人直接砍掉了一半。
: 开源是再没办法,总归自己fix还是个办法。闭源真是花钱还要求爷爷告奶奶。

avatar
t*y
73
其实你这个看要求了,资源紧张不好办,如果可以的话,也有很多工具和framework用
啊。 我们的client to server http用的就是curl库,挺好用。

【在 c****3 的大作中提到】
: 你算幸运的,JAVA的开源有很多大公司的人帮助搞定和修bug
: 我做通信的。算是Linux嵌入系统的应用层,也做C写的服务器应用。这块就没有那么幸
: 运了,经常要自己搞定。
: 不过你说的和订票相关的那些noSQL分布系统,象mongodb之类,基本也是C和C++写的,
: 项目时间也不长,这块我听同事讲,也是问题多多,不过还算修复及时。

avatar
c*3
74
说到底,架构师一方面,架构不行肯定完蛋。
但是到细节,象铁路订票这种流量,这种形式的应用,那个系统能顶得住,经得住考验
。在这种流量下没有大的bug,也得碰运气。
碰到开源系统在这样的流量下有严重bug,肯定也得被人骂死。人家买票的人才不管这
些。

【在 g*****g 的大作中提到】
: mongodb是C/C++写的,Cassandra和HBase是java写的。
: 项目也有几年了,比如Cassandra 0.8起production ready,现在都2.0了。

avatar
t*y
75
我同意主要是架构师和实现的问题。
但是和是否开源没关系。铁道部有条件做压力测试。简单一点的在一个铁路局局部试用
。主要问题是从上到下没有大拿。

【在 c****3 的大作中提到】
: 说到底,架构师一方面,架构不行肯定完蛋。
: 但是到细节,象铁路订票这种流量,这种形式的应用,那个系统能顶得住,经得住考验
: 。在这种流量下没有大的bug,也得碰运气。
: 碰到开源系统在这样的流量下有严重bug,肯定也得被人骂死。人家买票的人才不管这
: 些。

avatar
g*g
76
如果这个类库只达到你想要东西的10%,不管开源闭源,你是不会去使用的,你是有选
择的。

【在 t*******y 的大作中提到】
: 一样一样的。介绍的时候说,这个东西能干什么干什么,一测,不行,开始找人,找了
: 一圈,确认,不行。
: 闷头自己写一个。
: 我们老板话说的,开源,只完成了10%,剩下的90%自己想办法。
: 闭源,完成了90%,剩下的10%没办法。
: 各有优缺点。自己喜欢开源,可控。
:
: windows

avatar
t*y
77
你说的对,我那个是一种比方。

【在 g*****g 的大作中提到】
: 如果这个类库只达到你想要东西的10%,不管开源闭源,你是不会去使用的,你是有选
: 择的。

avatar
g*g
78
这不是运气,这是靠测试。测试充分,问题就少。我们弄了个chaos monkey,每天随机
把产品环境的结点直接当掉,就是为了这个。

【在 c****3 的大作中提到】
: 说到底,架构师一方面,架构不行肯定完蛋。
: 但是到细节,象铁路订票这种流量,这种形式的应用,那个系统能顶得住,经得住考验
: 。在这种流量下没有大的bug,也得碰运气。
: 碰到开源系统在这样的流量下有严重bug,肯定也得被人骂死。人家买票的人才不管这
: 些。

avatar
c*3
79
你有做够时间,当然啥也不怕。愿意测试多久,测试多少,都没有问题。
象铁路这种系统,已经出问题,如果你想短时间修复它,更改了系统架构,写出代码,
那里还有多少时间测试。这时候,你选哪个开源系统,能否顶住这种应用,还是要靠运气

【在 g*****g 的大作中提到】
: 这不是运气,这是靠测试。测试充分,问题就少。我们弄了个chaos monkey,每天随机
: 把产品环境的结点直接当掉,就是为了这个。

avatar
t*y
80
这个更会测,不然还不如不换。
这是工程问题加商业问题。

运气

【在 c****3 的大作中提到】
: 你有做够时间,当然啥也不怕。愿意测试多久,测试多少,都没有问题。
: 象铁路这种系统,已经出问题,如果你想短时间修复它,更改了系统架构,写出代码,
: 那里还有多少时间测试。这时候,你选哪个开源系统,能否顶住这种应用,还是要靠运气

avatar
c*3
81
不换肯定被人骂死。换又要面临时间的压力。
实际工作这种情况经常发生。谁还有功夫仔细斟酌架构细节,只要架构没有致命问题就
行了。
最后还得靠摸着石头过河,以及具体做事人的直觉。也许大公司不这样,但是大公司失
败项目也是一堆一堆的。

【在 t*******y 的大作中提到】
: 这个更会测,不然还不如不换。
: 这是工程问题加商业问题。
:
: 运气

avatar
g*g
82
我不反对你说的这个,我纯粹觉得这个跟开源闭源没啥关系。像铁道部这种,喜欢
直接整体外包IBM之类的,真出了问题,好找替罪羊。就一句IBM都做不出来,你让我
找谁去?

【在 c****3 的大作中提到】
: 不换肯定被人骂死。换又要面临时间的压力。
: 实际工作这种情况经常发生。谁还有功夫仔细斟酌架构细节,只要架构没有致命问题就
: 行了。
: 最后还得靠摸着石头过河,以及具体做事人的直觉。也许大公司不这样,但是大公司失
: 败项目也是一堆一堆的。

avatar
c*3
83
是和开源没有关系。我说到开源风险,也是因为有人说obamacare用noSQL,结果很失败。
铁道部用noSQL,也会有同样的风险。但是如果铁道部有做够好的人,有足够经验做细
节实施,知道如何避免开源的风险,也可能没有任何问题。
同样的道理,找魏老师,也许他的经验做够丰富,就能避免很多实施中的细节问题。他
的架构也许细节有问题,但是除非是架构致命缺陷,实施的时候,总归能找到办法绕过
去。但是最大风险也许是魏老师撂挑子。
这也是我说两个方案没准最后都可以工作的原因。

【在 g*****g 的大作中提到】
: 我不反对你说的这个,我纯粹觉得这个跟开源闭源没啥关系。像铁道部这种,喜欢
: 直接整体外包IBM之类的,真出了问题,好找替罪羊。就一句IBM都做不出来,你让我
: 找谁去?

avatar
g*g
84
分布式的系统,从一开始就在考虑瓶颈,摊开流量。做得不好崩了,可能,那是个bug
,总归可以改好。
单机系统,根本就撑不住这个流量,怎么办,优化优化再优化,大部分时间都放在优化
,而不是写商业逻辑上。还是不行最后怎么办?还是得走分布式,而这个架构改动之大
几乎是从头写。
我一直让魏老师给个写SSD的benchmark,就是让他知道他吹牛逼吹得有多荒谬。他倒是
知难而退,20行的程序打死都不肯写。
我总结了很多次,魏老师提出了一个轮子,而市面上已经有现成更好更可靠的轮子。

败。

【在 c****3 的大作中提到】
: 是和开源没有关系。我说到开源风险,也是因为有人说obamacare用noSQL,结果很失败。
: 铁道部用noSQL,也会有同样的风险。但是如果铁道部有做够好的人,有足够经验做细
: 节实施,知道如何避免开源的风险,也可能没有任何问题。
: 同样的道理,找魏老师,也许他的经验做够丰富,就能避免很多实施中的细节问题。他
: 的架构也许细节有问题,但是除非是架构致命缺陷,实施的时候,总归能找到办法绕过
: 去。但是最大风险也许是魏老师撂挑子。
: 这也是我说两个方案没准最后都可以工作的原因。

avatar
f*4
85
恩,所以很多时候自己造轮子,那真得不是喜欢造轮子 -_-

【在 c****3 的大作中提到】
: 你算幸运的,JAVA的开源有很多大公司的人帮助搞定和修bug
: 我做通信的。算是Linux嵌入系统的应用层,也做C写的服务器应用。这块就没有那么幸
: 运了,经常要自己搞定。
: 不过你说的和订票相关的那些noSQL分布系统,象mongodb之类,基本也是C和C++写的,
: 项目时间也不长,这块我听同事讲,也是问题多多,不过还算修复及时。

avatar
h*k
86
我觉得在美国IT界一个人的工资基本反映了他的能力,能力强的人设计的系统自然应该
更好。所以只要比比味老师和古德霸谁的工资高就知道谁的系统好了。:-)

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
N*K
87
一堆破机器堆系统 哪个金融机构用过?

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
d*u
88
"要找workaround远比闭源的容易多了"
扯挤吧蛋吧,我玩开源那会儿你还中关村卖毛片呢。没有一支NB的队伍来维护,用开源
的东西基本就是嫌死得不够快。

【在 g*****g 的大作中提到】
: 在整个设计里,我只用了Cassandra最简单的存储,没有什么非常功能。
: 整个春运网站,特别的是量大,而不是什么变态功能,或者逻辑很复杂。
: 而春运的量,在Internet company看来,也不是很变态的量。我前面给的benchmark,
: 已经超出了设计需要的10倍。
: 你们微软出来的人,总是成天对开源的东西瞎担心。不是说开源的东西没有问题,但是
: 开源的东西
: 要解决,要找workaround远比闭源的容易多了。一个复杂系统,总是会碰到问题。那些
: 正规backing开源东西的公司,跟闭源公司做服务并没有什么不同。你付钱,他为啥态
: 度不好。

avatar
z*e
89
臭臭你这是变相夸古德霸nb吗?

【在 d********u 的大作中提到】
: "要找workaround远比闭源的容易多了"
: 扯挤吧蛋吧,我玩开源那会儿你还中关村卖毛片呢。没有一支NB的队伍来维护,用开源
: 的东西基本就是嫌死得不够快。

avatar
d*u
90
靠,尼玛这又是亮W2的节奏?KB的60亿精子又要出来了。。。

【在 h******k 的大作中提到】
: 我觉得在美国IT界一个人的工资基本反映了他的能力,能力强的人设计的系统自然应该
: 更好。所以只要比比味老师和古德霸谁的工资高就知道谁的系统好了。:-)

avatar
g*g
91
淘宝,单日300亿订单。

【在 N******K 的大作中提到】
: 一堆破机器堆系统 哪个金融机构用过?
avatar
h*a
92
要光看今年收入我赌goodbug,Netflix股票今年太猛了。呵呵

【在 h******k 的大作中提到】
: 我觉得在美国IT界一个人的工资基本反映了他的能力,能力强的人设计的系统自然应该
: 更好。所以只要比比味老师和古德霸谁的工资高就知道谁的系统好了。:-)

avatar
g*g
93
您老每年都至少这个数,别谦虚了。我说的这些轮子有的还是你写的。
您老要是来拍我,至少我听着。魏老师就算了吧。

【在 h*****a 的大作中提到】
: 要光看今年收入我赌goodbug,Netflix股票今年太猛了。呵呵
avatar
h*a
94
这个基本上没错。所以选开源组件很重要的一点就是社区的情况,有没有大的公司做
user或者contributor。现在比较流行的开源软件后面都有巨头公司的身影,质量上来
说比几年前好多了。

没有一支NB的队伍来维护,用开源

【在 d********u 的大作中提到】
: 靠,尼玛这又是亮W2的节奏?KB的60亿精子又要出来了。。。
avatar
g*g
95
我觉得流行的一直很好。从最早的ant,junit,log4j,到后来struts, spring,
hibernate, maven。
别赶最新版就行。

【在 h*****a 的大作中提到】
: 这个基本上没错。所以选开源组件很重要的一点就是社区的情况,有没有大的公司做
: user或者contributor。现在比较流行的开源软件后面都有巨头公司的身影,质量上来
: 说比几年前好多了。
:
: 没有一支NB的队伍来维护,用开源

avatar
h*k
96
没看明白,什么典故?

【在 d********u 的大作中提到】
: 靠,尼玛这又是亮W2的节奏?KB的60亿精子又要出来了。。。
avatar
s*r
97
难点就一个,车票数据之间有高度依赖关系,系统还要求实时同步,这个问题确实很难
解决

【在 c****3 的大作中提到】
: 两个方案各有优缺点,但实际做的时候,都可能有意想不到的情况
: 魏老师的方法,是在现有系统上修补,实施速度可能快一些。从他的经验上看,也许他
: 可以处理。但毕竟不是业界通用做法,没有被充分研究过,风险比较大,万一出现设计
: 意想不到的情况,项目就泡汤了。另外一个风险是,这是非常规方案,完全依赖他个人
: 经验,如果他撂挑子不干了,铁路系统就虾米了。后期维护也存在同样问题,是高风险
: 的方案。
: NoSQL的方法,毕竟是研究了十几年了,虽然不完全适合春运卖票,但是是业界通用做
: 法,大部分情况已经被充分研究过,风险比较小。少量有实施风险的地方,可以充分论
: 证在动手。但铁路旧系统可能是传统的基于SQL数据库的,这种方法实施速度比较慢,
: 还要迁移现有系统和数据。但从长远来讲,扩展性比较好。而且因为是业界通用方案,

avatar
z*e
98
比w2一直就有
一旦有人说java vs 其他什么东西
说到比w2,其他东西基本上都遁了
只有swjtuer亮过自己的w2
精子那个说的是古德霸是湖人粉
所以科比有一个强奸案
臭臭经常说这个

【在 h******k 的大作中提到】
: 没看明白,什么典故?
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。