顯示具有 ubuntu 標籤的文章。 顯示所有文章
顯示具有 ubuntu 標籤的文章。 顯示所有文章

2015年6月13日 星期六

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





2009年12月6日 星期日

telnet之中文(ubuntu)


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




2009年11月20日 星期五

衝吧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



2009年10月21日 星期三

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

重開機後就完成啦。

2009年10月18日 星期日

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是比較適合我們的

2009年10月17日 星期六

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

2009年9月30日 星期三

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. ......
結果: