parted 是 GNU 計劃的一個磁碟分割工具，其和 fdisk 最大的差別在於，其支援完整的 GPT 支援 (GPT 是取代傳統 MBR 的格式，可讓單一分割區超過 2T 大小)，並支援動態調整分割區大小等一拖拉庫的功能。
以下示範如何在 /dev/sda 的硬碟上，切一個 gpt 分割區，並配置所有空間給這個分割區。
注意 parted 的指令是下了馬上生效，所以要注意不要打錯會造成毀滅性的指令 XD
- 首先執行以下指令代表要對 /dev/sda 下手：
# parted /dev/sda
- 進去後，打 help 可以看到可以用的指令清單。由於我們首先要對整個硬碟標上 GPT 標籤，因此執行以下指令：
# (parted) mklabel gpt
- 如果你不清楚或記不得 mklabel 的指令怎麼下，可以打 help mklabel 來觀看說明。接下來執行以下指令，代表要切一個 primary 分割區，其範圍為從最前面 (0) 到最後面 (-1)，負數代表從後面數回來，因此 -1 代表是最後一個 block。
# (parted) mkpart primary ext3 0 -1
- 離開：
# (parted) quit
- 格式化為 ext3 分割區：
# mkfs.ext3 /dev/sda1
- 收工，剩下的就是設定 /etc/fstab...
Benjamin Peterson 是現任的 Python release manager，前些日子他寫了一篇 On commit messages 提到了
該怎麼寫才算是好的提交訊息 (commit messages)。當然啦，這個是有在使用版本控制系統
才需要看的文章，如果你是軟體工程師，而你的部門/公司卻還沒開始使用版本控制系統，也許你得跟主管確認一下你沒有待錯部門...
以下是這篇文章的重點：
1. 在談到提交訊息 (commit log) 之前，得先定義一下什麼是好的提交。一個提交基本上應該是以一個任務為單位 (atomic)，也就是說，假如你要修正一個資料庫連線的問題，那在這次提交的變動中，所有程式碼的更動都應該跟解決這個問題有關。如果在一個提交中，包含了三個錯誤修正以及新增兩個功能，那肯定就過頭了。有個很簡單的方式可以用來判斷你這次的提交是不是符合這個條件：如果你能用 一句簡單的話說明這次提交的變動內容 (嘿，"修正三個錯誤以及新增兩個功能" 這種說法可不行，這是作弊 XD)，那就過關，反
之就是可能變動太大了。
- 提交訊息中 第一行 是最重要的。理由很簡單，因為現在大部分的版本控制系統 (VCS) 以及事件追蹤系統 (Issue Tracking System) 預設都只會顯示第一行。第一行應該要能以簡短的一段文字來描述這次提交的目的與變動，但不要只是 "修正錯誤" 這種有講跟沒講是一樣的描述... 你應該知道意思。 ;) 若有搭配事件追蹤系統，能在第一行標記此提交是關聯到哪個事件號碼 (Issue Number) 當然是最好的。
- 提交訊息第一行用來精簡描述這次變動的內容後，通常會空一行，然後開始詳細的描述此次變動的原因等資訊。我們可以在其中補上相關的討論串網址、貢獻者等等資訊，讓需要知道細節的人可以更快的瞭解這次變動的前因後果。
千言萬語不如來個範例比較實際：以下是一個典型的提交訊息，這個並非強制，但若是大家都統一提交的風格，之後在做追蹤事件時會方便很多：
Refs #1234: 修正整點就會自動發射飛彈到北京的錯誤
阿共抗議說我們的飛彈系統會不定時發射到北京去。在經由內部討論 (請參見 http://talk.foo.com.tw/article?id=1234 討論)，並徹查程式碼發現原因是我們的 CI 系統會跑 unit test，而我們的測試發射目的是北京，導致每跑一次就會發射飛彈轟炸阿共。為了避免引起國際的情勢緊張，決議將測試目標改為台北的總統府，剛好日行一善。
從這個提交訊息我們可以發現這個開發者雖然有寫測試，但是沒有用到 mock / stub，導致每次跑測試就會發射飛彈，如何避免浪費飛彈的問題這是下一篇我想寫的內容...
Well, finally, my blog comes back... again. :p
之前的 blog 都是用 wordpress 架的，但是因為常常有安全性更新，加上懶的寫文章，就乾脆下架了。 XD
很早之前就想要將 blog 用 Django 重寫，但一直沒有動力，直到這次 Django 1.2 大改版，想說就直接上 SVN 版本衝了。 @_@
總而言之，目前基本的功能都寫好了 (？)，所以接下來要來換掉樣版...