compare the evolution of hard irq implementation, you will find that hard irq numbers has shifted from 0x20~0x2f to 0x30~0x3f, but why someone need this change?

http://lxr.linux.no/#linux+v2.6.26/include/asm-x86/mach-default/irq_vectors.h
http://lxr.linux.no/#linux+v2.6.32/arch/x86/include/asm/irq_vectors.h

from oldlinux such as v0.11, as analyzed version as Doctor Zhao Jiong did, an old version just use it for the hardware limit, in the old 8259 interrupt controller days, the hardware 8259 is cascaded by 2 chips, and its real capability is only to handle 8 hard interrupt, by cascading style of implementation, there's another number is occupied by cascade, so there's only 7+8 = 15 interrupt numbers, every PC operating systems just re-program the 8259 IC, except for the intact PC standard, its 0x8~0xf for the first, and 0x78~0x7f for the second cascaded one, that can work well under 8086 Intel real mode, the DOS operating system keep it unchanged, and use int 0x21 as the system call service, then Linux re-program it as in the protected programming mode, for CPU internal usage, it reserved 0x0~0x1f 32 interrupt numbers; for the sake of x86 instruction encoding style, "int 0x80" is encoded as "0xcd 0x80", the interrupt number is just occupying one byte, so the CPU hardware limit is 256 int numbers, minus 32 reserved for CPU internal usage, it's 224 left, also as stated in the v2.6.26 irq_vectors.h comments said; Linux just use 0x80 as the system call interface, and shift/re-program 8259 to 0x20~0x27 and 0x28~0x2f; so the other range 0x30~0x7f, and 0x81~0xff are all unused; SMP architect is still strange, it generates special interrupts btween 0xee~0xff (238 ... 255); according to some recent secret unleashed, microsoft windows utilized 0x2e as the interrupt number, so the Linux int numbers changes just kept an reserved space for the unified kernel project; maybe it should be merged into mainstream someday;

 *
 *  Vectors   0 ...  31 : system traps and exceptions - hardcoded events
 *  Vectors  32 ... 127 : device interrupts
 *  Vector  128         : legacy int80 syscall interface
 *  Vectors 129 ... 237 : device interrupts
 *  Vectors 238 ... 255 : special interrupts
 *

http://www.oldlinux.org/

刻录完毕 Fedora-12-x86_64-DVD.iso 没有标准蓝色笔, 改用红色笔写上标签

发现故事于近期 LinuxWeeklyNews 之 Quotes of the week (语录) 环节：
http://lwn.net/Articles/359270/

The fact is, maintainership does _not_ mean ownership. It means that
you should be _responsible_ for the code, and you get credit for it,
but if problems happen you do NOT "own" it. Not at all.
If you don't understand that, you shouldn't be a maintainer.
-- Linus Torvalds
事实是，维护不是意味着你拥有这部分代码；而是你要对它负责任，你从中获得荣誉和别人的称赞；而当问题发生时，你并不承担错误；完全不是；

可以进一步这封邮件的全文：
http://lwn.net/Articles/360156/

这封出自 Linus 的邮件第一句话就是 "You're full of sh*t." (你就是一坨屎) ...

如果你再有时间和兴趣，还可以进一步阅读讨论线索之全文，以了解整个事件之来龙去脉：
http://thread.gmane.org/gmane.linux.kernel/908831/focus=41872
邮件线索原始标题： "请考虑重置 commit 7d930bc" (即反转 commit 7d930bc 的所有修改)
1) Dmitry Torokhov 报告 2.6.32-rc5 中 cfg80211 (也就是 wireless 部分) 出现 Kernel Oops, 经过一番艰苦 git bisect 之后，发现引起问题的原因在于 commit 7d930bc, 重置这号 commit 之后可以解决；可见这确实是一个邪恶的 commit, 而且 git show 显示它引入于 2.6.32-rc5 之后；
2) David Miller (net-2.6 总管) 说在我的 net-2.6.git 树已修正了，稍晚会推送给 Linus;
3) 这时 Marcel Holtmann 忽然说了句 这个事件是这样解决了，但类似事件我们是不是可以改进下工作流，更多考虑下 最直接那个 MAINTAINER 的看法？ (Wireless 的 cfg80211 和 nl80211 接口部分维护人是 Johannes Berg) 让他能有个说句话的机会，而不是直接跳过去了？
4) Johannes Berg 说话了，"唉，类似问题困扰已久" 指的是工作流上，当问题发生时，人们都直接找 Linus 或其它几位顶级 MAINTAINER 要求重置了那个出问题的 commit, 甚至也不通知一下 那个 commit 的原始作者和我们这些底层的 MAINTAINER, 导致我们反而后知后觉，后面 merging 过程中麻烦多多；所以能不能先发给我们，以标题类似于 "发现问题于 某 commit, 我们看怎么解决？"
5) Dmitry Torokhov: 我不明白问题出在哪里，我都已经抄送给 wireless 邮件列表了，我觉得在 -rc5 之后我们要迅速地解决问题
6) Johannes Berg: 我不反对要迅速解决问题，你当然可以直接发给Linus要求直接revert，我只是说能不能先发给MAINTAINER(也就是我了)，我们有了更好的办法再汇报给Linus不晚哪，因为有时候 仅仅一个 revert 是不够的，因为原来那个 commit 肯定也是解决了某事情，如果我们直接 revert 可能会导致更糟糕的事情；这种工作流显得更为友好；而不是只被列在Cc里面，好像MAINTAINER的意见只是第二位的；
7) Dmitry Torokhov: 是说 To: 和Cc: 差别待遇吗？好了好了，下次我把你们全列在 To: 里面好吧
8) Marcel Holtmann: 近期我也发现有这种趋势：人们就不管三七二十一，上来就要示 revert, 然后才考虑解决真正的解决问题；
9) Linus 发火了： "你就是一坨屎" BUG 终究是BUG 就要被 revert 掉；那些在 merge window (rc2) 之后还引入 BUG 的人们应该被钉在耻辱柱上；一个 commit 引入的问题比它修正的要多，你说我们是不是就该要 revert 它？
10) Andrew Morton: subsystem maintainers 通常都很不靠谱
11) David Miller: To Andrew: 这很 平常 (common), 但不是普遍的 (universal)
12) Andrew Morton: David, 顺便把这几个 patch 从 -mm 树给接过去？
13) David Miller: 没问题，已应用至 net-2.6 树；其中有个 isdn-eicon-return-on-error.patch 又在用自动格式化工具玩大便 (holy crap someone run that driver through some auto-formatting tool!)
14) Linus Torvalds: 坦率地说，我还是对这个bug是非常的不满意：1) 它是 -rc5 之后引入的 2) 它被多人 bisect 出来，这浪费了多少人的时间？ 3) 此 commit 的原始作者(Johannes Berg) 在被告知了 具体哪一个 commit 导致的问题却还想从报告者那里等待更多的信息(你都已经被通知这号commit有问题了，你就不能自己搞定吗？)；
15) Marcel Holtmann: 当然是需要修正，但盲目地 revert 可能导致其它副作用； And to be honest, Johannes Berg 在解决 wireless 问题上还是很积极的；
16) Linus Torvalds: 每个人都知道出一问题要修正它；但真正的问题是"我们要最快地修正它" revert 就是最快的办法 我等不及 subsystem maintainer 来修正它；(To Marcel)你别光说讨好的漂亮话了；你错了，你应该感谢 Dmitry ，请求原谅浪费了他的时间；
17) Marcel Holtmann: 其实四天前我的邮箱就有了 Johannes 发过来的 解决办法的 patch 了，你的意思是要我当时就 越过 MAINTAINER (Johannes and David Miller) 直接把它发送给你？
18) Linus Torvalds: 你要我们的用户再多等一天还是再多等五天？ 在 -rc5 之后出现的问题我们要在最快的时间把它修正，即使不是最优的结果，但我们的测试用户有多少时间给我们浪费的？ 我们要做的就是 "Deal with it", And yes, 有时候 "Dealing with it" 就意味着必要时绕过维护者。 最差的情况下 我们有这样一个严格的管道在必要时 让用户不必在 MAINTAINER 路上等待太多时间
19) Marcel Holtmann: 我也同意。但是公平说，这个 bug 并不是影响着所有人 ...
20) Linus Torvalds: 不是的，你又错了。我是被动卷入这个线索的，其实看一眼那个 commit 就知道那个 memcpy 就有 NULL pointer dereference 问题。有人撞上了这个 problem 这就够了
21) Ingo Molnar 插入： 列举 Johannes 前两天的一封回复邮件，以说明其(Johannes)回复是 无用的， 不负责任的 (Unhelpful, defensive, in denial.) 你的 "hey, nothing happened, we fixed it after all" 表示你对此的无知，此类可避免的事故在将来还会重演
22) Marcel Holtmann: 谁这么说话了？那不是我说的好不好？
23) Ingo Molnar: 没在说你。是说上面写那个邮件的那个人，上面已 quote (就是 Johannes 写的) 部分
24) ... 有时候BUG比较复杂，1天还搞不定；这就证明了你是不够 responsive; 接着讨论要做到什么样才能叫做 responsive, 多少时间响应？ ...
25) Linus Torvalds: 拜托，两天看起来是不多，但我们的 merge window 关闭已有5个星期了，我们马上就要发布 (2.6.32) 了

Linus 对 Kernel 还是相当严格，顺便也提到 Mailing list 这个 "Immediate but asynchronous" 交流方式的优点，

顺便 David Miller 提到有人还在玩 auto-formatting tool 提交补丁，这种在刚开始入门时尚可，入门久了，再玩就没什么意思了，还会引起人家反感，请看这里的二楼评论；
http://roclinux.cn/?p=1440

BTW, 近期发现 有人 做的 KernelPodcast 不错，以语音的方式为大家播报最近 Kernel 进展和人物事件， 可以同时 作为内核 学习 和 英语 学习材料：只是希望可以持久下去， 这样的工作除了 LWN 可以作为全职以外，一般人恐怕很难持续下去：
http://www.kernelpodcast.org/feed/

Open source participation in Asia be encouraged

This week, I've attended two open source related events here in
Singapore, they are Professors' Open Source Summer Experience
asia-pacific sponsored by Redhat, and Singapore Ruby Brigade (SRB),
that gathering location near Boat Quay is also wego's working offices;

http://teachingopensource.org/index.php/POSSE_APAC
http://singaporerubybrigade.pbworks.com/

The SRB was apparently more technical-centric and a good event for
hackers and real developers like me; some speaker talked about the
ruby rails cucumber, its new Behavior Driven Development (BDD), and
everyday git working flow, someone still think subversion is better,
but have a consensus that CVS is horrible, and outdated. After that
event, we all also had another meal of refreshments and walked
alongside the bank of Singapore river, talking more about ruby and
open source, their application status in Singapore and in the whole
south-east Asia; and, there were some students from linuxnus.org,
certainly linux is also another topic of discussion. Comparing to
China, open source and linux adoption here is also very limited, the
open source guys circle here is also small, one of them told me, "I
almost know every linux people here;" so you can imagine how large it
is. We supposed kinds of scenarios for firms' linux adoption, but
maybe the significant factor here is decision-maker's thoughts, who
knew them? From the long queue outside the M$'s shop for its new
production arrival last month, in my opinion they were just wasting
money; and from this perspective we know that open source here in sg,
in southeast-asia, the whole asia, still has a long way to go. Or we
can express the future in our optimistic way: "Open source here is
very promising, and has more tremendous potential".

But what a pity, my digital camera is broken several months ago when
still in China, I didn't take any photos for these wonderful events.
Besides when in the Riverside Point, the photographer staff of redhat
had taken many photo for all teachers form all corners of Asia, maybe
we can watch them several days later. And another camera for myself is
also critical, I shouldn't miss any important following days, but
separate camera with 1200M better or just a smart phone (5M+ pixels)?
who knows, still in consideration.

Maybe in the end, you need more introductions about these two kind of companies,
You don't know redhat? That's unplausible;
You don't know wego? Maybe, it's a travel search engine, enjoy your
good experience with it (wego.com).

test blogger from with email

--
Cheng Renquan (程任全), from Singapore

http://lwn.net/Articles/357451/

Welcome back of Con Kolivas , originally another aggressive linux kernel hacker,

* 2009 La Casa della Musica, Parma, Italy - Website, A/V Streams & Slides

LAC (Linux Audio Conference) is held annually and this year it was in Italy in April, and from its papers and slides, it can be observed that frugal may be the next right direction.

你知道 Intrepid Ibex (勇敢的巨角羊) 操作系统 (Ubuntu 8.10) 吗？

之前写过一篇 Blog

• 你知道 Intrepid Ibex (勇敢的巨角羊) 操作系统 (Ubuntu 8.10) 吗？

在这里，能找到这个系列又多了一个

1. Karmic Koala (命运的树袋熊) 9.10 Released in October 2009

最近又发现了一系列有意思的名字，就是 Linux 内核的发布代号：

这个代号隐藏于 每一内核发布的 Makefile 文件中，第5行是

git show v2.6.30-rc5:Makefile |head -n5
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 30
EXTRAVERSION = -rc5
NAME = Vindictive Armadillo

其中 Vindictive Armadillo (怀恨的犰狳) 就是了。

倒推过来是

1. v2.6.30 Vindictive Armadillo (怀恨的犰狳) (Not Released Yet)
2. v2.6.29 Temporary Tasmanian Devil (临时的 Tasmanian 恶魔)
   
3. v2.6.28 Erotic Pickled Herring ()
   
4. v2.6.27 Rotary Wombat ()
   
5. v2.6.26 Rotary Wombat
6. v2.6.25 Funky Weasel is Jiggy wit it
7. v2.6.24 Arr Matey! A Hairy Bilge Rat!
8. v2.6.23 Arr Matey! A Hairy Bilge Rat!
9. v2.6.22 Holy Dancing Manatees, Batman!
10. v2.6.21 Nocturnal Monster Puppy
11. v2.6.20 Homicidal Dwarf Hamster
12. v2.6.19 Avast! A bilge rat!
13. v2.6.18 Avast! A bilge rat!
14. v2.6.17 Crazed Snow-Weasel
15. v2.6.16 Sliding Snow Leopard
16. v2.6.15 Sliding Snow Leopard
17. v2.6.14 Affluent Albatross
18. v2.6.13 Woozy Numbat
19. v2.6.12 Woozy Numbat
20. v2.6.11 Woozy Numbat

A simple way with curl to post code snippet to ubuntu paste:

$ curl -v -d 'poster=chengrq&syntax=python' --data-urlencode 'content@/home/gektop/bin/diff-filter' http://paste.ubuntu.com
* About to connect() to paste.ubuntu.com port 80 (#0)
*   Trying 91.189.90.174... connected
* Connected to paste.ubuntu.com (91.189.90.174) port 80 (#0)
> POST / HTTP/1.1
> User-Agent: curl/7.18.2 (x86_64-pc-linux-gnu) libcurl/7.18.2 OpenSSL/0.9.8j zlib/1.2.3
> Host: paste.ubuntu.com
> Accept: */*
> Content-Length: 3002
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
> 
< HTTP/1.1 100 Continue
< HTTP/1.1 302 Found
< Date: Fri, 08 May 2009 01:29:08 GMT
< Server: Apache/2.2.8 (Ubuntu) mod_python/3.3.1 Python/2.5.2 mod_ssl/2.2.8 OpenSSL/0.9.8g mod_perl/2.0.3 Perl/v5.8.8
< Location: /166435/
< Content-Length: 0
< Content-Type: text/html; charset=utf-8
< 
* Connection #0 to host paste.ubuntu.com left intact
* Closing connection #0

I need a diff (or patch) manipulation utility, but unfortunately I have not found one, then I wrote one, of course, it's in Python.

#!/usr/bin/python

import sys, os

# Usage: diff-filter [-v] path1 path2 ...
#                    <INPUT >OUTPUT
if len(sys.argv) <= 1:

    print "Usage: %s [-v] path1 path2 ... <INPUT" % \
            os.path.basename(sys.argv[0])

    sys.exit(1)

# some global variables
inChunk = True

strip   = 1
matched = False
buffer  = ''

invert  = False

# to invert the filter
if sys.argv[1] == '-v':

    invert = True
    del sys.argv[1]

# the main filter
while True:
    line = sys.stdin.readline()

    if not line:
        break

    if line.startswith("--- ") or \
            line.startswith("diff") or \
            line.startswith("Binary") or \
            line.startswith("Index"):

        matched = False
        inChunk = False

        if line.startswith("diff") or \
            line.startswith("Binary") or \
            line.startswith("Index"):

            buffer += line
            continue
        else:
            path = line.split()[1]

            slash = path.find('/')
            path = path[slash+1:]

            for arg in sys.argv[1:]:
                if path.startswith(arg):

                    matched = True
                    break
            else:
                matched = False

        if invert:
            matched = not matched
        if not matched:

            buffer = ''

    if inChunk:
        print line,

    if matched:
        if buffer:
            print buffer,

            buffer = ''
        print line,

It also can be reached by the ubuntu paste service:

http://paste.ubuntu.com/166435/

Application field: if you have a big diff generated by "diff -R", and want to split it according to some seperate path or components, you can use this. Happy hacking!

Albert H. Einstein

When I was a fairly precious young man, the nothingness of the hopes and strivings that chases most men restlessly through life came to my consciousness with considerable vitality.
Moreover I soon discovered the cruelty of that chase, which in those years was much more carefully covered up by hypocrisy and glitterings words than is the case today.
By the mere existence of the stomach everyone was condemned to participate in that chase.

To the great Albert.

登记 gnupg 公钥

PGP/GPG 公钥和私钥对是很多场合都要求的认证机制，

PGP/GPG public key (not an SSH key)

既然如此，那就做一个吧：

安装一个最新版本的 gnupg:

$ emerge =app-crypt/gnupg-2.0.9-r1
$ gpg --gen-key

此过程一系列问题，姓名、电邮、Comment，最后生成的ID的形式是：

"Name (Comment) "

做好了之后，就传到服务器上去吧，当然传送的是公钥了，私钥是不以任何方式泄漏的；

$ gpg --list-keys
$ gpg --export --armor
$ gpg --keyserver hkp://keys.gnupg.net --keyserver-options debug --send-keys f9b0925b
$ gpg --keyserver hkp://keys.gnupg.net --keyserver-options debug --send-keys f9b0925b
gpg: sending key F9B0925B to hkp server keys.gnupg.net
gpgkeys: curl version = libcurl/7.18.2 OpenSSL/0.9.8j zlib/1.2.3
* About to connect() to keys.gnupg.net port 11371 (#0)
*   Trying 86.59.21.34... * Timeout
*   Trying 129.128.98.22... * connected
* Connected to keys.gnupg.net (129.128.98.22) port 11371 (#0)
> POST /pks/add HTTP/1.1
Host: keys.gnupg.net:11371
Accept: */*
Content-Length: 1956
Content-Type: application/x-www-form-urlencoded
Expect: 100-continue

* HTTP 1.0, assume close after body
< HTTP/1.0 200 OK
< Server: sks_www/1.0.10
< Content-type: text/html; charset=UTF-8
<
* Closing connection #0

http://www.kernel.org/faq/#account

缺省传送的是 hkp://keys.gnupg.net 服务器，在 ~/.gnupg/gpg.conf 文件中，也提示了其它传送方式，包括发送邮件的形式；因为上面这样的传送有时会失败，如 "86.59.21.34... * Timeout" 。

这个 hkp 访问协议从上面的传送过程也可以看出来，实际上就是一个在非标准端口运行的 http 服务器，提交的过程实际就是 http 表单的提交，既然知道了它在使用 11371 端口号，当然也可以使用浏览器来访问了，如：

http://keys.gnupg.net:11371/pks/lookup?search=0xf9b0925b

2098, "Hello, World!"

2098-hello-world.png

黄油文件系统(Btrfs)与南瓜文件系统(Squashfs)

黄油文件系统(Btrfs)是Linux下一代文件系统，具有很多先进的文件系统特性，在2008年9月份的内核峰会上已讨论决定在2.6.29合并入主流内核，现在正是2.6.29的rc开放时期(为期两周)，linus在昨天刚刚把它合并进去了～

http://lkml.org/lkml/2008/12/31/85

使用Btrfs的方法详见wiki站点：

http://btrfs.wiki.kernel.org/index.php/Main_Page

可以这么评价吧：
1. Solaris曾经有最后两根救命稻草是DTrace探测工具和ZFS文件系统，现在在Linux上有了带utrace内核的Systemtap和Btrfs文件系统，Solaris操作系统再也没有任何优势了，

另外，在这个页面还包含了很多Btrfs的许多创意想法，有已实现和正在实现的，包括在文件系统层次的RAID5,6:

http://btrfs.wiki.kernel.org/index.php/Project_ideas

南瓜文件系统(Squashfs)可能就更熟悉了，它采用gzip或lamz(更高压缩率)来制作只读的映像文件，常见于各发行版的LiveCD光盘中，也在今天早上(UTC时间1月9日凌晨)刚刚合并入主流内核(linus的mainstream内核)

http://marc.info/?l=linux-kernel&m=123153961726343&w=2

关于Squashfs的合并之路，倒不是一帆风顺的：
1. 其作者 Phillip Lougher 在这个线索中提到，在过去的数个月(据我观察有两三年了)中，他不停地接到用户的抱怨说为什么Squashfs停止了开发，于是在六个月前， Phillip 辞掉工作，专职为 Squashfs 开发，直到前不久，在与 Andrew Morton 的一次讨论中， Andrew 觉得可以合并进入 linux-next-for-2.6.31 的分支，但这个过程仍然很漫长，(根据3个月的规则，还至少需要七八个月)。 Phillip 已经6个月没有工作，对此已尽乎绝望，希望能尽快合并入主流，可以重新去找份工作，挣点钱。
2. 接下来的回复中，有两种观点；一种常规的观点是文件系统不是一般的驱动程序，是不能贸然合并的，这是传统的观点； Andrew 也是基于此观点认为 Squashfs 还需要在 linux-next 中观察个半年。反对的观点来自 Alan Cox ，说很多发行版的 LiveCD 已经在用 Squashfs 很多年了，还有什么样的大规模测试比这更能说明问题？
3. 终于， Andrew 同意现在就合并吧！我们终于有了一个以蔬菜命名的文件系统了～
4. 调侃继续：
蔬菜总比 FAT (肥胖) 好吧～
我喜欢南瓜(Squash)胜过于黄油(Butter)~

http://thread.gmane.org/gmane.linux.file-systems/28733/focus=28881

http://marc.info/?l=linux-kernel&m=123153961726343&w=2

Vim, Bram Moolenaar, 乌干达

From: /usr/share/vim/vim72/doc/uganda.txt

Kibaale Children's Centre  *kcc* *Kibaale*  *charity*

Kibaale(乌干达地名)儿童中心位于非洲东部、靠近Tanzania(坦桑尼亚)，在乌干达南部的一个小镇Kibaale。这个地区以Rakai区而闻名。居民大多是农民。尽管人们很穷，食物仍然是足够的。但是这个地区正承受着比世界上任何地方都更严重的AIDS灾难。也有人说它就是起源于这里。据统计有10~30%的乌干达人受到了HIV的感染。因为父母死亡，那里有很多孤儿。在这个地区有大约6万名儿童失去了一位或两位双亲，尽管总人口只有35万。并且这个数字还在持续增长。

这些儿童需要很多帮助。KCC正在努力工作以提供对食物、医疗和教育的需求。食物和医疗是为了让他们保持健康，教育是让他们将来能够自己照顾自己。KCC以基督的名义工作，但援助是提供给任何宗教的儿童。

解决这个地区问题的关键在于教育。这在过去的 Idi Amin 总统在位的数年以及接下来的内战中一直被忽略着。现在政府又重新稳定了，儿童和父母们都必须学习怎样照顾他们自己和怎样避免被感染。那里也为病人和饥饿的人们提供帮助，但它的主要目的是教会人们如何避免生病和怎样种植健康的食物。

大部分孤儿都住在大家庭里。由叔叔或大一点的姐姐来照顾。因为这样的家庭很大，而收入很低，对一个孤儿来说能得到健康的食物就已经很幸运了。而衣服、医疗和教育是已经超出他们能力所能及的。为了帮助这些有需要的孩子们，我们设置了一个专项赞助计划。可以经济上收养一个小孩。仅仅数美元每月就可以让KCC维持对这个小孩所采取的必要措施，就是保持健康和上学，其它对这个孤儿和支持他的家庭所必需的将由KCC来完成。

在直接帮助这名孤儿的同时，他们成长的环境也需要改善。KCC帮助当地学校提高他们的教学方法。在这个中心有一个示范学校来做教师培训。在那里培训保健员，宣传卫生教育，并且鼓励家庭建立好的厕所。我(Bram)帮助建立了一个水泥板生产基地。这些水泥板用于建造好的厕所，并且都以低于成本价出售。

这个项目还包括一个小的疹所，给孩子和他们的家庭提供医疗帮助。当有需要时，还提供到医院的交通。免疫计划也在实施，以应对传染病的发生(这里麻疹和霍乱一直是个问题)。

1994至1995年夏天我花了一整年时间在这个中心，以志愿者的身份工作。我帮助扩展这个中心，和在城市供水方面工作。我了解到KCC所提供的帮助确实有作用。当我回到荷兰时，我想要继续支持KCC。为了这个，我正在募捐基金和组织赞助计划。请考虑以下可能：

1. 赞助一名小孩上小学，17欧元每月(或更多)
2. 赞助一名小孩上中学，25欧元每月(或更多)
3. 赞助一个疹所，任何数额每月或每季度
4. 单笔捐款

相比于其它儿童赞助组织来说，这此数额都是很低的。这是因为这些钱都是直接到这个中心去了。机构本身的运作费用保持在低于5%。这是个小机构并且依赖于志愿者来运作，因此是可以做到的。如果你想赞助一名小孩，你应该想好需要至少保持一年。

怎样知道你的钱花在了正确的地方呢？首先，你可以得到我作为VIM的作者的个人保证。我信任在这个中心工作的人们，我在私下里了解这里的每一个人。更进一步说，这个中心也被 World Vision, Save the Child Fund 和 International Child Fund 这些组织所共同赞助和监管。我们大约每年对这个中心进行造访和检查一次进度(使用我们自己的钱)。我个人在 1996, 1998, 2000, 2001, 和 2003 年都分别访问过这个中心。访问报告都在ICCF的网站上有。

如果你有更多的疑问，请发电邮给我：

这个中心的地址是：

Kibaale Children's Centre
p.o. box 1658
Masaka, Uganda, East Africa

汇款方法：

USA: ...

Canada: ...

Holland: ...

Germany: ...

World: ...

Europe: ...

Credit Card: 请使用PayPal汇款至 ...
Others: 请汇款至这个银行帐号， ... 请以欧元或美元的形式电汇或邮寄支票，最小额度是70美元，(我的银行帐号不能接受小于70美元的外国支票，致歉)
邮寄支票地址： ...

请尽量使用欧元汇款以减少汇率损失。

这个地址长期有效。


原文在线地址：

http://vim.cybermirror.org/runtime/doc/uganda.txt

http://www.vim.org/htmldoc/uganda.html

Google地图搜索KCC所在位置(东非)：

http://maps.google.com/?q=Masaka,+Uganda,+East+Africa

荷兰ICCF组织网站，

http://iccf-holland.org/

上有每年财务报告都可以下载，最近一期是2007年的：

The financial report for 2007 is available (PDF).

http://iccf-holland.org/jaar2007.pdf

2007年中所有捐款总额是47,688欧元，其中持续赞助是20,802欧元，单笔捐款26,633欧元，利息253。

2007年的花费中只有0.4%是用于管理和运作费用。在2006年的费用比较高是因为花在了一个合法的程序以把 iccf.nl 域名要回来。2007的主要费用花在银行取出外国支票上。

这份文件中还提到了，从2001至2007年，捐款收入在稳步增长，从2001年的2万多至2007年的接近5万欧元。

基金是以每次大笔的形式直接转往乌干达，这样以减少银行手续费。

在2008年1月份有91名儿童被赞助收养。比前一年多了6名。捐款的月收入是大约1300欧元。还有很多赞助者是每年支付的。希望在2008年至少能收到同样多的捐款。

而单笔捐款是完全偶然的，也无法预知2008年的情况。

此财务报告由 Adiswil 制作于 2008-02-16 。

KCF has made a newsletter with various information: fall2007.pdf (PDF)

http://iccf-holland.org/newsletter/fall2007.pdf

和平、友爱与火箭！ (HP首席技术专家的基于ARM板的开源飞行高度记录软件开发实记) (From: OLS2008论文集)

Subject: 和平、友爱与火箭！ (HP首席技术专家的基于ARM板的开源飞行高度记录软件开发实记) (From: OLS2008论文集)

http://ols.fedoraproject.org/OLS/Reprints-2008/

Bdale Garbee Peace, Love, and Rockets!

http://ols.fedoraproject.org/OLS/Reprints-2008/garbee-reprint.pdf

作者 Bdale Garbee 是 HP 的开源和Linux首席技术专家，同时是一位模型火箭飞行爱好者，

他和他的儿子很喜欢制作和飞行各种各样的模型火箭，但是当他们想要一款电子高度计用于探测火箭实飞高度时，却发现市面上现有的产品都是功能很有限，且依赖于专有的软件来配置和解析出数据，这个令人很不爽！

这篇论文描述了他们如何制作开放的硬件和软件来满足自己对于高度的好奇心，现场演示文件中包含有更详细的更强动力的火箭设计计划，并包含了照片和视频材料。

这些材料应该是任何对开放的小型嵌入式设备好奇的人们都感兴趣的。
硬件是基于ARM的，以 "TAPR Open Hardware" 协议开放，
并且完全是基于开源的设计工具实现的。
软件是以GNU工具链和很多开源库在 FreeRTOS 上实现的。

有兴趣的同学们可以读这篇论文。