灌好作業系統後，可以先把 ThinkVantage System Update 裝起來，這樣 Thinkpad 相關的驅動程式及軟體都可以直接從這邊更新回來。對了，記得不要裝 Client Security Solution 因為裝了真的是自找麻煩! 另外 System Migration Assistant 和 Rescue and Recovery 我也沒裝..

接下來就是安裝應用程式了，儘可能都以免費的軟體為主:

PicPick 是一個很強大的截圖軟體
XnView 看圖及簡單的圖形處理
Paint.NET 是一個短小精幹的繪圖軟體
FileZilla 支援 FTP 及 SFTP 的檔案傳輸軟體
7-Zip 檔案解壓縮工具
K-Lite Codec Pack 播放各種影音檔案
Adobe Reader 閱讀 PDF 文件

Alcohol 52% Free Edition 虛擬光碟 (裝免費版的即可, 可選擇不裝贊助軟體)
Avira AntiVir 掃毒軟體
Unlocker 強制解鎖
RocketDock 像蘋果的工具列
新酷音輸入法 (最新版: 0.3.4.8)

其他網路工具包含:

• Messenger
• Mozilla Firefox
• Skype
• PCMan Lite
• Flickr Uploadr

Google 提供的工具:

• Google Chrome
• Google Talk
• Google Earth
• Picasa

另外微軟的 PowerToys for Windows XP 也有幾個不錯的小工具:

• CmdHere
• PowerToy Calculator
• Tweak UI

還有之前微軟有提供一個 Microsoft Chinese Date and Time，是一個我很愛用的農民曆及世界時間工具，但現在微軟似乎把連結拿掉了，不過網路上搜尋一下就找到了

不知道是不是我太落伍了...

我一直以為 C/C++ 下面 short, long, long long 三種資料型態都固定是 2, 4, 8 個 bytes 大小。只有 int 這個資料型態會因為 16-bit/32-bit 系統的不同而變成 2 或 4 bytes 的大小，所以理所當然 int 在 64-bit 的電腦也應該會變成 8 bytes (64-bit) 的大小囉 ?!

在整理前一篇文章《Bypass the 2GB file size limit on 32-bit Linux》的時候，讓我驚覺在 64-bit 的系統下，long 的長度也是各自表述的！

首先，int 的大小即使到了 64-bit 的機器上，大部分的系統仍然使用 4 bytes 的大小而已，這主要是為了避免程式從 32-bit 系統轉換到 64-bit 系統需要修改太多地方

再來，請參考 Wikipedia: 64-bit data models 的說明

絕大多數的 UNIX 系統在 64-bit 下面採用 LP64 這種 data model，這時候 long 就不再是固定為 4 bytes 大小，而是變成 8 bytes 的大小了！

然而，Win64 卻不是使用 LP64，而是採用 LLP64 這個 data model，這時候 long 的大小仍然還是 4 bytes

Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP, Linux, Mac OS X, and IBM z/OS native compilers). Microsoft's VC++ compiler uses the LLP64 model.

兩種 data model 的最大差異點就是 long 這個資料型態的大小，LP64 是 64-bit，而 LLP64 則是 32-bit

LLP64 data model 基本上可以說跟 32-bit 的系統一樣，唯一差別只有位址(pointer)改成了 64-bit 而已。資料物件(class, structure) 等如果沒有包含 pointer 的成員的話，整個物件的大小是與 32-bit 系統一樣的！

而 LP64 則是除了位址(pointer)改成 64-bit 之外，long 的大小也變成了 64-bit 大小。所以在 UNIX 下面，要把 32-bit 程式 porting 到 64-bit 可能要比 Windows 多花費多一點功夫。

所以呢，我們觀察到兩個問題影響著程式的相容性

1. 在 UNIX 下面，long 的大小在 32-bit 與 64-bit 的系統下是不一樣的
2. 同樣是 64-bit 系統，UNIX 與 Windows 對於 long 的大小看法是不一致的

為了使程式在 32-bit 與 64-bit 之間以及 UNIX 與 Windows 之間的相容性提昇，改用固定長度的資料型態是寫程式的一個好習慣

在 UNIX 下面，我們可以改用 stdint.h 這個 header file 中對於資料型態的定義:

int8_t     8-bit signed interger
int16_t    16-bit signed interger
int32_t    32-bit signed interger
int64_t    64-bit signed interger
uint8_t    8-bit unsigned interger
uint16_t   16-bit unsigned interger
uint32_t   32-bit unsigned interger
uint64_t   64-bit unsigned interger

在 Windows 下面，則改用下面這些整數固定大小的資料型態

INT8       8-bit signed integer
INT16      16-bit signed integer
INT32      32-bit signed integer
INT64      64-bit signed integer
UINT8      8-bit unsigned integer
UINT16     16-bit unsigned integer
UINT32     32-bit unsigned integer
UINT64     64-bit unsigned integer

絕對不要再使用 int 和 long 了！

尤其是寫網路程式時，很可能 client 是 Windows 而 server 是 UNIX，然後又有 32-bit 及 64-bit 系統混在裡面，一不小心就發生不相容的問題了...

當然，在 64-bit 的系統下寫程式，要考慮的絕對不只上面這些基本的資料型態。除了 pointer 的大小變成 64-bit 外，許多系統內建函式會用到的 size_t 及 off_t 的大小也變成 64-bit 了.... 寫程式時若有用到這些資料型態，需特別注意，尤其是 casting 時，千萬不要用 32-bit 的整數去裝這些資料，免得造成不可預期的結果！

最後提供一個小程式讓你得知你的系統主要資料型態的大小

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <stdio.h>
#include <sys/types.h>
int main()
{
        printf("sizeof(short)     = %d\n", sizeof(short));
        printf("sizeof(int)       = %d\n", sizeof(int));
        printf("sizeof(long)      = %d\n", sizeof(long));
        printf("sizeof(long long) = %d\n\n", sizeof(long long));
 
        printf("sizeof(size_t)    = %d\n", sizeof(size_t));
        printf("sizeof(off_t)     = %d\n", sizeof(off_t));
        printf("sizeof(void *)    = %d\n", sizeof(void *));
}

參考資料:

1. Wikipedia: 64-bit data models
2. 64-Bit Programming Models: Why LP64?
3. Introduction to Win32/Win64
4. Porting 32-bit Applications to the Itanium® Architecture
5. Preparing Code for the IA-64 Architecture (PDF)

在 32 位元的 Linux 上面寫超過 2GB 的檔案會發生錯誤，甚至導致程式終止執行

這是因為 Linux 的系統內部處理檔案時用的指標定義為 long，而 long 在 32 位元的系統上的大小為 32 位元，因此最大只能支援 2^31-1 = 2,147,483,647 bytes 等於是 2GB 扣掉 1 byte 的檔案大小

64 位元的系統 (例如 AMD64 或 IA64) 則因為 long 定義成 64 位元，所以不會有問題..

#  if __WORDSIZE == 64
typedef long int int64_t;
# endif

不過在 FreeBSD 上面，即使是 32 位元的系統，也不會有 2GB 檔案大小的限制，這是因為 FreeBSD 內部處理檔案時，本來就是使用 64 位元的數字當作指標，所以不會有問題

因此在 32 位元的 Linux 上面，程式需要作一些額外處理才能正確寫超過 2GB 的檔案

我們先寫一個小程式來測試一下 (large.c)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
void sig_xfsz(int sig)
{
        printf("ERROR: SIGXFSZ (%d) signal received!\n", sig);
}
int main()
{
        int     i, fd;
        char    dummy[4096];
 
        signal( SIGXFSZ, sig_xfsz );
 
        unlink("large.log");
        fd = open("large.log", O_CREAT|O_WRONLY, 0644 );
 
        bzero( dummy, 4096 );
        /* 2GB = 4KB x 524288 */
        for( i = 0 ; i < 524287 ; i++ )
                write( fd, dummy, 4096 );
        write( fd, dummy, 4095 );
        printf("large.log: 2147483647 bytes\n");
 
        if( write( fd, dummy, 1 ) < 0 )
                printf("ERROR: %s [errno:%d]\n",strerror(errno),errno);
        else
                printf("large.log: 2147483648 bytes\n");
 
        close(fd);
        exit(0);
}

在 32 位元的 Linux 下面，以上程式編譯後若沒有特殊處理，執行結果如下:

# gcc -o large32 large.c
# ./large32
large.log: 2147483647 bytes
ERROR: SIGXFSZ (25) signal received!
ERROR: File too large [errno:27]

在寫第 2147483648 byte 的時候，程式會收到 signal SIGXFSZ，同時 write() 會回傳 -1 錯誤，errno 則為 27 (File too large)。更甚者，如果程式沒有像上面一樣去處理 SIGXFSZ 的話，內定的 signal handler 甚至會造成程式停止執行並產生 core dump

接下來，我們在編譯同一個程式的時候加入 -D_FILE_OFFSET_BITS=64 再試看看:

# gcc -D_FILE_OFFSET_BITS=64 -o large64 large.c
# ./large64
large.log: 2147483647 bytes
large.log: 2147483648 bytes

果然順利突破 2GB 的限制了!

而同樣的程式在 32 位元的 FreeBSD 下面，不論有沒有加這個定義，跑起來都是正確的

不過處理這些大檔案的時候，除了編譯程式時的參數不同外，有些函數的使用上也要作一些調整，例如 fseek() 與 ftell() 這兩個原本使用到 long integer 當作 offset 的函數:

1
2

int fseek(FILE *stream, long offset, int whence);
long ftell(FILE *stream);

只要系統是 32 位元，即使是在 FreeBSD 下面，都需要改為使用 off_t 的版本:

1
2

int fseeko(FILE *stream, off_t offset, int whence);
off_t ftello(FILE *stream);

在 Linux 下面，如果 _FILE_OFFSET_BITS 定義為 64，則 off_t 這個型態會自動轉成 64 位元的大小（在 FreeBSD 上面，off_t 本來就是 64 位元的大小)

每種系統支援大於 2GB 的檔案讀寫所需要的編譯選項都會有一些差異，即使是同樣是 Linux 也會因為 32 位元或 64 位元而有不同。有一個簡單的方法可以判斷，就是利用 glibc 提供的 getconf 來取得編譯(compile)以及連結(linking)時所需的參數:

# getconf LFS_CFLAGS
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
# getconf LFS_LDFLAGS 
 
#

上面是在 32 位元的 Redhat Linux 上面跑出來的結果，代表的是在這個系統上，若要讓程式支援 2GB 的檔案讀寫，編譯(compile)時需要加上 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 這兩個參數，連結(linking)時則不用加任何參數

參考資料:

• Large File Support in Linux
• LFS: Large File Support (Wikipedia)

In Linux (since Linux 2.6 and 2.4.21)
you can change the core dump filename from the file /proc/sys/kernel/core_pattern

         %%  A single % character
         %p  PID of dumped process
         %u  real UID of dumped process
         %g  real GID of dumped process
         %s  number of signal causing dump
         %t  time of dump (seconds since 0:00h, 1 Jan 1970)
         %h  hostname (same as 'nodename' returned by uname(2))
         %e  executable filename

Linux have a default core filename pattern of "core".
Alternatively, if /proc/sys/kernel/core_uses_pid contains a non-zero value, then the core dump file name will include a suffix .PID (process id), ex: core.PID

In FreeBSD, sysctl variable "kern.corefile" controls the filename of core dump.

Any sequence of %N in this filename template will be replaced by
the process name, %P by the processes PID, and %U by the UID.

FreeBSD have a default core filename pattern of "%N.core"

You can include path in the filename pattern both in Linux and FreeBSD.
This make it possible to put core dump file in a separated directory.

You can enable core dump by:

[bash] edit /etc/profile

ulimit -c unlimited

[csh/tcsh] edit /etc/csh.cshrc

limit coredumpsize unlimited

You can disable core dump by:

[bash] edit /etc/profile

ulimit -c 0

[csh/tcsh] edit /etc/csh.cshrc

limit coredumpsize 0

On FreeBSD, you also need to check the setting of kern.coredump:

# sysctl -a |grep kern.coredump
kern.coredump: 0
# sysctl kern.coredump=1
kern.coredump: 0 -> 1
# sysctl -a | grep kern.coredump
kern.coredump: 1

You can enforce this setting in /etc/sysctl.conf

[2008/01/01] Thanks for the complement from gslin, kern.sugid_coredump controls the core dump for setuid/setgid process in FreeBSD.

最後，用 fstat 去仔細分析，終於找到原因：

已經開啟的檔案，即使開啟中被強制砍掉(unlink)，對原 file descriptor 持續寫入的部份仍會繼續佔用硬碟空間，寫得越多，佔用的空間也越多

實務上最常遇到這種狀況的就是 log rotation，尤其是 rotation 後的舊 LOG 是壓縮過的情況。因為經過 gzip 壓縮過後，原始的 LOG 會被刪除，只留下 XXX.gz。這個時候如果沒有人通知原來寫 LOG 的程式要重新開啟一次 LOG (重新寫一個檔案)，就會導致程式在不知情狀況下繼續寫 LOG，然後空間就莫名其妙被用掉了！

例如 FreeBSD 下專門作 log rotation 的 newsyslog 設定檔 (newsyslog.conf) 就有個欄位可以設定在 log rotation 後送一個 signal 給 process，而 apache (httpd) 就接受 SIGUSR1 來當作重新開啟 LOG 檔案的訊號（事實上對 apache 而言是 graceful restart）。很多人以為這只是為了讓 LOG 能繼續寫不會漏掉，但其實更重要的是：如果不這麼作，你的硬碟可能很快就爆掉啦...

我們可以寫個簡單的程式來測試一下這種狀況：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#include <stdio.h>
#include <fcntl.h>
int main()
{
        int     fd, i;
        char    cmd[32], buf[1024];
        memset( buf, 0, 1024);
        snprintf(cmd,sizeof(cmd),"df .");
 
        printf("==> open file for write and delete it ...\n");
        fd = open( "test-file.log", O_CREAT|O_WRONLY|O_TRUNC );
        unlink("test-file.log");
        system(cmd);
 
        printf("\n==> write 100MB to file ...\n");
        for( i = 0 ; i < 1000*100 ; i++ )
                write( fd, buf, 1024);
        system(cmd);
 
        printf("\n==> close file ...\n");
        close(fd);
        system(cmd);
}

首先，這個小程式會先開啟一個檔案，然後馬上砍掉它（但先不關閉檔案），接下來執行 "df ." 來查看目前硬碟用量。第二步驟是寫入100MB的垃圾資料到這個已開啟的檔案(file descriptor)中，然後再執行 "df ." 來取得硬碟用量。最後關閉檔案後，再執行一次 "df ."。執行結果如下：

==> open file for write and delete it ...
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/ad8s1d 144520482 28011428 104947416    21%    /home

==> write 100MB to file ...
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/ad8s1d 144520482 28111508 104847336    21%    /home

==> close file ...
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/ad8s1d 144520482 28011428 104947416    21%    /home

我們可以看到程式寫了100MB之後，空間真的被佔掉了，即使我們已經刪除這個檔案，且從目錄的檔案列表中無法直接看到這個檔案了。而當被開啟的檔案關掉後，這些空間也立即被釋放回來了

接下來我們把程式中的 df 改成 fstat，可以更清楚看到狀況

1

        snprintf(cmd,sizeof(cmd),"fstat -f -p %d .", getpid());

這是最後的結果：

==> open file for write and delete it ...
USER     CMD     PID   FD MOUNT     INUM MODE         SZ|DV R/W
cdsheen  a.out 91475   wd /home 12694528 drwxr-xr-x    2048  r
cdsheen  a.out 91475 text /home 12694672 -rwxr-xr-x    7910  r
cdsheen  a.out 91475    3 /home 12694673 ----r-x--x       0  w

==> write 100MB to file ...
USER     CMD     PID   FD MOUNT     INUM MODE         SZ|DV R/W
cdsheen  a.out 91475   wd /home 12694528 drwxr-xr-x    2048  r
cdsheen  a.out 91475 text /home 12694672 -rwxr-xr-x    7910  r
cdsheen  a.out 91475    3 /home 12694673 ----r-x--x  102400000  w

==> close file ...
USER     CMD     PID   FD MOUNT     INUM MODE         SZ|DV R/W
cdsheen  a.out 91475   wd /home 12694528 drwxr-xr-x    2048  r
cdsheen  a.out 91475 text /home 12694672 -rwxr-xr-x    7910  r

從這版開始，官方也提供幾個主要硬體的安裝光碟了，
不再像之前一樣需要自己辛苦地製作安裝光碟了

http://ftp.giga.net.tw/OS/OpenBSD/4.2/i386/install42.iso
http://ftp.giga.net.tw/OS/OpenBSD/4.2/amd64/install42.iso
http://ftp.giga.net.tw/OS/OpenBSD/4.2/macppc/install42.iso
http://ftp.giga.net.tw/OS/OpenBSD/4.2/sparc/install42.iso
http://ftp.giga.net.tw/OS/OpenBSD/4.2/sparc64/install42.iso

讓大家方便安裝之餘，也請大家有能力的話，多多贊助一下吧

關於 OpenBSD 4.1 的相關資訊請參考： http://www.openbsd.org/41.html

照例製作了兩份安裝光碟 (包含 i386 與 amd64 兩種平台)，想用的人可以到以下網址抓取

OpenBSD 4.1 Unofficial Images: http://ftp.giga.net.tw/#openbsd

這份光碟是從 OpenBSD 4.1-RELEASE 製作的… 也有用 VMware 裝過沒問題了

同樣的還是要聲明一點，以上可以下載的安裝光碟都不是 OpenBSD 官方的安裝光碟，官方的安裝光碟是要賣錢的，如果你想幫助 OpenBSD 的開發團隊，請考慮購買一份官方的安裝光碟，訂購的資訊請詳閱：

http://www.openbsd.org/orders.html

關於 OpenBSD 4.0 的相關資訊請參考： http://www.openbsd.org/40.html

昨天下午把檔案 mirror 回來後（ftp.giga.net.tw ～當然 packages 沒有全抓，硬碟空間不夠^^||），就照例製作了兩份安裝光碟 (包含 i386 與 amd64 兩種平台)，想用的人可以到以下網址抓取

OpenBSD 4.0 Unofficial Images: http://ftp.giga.net.tw/#openbsd

這份光碟是從 OpenBSD 4.0-RELEASE 製作的...
昨天還嘗試用 VMware 裝過沒問題，或許應該把裝好的 VMware Image 也丟上來，可能會造福更多人...

同樣的還是要聲明一點，以上可以下載的安裝光碟都不是 OpenBSD 官方的安裝光碟，官方的安裝光碟是要賣錢的，如果你想幫助 OpenBSD 的開發團隊，請考慮購買一份官方的安裝光碟，訂購的資訊請詳閱：

http://www.openbsd.org/orders.html

其實 OpenBSD 4.0 早在九月底十月初就 Ready 了，mirror 的時候就可以發現很多檔案的日期都是一個月前的，隔一個月才把 binary 放出來大概是希望留點時間可以製作官方光碟吧... 有能力的人（或者有辦法決定公司採購預算的人^^）可以考慮贊助個幾張光碟吧

沒想到一時疏忽，修改 fstab 時忘了加上 /mirror/ ...

/dev/mirror/gm0s1b none swap sw 0 0
/dev/mirror/gm0s1a / ufs rw 1 1

所以重開機時開不起來了...
原本根據 這篇 的說明，只要在 mountroot> prompt 下，重新指定 root partition 位置就可以進去修正了...

但是，沒想到好像踩到 FreeBSD 6.1 的地雷了：
kern/98910: [kbd] keyboard not working at mountroot prompt on IBM T42P

也就是 mountroot> 下鍵盤不能動了.... 我用的是研華的伺服器，問題跟上面這個 PR 一模一樣...

偏偏我這台機器的光碟和軟碟又都壞了.... 只好很苦命的再把機器搬出機櫃來拆開，外接光碟重新修正了事....

首先是把系統碟先換到比較大顆的硬碟，步驟請參考：

FreeBSD Handbook: How do I move my system over to my huge new disk?

接下來就要玩玩 Software RAID-1 (Mirror) 了

過去 FreeBSD 下面 Software RAID 的作法大多使用 vinum，但 vinum 的用法比較複雜，而且似乎只能適用新的分割區，無法對原有的硬碟直接建立一份 Mirror。

GEOM Mirror (gmirror) 是一種從 FreeBSD 5.3 開始支援的新 Software RAID-1，尤其適用於系統碟 (root partition)。

關於 FreeBSD 下面幾種 Disk Mirroring 的作法，可參考：

FreeBSD System Disk Mirroring - How to establish a RAID-1 for the system partitions

詳細的作法可參考這篇文章：

ONLamp.com: Using Software RAID-1 with FreeBSD

對舊硬碟設定一下，然後重開機後，把新硬碟加上去，再稍微設定一下，十分鐘內就搞定了！

最方便的是，使用 GEOM Mirror 建立的系統碟在系統內部並不會有特殊設定檔，所有的設定是直接放在硬碟最後一個磁區的 metadata 內，而且使用 gmirror RAID-1 的系統碟可以隨時切換用任何一顆開機，不會有任何問題

除了 gmirror 提供 RAID-1 之外，同樣採用 GEOM 架構的程式還有 gstripe (RAID-0) 及 graid3 (RAID-3)，有興趣的人可以玩看看...

今天第一次嚐試在 Dell PowerEdge 2850 上面安裝 FreeBSD 6.0

安裝過程並沒有甚麼問題，但是安裝完成、並重新開機之後，發現 console 的鍵盤竟然不能動了！

同樣的情況似乎也存在於 FreeBSD 5.3 及 FreeBSD 5.4 的樣子（不確定，有人說 FreeBSD 5.3 沒這問題）

經過一番搜尋，發覺是因為這台機器上面有一張 "Dell Remote Access Card (DRAC)"，這個裝置會被系統辨識成一個 USB Keyboard，所以導致開完機之後，正常的 PS/2 鍵盤反而不能動了！

解決方式如下：

1. 先以 Single User Mode 進入系統
2. 在命令列模式下，先執行下列命令：

   # fsck -y  /
   # mount -u  /

3. 然後編輯 /etc/devd.conf，把對於 USB Keyboard 的支援暫時拿掉，也就是把下面幾行開頭加上 #

   # When a USB keyboard arrives, attach it as the console keyboard ...
   #attach 100 {
   #       device-name "ukbd0";
   #       action "kbdcontrol -k /dev/ukbd0 < /dev/console ...
   #};
   #detach 100 {
   #       device-name "ukbd0";
   #       action "kbdcontrol -k /dev/kbd0 < /dev/console";
   #};

4. 然後輸入 exit 離開 Single User Mode 之後，就可以順利進入系統，而且 console 鍵盤也可以正常運作，下次開機也不會有問題！

目前看起來，Dell PE-2850 使用 FreeBSD 6.0 當作業系統，除了上面這個 console 鍵盤問題之外，還沒遇到其他問題，系統也還算穩定

官方還沒正式宣佈，也沒得下載，不過 CVS 中已經可以取得 RELENG_6_0_0_RELEASE 了

先把手邊那台機器更新了...

FreeBSD flX 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov  3 10:15:06 CST 2005
     root@flX:/usr/obj/usr/src/sys/flX  amd64

然後我的 ASUS A8N-SLI (nForce4) 主機板內建的 Gigabit 網路卡 (nve)，終於可以運作了：

nve0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 00:11:d8:aa:03:7c
        media: Ethernet autoselect (none)
        status: no carrier

其實本來先測 FreeBSD 5.4-RC3，但是似乎與 ASUS A8N-SLI 主機板 + AMD64 CPU 不太合，而且 sysinstall 竟然抓不太到 SATA 硬碟... 所以最後還是決定玩看看 NetBSD 好了

安裝過程還算順利，就我的感覺，NetBSD 的安裝介面比 FreeBSD 簡單明瞭，第一次接觸的人比較不容易搞混，FreeBSD 的 sysinstall 選項稍微多了一點，新手有時會不知從哪下手!

裝起來後，設定四顆 200G 的 SATA 硬碟費了一些時間，主要是發現 NetBSD 抓到的硬碟順序竟然跟主機 BIOS 的硬碟順序不同... 這一點實在是很奇怪... 開關機不下數十次的反覆測試後終於搞清楚問題，設定好的系統差點被我自己 format 掉...

NetBSD 使用的是 pkgsrc 系統，大致是跟 FreeBSD ports 很像，只是 pkgsrc 是裝在 /usr/pkg/ 下面，source 則在 /usr/pkgsrc/ 下面，安裝軟體一樣是 make install 就好了... 不過使用上還是有點不習慣~~

pkgsrc 的軟體數目還沒有 FreeBSD ports 多，不過支援的作業系統很多：

看來 pkgsrc 的目標應該是希望有一天能統一江湖...

至於 NetBSD 系統本身的效能部分，則還沒有時間測試

不過這台機器是拿來當備份機的，所以可能也測不出什麼吧~

想玩的人可以到 GIGA FTP 依據你的硬體平台把 ISO 檔下載回去燒成光碟安裝..
最新版本是 NetBSD 2.0.2

CVS 部分，更新目前似乎都是直接對國外，國內好像找不到比較正式的 mirror..
改天有空在 GIGA 這邊也弄一份好了...

boot -s
# fsck -p
# mount -a -t ufs
# swapon -a
# passwd -l
# exit