245 items (10 unread) in 10 feeds
Blogs
(1 unread)
Tech
(2 unread)
Jamyy's Weblog
(2 unread)
LAMP
(7 unread)
PHP.net news & announcements
(1 unread)
FreeBSD Security Advisories
delphij's Chaos
(1 unread)
FreeBSD 项目新闻
风雪之隅
(5 unread)
许多老派的 FreeBSD 用户喜欢用源代码方式升级。运行了十多年的基于 cvsup 的同步机制由于有很多镜像支持因此一直没有遇到太大的问题，但是 FreeBSD 6.1 开始引入的 freebsd-update 提供了新的以二进制形式更新系统的方法，最近几年 FreeBSD 内核的许多改进已经使编译自定义的内核不再像以前那样重要了。
最近几天发布的 FreeBSD 7.1-RELEASE 引发了升级的热潮。由于 7.1-RELEASE 导致的流量冲击，而现存的 freebsd-update 服务器和 portsnap-master 是同一台，导致现在 portsnap 服务不太正常。目前 security officer 已经在建立新的 FreeBSD update 服务器。
之前和 A core 聊过这个问题。整理一下发出来。
这个话说的可能比较绝对，有人说，缺少信任的社会是可悲的----而我想说的是，现今，被过度滥用的信任则是可怕的。通过各式各样的社交网站，如 Facebook、LinkedIn、开心网、天际网等等（我想有人会提到 豆瓣，但是我个人认为豆瓣算是一个比较另类的社交网站，因为上面的人很少使用真名），很多人之间的联系被轻易地挖掘和利用。
类似"谁认识谁"这样的信息，在过去是不太容易获得的。而有了社交网站，一切都变得如此透明。一个人的人际关系如何？作为招聘的HR，只要到这样的网站上检索一番就能够一目了然；想要让一个人身败名裂？很简单，从身边的人下手----几年前，在blog还没那么普及的时候，我就收到了一封匿名的"检举信"，讲的是某低年级同学在某地所做的丑事，导致该君到处写信灭火，而事实？只是寻衅报复----互联网使得信息的传播变得比人类以往的任何时候都要更加迅速，当然，正如很多可以分成靠谱的和不靠谱的东西一样，海量的信息带来的则也包括了海量不靠谱的信息。
和很多人一样，我对于要求填写个人信息的注册表格有非常强烈的抵触情绪。我为什么要相信一个网站或公司能够确保这些信息不被未经授权的第三方得到？事实上，正如对软件所做的各种保护一样，主流安全公司所做的所谓验证，无非只是一种心理上的安慰----这家公司采用了比较严格的流程，使得你的隐私信息，例如姓名、地址、信用卡号，等等，不太容易被攻击者得到----比如说，这些信息只能一次性地写入到服务器，之后只能得到其中的后几位，而那台记录这些信息的服务器受到了更为严格的保护----但是，只要这些信息能够被任何这家公司的工作人员读取，那么，它就不可能是绝对安全的。
你相信大型邮件服务提供商，例如 Google、MSN、Yahoo、网易、新浪 能够保证邮件的安全吗？我想，海量的用户带来的巨大的关注成本以及这些公司招聘时候对入职人员的进行的考察所保证的职业操守，足以让我相信做为一个普通用户，完全可以信赖这些邮件系统；然而，如果你的通讯涉及到巨大的商业或其他利益，事实上，基本上没有有效的办法去阻止邮件在不知道的情况下发生丢失或被泄露给通讯双方所不知道的第三方。
从工作在客户端的间谍软件，到大楼的网管，再到互联网服务提供商（到互联网骨干，再到IDC等等），再到服务器所属的那家公司----如果考虑收信的一方，那么还要再多加一倍的可能入侵的环节，更重要的是----你的通讯多数时候是明文的。加密并不能解决全部问题，除非能够有有效的方法确认收件人的身份，并保证路上不出现故意的"遗失"，还要保证，在你能够把文本加密之前，所用来编辑和加密的系统是可信的。
互联网时代没有隐私。永远不要说"永远不"，但是我还是想说，如果不希望某些信息公之于众，那么最好的办法仍然是把它烂在肚子里，而不是放到互联网上某个让你觉得别人永远找不到的角落。类似地，也不要把能够很容易地获得的信息太当回事，这个世界上有很多不够小心的人，但这并不代表，这个世界上的人都不够小心。
哦，对了，写这篇文章是因为看到了 MD5 considered harmful today，终于有人凑出了一个CA证书。是的，加密也不一定有用了。
来自李笑来老师的blog(原来在新东方上过他的GRE课)的《如何找到属于自己的兴趣》。
帮人发的。北京某公司，地点在中关村。
要求：熟悉Windows Server，独立管理过ExchangeServer半年以上，独立管理过Windows Active Directory半年以上，熟悉网络基础知识，对IOS有初步了解（非背题通过CCNA者尤佳），在生产环境或桌面环境或实验环境使用过Unix类操作系统三个月以上，对Unix类操作系统感兴趣，对系统运营工作感兴趣。
预期年薪6－9万，文化程度等不限。能抬起25公斤物体者优先。
有意者请用简历轰炸 laypeople@hotmail.com。
我这次不铁口直断了，估计明年见了，如果这周能够RC2的话，最终RELEASE估计要到明年的1月5日左右。
这次FreeBSD 7.1在软件工程角度是相当失败的案例，我想我们应该从里面总结一些教训出来。
首先，我们的目标是什么？
我想，用户对于一个发行版本的期待是：一个经过了大量测试的、阶段性的稳定版本。而开发人员对于发行版本的期待则是尽可能地将可用的功能交付给用户。作为OS，我认为这应该包括自动化的回归测试、性能改进、更新的驱动程序、文档的修订，以及更新的第三方软件等等。
FreeBSD目前的开发模式，是将分别开发的三大模块，即内核与基本系统(src/)、文档(doc/)、第三方软件(ports/)的人在一定的时候聚集在一起，通过代码冻结的方法来使他们从增加新功能转移到集中去修bug，最后发布一个版本。这个模式在过去运转的相当好，以至于我们没有发现其中存在的问题。
这次FreeBSD 7.1暴露出来了这个模式存在的很多问题。例如，由于安全小组发现了很多安全漏洞，而另一方面，安全小组的人手不够，限制了修正这些问题的速度。我本人撰写的一个安全公告等了一个月才在今天最终公之于众，而另一方面，安全小组对于发行版本拥有一票否决的绝对权力，导致6.4和7.1的发布都一再推迟。
而作为非常快节奏的开发的 ports/ 维护者，则对不断的推迟感到相当不满。FreeBSD目前只维护 ports/ 的 -HEAD，也就是说，在正式发行 -RELEASE 之前，ports/ 不能进行大量的、破坏性的修改。例如，我本人维护的 OpenLDAP 现在就必须等待 -RELEASE 之后才可以进行升级。不断地推迟新的发行版本，会导致 ports/ 的开发继续延迟。
多种因素作用在一起的结果是，这次7.1-RELEASE的发布让所有的人都不太满意。
我想，想要解决这些问题，需要从几个方面入手。
首先是功能冻结和代码冻结的时间。目前，FreeBSD的做法是src/和ports/几乎同时开始冻结，但是实际上 src/ 需要花费的测试周期要比 ports/ 多。举例来说，一次正常的 -STABLE 发行版本所需要的测试和除错周期大约是 8 - 10 周，而完成一次 ports/ 联编所需要的时间则只需要 48 － 160 小时，并且这个过程是持续进行的。我认为我们必须定义一个功能冻结点，这个点之后，不再允许在 -STABLE 分支中增加任何新的API/ABI，然后以这个版本（例如-RC1）为基础进行 ports/ 的联编。另一方面， ports/ 是否有必要随 src/ 冻结？我认为意义不大，因为多数用户并不会使用光盘附带的 package，甚至于使用 -STABLE 的 package 会成为阻碍在 -STABLE 分支中增加新的 API 的障碍，这样一来，在人手有限的情况下，人力不如去维护一个每季度创建一次的稳定 ports/ 分支（只升级其中的安全更新；只维护最多两个分支；确定交付时间），而 -RELEASE 则随同最近的一个这样的分支去发布。
在升级支持方面，目前FreeBSD发布新版本的周期显得过长。这会带来两个问题：其一，在无法预测何时会发布发行版本的前提下，用户如何安排升级？其二，在这样一段较长的时间内，如果出现新的硬件，发行版本光盘无法及时更新，而普通用户更新光盘中的驱动程序则比较困难。
为了因应这种情况，我认为我们应该将现有的 X.Y 发行版模式改为 X.Y.Z 发行版模式。其中，X每18个月发布一个新版本，Y每6个月发布一个新版本，而Z的发行周期则视需要而定，每一个新的Z版本均发布对应的ISO文件，而其中除了重要的安全和可靠性更新之外，也包含经过较长测试的、对于新硬件的支持改进，作为对 -STABLE 快照的补充。
最后的问题其实还是，我们的发行版本的目标用户人群是什么？我希望能够得到一些来自用户的反馈。还有一个好消息是，这个礼拜我们总算有希望能看到RC2了......
说明：这个实际上是一个workaround，不过我暂时没时间修这个bug。这是一个作弊条，主要目的在于解决这一特定问题而非阐述其背后的原理和最佳实践。
方法：通常启用/上面的SoftUpdates（默认情况下FreeBSD并不启用/上面的SoftUpdates，因为/通常容量很小，开启SoftUpdates意义不大）。正常启用/上面SoftUpdates的方法是启用到单用户模式，然后用tunefs -n enable /来启用SoftUpdates，然后立刻重启。
远程启用SoftUpdates，因为通常无法让机房或机器旁边的人操作，因此进入单用户模式是不实际的；另一方面，如果以读写方式重新挂载 /，则会导致SoftUpdates设置被覆盖，因此不能通过写文件来标记。
具体的做法是使用下列 /etc/rc.early 脚本。注意：这个并不是最简/最优的方案，只是一个能用的方案。
#!/bin/sh
mount -o rdonly /usr
( /sbin/dumpfs / | /usr/bin/head -n 20 | /usr/bin/grep soft-updates > /dev/null 2>&1 ) || (tunefs -n enable / && reboot)
umount /usr
操作成功之后删除 /etc/rc.early 即可。
在Hotmail里面收到了很多假开心网的邀请信。点开一看，恶心的来了：填好了MSN地址，然后让你填密码。
这家公司真恶心。
很快就要正式发布FreeBSD 6.x系列的最后一个（第五个）版本了。FreeBSD 5-STABLE发表了3个版本（5.3、5.4、5.5），FreeBSD 6-STABLE比它多两个。我对于FreeBSD 6.x系列在6.2之后的发展基本上不太满意，这次这个版本我想也是类似地，修正了一些之前版本的bug，增加了一些新硬件支持，但是显然这些与7.1-RELEASE相比是远远不够的。个人建议现有的6.x用户升级到7.1-RELEASE。
上次在MeetBSD的时候Tim提到了一种处理大量静态页的办法。今天看Squid开发人员在NYC的BSD活动上的一个演讲里面也介绍了各种方法处理I/O的区别。
大量小文件是脑残的做法。意味着大量浪费buf cache。
善用mmap等现代OS特性来规避不必要的开销。但是varnish也遇到了问题，即如果内容不能完全放在内存里面就会导致性能急剧下降。
之前 A core 说过一个100、10、1的规律，不知道我是那个100个想到的，还是会做到原型的10，或者会是那1个在生产里面用上这种做法的？
一段时间之前我曾经和很多人讨论过使用ZFS作为/的可能性。现在看来，这个也未必真就是一个很好的主意。
目前FreeBSD 8-CURRENT已经完全支持从ZFS启动了（换言之，连 /boot 也不需要了），方法是透过 GPT 分区（我最近MFC了最后一套gpart的补丁回7-STABLE，gpart将在7.1-RELEASE中以一种可用的形式出现）的gptboot。简单地说，配合ZFS v13和支持ZFS的gptboot，FreeBSD就可以从ZFS启动了。针对RAID-Z和RAID-Z2的支持也在计划中。
但是，我认为现阶段使用ZFS做／仍然是风险相当大的事情。
有几个比较重要的原因。当然首先最重要的原因是ZFSboot目前不支持RAID-Z或RAID-Z2，对典型的ZFS用例（使用单盘而非在RAID卷上创建ZPOOL）来说这显然是不适合的，然后是ZFS作为/的时候，所有直接在/文件系统上的内容是无法通过其快照功能回滚的（题外话，FreeBSD内核处在以/dev为/的时候，如果使用一些不好的hack是可以做到的，也就是说告诉人家说回滚到某个快照即将完成，请重新启动系统，然后在重启过程中做）。如果做系统的时候不知道这件事，以后用起来就会比较麻烦，而另一方面，实际上/需要回滚的机会，除了使用开发版本的纯爷们们之外，似乎也不是很大。
因此，目前来说ZFSboot主要的作用是省掉笔记本上1-2GB的UFS /boot的容量。但其实即使是这样也会有问题----我们一般希望使用尽可能少的东西去恢复系统，比如说，你可能不希望在笔记本硬盘出现问题的时候还要手忙脚乱地刻张光盘出来......假如/是ZFS，那么除非它是另外一个zpool（这个是Sun的最佳实践推荐的），要不然recoverdisk的时候就需要从活动的FS上去复制数据，很明显，这样做可能导致复制出来的数据是坏的。而假如/是一个单独的zpool，又会面临另一个问题----ZFS是一个仍然在开发过程中的文件系统，内核升级的时候，是否做upgrade？如果upgrade之后起不来怎么办？另一方面，嵌入GPT boot分区的那个ZFSboot很可能不认识新版的ZFS，这些都会是问题。
这样，至少在现在，看起来保留包含/boot、/etc这些部分的/，然后将ZFS作为存储挂到/var、/usr/local这些地方是更好的做法。在多盘系统上，则可以将/复制出来两份存在另一块磁盘上，以实现容灾。而在其他硬盘上可以将/的容量分给交换区或者ZIL，以确保所有硬盘上的RAID-Z[2]分片尺寸一致。
今天MeetBSD由Pawel Jakub Dawidek开讲，等，为啥出来的是xterm......？然后OpenOffice Impress从命令行启动了。
ZFS是大家最关心的一个话题。Pawel最近这段时间对ZFS做了相当多的完善工作（主要是写测试用例和改用例发现的bug）。新版本的ZFS v13除了大大改善了可靠性问题之外，还增加了很多有意思的功能。不过这样一来，这patchset的尺寸？（后话：后一天的committer闭门会议，在大家的一致怂恿下ZFSv13终于给commit到了-HEAD）提问非常踊跃，我们最大的白老鼠之一，运营Internet（作为ISC公司的雇员）的Peter Losher就他遇到的一些问题进行了询问，并且得到了满意的答复。
Murray老大在这之后对这次Google SoC进行了总结。FreeBSD这几次SoC的项目成功率都很高，唯一的遗憾是在SoC之后，很多没有最终进入-HEAD。在肯定SoC的成功的同时，如何更好地利用？很多SoC的代码品质并不是很高，如何求得完成目标与高品质代码之间的合理平衡？这些都是我们需要思考的问题。
Robert Watson代表 FreeBSD基金会 对2008年募捐、预算执行等事项进行了总结，并向为FreeBSD作出了突出贡献的 Kris Kennaway （Google公司，在性能改良方面做了非常多的工作）和 David Wolfskill （Juniper公司，我们默默无闻的 postmaster）颁发了荣誉奖项。
下午的活动主要是philip关于crypto加速的介绍（这部分是我基本上不怎么碰的东西）。crypto加速也有类似的反加速效应问题，raw速度有时甚至比直接用CPU算还慢，优势只有在真忙的时候才体现的出来。
Josh Paetzel介绍了他们在系统运营中利用pf来达到无缝jail升级的做法。瞬时切换不同版本的Apache等等。这个利用到的组件比较多，并且随运行的服务不同，也需要很复杂的数据切换才行；对于类似PostgreSQL这样的应用，这种做法还有一个问题是两个jail不能同时开同一个数据集，因而限制了它的应用范围。
接下来上场的是来自Isilon公司的Zach Loafman，他主要不是介绍技术，而是Isilon与FreeBSD之间的关系。Isilon赞助FreeBSD开发的哲学是：We pay to get it done right, and we will pick up later，他们先后赞助了FreeBSD的MPSAFE VFS、NFS lockd、RPCGSS等，未来还将继续支持NFSv4等的开发工作。
最后是Kris讲的如何做性能分析，这个讲解主要是针对SA的，介绍了FreeBSD提供的工具、如何迅速查找和分析问题等等。
总体来说这次MeetBSD 2008非常成功。会后的闭门会议也解决了很多积压已久的问题。
今天起了一个大早，9:00到了位于 1600 Amphitheatre Parkway 的 Google 总部。
手头没有精确的人数统计，不过目测来看，大概有120－150人。看到的第一个见过照片的人是著名的 Cameraman 同学， DragonFly 的 Matthew Dillon 老大！
由于今年是 FreeBSD 计划成立15周年，今年的 MeetBSD '08 California 很大程度上是一次 FreeBSD 的活动。
第一个发言的是 Robert N. M. Watson 博士。他做的 Presentation 是关于 FreeBSD 网络协议栈最近几年的改进。Julian Elischer 和 Matthew Dillon 分别和他讨论了关于网络协议栈虚拟化，以及在多核系统中如何在单核性能和改善并行度两者之间找到一个比较好的平衡的问题。Robert提到，在新的系统中，同步开销已经由于硬件的改进而大幅下降，因此，在新硬件中上锁产生的开销已经不再会导致在单核上有明显的差距，而此时更好地利用核上cache能显著的改善性能（另外他也提到，在较旧的硬件上使用FreeBSD 7.x+的SMP内核的单核系统的性能会比非SMP内核性能有明显的劣势，而对新硬件而言则没有这种区别。（之后Matthew Dillon拽了Robert Watson到一边单独讨论去了。后话：那边人越聚越多......）
第二个发言的是 AeroSpace Corporation 的 Brooks Davis，讲的是科学计算集群。这个presentation更多的是科普性质，比较了不同种类的隔离之间的优缺点（分布式分时系统的管理成本较低，但性能较差；SGE那种类型的提供了较好的性能和隔离性，但管理成本比较高；VPS例如FreeBSD jail的隔离是不完全的，另外灵活性有一些限制，例如不能在FreeBSD上面jail一个Windows出来，等等），他同时提到了资源限制和partitioning的问题。比较有意思的是他们的cluster用到了 md(4) 来做 TMPDIR；他们移植了 DragonFly 的 varsym 特性，看起来这个功能還是相当有用的（可以让不同的run解析出来不同的symlink目标）；此外，他们还利用了7.1新增的cpuset特性来帮助将任务绑定到不同的CPU上，cpuset特性改善了调度的可预测性。
中午吃饭的时候终于看到了活的Kris Kennaway。拍了一些其他大牛的照片，特别是我们的 Mighty Postmaster (TM) David Wolfskill。
下午， Cisco 的 M. Warner Losh 介绍了一些嵌入式开发的经验和趋势，以及目前需要人手的部分（为Flash类存储优化的FS、简化的rc.d框架等等），有兴趣的同学可以试试看。
接下来是Kris Moore讲PC-BSD。PC-BSD采用的方法是覆盖FreeBSD中的文件，这个让我觉得挺诧异的（因为这样做的话，如果这些被覆盖的文件有了更新就需要比较手动化的处理了），不過总体说来，他们在包管理方面做了很多有助于帮助最终用户接受的改进，例如PBI，等等。PC-BSD支持GJournalled UFS和ZFS，等有时间要拿他的光盘试试看。
Dru介绍了BSD Certification的情况。今年2月已经开始提供BSD Associate的考试了（听她的介绍，应该相当于国内的初级系统工程师，也就是有6个月左右工作经验的人），而BSD Professional考试也在筹备当中。
下面是我比较感兴趣的Kip Macy的Xen的介绍了。目前FreeBSD -CURRENT(i386/pae+smp)已经可以跑在Xen里面了，他们也在做Amazon S3方面的工作。不过今天没有讨论太多关于Xen本身的细节，例如I/O调度的公平性等问题。Kip同时表示他暂时不打算跟Xen dom0死磕，而是要先把domU的64位支持，以及native驱动这些东西做好再说。他同时展示了一组性能数据，比较奇怪的是关闭TSO会使80％的情况产生性能提升。
洛杉矶的闻名于世，很大程度上与这里发达的电影工业有关。同时，在这里还有世界上建成的第一个主题公园----迪斯尼主题公园。
不过比较遗憾的是，去 Disneyland 的当天天气不是很好。
第二天和老婆去了环球影城（Universal Studios）。环球影城主要是展现了电影拍摄的很多场景，特技制作等等。注意！如果你带着相机去的话，现在是把相机收起来的好时候了，因为多数场景都会向游客喷水......
好莱坞电影工业很可怕的一点是----他们能真搞一架飞机来......
由于时间关系，我们从环球影城出来之后，就开始往回开了。原本以为返回的路程会相当枯燥乏味，结果发现事实并不是这样。5号公路虽然是一条很笔直的公路，但路上的景致也相当不错。
（全文完）
写这种 数典忘祖 的东西也得有点底线吧？
我倒是想问作者： Would Linux exist without Internet？
现代操作系统中，抢占式调度是一个很有意思的话题。
教科书对于抢占式调度的定义比较简单----抢占式调度中，任务切换动作可以由于优先级变化而触发，而并非仅限于时间片用完或主动放弃CPU（当然，一般而言我们并不认为中断处理是一次严格意义上的抢占操作）。
从直觉上看，抢占式调度必然增加潜在的上下文切换次数，并因为增加了这些开销而降低系统吞吐量。那么，为什么要引入抢占式调度呢？
答案是：减少响应时间，或者说，让系统能更及时地响应高优先级的请求。
例如，在多处理器系统中，运行在其他处理器上的线程释放 mutex 的时候，可能会引起其他休眠中线程的优先级发生变化（例如，由于能够计算等待的时间，导致全部等待线程的优先级均提高）。这时很可能就需要进行抢占操作，以便让这些线程恢复执行，等等。
抢占式调度的缺点是，首先，它会提高系统发生死锁的机会，或者，更准确地说，它能够触发一些以前不易触发但真实存在的 竞态条件（race condition）；其次，通常抢占会增加一些调度开销，导致系统吞吐量的下降。
还有一个经常会被问到的问题是，如果将时间片缩到足够小的程度，那么是否可以达到与抢占式调度相同的目的呢？我认为这个问题基本上可以回答"是"，然而，小时间片往往意味着更大的调度开销。
加州的1号公路是一条沿太平洋修建的公路，路边的风景很美。
不过尽管如此，这条路也有一个很严重的缺点，就是经常会有几十mile的距离没有任何岔路可以开到其他公路上。由于地势险要，沿途的加油站的油价都比普通的内陆地区要高出很多，有些地方甚至会高出50％。
于是，最担心的事情还是发生了。经过一段时间的休息，我们继续前进。油表还剩大约1/12的时候，我们遇到了一家要价 $6.75/gal 的加油站（当时北加州同等级别的油价大约是 $4.15 左右）。我心想前面一定还会有加油站，于是赌气没加。
一路下坡，但是走了大概10 mile之后，油灯亮了，囧！
一般的经验，油灯亮起来之后，车子通常可以继续行使接近1 gal汽油所能支持的距离，但是租来的车子这些性能并不是很熟悉。我立即关闭了车上的收音机、空调等装置，并将GPS拔下。因为之前一直都是较缓的下坡，所以看起来往回走也不会很省油，看来只能硬着头皮往前走了。
没想到又走了三、四英里之后我们看到了另一个让人泄气的牌子----前方加油站：27 mile。手机----没有信号。
我立刻想起了一对带着孩子的韩国夫妇在俄勒冈州森林公路里面汽车抛锚的事情。
一路call box还没有几个，带的食物和水够不够支持我们把车推到加油站？我想应该是够了......没办法，继续走。
很幸运的是，车子在到达加油站之前没有把油耗干。这家加油站较之之前那家更为简陋，简陋到连信用卡都不支持，在支付了20美元现金之后，总算是加了些油。稍事休息之后，继续上路。
沿途又路过了一些休息站等等，按下不表。由于路上一些地方消耗的时间太多，我们决定改变原计划，越过Santa Monica海滩（遗憾）直接进入洛杉矶城。
