我論Kalug是個有趣的秘密組織. XD

這個月號稱"非常秘密"的kalug聚會剛結束,

Yuren也在他的blog上發表了他文情並茂的感想.

文章寫的很傳神,
但又突然發現南部的OpenSource使用者都太習慣秘密活動了...

Yuren Ju僅僅自介自己是"""普通的Linux End-User 一枚..."""

這也謙虛的太過份了...明明就是Blog上知性+感性的文章產量無數,秘密的研究如何用P2P征服世界,而帶來的筆記型電腦上有火焰特效+3Dberyl旋轉桌面還轉到有人說"原來用這linux就好像在打電動一樣"的無敵閃光Linux使用者吧... :D

此外, 這個在南部據說真的很秘密的秘密組織又新開了一個秘密的irc頻道在freenode,
又很秘密的被Yuren Ju秘密的推廣了一下. 我當然就很秘密的拿來秘密的引用了. XD

"""我覺得這個聚會很棒啊, 不過為什麼KaLUG聚會一個月只辦一次 ???"""
PostgreSQL中文社群網誌裡覺得一個月五十篇還嫌少的熱血作者Kuo Chaoyi這麼問.

blueKnows說他一天辦一次都奉陪,這真是太熱血了啦.....

不過我秘密的心想.... 那這咖啡店賺我們這群秘密的顧客還真夠賺的啊!! XD << 哪個要秘密的開秘密的咖啡店的請趕快啊! >>

ps: 喔對了... 我要很秘密的說: Postgresql真的讚! 還有Postgresql中文網誌也不算很秘密的在找寫手喔... :D

[link] Add OpenID consumer support to any Django application

Simon Willison just release first version of django_openidconsumer.

As Simon says:
"""
I plan to keep the package under active development, with the aim of using it to demonstrate best practises in implementing OpenID (hence the support for multiple OpenIDs and simple registration out of the box). Next on the list is integration with Django's built in authentication system, including the ability to associate one or more OpenIDs with an existing user account.
"""

This is so cool if you need any openid support in django. :)

一些 OpenID 的連結:

How to use OpenID

Six cool things you can build with OpenID

The Future of OpenID

Web developer Simon Willison talks to Vitamin about OpenID

What is OpenID good for?

[link] Django dbmigration

MikeH在django mailing list上丟出了db migration的工具.

Django原本也有個schema-evolution的branch, 但是很可惜由於過於複雜, 野心又太大,Developer加入又離開,一直都沒有什麼太大的進展,到現在trunk仍然沒有一個可用來作scheme migrate的工具,基本上每次要新增欄位, 大家不是手寫SQL,就是自己寫script轉換舊資料,都在作重覆的事,沒有一個很pythonic的解決方案.(Actaully it's not really a big problem, since everything is so easy in python. However, I believe everyone who use django are all tired of keeping hear some newcomers yelling that rails 'already' had that. :P)

不過這次丟出的dbmigration看起來非常的不錯, 雖然版本只有0.1, 不過現在已經可以支援用django的ORM及SQL寫migration,如果繼續發展下去,應該會是非常有用的工具.

Mozilla "moves" to python-based DSCM: mercurial to replace CVS

Version Control System Shootout Redux Redux

"""
It's important to realize the headline here isn't "Mozilla Project picks Mercurial for Next Generation Version Control System." It's "Mozilla Project moves to Next Generation Version Control System."
"""

根據引用文章的說明, 不是pick而是move :D (註：原文在這邊要表示的意思是bzr跟hg都是很好的系統, 所以Mozilla不是選了hg而是移向下一代的版本控制系統)



我不是標題黨, 不過Mozilla的確要改變原本使用CVS的方式,
改採現正流行的distributed SCM (DSCM, Distributed Software Configuration Management 話說現在每次只要寫縮寫不打全文就會被某人唸, XD ) ,
而選中的正是由python實作的: mercurial.

由該文引用的這張被kuso過的真人快打系統圖中,
可看出下面這幾種是曾經在mozilla會議中提出來討論過的:
rcs,mecurial,cvs,svn,svk,bazaar,arch,bitkeeper,sourcesafe,clearcase,Perforce,git.

根據該文的說法, 有被認真考慮過的只有底下4個: bazaar / mercurial / git / Monotone
git跟Monotone也很快就因為win32 client支援程度不好的問題被ruleout.
(比較意外的是非常先進但使用haskell實作的darcs似乎完全沒有被考量. 不過根據該篇文章的一篇評論,似乎有人在開始匯入時就out of memory了.)

因此很快的, 剩下兩個均由python實作(也意味著跨平台應該非常好 :D)的DSCM mercurial/bazaar就被mozilla同時考慮了.

mercurial(以下簡稱hg)跟bazaar(以下簡稱bzr),是兩個性質非常類似的DSCM, 基本上兩個幾乎可以等同看待, 操作命令也幾乎一模一樣, 就我個人非常淺薄的使用體會跟認知,bzr功能略強一些, 而hg速度快上不少.
我個人使用的是bzr, 所以其實就私心來說是希望bzr能被mozilla採用的. 很可惜的, 根據這篇文章的說明, mozilla也很想採用bzr, 但是發現匯入mozilla cvs庫卻需要用上一個月 :P (使用的是0.14/最新的0.15已經試圖想解決performance問題) 相反的採用hg就只有7天.

不論如何mozilla似乎已經要決定轉換到hg了,
去年shawn跟我提過的hg現在果然是紅了,
曾經有一次開玩笑的跟yungyuc在線上聊天聊到如果那天bzr停止發展了那我大概就會在hg的船上. 沒想到這麼快機會就來了 XD 不過事實上bzr還在積極發展並改善速度加上也可以使用hg的repos,且又由於我的檔案大部分都不大, 加上binary file都還在100MB以內, 倒是還沒遇到太多效能上的問題. 也許哪天真的有需要也可改用hg,暫時我將還是使用bzr為主. 不過大家在選用時可以將hg列入考慮. 另外該篇文章也提到:
"""
There was a lot of support in the project for both tools, and I personally know that the Bazaar developers spent a bunch of their 0.15 development time working on some of the performance issues we ran into. The great thing about these "nextgen" version control systems is that they all track the information necessary to re-create history. Because of this, switching between systems is much eaier, and in some cases, using your favorite system is possible (bzr, for instance, can pull directly from Mercurial).
"""
所以我認為至少在這短時間內, 這兩者都是非常好的選擇. :)

底下列出目前使用hg跟bzr的知名opensource專案, 僅供參考:

hg:
Mozilla,opensolaris,ALSA,mutt.Xen,MoinMoin,e2fsprogs. (gpl-sun-java is considering hg too)

bzr:
Ubuntu, Drupal,BitlBee,nose,PyChart,Samba.

(當然, 更大部分的專案都使用svn 事實上我也很愛用svn 只要svn符合你的需求,svn目前還是非常正確的選擇, and, Nobody ever got fired for picking IBM :^)

[link] django template utilities

James Bennett發佈了django-template-utils

django的template tags的使用跟抉擇一直是個藝術,
有些人嫌他功能過於強大(ex: guido),也有不少朋友覺得他功能過少,
James Bennett開發了一些template tags並整理了不錯的使用文件.有興趣的人可以參考看看.

[tip] Emacs 管理方法的一些零散小看法.

每個使用emacs的人emacs管理方法都各有不同,
未必我的經驗就是好的, 網路上也有不少先進有他們獨到的看法,
我也時常受益良多,
不過在這之前我得先說個悲慘的emacs小故事:

從前有一個喜愛使用emacs的人,
因為他慣用的.emacs被人弄丟了,
從此之後就使用了vi.

(註: 這個人的名字叫Tim O'reilly.)

這個被我渲染過的悲慘小故事告訴了我們,
如果想要好好使用emacs,
就不得不用點心思在管理emacs files上.
何況別人的.emacs對你而言經常是無用的,
而一旦你丟失了你的慣用.emacs,
想重新打造一個屬於自己的.emacs將耗盡你的青春,
甚至還不如去學一個別的editor.

我目前的一些管理方法是這樣的,當然我說過了,
我的作法未必正確,而且未來也可能會改變我的看法,
這篇將就將就參考看看吧:

1. 維持~/.emacs 簡單, 使用~/.emacs.d來管理emacs

我的.emacs目前只放了一些很簡單的事情,
如: Custom 跟我的initial .el"s" function.
好處就是.emacs很清爽, 如果有需要的話,
也只要將非常重要的設定放在這邊就好了 其他的利用.emacs.d來對設定分門別類.

2. Add functions to auto-compile every .el after you edit it.

編譯成.elc會加快你loading emacs的速度.

我寫了一個elisp function來自動作這件事情:
(.emacs可另外處理)

(defun auto-byte-compile-el-file ()
  (let* ((filename (file-truename buffer-file-name)))
    (cond ((string= (substring filename                                       
            (- (length filename) 3)) ".el")
          (byte-compile-file filename)))))

(add-hook 'after-save-hook 'auto-byte-compile-el-file)

3. 使用版本控制軟體(SCM).

我使用的是bazaar, 一個分散式的SCM. 因為我覺得他對我來說很方便.
不過不論如何,我強烈建議採用任何一個你慣用的SCM(cvs/subversion/darcs/git)來控管你的.emacs/.emacs.d
別忘了,你的.emacs非常重要, 甚至比妳專案的程式碼都還來的重要,
程式碼丟了不過是個案子, .emacs丟了妳痛苦一輩子 :P

4. 善用M-x toggle-debug-on-error

這是debug emacs設定的最佳實務技巧.
相信我, 妳會用到他的.

5. 使用管理rc的方式來管理.emacs.d

將你的.emacs.d 分類, 並寫成像rc的方式.
類似如此:

000globalinit.el
010packageinit.el
020etags.el
...

600ecb.el
700lisp.el
710python.el
715django.el
720javascript.el
730cc.el
740ruby.el
750haskell.el
900testconfig.el

6. install site packages to your .emacs.d

將你安裝的emacs套件與你的設定檔分開管理. 但是都放在 .emacs.d裏面.

7. 將 bookmark, TAGS, auto-save, desktop_state, semantic.cache, backups, session 等檔案納入.emacs.d管理.

emacs有很多檔案預設會四散在各地, 最好也將他納入.emacs.d管理.

8. set $EDITOR to emacsclient.

emacs的啟動速度是個問題, 使用emacsclient是個好方法.

9. 替.emacs.d 作一個bookmark, 並安裝dired-single.el
我相信你會常常需要修改.emacs.d, 我的作法是作一個bookmark,
此外,dired-single.el可以讓你不要每次切換目錄都開一個dired出來.

10. 當然還有很多想法/技巧我無法一一列舉,
不過我覺得用emacs是一輩子的事, 值得用一輩子來學習.

****

It's your editor, not other's.

沒有任何兩個人心中的夢幻editor是一樣的,
像我重設了emacs的ctrl-k刪行行為,
但另外一個emacs user卻可能嗤之以鼻.
另外emacs user經常大幅度的改變了不少預設的keystroke,
故每個人都有一套自己順手的emacs操作方法,
所以自己的.emacs要自己管理, 沒有人能幫上你太多忙.

每個人都在打造屬於自己最適合自己的"editor神器",
但天下可沒有白吃的午餐, 別人的神器未必是你的神器,
而emacs的價值就在於emacs提供了一個機會讓你去打造屬於自己的editor,

"Think emacs as an environment."

如果你是programmer,
如果你一天花時間在editor上超過八小時,
請用你學習作業系統的想法去打造emacs,
既然肯花很多時間去打造屬於自己的windows/linux/*bsd/OSX,
為何不願意花時間打造editor?

Since you use emacs, you need to think different.
I believe emacs will reward you. At least, it rewards me a lot.

:-)

[tip] How to Setup OpenVPN to connect 2 internetworks seamlessly.

Author: timchen119 (timchen119.blogspot.com)

openvpn有非常多種設定方法, 依個人遇到的需求不同有所變化.

我這邊整理的是使用一台server跟一台client共安裝兩台openvpn機器(linux gateway),
讓兩個可能地理位置不同的區域網路連接起來的方法.

Network 10.1.0.x                                       Network 10.2.0.x

10.1.0.2 <---> 10.1.0.1 ============================= 10.2.0.1 <---> 10.2.0.2
                  GW                 VPN                  GW
               (10.8.0.0)
              OpenVPN Client                        OpenVPN Server
              192.168.23.39                         192.168.23.38

After setup OpenVPN, you should possible connect to 10.2.0.2 from 10.1.0.2 without any special settings.

Steps on debian linux:

1. apt-get install openvpn (on both client/server)
2. cd /usr/share/doc/openvpn/examples/easy-rsa/
3. edit vars / source vars (if you need key more than 1024bit, 2048bit+ recommended.)
4. ./build-dh
5. ./build-ca
6. ./build-key-server server
7. ./build-key client
(Note: you have to set different common name from server's,
we'll need this later, I'll use CVKK2 for example)

8. on client side:

a. put ca.crt client.crt client.csr client.key to /etc/openvpn
b. create /etc/openvpn/client.conf
client
ns-cert-type server
remote 192.168.23.38 #server ip
dev tun
tls-client

comp-lzo

dh dh1024.pem
ca ca.crt
cert client.crt
key client.key

log openvpn.log
log-append openvpn.log

c. check you gateway/ip forward settings:
if you didn't setup yet you'll need this in your /etc/init.d and a link in /etc/rc2.d:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.0/24 -j MASQUERADE

9. on server side:

a. put ca.key ca.crt server.crt server.csr server.key dh1024.pem to /etc/openvpn

b. create /etc/openvpn/server.conf

dev tun
server 10.8.0.0 255.255.255.0
push "route 10.2.0.0 255.255.255.0"

comp-lzo
ifconfig-pool-persist ipp.txt

persist-key
persist-tun

tls-server
dh dh1024.pem
ca ca.crt
cert server.crt
key server.key # This file should be kept secret

client-config-dir ccd
route 10.1.0.0 255.255.255.0
client-to-client
push "route 10.1.0.0 255.255.255.0"

c. mkdir /etc/openvpn/ccd

d. create file CVKK2 in ccd directory.
(the filename should match client's commonname in client.crt)

put this following line in this file:
iroute 10.1.0.0 255.255.255.0

e. check you gateway/ip forward settings:
if you didn't setup yet you'll need this in your /etc/init.d and a link in /etc/rc2.d:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o eth0 -s 10.1.0.0/24 -j MASQUERADE

[tip] Share gentoo distfiles directory with FreeBSD NFS server.

由於我的gentoo機器不止一台, 所以一直以來都是先mirror一份portage進LAN之後, 再rsync自己.
不過由於我的機器IO太慢了, 最近總算忍不住向lloyd借了一台freebsd機器來架了一個portage rsync server, 想說順便將portage裡的distfiles share出去, 這樣就不用將distfiles一抓再抓. 沒想到只要一mount,emerge就出現問題.會一直掛在那邊不抓檔案. 實在非常詭異.

不過稍微研究了一下就被我找到問題點了, 原來是fbsd上的rpc.lockd沒開.

解決方法有二.
1. edit freebsd's /etc/rc.conf 將rpc_lockd_enable 改成"YES", 然後再將rpcbind restart.

2. mount option + "nolock" for gentoo.
將mount option改成
rw,soft,timeo=1,noatime,rsize=1024,wsize=1024,nolock

我是採用了第2個方法.
果然加上了nolock之後emerge就很順暢了.

Debian 4.0 released...

起床就看到好消息:

http://www.debian.org/News/2007/20070408

"etch" Debian 4.0 released.

(sarge...我終於可以擺脫你了 XD)

老天終於聽到我的呼喊了~~ XD

pypy 1.0 first try

I'm not going to explain too much pypy, I'll just list my instructions on C version PyPy 1.0 + jit (pypy-c with jit) build.

* you may need install these first *

apt-get install

gcc libc6-dev make autoconf libgc-dev bzip2
subversion python2.4 python2.4-dev
python-ctypes python-pygame

Note: you don't really need python-pygame if you specify with --text.

Note for debian stable user:

if you're using debian stable, you have to manually install ctypes.

python2.4-ctypes is 0.9.5-1 in debian stable,

pypy need version 0.9.9.6 or later:

wget http://nchc.dl.sourceforge.net/sourceforge/ctypes/ctypes-1.0.1.tar.gz

tar zxvf ctypes-1.0.1.tar.gz

cd ctypes-1.0.1

python2.4 setup.py install

* how to translate pypy to c-version pypy with jit *


WARNING: YOU AT LEAST NEED a 512MB RAM box...
I'll recommend 1GB RAM box.
since this will generate a 700mb python process
( 704m 693m 5872 R 99.9 78.3 53:14.25 python2.4,
I build this on 3.2GHZCPU+1GB ram debian stable box)
I first translate pypy in a 512MB RAM gentoo box,
after 3 days memory swapping I gave up.

wget http://codespeak.net/download/pypy/pypy-1.0.0.tar.bz2

#or svn co http://codespeak.net/svn/pypy/dist pypy-dist

tar jxvf pypy-1.0.0.tar.bz2

cd pypy-1.0.0/pypy/translator/goal/

python2.4 translate.py --batch --text --jit targetpypystandalone

and wait 2 hours (if you have 1gb ram)

* woot! pypy-c !

let's check this:

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# ls -lh pypy-c
-rwxr-xr-x 1 root root 9.2M Apr 3 16:22 pypy-c

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# ldd pypy-c
linux-gate.so.1 => (0xffffe000)
libgc.so.1 => /usr/lib/libgc.so.1 (0x4001e000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x4004f000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x40074000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40086000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x401b7000)
/lib/ld-linux.so.2 (0x40000000)

* The benchmark part

1. startup time is great

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time ./pypy-c -c "print 'hello world!' "
hello world!

real 0m0.006s
user 0m0.003s
sys 0m0.003s

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time python -c "print 'hello world!' "
hello world!

real 0m0.009s
user 0m0.005s
sys 0m0.005s

2. jit speed seems promising.

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time ./pypy-c demo/jit/f1.py > /dev/null 2>&1

real 0m0.449s
user 0m0.442s
sys 0m0.007s

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time python demo/jit/f1.py > /dev/null

real 0m5.347s
user 0m5.343s
sys 0m0.004s

however current JIT not faster than psyco.full():

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time python demo/jit/f1-psyco.py > /dev/null

real 0m0.048s
user 0m0.046s
sys 0m0.002s

3. it's a bit slow in a real test in this stage.

I took the nbody test in "Computer Language Shootout",

http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=python&id=0

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time python nbody.py 20000
-0.169075164
-0.169089263

real 0m1.729s
user 0m1.724s
sys 0m0.005s

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time ./pypy-c nbody.py 20000
-0.169075164
-0.169089263

real 0m13.542s
user 0m13.539s
sys 0m0.003s

pypy-c without jit almost 8 times slower :(

and, with the current 1.0 alpha stage JIT, the performance isn't any better.
(since nbody.py use lots of floating arithmetic)

I add these in nbody.py:

import pypyjit
pypyjit.enable(advance.func_code)
pypyjit.enable(energy.func_code)
pypyjit.enable(offset_momentum.func_code)

pypy:/home/tim/pypy-1.0.0/pypy/translator/goal# time ./pypy-c nbody.py 20000 > /dev/null 2>&1

real 0m19.550s
user 0m19.531s
sys 0m0.019s

* conclusion:

1. I don't think pypy 1.0 is ready for production. At least not in my project.
So don't try to replace CPython via pypy at this stage.
(but maybe you have a good reason)

2. pypy 1.0 is not faster than CPython at this stage. Actually, much slower.
(JIT looks promising, however it's still in alpha stage.)

3. pypy really need a 2.0 release. (A joe average user branch)
It looks good,
since it wanna try to do something really different,
but not good enough yet.
we need more.

4. my benchmarking is so naive here, so if you don't like it,
you should do it your own self.

5. despite these, good work.
Thanks the effort from pypy team. we really really need more.

[tips] emacs遠端sudo編輯檔案

上次shawn問我了一個問題,
怎麼用emacs遠端登入之後sudo成root編輯遠方的檔案(如:/etc/fstab).

如果是使用emacs-unicode2 branch其實很簡單. 因為內建的tramp是2.0.55
只要使用C-x C-f後鍵入
/multi:ssh:user@host:sudo:root@127.0.0.1:/etc/fstab

不過由於我另裝的tramp裝的是比較新的2.1.9pre
原來的方法就行不通
需要改成使用proxies的方法

在.emacs內加入
(add-to-list 'tramp-default-proxies-alist
'("blah\\.blah2\\.org\\.tw\\'" "\\`root\\'" "/ssh:%h:"))

這次改成C-x C-f後鍵入
/sudo:root@blah.blah2.org.tw:/etc/fstab

即可透過emacs跟sudo直接遠端編輯/etc/fstab

需要更多資訊還可以參考
http://www.gnu.org/software/tramp/#Multi_002dhops
http://www.emacswiki.org/cgi-bin/wiki/TrampMode

真是個好節日啊~~

http://pythononplanes.com/

"Planes is the most well thought-out snake oil framework I’ve ever sniffed."

這個我一看就知道很明顯的不僅可以減少程式碼,
還可以快速增加生產力10000倍!!! XD

"it lets you write beautiful code by favoring snake oil over gems."

Snake Oil 萬歲! XD

Tim Oreilly -- blogger的行為七準則草稿

Tim O'reilly, O'Reilly Media 的Founder,
就在不久之前發表了Call for a Blogger's Code of Conduct
也拋出了這樣的一個早已存在但終於不得不正視的新議題.

事件的導火線在於Kathy Sierra,著名的Head First系列的女作者,
(Head First Java,Head First Design Patterns,Head First Servlets and JSP,Head First EJB)
不久前因在其blog上受到了死亡威脅,
而中止參加一場O'Reilly在San Diego的ETech conference.

有圖有真相: http://headrush.typepad.com/photos/uncategorized/2007/03/26/unclebobpicture.jpg
http://headrush.typepad.com/photos/uncategorized/2007/03/26/unclebobcomments1.png

於是有鑑於此, Tim O'reilly拋出了的新的Blogger行為準則草稿, 略譯之後加上個人的感想如下:
(如果以Web 2.0行銷術語來說, 也就是"Web 2.0時代的新部落客行為準則" XD)

1)Take responsibility not just for your own words, but for the comments you allow on your blog.
不只對在blog上的發表的文章負責, 也要包括blog上的評論.

提姆註: Tim O'reilly對於Chris Locke的'YOYOW -- You Own Your Own Words'的論點提出的對應觀點, 在目前, 有非常多的blogger認同Chris Locke的觀點, 也就是評論者應對自己的評論負起責任, 而網站所有者不應對此負責. Tim O'reilly認為, 這樣的YOYOW的觀點不應無限上綱, 而應該有個最低限度, 就像我們常說的所謂"自由"的前提是在不妨礙他人的情況下.

Tim O'reilly: """Yes, you own your own words. But you also own the tone that you allow on any blog or forum you control."""

2) Label your tolerance level for abusive comments.
在blog上標示對含攻擊性的評論之容忍限度.

提姆註: Tim O'reilly 提到 BlogHer所提出的"不可接受的內容"應該是一個不錯的起點.

3) Consider eliminating anonymous comments.
可考慮停用匿名評論

提姆註: Tim O'reilly認為雖然匿名性仍然在某些地方有必要,
不過在大部分的情況下,Identity會改變人們的行為.

4) Ignore the trolls.
忽略小白

提姆註: 避戰而不畏戰是也, 有不得不戰的理由時再踩小白幾腳,
大部分時間請直接忽略小白. 因為小白是殺不死的 :D

5) Take the conversation offline, and talk directly, or find an intermediary who can do so.
將對話內容離線,直接面對面交談或者找一個和事佬.

提姆註: 這點可以注意看一下Tim O'reilly的說明, Tim的意思是儘量不要就某一議題在blog上隔空對罵.很多事情見了面交談或許會好一點.比如Chris Locke覺得Kathy明明知道圖片不是他發表的,為什麼公開的指責他是網站所有者之類的. 當然, 人如果都能這麼理性的話...那就世界和平了 XD
不過Tim O'reilly的意思是, 如果可以的話, 不論如何多製造私底下交談的機會都會比對罵來的好一點.

6) If you know someone who is behaving badly, tell them so.
如果妳知道誰的舉止不佳, 告知他們.

提姆註: 可能的話, 婉轉一點 :P 我自己覺得比較糟糕的一點是, 這個時代, 大家都怕瘋子. :P 不過Tim O'reilly在這邊主要指的是自己的朋友, 不要畏懼告訴自己的朋友妳覺得他的評論或文章有過於攻擊性的問題, 應持續的溝通.

7) Don't say anything online that you wouldn't say in person.
不要在網路上說任何妳平常不會直接面對面的對人說的話.

Tim O'reilly的Blogger七準則草稿只是一個起點,
(當然, 我認為是一個好的起點)
國外也有相當多正反皆有的評論跟相關討論,
對於複雜的網路生態跟blogger習性,
未來想必有更多思考跟討論的空間.