## flexcoin全世界第一家Bitcoin銀行

Bitcoin是互聯網上一種虛擬貨幣，欲知更多自己搜索下，已經有很多文章介紹了。

Flexcoin.com是網路上第一家基於於Bitcoin的銀行。Flexcoin使你可以在全世界所以可以連接到互聯網的地方使用Bitcoin。

Flexcon是整個Bitcoin體系中一個非常重要的部分。我們的技術使我們可以為用戶做到通過用戶名快速轉賬到一個用戶名下，而不是一串奇怪的數字標志的用戶名。如下：
Before Flexcoin: 1555hjPG7pRwTHVMfukPvjXexQMHFE3qu6
After Flexcoin: coffeeshop

Flexcoin解決了Bitcoin貨幣體系中一個很大的問題。

Flexcoin出現前，當別人給你發來Bitcoin，你只有從你初次接收它的設備上操作它。你不能夠，至少不能輕易地通過你的手持設備或者其他什麼設備使用它。一般地講，只有在你初化接收和發送Bitcoin的機器上才能操作Bitcoin。通過使用Flexcoin，你甚至可以把Bitcoin發送到一個電郵地址。Flexcoin的設計使即使不怎麼懂技術的用戶也能夠使用。

Flexcoin做的工作看起來很簡單，他提供了一個集中的處理你所有Bitcoin財產的地方。Flexcoin就是全世界第一家Bitcoin銀行。你可以通過任何可以使用Web的設備用一個賬號來管理所以屬於你的Bitcoin。

Flexcoin也是整個Bitcoin界的安全引領者。比如，Flexcoin是第一個實現了在電郵件絕不放置URL的機構。從Flexcoin發出的電郵絕對不會有鏈接或者圖象。如果你收到一封違反剛才聲明的電郵，那一定是欺詐郵件。

Bitcoin的官方網站是 www.bitcoin.com

## MediaWiki入门教程

MediaWiki是这个世界上使用人数最多的百科建站系统。全球最著名的Wikipedia.com就是用MediaWiki建立的。另外，MediaWiki是在GPL协议下免费开源工程，这意味着你可以免费使用它。下面将介绍如何使用MediaWiki.

## 怎么使MediaWiki只能够被私人使用？

# 禁止未登录用户编辑内容.
$wgGroupPermissions[‘*’][‘edit’] = false; # 禁止用户注册，除非系统管理员创建用户。$wgGroupPermissions[‘*’][‘createaccount’] = false;

## 怎么创建一个页面？

== Create a page ==
* 把词条输入搜索框，然后搜索。
* 搜索结果显示没有匹配到任何页面，这时有一个选项让你创建一个页面。
* MediaWiki标志语言(MediaKiki Markup Language也常被称为:wikitext)可以在 http://www.mediawiki.org/wiki/Markup_spec 找到。
* 各种编辑页面的例子可以在 http://meta.wikimedia.org/wiki/Help:Editing and http://meta.wikimedia.org/wiki/Help:Wikitext_examples 找到。

## 怎么改变MediaWiki的Logo呢？

MediaWiki的内部链接的颜色有两种，一种是红色，一种是绿色。当内部链接的颜色是红色时，表示还没有收录这个词条，如果你点击的话，会提示你建立新词条。如果是绿色，则相反。

## It’s a mistake to include Xen in a Linux distro

As the title show, it's a mistake to include Xen in a linux distro. Why?

Somebody would argue that Xen is a very useful technology. Xen does the virtualization work very well and many projects are using Xen which prove Xen is so great.

I'm not mean Xen is not good. However, just because Xen is a hypervisor that is based on another microkernel that is not Linux kernel itself. Linux distros that ship Xen today actually are running an entirely different Operating System kernel that most users even don't notice that. Xen should be a separate, purpose-built kernel, so it should never be a part of the Linux kernel. Isn't it strange that you think you are running a linux OS, but this 'linux' has a kernel that is not linux, which is another kernel. You take away the Linux kernel, how could you say the OS is Linux.

Just before the born of the Linux native virtualization KVM, the distros shipped Xen because there exist no other choices. Many Linux developers at that time know little about virtualization. Xen seemed a pretty easy and pretty good choise. So the Linux community made the hasty decision to ship Xen instend of investing in makeing Linux's own hypervisor. But now KVM has come for more than five years(since kernel 2.6.20 in Feb, 2007. KVM actually has a longer history. It was out there before being merged into mainline kernel code.) and KVM has proven itself to be completent to replace Xen. The most important thing is that KVM as a part of the linux kernel leverages the features of kernel like memory management, process scheduling and so on, making the kernel a perfect hypervisor. So, there is no reasons to ship Xen in Linux distros any more.

## 什麼是敏感指令

1974年，Popek和Goldberg在美國电脑協會的通訊期刊上發表了一篇論文"虛擬化第三代架構的一般性要求"(Formal Requirements for Virtualizable Third Generation Architectures)。在這篇文章中，提出了敏感指令的概念。

——-

ykyi.net 翻译

## 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.

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

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处变动。这里所说的变动仅仅指能够被合并到主干的补丁包，而那些被拒绝的补丁包没有被统计进来。

#### 坏的补丁包

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

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.