2015年7月18日 星期六
Find the latest modified file in a directory recursively.
{
if ($0>max) {
max=$0;
getline mostrecent
} else
getline
}
END{print mostrecent}' RS='\0'
2015年7月17日 星期五
script 的執行方式差異 (source, sh script, ./script)
##### [ demo01.sh
#!/bin/bash
# Program:
# User inputs his first name and last name. Program shows his full name.
# History:
# 2005/08/23 VBird First release
# 2015/07/16 Yulin Modified for demo of different script execution ways.
read -p "Please input your first name: " firstname # 提示使用者輸入
read -p "Please input your last name: " lastname # 提示使用者輸入
echo -e "\nYour full name is: $firstname $lastname" # 結果由螢幕輸出
##### ] demo01.sh
$source demo01.sh
$. demo01.sh
==> both the above 2 ways alter the environment of the parent process.
#sh demo01.sh
#./demo01.sh
==> both the above 2 ways create a child process to carry out the script and won't alter the environment of the parent process.
2015年6月24日 星期三
PuTTY進入Linux出現亂碼
2015年6月23日 星期二
五種開源授權規範的比較 (BSD, Apache, GPL, LGPL, MIT)
Open Source License scanner https://www.fossology.org/
原文 : http://inspiregate.com/internet/trends/74-comparison-of-five-kinds-of-standard-open-source-license-bsd-apache-gpl-lgpl-mit.html
BSD開源協議(FreeBSD license、Original BSD license)
BSD開源協議是一個給於使用者很大自由的協議。基本上使用者可以"為所欲為",可以自由的使用,修改源代碼,也可以將修改後的代碼作為開源或者專有軟件再發佈。但"為所欲為"的前提當你發佈使用了BSD協議的代碼,或則以BSD協議代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
如果再發佈的產品中包含源代碼,則在源代碼中必須帶有原來代碼中的BSD協議。
如果再發佈的只是二進制類庫/軟件,則需要在類庫/軟件的文檔和版權聲明中包含原來代碼中的BSD協議。
不可以用開源代碼的作者/機構名字和原來產品的名字做市場推廣。
BSD 代碼鼓勵代碼共享,但需要尊重代碼作者的著作權。BSD由於允許使用者修改和重新發佈代碼,也允許使用或在BSD代碼上開發商業軟件發佈和銷售,因此是對 商業集成很友好的協議。而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。
Apache Licence 2.0/1.1/1.0
Apache Licence是著名的非盈利開源組織Apache採用的協議。該協議和BSD類似,同樣鼓勵代碼共享和尊重原作者的著作權,同樣允許代碼修改,再發佈(作為開源或商業軟件)。需要滿足的條件也和BSD類似:需要給代碼的用戶一份Apache Licence
如果你修改了代碼,需要再被修改的文件中說明。
在延伸的代碼中(修改和有源代碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。
如果再發佈的產品中包含一個Notice文件,則在Notice文件中需要帶有Apache Licence。你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。使用者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發佈/銷售。
GPL(GNU General Public License)
我們很熟悉的Linux就是採用了GPL。GPL協議和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代 碼做為閉源的商業軟件發佈和銷售。這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商 業軟件公司開發的免費軟件了。GPL協議的主要內容是只要在一個軟件中使用("使用"指類庫引用,修改後的代碼或者衍生代碼)GPL 協議的產品,則該軟件產品必須也採用GPL協議,既必須也是開源和免費。這就是所謂的"傳染性"。GPL協議的產品作為一個單獨的產品使用沒有任何問題, 還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟件產品必須使用GPL協議,對於使用GPL協議的開源代碼,商業軟件或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。
其它細節如再發佈的時候需要伴隨GPL協議等和BSD/Apache等類似。
LGPL(Lesser GPL)
LGPL是GPL的一個為主要為類庫使用設計的開源協議。和GPL要求任何使用/修改/衍生之GPL類庫的的軟件必須採用GPL協議不同。LGPL允許商 業軟件通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟件的代碼。這使得採用LGPL協議的開源代碼可以被商業軟件作為類庫引用並發布和 銷售。但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協議。因此LGPL協議的開源代碼很 適合作為第三方類庫被商業軟件引用,但不適合希望以LGPL協議代碼為基礎,通過修改和衍生的方式做二次開發的商業軟件採用。
GPL/LGPL都保障原作者的知識產權,避免有人利用開源代碼複製並開發類似的產品
MIT
MIT是和BSD一樣寬範的許可協議,作者只想保留版權,而無任何其他了限制.也就是說,你必須在你的發行版裡包含原許可協議的聲明,無論你是以二進制發佈的還是以源代碼發佈的.現今存在的開源協定很多,而經過Open Source Initiative組織通過批准的開源協定目前有58種(http://www.opensource.org/licenses /alphabetical)。 我們在常見的開源協定如BSD, GPL, LGPL,MIT等都是OSI批准的協定。 如果要開源自己的代碼,最好也是選擇這些被批准的開源協定。
這裏我們來看四種最常用的開源協定及它們的適用範圍,供那些準備開源或者使用開源產品的開發人員/廠家參考。
BSD開源協定(original BSD license、FreeBSD license、Original BSD license)
BSD開源協定是一個給於消費者很大自由的協定。 基本上消費者可以“為所欲為”,可以自由的使用,修改原始程式碼,也可以將修改後的代碼作為開源或者專有軟體再發佈。
但「為所欲為」的前提當你發佈使用了BSD協議的代碼,或則以BSD協定代碼為基礎做二次開發自己的產品時,需要滿足三個條件:
1. 如果再發佈的產品中包含原始程式碼,則在原始程式碼中必須帶有原來代碼中的BSD協定。
2. 如果再發佈的只是二進位類庫/軟體,則需要在類庫/軟體的文件和版權聲明中包含原來代碼中的BSD協定。
3. 不可以用開原始程式碼的作者/機構名字和原來產品的名字做市場推廣。
BSD 代碼鼓勵代碼共用,但需要尊重代碼作者的著作權。 BSD由於允許消費者修改和重新發佈代碼,也允許使用或在BSD代碼上開發商業軟體發佈和銷售,因此是對商業集成很友好的協定。 而很多的公司企業在選用開源產品的時候都首選BSD協議,因為可以完全控制這些第三方的代碼,在必要的時候可以修改或者二次開發。
Apache Licence 2.0(Apache License, Version 2.0、Apache License, Version 1.1、Apache License, Version 1.0)
Apache Licence是著名的非盈利開源組織Apache採用的協定。 該協定和BSD類似,同樣鼓勵代碼共用和尊重原作者的著作權,同樣允許代碼修改,再發佈(作為開源或商業軟體)。 需要滿足的條件也和BSD類似:
1. 需要給代碼的使用者一份Apache Licence
2. 如果你修改了代碼,需要再被修改的文件中說明。
3. 在延伸的代碼中(修改和有原始程式碼衍生的代碼中)需要帶有原來代碼中的協議,商標,專利聲明和其他原來作者規定需要包含的說明。
4. 如果再發佈的產品中包含一個Notice檔,則在Notice檔中需要帶有Apache Licence。 你可以在Notice中增加自己的許可,但不可以表現為對Apache Licence構成更改。
Apache Licence也是對商業應用友好的許可。 消費者也可以在需要的時候修改代碼來滿足需要並作為開源或商業產品發佈/銷售。
GPL(GNU General Public License)
我們很熟悉的Linux就是採用了GPL。 GPL協定和BSD, Apache Licence等鼓勵代碼重用的許可很不一樣。 GPL的出發點是代碼的開源/免費使用和引用/修改/衍生代碼的開源/免費使用,但不允許修改後和衍生的代 碼做為閉源的商業軟體發佈和銷售。 這也就是為什麼我們能用免費的各種linux,包括商業公司的linux和linux上各種各樣的由個人,組織,以及商 業軟體公司開發的免費軟體了。
GPL協定的主要內容是只要在一個軟體中使用(“使用”指類庫引用,修改後的代碼或者衍生代碼)GPL 協定的產品,則該軟體產品必須也採用GPL協定,既必須也是開源和免費。 這就是所謂的「傳染性」。。 GPL協議的產品作為一個單獨的產品使用沒有任何問題, 還可以享受免費的優勢。
由於GPL嚴格要求使用了GPL類庫的軟體產品必須使用GPL協議,對於使用GPL協議的開原始程式碼,商業軟體或者對代碼有保密要求的部門就不適合集成/採用作為類庫和二次開發的基礎。
其它細節如再發佈的時候需要伴隨GPL協定等和BSD/Apache等類似。
關於開源協定GPL V2和V3
單從開源行業的GPL協定上來看,似乎開源linux產品上的一切是可以無條件的開放和共用的,但是從實際的操作來看,在GPL相對的許可授權之下,又有其相對封閉的一面,就這次的GPL v2到GPL v3的修訂改版來說,正是GPL協定“封閉”一面的具體體現。
根據GPL v2的相關規定:只要這種修改文本在整體上或者其某個部分來源於遵循GPL的程式,該修改文本的整體就必須按照GPL流通,不僅該修改文本的源碼必須向社 會公開,而且對於這種修改文本的流通不准許附加修改者自己作出的限制。 而在GPL v3的修訂草案中,不僅要求用戶公佈修改的原始程式碼,還要求公佈相關硬體,恰恰是這一條,由於觸及和其他相關數字版權管理(DRM)及其產品的關係,並且也 由於有和開源精神相違的地方,所以備受爭議,甚至因此也遭到了有著“LINUX之父”之稱的托瓦爾茲的反對。
從表面上看,GPL v2到GPL v3的升級之困只不過是對協定修訂過程中某一條款的分歧,而更為嚴重的是在兩種協定都合法存在的前提下,具體的開源軟體或者開源產品的所有者有權選擇是遵 循GPL v2協議還是恪守GPL v3協定,因此衝突也就來了,這種衝突正如中科紅旗的CTO鄭忠源描述的那樣:“世界有如此多軟體都在GPL v2的約束之下, 而自由軟體是集合全世界程式師勞動,即使是貢獻一行代碼,如果該程式師只同意這一代碼只遵循GPL v2之下,就不能隨便去修改協定。 如果計劃將軟體轉移到GPL v3之下,理論上講,必須徵得所有代碼人的同意。 但是目前還很難確定有多少開發人員願意轉移到新版本之下,如果有的人願意轉,有的人不願意轉,這其中就有 很多的麻煩; 而如果多數人都不願意改變,那這一事情也許就無聲無息......”
通過業內人士的精闢描述,相信大家一定對開源行業和開源軟體產品有了一個全新的認識吧,就那熟悉的LINUX系統來說,雖然表面上看起來大家有權按 照自己的需要和目的進行任意的改寫重組,但是在諸多的獨立程式面前,別人是只能共用使用,而無權修改的,當然獲得授權就另當別論了。 而就GPL v2到GPL v3的協定升級來說,這種協議的選擇上的分歧實際上也是開源行業里一種觀念認知上的相左,到底誰的選擇是正確的? 絕對不是一兩句話能說得清的,尤其是在各 種利益交織之下。
情勢之下,開源社區的GPL v2與GPL v3選擇之困很現實的會在相當一段時間內給這個行業及其產品造成“兼容問題”,說白了就是兩種協定以及兩種協定之下的矛盾,不管是人的還是產品的都將會持 續下去,而這種僵持對整個開源行業來說未必是一件好事,最起碼從“精神”方面來說這個行業已經在開始分道揚鑣。
LGPL(GNU Lesser General Public License)
LGPL是GPL的一個為主要為類庫使用設計的開源協定。 和GPL要求任何使用/修改/衍生之GPL類庫的的軟體必須採用GPL協定不同。 LGPL 允許商業軟體通過類庫引用(link)方式使用LGPL類庫而不需要開源商業軟體的代碼。 這使得採用LGPL協議的開原始程式碼可以被商業軟體作為類庫引用併 發佈和銷售。
但是如果修改LGPL協議的代碼或者衍生,則所有修改的代碼,涉及修改部分的額外代碼和衍生的代碼都必須採用LGPL協定。 因此LGPL協定的開原始程式碼很適合作為第三方類庫被商業軟體引用,但不適合希望以LGPL協定代碼為基礎,通過修改和衍生的方式做二次開發的商業軟體採用。
GPL/LGPL都保障原作者的智慧財產權,避免有人利用開原始程式碼複製並開發類似的產品
MIT(MIT)
MIT是和BSD一樣寬范的許可協定,作者只想保留版權,而無任何其他了限制. 也就是說,你必須在你的發行版里包含原許可協定的聲明,無論你是以二進位發佈的還是以原始程式碼發佈的GPL v2
- 又稱為 “General Public Virus", 只要 引用/修改/衍生自 GPL 授權程式碼的軟體也必須採用GPL 授權且必須公開程式碼。
- Linux Kernel 使用此授權
GPL v3
- 基於 GPLv2, 但加入專利授權
- GNU Make 使用此授權
LGPL
- 若在程式中引用了 LGPL 授權的 library 而不是修改 LPGL 授權程式本體而產生衍生版本,引用library 的程式便不需要公開程式碼。
- GNU C Library 使用此授權
AGPL
- GPL 威力加強版, 主要是針對雲端服務. 只要讓使用者執行, 無論透過網路還是實體程式, 都需開放源始碼
- Gitorious 使用此授權
整理比較表格如下:



2015年6月11日 星期四
2015年5月11日 星期一
WISH電瓶耗電
技師/班長/組長都來一起幫忙看,不過一開口就是指向我加裝的GSM/超音波/不斷電喇叭
不甘心的我,請他們先把冷光踏板斷電,再量還是沒什麼差異
我只好拔下車上的GSM手機,一量之下只剩下0.09A,雖然離不加裝任何防盜品的原車0.02A-0.03A還有一段距離,但是至少抓到了耗電最大的加裝品......
依猴子爸測得原廠防盜耗0.2A,和原廠說的數據0.02A差了10倍
您測得的0.2A...會不會太大了點? 我是在有加裝二顆不斷電喇叭+GSM防盜+12v小電瓶的情況下才吃到0.2A,你的車子是否可能有漏電?
因為以46安培的電池充飽電, 46/0.2 = 230(小時) = 9.58(天) 完全吃完電的話,即使是新車應該不到一個禮拜就發不起來了,但實際上車子卻可以放到二個禮拜還是發的起來,甚至有同學放到一個月(我個人很佩服~
p.s. 想不到故障燈這麼耗電,只是閃個燈...實在不太了解
2015年4月27日 星期一
Integrate OpenCV with QT
Install QT, CMake, and OpenCV
PATH=%PATH%;
Launch CMake_GUI
Set [Source code] to %CV%
Set [Build] to %CV%\mingw
Click "Configure"
Specify the generator for this project = MinGW Makefiles
Specify native compilers = %QT%\Tools\mingw482_32\bin\gcc.exe and g++.exe
You can see lots of items are colored in red.
Alter configuration (optional),
Check BUILD_EXAMPLES
Check INSTALL_*
Uncheck WITH_1394
Check WITH_OPENGL
Check WITH_QT
Click "Configure" and some items are colored in red:
%QT%/5.3/mingw482_32/lib/cmake/Qt5Concurrent
%QT%/5.3/mingw482_32/lib/cmake/Qt5Gui
%QT%/5.3/mingw482_32/lib/cmake/Qt5Test
%QT%/5.3/mingw482_32/lib/cmake/Qt5Widgets
%QT%/5.3/mingw482_32/lib/cmake/Qt5OpenGL
Click "Configure" and you see
All items are colored in white rather than in red.
Configuring done
Click "Generate" to generate makefiles.
Open a command prompt in
mingw32-make
mingw32-make install