traceroute failed.Specify protocal traceroute used manually to fix it.

Today, I ran the traceroute program on a machine running FreeBSD. It failed once and again.

Traceroute complained:

traceroute: sendto: Permission denied.

So I tried to ping. Ping failed, too. I then checked out the configuration of the firewall, which actually denied the pass through of ICMP packet. So I set it to allow ICMP pacakges to pass through the firewall. Ping worked as I expected. But traceroute still failed.

I was very confused, I tried to run the tcpdump to find out why. Tcpdump showed that traceroute was sending UDP packet. Oh, my gosh. I had always thought traceroute was implemented on ICMP. After I read the tcpdump manpage. I found traceroute default on using udp protocal, but user can switch to use icmp by indicating the -M icmp or -I(The capitalized i). Alternatively, you can also command traceroute to use raw packet of specified protocol for tracerouting by specifying -P(beware P is capitalized). When you use raw packet, the default protocol is 253 (rfc3692). So, I ran traceroute using the command as: traceroute -P ICMP www.the_host.com, everything worked fine.

COPYRIGHT WWW.DOGEYE.NET

如何正确地提交内核补丁包

原文:https://lwn.net/Articles/500443/

翻译:blog.ykyi.net 

Greg Kroah-Hartman(又Greg KH)在执行一个了不起的作务:减少内核开发者,尤其是维护者的暴躁情绪。他在日本横滨举行的全球Linux大会上的讲演呼吁公众理解内核维护者的工作,内核贡献者的什么样的行为会导致内核维护者变得暴戾。但是,如果内核贡献者们能够遵守一些约束,他代表他自己做了许多承诺。

Greg Kroah Hartman把Linux内核称之为"有史以来最宏大的软件开发项目",而且它的开发速度也是“亘古未有”。从3.0到3.4,有373个公司的2833位开发者参于了Linux内核的开发。这一年,(2011年的5月到,2012年的5月),Linux内核在每个小时会有5.79处变动。而且这个开发速度仍然要加速,如果你看看3.4的开发过程,每小时共有7.21处变动。这里所说的变动仅仅指能够被合并到主干的补丁包,而那些被拒绝的补丁包没有被统计进来。

补丁包修改了哪些文件,内核开发者就把补丁包发给负责这些文件的维护者。所以的内核维护者,现在大概有700人。他们把改变应用到130个子系统的维护者那里。再从子系统的维护者到Linus的Linux内核代码分支。最后并必Linux内核的主干。如果提交的补丁包一路通过的话。

因此,来看看为什么一些补丁包不会被接受呢?Greg Kroah Hartman以刚过去的两个星期收到的补丁包为例,这两个星期刚好处于3.5版本的Merge Window时间。Merge Window是一个他确不应该接收到许多补丁包的时间段。他应该在Merge Window开始前收到所以有可能会在Merge Window其间被发往Linux Torvalds的补丁包。不过,他说他在这两个星期的时间里收到487个补丁包。其中的大多数都有很多问题,有些补丁包来自那些本应该对内核有更好理解的内核开发者们。

坏的补丁包

Greg KH举例说明了一些他收到的坏的补丁包。其中一个补丁包被命名为:patch 48/48(一个有48个补丁集的最后一个),但是其它的47个都没有。他还收到一堆补丁但没有写清楚先后顺序。如此,他要么猜测一个顺序,这毫无疑问会失败。另一个替代方案就是安全不管这个补丁了。另外还收到过有10个补丁的补丁集,但是2号补丁确丢失了。

另外有一个通过邮件发送来的补丁包被声明“机密”。Greg KH说他经常收到此类方式的补丁。对于此类补丁,你无能为力。因为Linux是在开放的生态中开发的,你不能够给邮件列表发送一个机密邮件偷偷就合并一个补丁。很明显,这种方式发来的补丁是因为在处理邮件阶段的模板造成的,但是'机密'必须被去掉。

还有不良排版的补丁包。比如所有的Tab符都被转成了空格,Microsoft Exchange常常这么做。如果对于你,开发环境是个问题的话,那可以像IBM,Microsoft或者还有其它公司那样,在角落里再放一台Linux机器给开发者用来发送邮件。有时候diff的输出的行前空格都被剥去了,或者diff的输出并不是unified格式(见另一篇博文,讲述如何用diff生成linux内核补丁包)。虽然久经考验的Linux开发者们可以熟练的编辑原始diff输出格式,但是diff的原始输出本身是件很令人恐怖的事情,他们本不应该被如此对待编辑它们。

有些补丁包是在错误的目录下被创建的,比如在一个驱动器目录下。有个补丁包在/usr/src/linux-2.6.32目录下被创建,但是这个补丁包里面有好些错误,包括源代码树的年龄,而且它隐含假设它是在root上构建。在root上构建是相当之危险,如果linux的构建过程中出现一个bug,就有可以把整个文件系统都删除。没有一个内核核心开发者留意到了这个情况,因为他们没有使用root。有建议说把这种bug留下来当成一种威慑力(原作者开玩笑),自然不会被采纳,不过那么极端的危险情况是真的有可能发生啊。

还有离谱的,有些补丁包是针对一个本来与这个补丁包毫无关系的代码树。Greg KH说他曾经收到一个补丁包针对SCSI代码树,实在想不通这个与SCSI毫无关系的补丁关怎么会针对SCSI代码树创建。

然后还有代码风格的问题。有些补丁包没有使用Linux内核的代码风格。提交补丁包的开发者也知晓这个问题,但是他们似乎在说“我不管,让我的代码通过吧!”Greg KH说,现有一些工具可以帮助定位到有这些问题的代码并修复它们。所以,没有任何借口发送不符合代码风格的补丁包。

Greg KH还着重说了编译不能通过的问题。他说,有些内核内核贡献者把不能通过编译的补丁包也发过来。或者有些补丁包集3/6失败了,在6/6修复了。我甚于收到过补丁包在5/8失败,但是作者附带了一个说明说作者在未来某个时候会发来改正方案。另外还有补丁包很明显没有正确的内核文档部分,因为在构建文档的时候会失败,很明显补丁包的创建者根本就没有运行过内核文档抽取工具。(不想译了,太多了…呜~~累死了.)

One of the patches he got "had nothing to do with me". It was an x86 core kernel patch, which is not an area of the kernel he has ever dealt with. But the patch was sent only to him. "I get odd patches" a lot, he said.

The last patch he mentioned was 450K in size, with 4500 lines added. Somebody suggested that it be broken up, but in the meantime several maintainers actually reviewed it, so the submitter didn't really learn from that mistake.

All of this occurred during a "calm two weeks", he said. These are examples of what maintainers deal with on a weekly basis and explains why they can be grumpy. That said, he did note that this is the "best job I've ever had", but that's not to say it couldn't be improved.

If someone sends him a patch and he accepts it, that means he may have to maintain it and fix bugs in it down the road. So it's in his self interest to ignore the patch, which is an interesting dynamic, he said. The way around that is to "give me no excuse to reject your patch"; it is as simple as that, really.

Rules

Kroah-Hartman then laid out the rules that contributors need to follow in order to avoid the kinds of problems he described. Use checkpatch.pl, he said, because he will run it on your patch and it is a waste of his time to have to forward the results back when it fails. Send the patch to the right people and there is even a script available (get_maintainer.pl) to list the proper people and mailing lists where a patch should be sent.

Send the patch with a proper subject that is "short, sweet, and descriptive" because it is going to be in the kernel changelog. It should not be something like "fix bugs in driver 1/10". In addition, the changelog comment should clearly say what the patch does, but also why it is needed.

Make small changes in patches. You don't replace the scheduler in one patch, he said, you do it over five years. Small patches make it easier for reviewers and easier for maintainers to accept. In a ten-patch series, he might accept the first three, which means that the submitter just needs to continue working on the last seven. The best thing to do is to make the patch "obviously correct", which makes it easy for a maintainer to accept it.

Echoing the problems he listed earlier, he said that patches should say what tree they are based on. In addition, the order of the patches is important, as is not breaking the build. The latter "seems like it would be obvious" but he has seen too many patches that fail that test. To the extent that you can, make sure that the patch works. It is fine to submit patches for hardware that you don't have access to, but you should test on any hardware that you do have.

Review comments should not be ignored, he said. It is simply common courtesy if he takes time to review the code that those comments should be acted upon or responded to. It's fine to disagree with review comments, but submitters need to say why they disagree. If a patch gets resent, it should be accompanied with a reason for doing so. When reviewer's comments are ignored, they are unlikely to review code the next time.

Maintainer's role

When you follow those rules there are certain things you can expect from him, Kroah-Hartman said, and that you should expect from the other maintainers as well. That statement may make other maintainers mad, he joked, but it is reasonable to expect certain things. For his part, he will review patches within one or two weeks. Other maintainers do an even better job than that, he said, specifically pointing to David Miller as one who often reviews code within 48 hours of its submission. If you don't get a response to a patch within a week, it is fine to ask him what the status is.

He can't promise that he will always give constructive criticism, but he will always give "semi-constructive criticism". Sometimes he is tired or grumpy, so he can't quite get to the full "constructive" level. He will also keep submitters informed of the status of their patch. He has scripts that will help him do so, and let the submitter know when the patch gets merged into his tree or accepted into the mainline. That is unlike some other maintainers, he said, where he has submitted patches that just drop into a "big black hole" before eventually popping up in the mainline three months later.

He ended by putting up a quote from Torvalds ("Publicly making fun of people is half the fun of open source programming. …") that was made as a comment on one of Kroah-Hartman's Google+ postings. The post was a rant about a driver that had been submitted, which even contained comments suggesting that it should not be submitted upstream. He felt bad about publicly posting that at first, but Torvalds's comment made him rethink that.

Because kernel development is done in the open, we are taking "personal pride in the work we do". As the code comment indicated, the driver developer didn't think it should be submitted because they realized the code was not in the proper shape to do so. It is that pride in the work that "makes Linux the best engineering project ever", he said. Sometimes public mocking is part of the process and can actually help instill that pride more widely.

Linux内核维护者的职责

原文: http://www.linuxfoundation.org/news-media/blogs/browse/2012/06/role-linux-kernel-maintainer

翻译: blog.ykyi.net

几个星期前在日本举行的Linux大会(LinuxCon)上,我做了一个演讲,题目是"Linux内核维护者,他们在做什么,如何能够帮到他们"。

这个演讲的视频可以通过这个链接看到。如果你想要幻灯片,和我的讲演稿,可以在这个地址获得。

如果你之前觉得为什么一个开源工程的维护者对发给他/她的东西总是如此古怪乖戾,那我强烈推荐你去看看我为这个演讲写的笔记,或者幻灯片,里面包含了所有的笔记。

另外,如果你想要知道如何才能令你的内核补丁包得到通过,请先看看上文提到的幻灯片,我不想过多重复了。

嗯,有一个例外!

首先,看起来我的这个演讲引发了一连串热烈的讨论。最最开始是因为Jake Edge在lwn.net上一篇精彩的总结(这篇文章我有翻译前半部分,点击这里),引来了大量评论各有大量围观群众。这些人中的绝大部分应该没有看过上面提到的幻灯片,也应该看到我的演讲的视频,无论如何还是激起了大家的兴趣。普罗大众总是会因为某些人在大吵的时候兴奋地在一旁围观。

接着,Jon Corbet撰文加入了争论。他做了一个非常非常好的总结:开源工程的维护者们总是被海量的低质量提交沦陷,总是要日复一日地不停地回复已经被回答过好多次的同样问题。人们看起来从不去阅读文档,而通常在文档里就能找到答案。再一次,强烈建议你看看上文提到的幻灯片或者笔记或者视频。刚才提到的两篇文章也值得一读,包括下面的精彩评论。

(什么,你还没有订阅过 lwn.net,为什么不订阅呢?真是为你感到羞愧啊!现在还不快去订阅?) 译者注:订阅lwn.net是要支付付用的。原作者在文章中给lwn.net做广告呵呵。

后来, Linux内核峰会的召集期限已过,收到的很多提议都是关于内核维护者的。他们的工作量,如何解决已经出现的棘手问题。如果你有兴趣的话,可以在 这里 了解到到底我们在为什么抓狂。 

对于我演讲里所讲述过的内容,在这里我还想重复的是:身为一个内核子系统的维护者,对于那些给我发送关于我负责的内核部分的内核补丁包的开发者,我如下承诺:

  • 我会在一到两个星期内复审你的补丁包(参见下文)
  • 我会对你的补丁包提出准建设性的批判意见。
  • 如果你提交的补丁包被拒绝的话,我会给你被拒的理由。如果补丁包被接收,我会告诉你补丁包会被合并到哪个分支,你可以从哪里看到它以及什么时候你可以看到它最终被合并到linus的分支中。

就这样。对于提交者,我希望看到格式良好,文档丰富,可以整洁地应用到代码树的补丁包,而且做了真正有用的事情。这样的话,你我都会很开心,是吗?

对意下一到两周的回复时间:

当然了, 如果我生病了,或者我正在这个星球上某个地方旅行。我的回复就会适当延迟。你绝对可以随时发邮件给我询问你的patch的状态。我很乐意回复这些邮件。我宁可一一处理好所有这些询问邮件,而不是让等待了几周的开发者发疯。

另外,要注意一下合并窗口(Merge Window)的问题。在整个Merge Window阶段,我不能接受任何在我的分支Release上还没有修正所有已知bug的补丁包。所以这意味着,通常在Linus的Release前一周开始,一共三周的时间内,我不会处理你提交的补丁包。在这段时间内,上百份补丁包会堆积起来,所以请给我一些时间让我从补丁海里面脱身出来。一般到-rc3的时候,我就赶上了,但如果没有呢,人可以写邮件给我咨询。

copyright blog.ykyi.net

 

中山大学软件学院11级硕士研究生2012年上学期软件项目管理期末考试试题

如题,这是中山大学软件学院02年上学期期末的软件项目管理期末考试试题 for MSE 11.

The final exam of Software Project Management in the first semester of 2012 for MSE 11, Software School, Sun Yat-sen University.

一 概念题,名词解释(每题5分,共30分)

1. WBS (Work Breakdown Structure)

2. CPM (Critical Path Method)

3. 里程碑 (Milestone)

4. RAM (Responsibility Assignment Matrix)

5. SPI (Software Process Improvement)

6. 决策树

二. 问答题(每题10分,共70分)

1. 请具体解释项目管理知识体系的九大知识域?

2. 如何理解迭代式开发,有何优缺点?

3. 什么是CMMI? CMMI的五个级别各有什么要求?

4. 简述软件项目的风险管理过程。

5. 如何估算软件项目的成本。

6. 项目经理应用哪些能力?为什么?

7. 请具体解释五大项目管理过程组。