感慨 SCO 的没落

logo-bgblue.gif

这个圣诞对 SCO (Santa Cruz Operation)公司高层来说肯定不轻松,Nasdaq 通知信确认 SCO 将从12月27日被摘牌,这是一场终于到来的噩梦。IBM、红帽子、Novell 肯定会对这事儿拍手称快!

当年 Linux 风头正健的时候 SCO 居然下嫁给 Caldera ,无数人惊呼,”Unix 已死,Linux 当道”,真实情况却并不是这样。没多久,Caldera 就发现 Linux 在市场实在不受待见,用户也不买 “Caldera” 这个名字的账,结果 2002 年又更名回 SCO。当时还拉了一堆虾兵蟹将搞 “统一 Linux” (United Linux) ,也是属于“十八路诸侯讨董卓”的路数,没过多久就瓦解了。SCO Unix 在市场上属于找不到北的那种的,基本上比 Novell 还没感觉。

SCO 这几年混的也太臭,简直一副无赖嘴脸,仗着自己”有” UNIX System V 的代码版权,对 IBM 的 10 亿美金诉讼赔偿简直是”碰瓷”行径,只不过 IBM 也不是善茬儿,陪你玩到底;SCO 还不甘心,干脆把大家都拉进来,四面数敌,到处勒索,结果光是诉讼就搞得满头是包。最富有戏剧性的是今年 8 月份,一纸裁决下来,宣判 UNIX 与 UnixWare 属于 Novell 的,这对 SCO 简直是釜底抽薪,只有缴枪的份儿了。

想当年,在国内, SCO 占据了国内 Unix 绝大部分市场,那时候 SCO Unix 相关的图书也是卖到洛阳纸贵。中软和东方龙马是相当大的两个分销商,而这两个公司也走出了国内无数的 Unix 技术人才(这两个公司的发展状况和 SCO 倒是也有几分相似之处)。前几天和一位中软前同事吃饭,谈及此事,仍是不胜唏嘘。我刚毕业的时候,在中软的一家子公司工作,一部分业务就是操作系统分销,当时就感觉这玩意儿有点过时,但是国内很多单位(比如邮政)对 SCO Unix (主要是 Open Server)依赖性还是很大,我算是赶上了末班车,说起来,对 SCO 也算是有很深的感情啊。

市场是残酷的,时间也是残酷的。SCO 快死掉了,多少年后我也会怀念 OpenServer、Unixware 这些产品。

EOF
EOF

关于 Oracle 的 IO 响应能力: 10 毫秒的来历

最近在 ITpub 上有几个讨论 IO 的帖子很热闹,其中一个讨论中 Biti 说”响应时间在 10ms 左右能达到的最大 IOPS 能力,是系统 IO 能力的一个最重要指标” ,下面好多网友不知道这个 10ms 怎么来的,以及为什么是 10ms .

其实如果你熟读 Oracle 手册的话,你会发现 10g 中已经涉及到这个 “10ms” 的信息了,而且,侧面透漏出很多潜在的细节。

在 Oracle 10g 中有一个新的参数: DBIO_EXPECTED ,这个参数指 DB 平均读取一个 数据库块的时间,单位是毫秒(millisecond)。由 ADDM( Automatic Database Diagnostics Monitor)用以分析系统 IO 性能的参考值。默认是 10ms ,之所以取这个值,是因为当前企业内投入使用的硬盘(存储)一般一个 IO 时间(读取一个 DB 块)大约在 10 ms 之下,超出 10 ms 一般意味着在 IO 跑得有点费劲了。这个 10ms 是个经验值,但这个经验值是有来由的。

有些慢速硬盘,比如希捷 Barracuda® ES.2,寻道时间接近 10毫秒,一些老一点的 SATA 盘肯定更慢了;而 Cheetah® 15K.5 则大约只是 3ms-4ms 的样子(DBA没事的时候不妨看看硬盘厂商的白皮书,挺好玩的)。一个 DB 系统上线时,测试一下 IO 基准能力还是必要的。注意测试的时候出现的”拐点”,意味着这个时候的 IO 响应时间是至关重要的,因为这个时候 IO 即使有应用Cache、 数据库 Cache、(主机 Cache)、存储 Cache,也还是有大量 IO 压在了后面的磁盘上,如果磁盘的 IO 到了峰值,IO 层的能力也就到了峰值了(特定响应时间下的最大 IOPS)。多数系统上,应该在 10ms 附近。所以,你盯着 DB 上离散读的平均响应时间,到了 10ms 意味着快撑不住了。

要如实使用 ADDM 衡量 IO 状况,DBIO_EXPECTED 参数还是需要作一点调整的。要注意这个参数并不是初始化参数,如果需要重新设定,则需要提交如下语句修改:

EXECUTE DBMS_ADVISOR.SET_DEFAULT_TASK_PARAMETER('ADDM', 'DBIO_EXPECTED', 4000);

上面的数值单位是微秒。

数据库 IO 是一个非常有意思的话题,本来想写一系列的东西。结果这篇写出来发现不伦不类。权作抛砖吧。

EOF

年底当心小偷

今天又有同事遭遇小偷了,幸运的是小偷没得手。后来同事跟我说,那两个小偷在他后面还跑的气喘吁吁,估计跟着他跑了一条街才找机会下手,做小偷也不容易,看人家多敬业! 下午的时候,合作伙伴的朋友来访,告诉我他的 iPhone 前几天在车上丢了。再前一段时间也有个同事差点在路口被抢走 iPhone。

其实最近一段时间,已经有不少同事不断爆料,就在公司楼下,小偷异常猖獗。快到了明抢的地步了。

这一切说明了什么? 快过年了,小偷也想捞一票回家啊!

杭州本地小偷似乎不多,多数都是从外地杀进来的,据说看面貌很像维族兄弟,我相信维族兄弟们绝大多数是善良的,但是不乏也有少数败类败坏了维族同胞声誉。提及“维族”很容易被误解为民族歧视(如果说新疆人更有人不愿意听,说中国人、黄种人的话还没人知道具体特征),别误会,汉族里的小偷数量肯定更他妈的多,我当年在东北老家就被家乡人民偷了一次呢,但个体不能代表全体。小偷都是类似的,只有被偷的人才是不同的。

元旦,春节,也算小偷的两个黄金周了,一年就赶着这段时间出活呢,所以大家多加一点小心。走在路上,把包背在身前,这样子有点傻,但也比丢了东西强。上天桥、过马路,手最好在口袋里抓着手机、按着钱包,即使现在手机便宜,可丢了的话,联系人重新输入不也是挺麻烦? 要是里面有个隐私啥的就更不好办了。

愿天下无贼!

EOF

此文作者:, 位于 Review 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

年度回顾:2007 年最常用的 Web 2.0 服务

2007 年就快过去了。这一年中, Web 2.0 应用对我的网络生活影响程度更大了一点。回顾一下,除了过去经常用的 del.icio.us、Flickr 等「老一辈」的 Web 2.0 服务外, 今年新熟悉了几个 Web 2.0 服务。

Twitter — Micro-blogging Service

截止到写这篇 Blog 为止,我在 Twitter 上有超过 1000 条更新,Followers 接近 250 个。算得上是个中度用户,中毒还不算深。

Twitter 刚上手不知道怎么玩,但是玩起来还有点容易上瘾。必须要承认 Twitter 是个时间杀手,我过去也担心这东西带来的信息过载,有的时候会有比较大的信息噪音,比如那些绑定了 Feed 到 Twitter 上的朋友,对于 Feed 通知更新太频繁的我都屏蔽掉了,现在尽管每天接收大量 Twitter 的 Updates ,但总体感觉信息还是比较有质量。

顺便说一下,我用 TwitterFox 这个 Firefox 插件。用 IM 收发更新容易受到被动干扰。有些担心有一天 Twitter 会被阻尼,但我不打算用国内的克隆版,使用这些 服务也是为了体验创新的产品设计。

LinkedIn — SNS Service , Business-oriented

在尝试 LinkedIn 之前,我是若邻 (Wealink.com) 的用户,但若邻的整体用户氛围现在非常让我比较反感,尤其是很多人打着「猎头」的头名来套瓷,还有社区内的很多人一天到晚的转发帖子,信息噪音太大了。LinkedIn 上的用户还是比较规矩的,没事也没人来干扰你。

LinkedIn 是《连线》杂志评选的 2008年十大最值得关注创业公司,符合我要用就用同类站点中最好的习惯,你总不想某天找不到自己辛苦积累的信息吧? 之所以起用 LinkedIn 这样的服务,还是觉得有必要积累一点个人资本,认识一些国内外业内的朋友,互相通通气。我在 LinkedIn 上的 Profile 连接超过了 75 个,估计还能逐渐增加一些,话说回来,LinkedIn 上 Google 的员工,平均每人也只有 47个联系人」。车东在上面有超过 500 个连接,可以作猎头了。

其实面临求职的朋友不妨在 LinkedIn 或者类似的服务上维护一份自己的简历,事半功倍。

其他的 SNS 服务,如 MySpace 或者是 Facebook ,我不打算用。没那个精神头了。

Google Reader — Information Gateway

自从 Feedburner 被阻尼了之后,不得不抛弃客户端工具 GreatNews,而起用在线 RSS 阅读工具,另外一个考虑是性能问题,订阅 Feed 超过 1000 个后,GreatNews 更新非常消耗本地资源。虽然抓虾也不错,但我基本上是用抓虾看看热文,大部分的阅读还是在 Google Reader 内,看到不错的文章就 Share 一下,通过 RSS 集成到 CNOUG.net 上,便于 DBA 圈子内的其他朋友也及时看到,共享嘛。

Google Reader 最近的好友间阅读共享功能也很有意思,虽然多数人都在质疑这个功能有泄漏隐私之嫌。我个人觉得可以通过算法来调整这个设计上的漏洞。Google 不是一项强调数据说话麽? 那就来点更智能化的东西吧。

这两天也在尝试 Soup.ioFriendFeed 这两个东西,直觉中明年要启用其中的一个。你在去年尝试并喜欢那些 Web 2.0 服务? 说一下吧

EOF