xiaoxiang7788 于 2009-6-26 13:21 发表

请先弄明白分布式持续集成和你说的分布式构建的区别。如果把持续集成和持续构建混为一谈的话，是一个非常大的冷笑话哦。;P [/quote] 我理解的 Build 和 Integration 是一个意思，无非是编译、打包、测试、部署等等

wdk 于 2009-6-26 12:42 发表

新人有一个问题不懂：“双核 8CPU” 和 “8 核双 CPU” 是不是总共的核的数量是相等的啊？ 8 CPU x 2 Core 2 CPU x 8 Core

是这样算么？ [/quote] 算是这样算的，但简单的乘积对于性能分析来说帮助不大。

xiaoxiang7788 于 2009-6-26 11:18 发表

Cruise 对分布式持续集成做的比较好, 有兴趣可以研究一下的嘛. 具体分布式持续集成是怎么一回事, 可以参看一个文档. http://www.infoq.com/cn/articles/thoughtworks-practice-partv 介绍的是持续集成在 Cruise 里面 ... [/quote] 看了一下，Cruise 所做的并不是严格意义上的 “分布式构建”

通常分布式构建是指在 “编译级别” 上的并发性，而不是 “平台级别” 的并发

scmroad 于 2009-6-26 11:23 发表

既然第二个可以那么快，而且应用程序与硬件之间是被操作系统隔开的。证明程序是没有问题的.

所以有几个问题产生了：

1。这两个服务器的品牌一样么？硬件架构肯定不一样了，CPU 数目就不同啊 2。“双核 8CPU” 和 “8 ... [/quote] 除了 CPU，其他都是一样的，第一个只是并发性不够，大量的并行构建会拖垮那台机器

8 CPU x 2 Core 的机器，主频是 1.35G 的，2 CPU x 8 Core 的机器，主频是 1.2G 的

我想说明的是，构建通常是一个并发性很高的工作，多核、多线程要比多个 CPU 重要很多

laofo 于 2009-6-25 17:52 发表
分布式持续集成?这个名词很新颖.能不能展开具体说说,

前两天 elian 还在群里提出一个分布式构建,我觉得都大有钻研的意义. [/quote] 分布式构建对于工具的依赖性很强，不一定适合每个项目

目前比较成熟的分布式构建工具中

distcc - 只适用于 gcc，扩展到其他编译器有些困难 dmake - Sun 的，需要完全修改现有的 Makefile 语法 clearmake - IBM 的，基于 Makefile 但要安装 ClearCase 和 MVFS emake - Electric Cloud 的，基于 Makefile 但要安装 EFS

前两项是免费的，后两项相当贵。

有些公司有自己编写的分布式构建工具，但我比较怀疑可扩展性如何……

手头有一个例子比较能说明问题，我们有一个嵌入式系统要在 10 个平台上编译

之前用的是 “双核 8CPU” 的服务器，没办法并行编译，Daily Build 大概要 6 个小时

后来换成 “8 核双 CPU” 的服务器，10 个平台并行编译，Daily Build 只需要不到 1 小时的时间

另外，C++ 的编译和 C 的编译比起来，需要更快的 CPU，没做过其他语言的产品……

我看看热闹还可以，原创就不行了……

英文缩写词的发音也没有统一的标准，完全看个人喜好

GUI、GNU 这种缩写当成单词来念比较方便，拆开来读也完全没问题

但有些缩写就必须要拆成字母来读，比如 IBM、BBC 之类的……

这个没统计过，毕竟不是 HR

见过最快的大概要 10 年吧，当然也不是什么人都做的到

汉语拼音，一声。

类似的还有 GNU，都是按汉语拼音来读的

scmroad 于 2009-6-12 16:15 发表
不过，最近刚从公司听说最近 Dev 一个 Team 招人，月薪给开到了 5w，想想我可怜的工资。。。我忧伤。 [/quote] senior staff engineer 的行情价……

跟工作量有关系，我们这从 1 / 50 到 1 / 200 都有

但我估计比较成熟的环境下，1 / 100 应该是比较常见的

SAP 当初是从 ClearCase 迁移到 Perforce 上来的，至今也仍然在用 Perforce

至于这个 DTR，应该只是用在 ABAP 相关的开发当中，包括 SAP 的客户也需要使用这个 DTR

即使绕开技术不谈，把 ClearCase 或者 Perforce 集成到产品当中扔给客户，不知道要多花多少钱

我来公司的时间很短，还没碰见过升级，只听说过流程……

基本上公司自己的代码都会存放在单独的目录下，升级不是太大的问题，但是集成需要花一些时间

我们公司大量定制开源产品，高层说这是<企业文化>

FreeBSD，CVS，Subversion，GCC，GNATS，etc

不定期的会对这些产品做升级，我们自己的修改，有些自己留着，有些反馈给开源社区

而真正的第三方的库文件，是由开发团队自己管理的，我就不太清楚了

我们用 GNATS，感觉这种东西没一个好用的

即使不好用还不能随便换，数据迁移起来太费劲了

噢，感觉行情要比上面列出来的要好一些

其实也不会有特别准确的行情或者平均水平，工作的最初几年，薪水的个体差异肯定非常大

貌似百度薪水差别相当大，每个人爆出来的结果都不一样。

scmroad 于 2009-4-24 17:20 发表
没办法啊.职业性质决定了它的发展.

如果不转行,一直沿着 CM 在公司往上发展,最高能到 CM Manager,还有更高的职位么?
如果出去做兼职,做培训,做 consulting,可能赚钱会多一些.

有其它高回报的途径没?我也想赚更多的钱 ... [/quote] CM 做管理方向，极少见到级别特别高的，估计也是我孤陋寡闻

技术方向的发展相对要好很多，见过和 Director 平级的大牛仍然在做 CM，职位上仅次于 VP 了

CM 就是因为太安全了，结果很难做到特别高级的职位，高风险才有高回报……

Git 这种东西，自己用用还可以，但还远不是一个企业级的工具。

这篇文章说到底无非是一个 private versioning 的功能，AccuRev 很多年以前就提供内置的支持了。

我只是看看财报，具体的八卦就不太了解了……

Cadence 虽然领跑 EDA 市场，但近期亏损非常厉害，相比之下，Synopsys 的日子好过多了。

怎么说都是西门子，还是支持一下吧。

噢，应该是 “向上不封顶，向下不封底”

我的语文太烂了，好在你看明白了……