apt-get update之更新non-LTS套件之解法

Ubuntu之非NON-LTS(Long Term Support)版本，通常9個月後就不再support，所以apt-get update更新往往就會看到找不到package的錯誤。 此時這些舊的package都會被移到http://old-releases.ubuntu.com/，所以要改一下路徑apt package的路徑。

brook@vista:~$ cat /etc/issue
Ubuntu 13.04 \n \l
 
brook@vista:~$ sudo apt-get update
[sudo] password for brook:
Ign http://extras.ubuntu.com raring Release.gpg
Ign http://archive.ubuntu.com raring Release.gpg
....
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/raring-security/main/binary-i386/Packages  404  Not Found [IP: 91.189.88.149 80]
 
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/raring-security/restricted/binary-i386/Packages  404  Not Found [IP: 91.189.88.149 80]
 
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/raring-security/universe/binary-i386/Packages  404  Not Found [IP: 91.189.88.149 80]
 
W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/raring-security/multiverse/binary-i386/Packages  404  Not Found [IP: 91.189.88.149 80]
 
E: Some index files failed to download. They have been ignored, or old ones used instead.

Solution：

brook@vista:~$ cat /etc/apt/sources.list
#deb http://old-releases.ubuntu.com/ raring-security main
#deb http://old-releases.ubuntu.com/ubuntu/dists/raring-security/restricted/ raring-security main
deb http://old-releases.ubuntu.com/ubuntu/ raring main
deb http://old-releases.ubuntu.com/ubuntu/ raring universe

參考資料：
1. Ubuntu LTS(Long Term Support)
2. Old Ubuntu Releases

telnet之中文(ubuntu)

今天用ubuntu的"Terminal"上ptt，卻出現亂碼，原來是"Character Encoding"預設是"UTF-8"，將其改成"BIG5"就OK啦，post文章中文也不成問題了。

衝吧ubuntu

由於現在的CPU都有動態調整CPU頻率的能力，所以，一般都會在比較低的頻率上執行，在ubuntu 9.10上，預設是ondemand，所以平常都是以最低的頻率執行，有需要的時候才會逐漸調高頻率執行，有哪些參數可以下？請參考：

brook@ubuntu:~$ more /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors 
conservative ondemand userspace powersave performance 

您可以在您的/etc/init.d底下發現一個名為ondemand的檔案，將內文中的"ondemand"改為您想要執行的governor即可，我是效能愛好者，所以，我當然是"performance"嚕。如：

#! /bin/sh
### BEGIN INIT INFO
# Provides:          ondemand
# Required-Start:    $remote_fs $all
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Set the CPU Frequency Scaling governor to "ondemand"
### END INIT INFO


PATH=/sbin:/usr/sbin:/bin:/usr/bin

. /lib/init/vars.sh
. /lib/lsb/init-functions

case "$1" in
    start)
        start-stop-daemon --start --background --exec /etc/init.d/ondemand -- background
        ;;
    background)
        sleep 60 # probably enough time for desktop login

        for CPUFREQ in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
        do
                [ -f $CPUFREQ ] || continue
                echo -n performance > $CPUFREQ
        done
        ;;
    restart|reload|force-reload)
        echo "Error: argument '$1' not supported" >&2
        exit 3
        ;;
    stop)
        ;;
    *)
        echo "Usage: $0 start|stop" >&2
        exit 3
        ;;
esac

ubuntu 9.04(jaunty)升級至9.10(karmic)

今天心血來潮，索性把ubuntu 9.04升級到9.10，沒考慮太多，所以不怕危險的話，就彷下面步驟升級吧。

1. 修改/etc/apt/sources.list，把裏面的jaunty改成karmic
2. apt-get update
3. apt-get dist-upgrade

重開機後就完成啦。

32位元的compiler在32bit與64bit ubuntu下效能比較

繼之前的效能比較後(64bit與32bit應用程式在64位元ubuntu下之效能比較)，我們面對比較實際的問題，因為開發用的compiler為32-bit之montavista，那麼到底是32位元的ubuntu效能好還是64位元的ubuntu好，所以我們決定直接將專案分別在32bit和64bit的ubuntu下compiler 10次，最後，發現在32bit底下有較好的效能。

圖為montavista 32bit compiler分別在32bit與64bit ubuntu下，compile專案所需的時間，以及所設定的make之job數比較圖，很明顯的，當job數越多，效能越好，而且32bit效能一直好過64bit。

JOBS	64-bit(sec)	32-bit(sec)
default(4)	479.567	451.847
6	426.922	400.545
8	400.724	370.174
10	393.842	363.798
12	391.594	361.957

這邊的結論不是想說32bit或是64bit的ubuntu哪個好，而是得到在我們的編譯環境下，32bit的ubuntu是比較適合我們的

64bit與32bit應用程式在64位元ubuntu下之效能比較

手邊最近剛好進來了一台i7搭配6G的PC，雖然裝了ubuntu 64bit-server的OS，但是我們的應用程式很多都還是32位元的，而且很好奇到底是64bit的application快，還是32bit的application快，於是我分別將unixbench編譯成32-bit和64-bit進行測試。
結果發現，即便是在64bit的OS下執行程式，32bit的效能不見得比64bit來的差，不是單純的將OS和硬體升級成64位元，電腦就會變快了，應用程式有沒有對64做最佳化也是非常重要的關鍵。

在讀寫方面，64位元小勝32位元。圖表為讀寫10sec所讀寫到的資料量，file system為ext3。

在一些演算法的運算下，各有小勝的項目。

在process的處理上，32bit勝出。


至於system call和pipe則64bit勝出。


檔案複製上，32bit勝出。(這點感覺還挺那悶的)

數值運算上，64bit小勝。

所有數據資料

	64-bit	32-bit
Dhrystone 2 without register variables	22989948.3	15872890.4	lps
Dhrystone 2 using register variables	23031345.5	15525587.1	lps
Arithmetic Test (type = register)	3795084.9	3800669.2	lps
Arithmetic Test (type = short)	3792994	3475120.4	lps
Arithmetic Test (type = int)	3798887.6	3795243.4	lps
Arithmetic Test (type = long)	1361641.8	3797989.6	lps
Arithmetic Test (type = float)	2999814.7	1755172.6	lps
Arithmetic Test (type = double)	1908910.6	1755790.4	lps
System Call Overhead Test	5310434.8	4194268.7	lps
Pipe Throughput Test	2713396.7	2364773.8	lps
Pipe-based Context Switching Test	N/A	421790.3
Process Creation Test	13766.1	14274.1	lps
Execl Throughput Test	4028.2	4128.9	lps
File Read  (10 seconds)	8619286	7545589	KBps
File Write (10 seconds)	1519095	1453324	KBps
File Copy  (10 seconds)	79768	91090	KBps
File Write (30 seconds)	1515752	N/A	KBps
File Copy  (30 seconds)	89420	N/A	KBps
C Compiler Test	1826.8	1863	lpm
Shell scripts (1 concurrent)	8495.3	15928.3	lpm
Shell scripts (2 concurrent)	6293.3	12343.3	lpm
Shell scripts (4 concurrent)	4276.7	7584.6	lpm
Shell scripts (8 concurrent)	2818	5387	lpm
Dc: sqrt(2) to 99 decimal places	593737.4	625083.3	lpm
Recursion Test--Tower of Hanoi	244750.3	168275.4	lps
Arithmetic Test (type = double)	751	690.8
Dhrystone 2 without register variables	1027.9	709.7
Execl Throughput Test	244.1	250.2
File Copy  (30 seconds)	499.6	N/A
Pipe-based Context Switching Test	0	319.9
Shell scripts (8 concurrent)	704.5	1346.8

下載unixbench：
http://www.tux.org/pub/tux/benchmarks/System/unixbench

linux - 監控溫度(EX58-UD3R)

規格:
主機板: EX58-UD3R
CPU : i7 920

安裝:
brook@ubuntu:~$ sudo apt-install lm-sensors
brook@ubuntu:~$ sudo modprobe coretemp
brook@ubuntu:~$ sensors

錯誤排除:
brook@ubuntu:~$ sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. brook@ubuntu:~$ sudo modprobe coretemp 或者 brook@ubuntu:~$ sudo sensors-detect # sensors-detect revision 5249 (2008-05-11 22:56:25 +0200) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. We can start with probing for (PCI) I2C or SMBus adapters. ......
結果: