技术

Oracle clarifies plans for Java tools and OpenOffice

摘自 h-online

Oracle 更新了其处理现有 Sun 业务的计划的 FAQ (PDF 下载),变更的部分包括如下4个开源产品:

Classfish,将继续开发,it will be "actively supporting the large Glassfish community". The company does say that it will "invest in aligning common infrastructure" between its Oracle WebLogic server and Glassfish.

Netbeans,会继续作为开源产品提供,但要注意其面临另外的 Oracle 两个免费开发工具的竞争——Oracle JDeveloper, Oracle Enterprise Pack for Eclipse。 JDeveloper 将会作为 Fusion middleware 的开发工具长期存在, Netbeans 肯定不能再获得以前那样公司的关注了

OpenOffice 的未来则得到了保证,"After the transaction closes, Oracle plans to continue developing and supporting OpenOffice as open source". Oracle plans to offer a commercial license for OpenOffice for larger customers who require support and enterprise tools.

VirtualBox,将和 Sun 的其他虚拟化产品一样继续支持,但没有作具体的说明

最被关心的可能还是 MySQL,仍然只是“花费更多的资金来开发,和Oralce其他的数据库产品一起销售,就好比我们的 BDB, InnoDB 引擎等开源产品。。。。”

Topic: 商业 技术

关于 Mobile Web 开发中的 Content-Type Header

偶很久以前发布在内部 wiki 上的, :)

参考:http://www.developershome.com/wap/xhtmlmp/xhtml_mp_tutorial.asp?page=mimeTypesFileExtension

XHTML MP 可以使用三种文档类型

  1. application/vnd.wap.xhtml+xml

  2. application/xhtml+xml

  3. text/html

OMA 推荐的标准 MIME 类型为 application/vnd.wap.xhtml+xml . 在某些手机浏览器上,必须使用这个类型才能正确显示

application/xhtml+xml 也可以采用,这个是 XHTML 建议的文档类型 (W3C 标准)

但是,某些情况下可能还是需要返回 text/html 类型,这是因为有些老的浏览器不支持 application/vnd.wap.xhtml+xml 或 application/xhtml+xml,比如 IE 6 就会弹出一个对话框让你打开...

【既然我们是提供移动体验,为什么还考虑 IE6 这种东西呢???我的想法是,人们有可能在别的媒介上看到 m.vip.sohu.com 或者 m.mail.sohu.com 这样的域名,他们有可能会用 IE 打开来看看,对于这种情况,我们最好是让他能在桌面浏览器上也了解到这个页面的功能,而不是粗暴的让他下载一个 xml 文件。 (qyb)】

解决方案是:检查用户浏览器发过来的 Accept,如果它能支持 application/vnd.wap.xhtml+xml,那么 response Content-Type header 就是 application/vnd.wap.xhtml+xml ;如果能支持 application/xhtml+xml,那么 response Content-Type header 就是 application/xhtml+xml;如果什么都不支持,那就返回 text/html

另外,页面必须是 UTF-8 编码, GB编码的 XHTML 在某些手机上无法识别

Topic: 技术

闪电邮箱移动版本功能更新

在我们三周的产品更新计划里,10月15日这次发布对最终用户来说最大的增强就是移动访问能力的改善.

大概半年多前,我们已经去掉了对 WML/WAP 1.3 的支持——当时得到的一个数据是现存的手机有 80% 支持 WAP2.0,在售的手机有 95% 支持 WAP 2.0。这次进一步增加了色彩和图标的使用,让用户得到更佳的视觉体验,而且针对智能手机也做了一些优化。

无图无真相:

  • 微软刚刚发布的 Windows Phone 6.5
  • 这是 Palm Pre/WebOS, 传说电信要定制?
  • Android,也就是中国移动的 OPhone
  • 当然少不了iPhone,中国联通

GMail 大概维护了有4套webmail UI:普通Ajax/基本HTML/WAP/Mobile Ajax 。 我们精力有限,可以肯定 Basic HTML 不会提供了,或者说我们的 WAP 版本也算一个 Basic HTML ,在 Ajax Load 过程中,已经在提示用户可通过 m.mail.sohu.com 进行访问。我们会继续完善我们的这两套 UI, Mobile Ajax 有兴趣,但还没有规划。

最后,mail.sohu.com 这个入口是能够识别绝大多数的移动浏览器并自动重定向到移动版本 m.mail.sohu.com 上的,如果您的手机不是这样,希望能告诉我。//beg

下一次发布是 11/5

Topic: 商业 技术

xorg 也计划每半年一次的发布以及类似 Linux 的代码维护模式

由于这次 xorg 1.7 跳票十分严重,Peter Hutterer 建议对以后的版本开发以及发布进行改进,主要就是两点

1. master 只对 release manager 开放,和 Linux 开发模式类似——每个人在自己的分支上工作,由 Linus 负责合并其他程序员提交的 patch

2. master 维护阶段分成3步,merge window、bugfix、release freeze。他目前建议是 3M + 2M + 1M 的时间段,这样正好每半年做一次发布,也和 GNOME、Ubuntu/Fedora 的发布节奏吻合。

这种基于deadline的发布比起基于feature的发布来,商业性的意味更强一些,而少了工程师理想化的色彩....

最后要说的是,我注意观察了一下 QQ Mail 的更新周期,大概是每三周一次。现在我们团队正在实验类似的更新模式,对互联网产品来说,这种模式还是值得借鉴的。

Topic: 技术

很尴尬的成为 SSL 中间人攻击的教材

见:http://wuhongsheng.com/it/2009/09/ssl-hijack/ ,现在这个所谓的漏洞已经得到修补,暂时不打算跨省追捕这个吴洪声

附带宣布一下,继 vip.sohu.com 提供 https 服务之后,mail.sohu.com 也计划提供全程加密的 https 连接。技术在 vip.sohu.com 上已经证明可行——主要是灵活处理 URL,在普通模式下静态资源比如图片/JS使用 CDN;在 https 模式下使用 https://mail.sohu.com。

Topic: 商业 技术

2.6.32 的 scheduler 变化

引用:http://lwn.net/Articles/352863/

"kernel 2.6.32 前瞻"里提到过,在和 BFS 进行了对比测试后,程序员们将在 2.6.32 里修复原来 CFS 的一些问题,这里都有些什么呢??

首先是 NEW_FAIR_SLEEPERS 特性缺省会被禁止掉。这个功能是当一个进程结束睡眠返回运行队列的时候,gives it a small runtime credit。现在看起来这个东东实现得有些问题,未来解决后也许会重新打开。

该特性实际上现在就可以关掉。CFS scheduler 提供了 15 个 bool 值来控制其运行(原文是说它有32768种组合),我们只需要简单的

echo NO_NEW_FAIR_SLEEPERS > /debug/sched_features

或许你的桌面就运转如飞了。

还有一个变化就是 Child-runs-first。【虽然我们在操作系统课里学到,fork() 之后的代码段究竟是 parent or child 首先执行是不可知的,但实际上操作系统的行为绝对不是完全随机的,我猜在 CPU 不那么多的系统上更是如此。】最近 Linux 的实现里,子进程会被安排优先执行,从概念上来说这样设计是对滴,因为通常意义上子进程的工作更重要;但这个有可能影响性能:在此时父进程的上下文信息被当前CPU、TLB保持,立即切换到子进程会有些延迟。在 kernel build 测试里,Parent-runs-first 性能有了显著提高。

有人提出质疑,说这样的变动可能导致那些假设子进程会首先运行的程序异常。尽管我觉得那些不按理论规范只凭经验写程序的人碰到麻烦是咎由自取,2.6.32里还是很厚道的留下一个kernel.sched_child_runs_first sysctl调用去向前兼容。

最后是 cpuidle,为了社会和谐,现代高功耗的 CPU 都有这个 idle 功能。一方面是在低功耗模式下,切换到普通模式由于本身这个操作是相当耗能的,所以在低功耗状态下会执行得很慢;另外这种切换有一个性能损失造成延迟...甚至 BFS 也没有解决这个问题。有人已经弄出一个 patch 解决问题(具体算法去看 LWN 原文),有可能会被合并到 2.6.32 里。

Topic: 技术

kernel 2.6.32 前瞻

先介绍一下现在内核的开发模式:一开始Linus大概花2-3周的时间从其它人的git里合并代码,他肯定不可能看懂所有的代码,但我们也知道他也会拒绝那些他不太喜欢的代码;然后关闭 merge window,发布一个rc1,理论上所有的功能都freeze,剩下的只是 bugfix;这里也有例外,要看linus的心情而定,比如2.6.31的rc2里是又额外添加了新feature的;接下来差不多每周发布一个新的rc,在 7-10个rc版本之后,一个新的内核版本就正式发布了。总之现在大约是每11-13周有一个新的2.6.x出来

下面看看2.6.32

  1. 在 Greg KH 发出威胁后,微软的程序员终于在列表上开始了回应,似乎 Hyper-V 驱动还能继续在 stage 里呆着。微软必须学好怎么在 kernel 开发者社区中生存
  2. 某些程序员在和 Brain Fuck Scheduler 进行了对比测试后,发现了当前调度器中的一些问题,在 2.6.32 中会得以修正。看起来 BFS 永远也不会被合并到tree里,希望它的一些概念能给我们使用 linux desktop 带来更好的体验
  3. devtmpfs 是一个争议很大的特性,有几个人认为它很垃圾,但linus看起来不这么想。devtmpfs 又称为 devfs 2.0,好处之一是在内核自举的时候就把设备都挂到 /dev 上,节省了执行 udev 的时间
  4. DRBD... 终于也要进入内核了,事实上 devtmpfs 受到质疑的原因之一就是它对 DRBD 设备的集成. DRBD 算是一个简易廉价的存储HA实现,我知道以前 zhanzuo.com 就在用这个特性
Topic: 技术

闪电邮箱会话功能第二弹:会话计算和显示

gmail的会话合并是通过主题来完成;而且没有参考Header里的字段——做一个简单的测试:回复一封信,换一个主题,然后可以看到回复信和原件并不在一个会话里。

根据主题来确定会话是一定要有的,几个中文webmail只有163、QQ、sohu正确的实现了In-Reply-To,为了更大的兼容性必须如此。

搜狐现在的方案是,同时根据Message-ID、In-Reply-To、References,以及信件的主题来做会话的归属计算。所以在 GMail 里看到的会话和 Sohu 里看到的会不太一样。

GMail 仅仅使用主题来计算可能是优化这种情况:发信人很懒,每次写信都是从读信页面里选择回复,然后换个新主题,删除掉所有内容,而不是重新写一封邮件。我们以后是否也换成这个策略等用户反馈吧

或者可以更智能的从内容里面的引用关系、相关度去计算会话??现阶段还只能想象了。

某些情况下我们会主动 break 会话:

  1. 和第一封时间超过 30 天的 (想象一下你订了一个服务叫“今日股评”)
  2. 会话总数量超过 100 封 (太多了对阅读信件UI是一个灾难)

===============================================

有的时候,信箱里会有2封或多封Message-ID一样的邮件,最简单的情况是你写一封信给自己,这样已发送和收件箱里各有一封;或者你发一封信给邮件列表,邮件列表会重新给你寄一份。

在一个会话里看到两封一模一样的信不那么优雅,我们的规则是这样:

  1. 首先隐藏不在本文件夹的信(比如一封信发给自己,那么在收件箱中,看到的是投递过来的信;在已发送中,看到的是发送出去的信)
  2. 然后隐藏新邮件(这样也是为了防止攻击,恶意顶掉别人发的信件)
  3. 最后保证,一个会话只显示一个 Message-ID
Topic: 商业 技术

RedHat Enterprise Linux 生命周期

开源爱好者在系统选型的时候可能很少有人去仔细考虑商业产品的生命周期问题,但这个策略对系统架构实在是影响巨大。即使你是在运行CentOS这样的免费克隆,也应该对RHEL的相关知识了如指掌。详情去看 https://www.redhat.com/security/updates/errata/ ,我这里只是简单介绍:

  1. 每个RHEL版本生命期是7年
  2. 7年里分为三个阶段,Production 1 Life Cycle Phase、Production 2 L C P、Production 3 L C P。。。下面就用 p1 p2 p3 来缩写吧
  3. 大致来说P1是头4年,P2是第5年,P3是剩下的2年
  4. 不管产品在哪个阶段,都可以得到技术支持、安全方面的更新、以及bug修补。关于这个bug修补,RedHat是有选择的,只有那些被认为影响业务运行的才会被修补。
  5. 在P1和P2阶段会发布Minor Release。就是Update1, Update2...或者说4.1、4.2. P1 阶段的Update相当于微软的ServicePack——这种Update并不只是简单的补丁集合,而会包括功能方面的扩展和增强——比如最近的 RHEL 5.4 一个显著变化就是加入了 KVM 的支持(Xen将被RHEL慢慢遗弃);P2阶段的Update将不包括功能的变化。这种企业发行版本的一个特点也是在功能不断更新(4年之久)的情况下,还可以长期保证客户、ISV的向前兼容能力。P1阶段的每次Update都会发行新的安装介质,在P2阶段除非极端必要,否则不会有新的介质出现(这一点RHEL做得不如CentOS,哈哈)
  6. 在长达7年的时间里,除了要应付业务和软件的变化外,另一个挑战就是硬件变化。在P1 阶段RHEL会积极的将最新硬件(我猜主要是认证厂商的服务器)驱动backport。P2阶段则是有选择的更新硬件驱动,上面说了P2阶段不会再有功能变化,因此只有那些不会影响软件堆栈的硬件驱动才会加入。如果你一定需要在尚不支持的硬件上运行P3阶段的RHEL版本的话,RedHat的方案是:现在已经进入了第6个年头,最新版的RHEL此时应该在P1或P2阶段,客户可以在新的RHEL上虚拟化上一个版本。

最后总结一下:RHEL的头四年可以获得最佳的软硬件支持,GNU/Linux Stack 对商业运行来说有价值的更新会被backport(epoll就曾经这样被移植回了RHEL3的2.4内核);在第5年将只有部分的硬件支持,这个时候应该开始把业务迁移到新的RHEL上;在最后2年就只剩下bugfix,给客户一个平稳过渡的时期。


现在RHEL4的P2已经快要结束,还在使用RHEL4的同志们该开始考虑升级到RHEL5了;或者再等半年,2010Q1据说6就会发布了

Topic: 技术
订阅 RSS - 技术 | BT的花