OSSLab Geek Lab實測部署Nutanix超融合免費版4 node
總共四台物理Server
每台
E3-1270v3 3.5GHz 4核心
32GB DDR3 ECC
32GB SanDisk USB for boot
主版內建 2x 1G NIC
2x port Intel 10G NIC(考慮換成mellanox connectx3 )
1x 2T HDD
1x 128GB SSD
每台物理機只有單顆硬碟+單顆硬碟
但圖片VM內Disk I/O卻這樣快.這是因為Nutanix有採取SSD tiering+一些分散式儲存方法.
安裝還算簡單, 但一些思路會跟之前VM 虛擬化有點不同.
OSSLab Geek Lab將會做直播演講,來分享
1.傳統虛擬化跟超融合有啥不同
2.二種架構優缺點
3.免費版超融合安裝注意事項
4.免費版超融合實際操作示範
5.細部設定與備份等規劃
有啥想問的可以留言
#OSSLab #虛擬化Sever專家 #資料救援
#買東西不要光掏出錢 #要理解原理才好維護 #Nutanix
要理解原理才好維護 在 直流馬達DC Motor 原理(影片動畫讓人相當好懂好理解) 的推薦與評價
直流馬達DC Motor 原理(影片動畫讓人相當好懂好理解) ... (歡迎按讚或分享, 而想要一同召集行動的留言回覆按+1) ... 為網頁程式進行設計、修改、測試、佈署及維護. ... <看更多>
要理解原理才好維護 在 Re: [問題] 為什麼作業系統都用C寫? 而不用C++呢? 的推薦與評價
這串討論似乎變成C與C++之爭
最精采的是看到yehsd、yoco315(按字母順序排序)兩人的激烈攻防
這串討論我反覆地看過兩次,再上google參考前人對C/C++的見解
比對之下,個人覺得yehsd、yoco315兩位的論點太虛了,不著邊際,搔不到癢處
兩位可能都是一等一的高手,程式底子十分深厚,但是兩位的言論流於意氣之爭
幾乎沒什麼重點可言
討論什麼constructor是不是空的實在是很無聊,就算是空的又如何?
我個人比較傾向於認為:C++不適合用來寫OS,用C寫才是王道
但yehsd似乎也提不出多棒的觀點來證明C++的不好
以下是我向yoco315提出「用C++不適合寫OS」的理由
1.效能也許會較差(這一點兩位y兄爭了很久):
說真的,我完全不能證明C++比C效能還差,甚至我可以證明,C效能永遠不比C++好
證明如下:
若set_Y為C中效能優於C++的子集合,已知C++為C的超集,set_Y必然也是C++的子集
set_Y at C > set_Y at C++,固set_Y為空集合
總之,C做得到的C++也做得到,C++的效能沒理由較差
一般認為C++效能較差是有幾點現實上的考量:
a. C++太多太雜太難掌握,讓程式人員浪費太多時間在語言本身而非問題的最佳解上
b. C++會偷偷增加一些程式碼來維持本身的OO特性,一不小心就多出了不必要的code
c. C++會偷偷增加一些程式碼來維持運算子過載特性,一不小心就多出了不必要的code
d. 用C++物件導向實作的函式庫,很方便使用沒錯,但代價就是負擔太大(如Qt)
e. ...應該還有很多我不知道的
2.C++程式不易讀
C++遠比C複雜太多了,太多好用的功能疊加在一起就變得很難用
例如:運算子過載(重載?)
Integer a = 1; // a為1
Integer b = 3; // b為2
printf("a+b=%d", a+b); //印出3
運算子過載真是太好用了,而且程式一看就懂,真是太好維護了,但是如果…
Man a_man("大雄"); // 定義一個男人
Woman a_woman("靜香"); // 定義一個女人
int money = MAX_VALUE;
printf("幹這是什麼鬼:%s", a_man + money + a_woman);
這種code要怎麼維護?先回頭找一下Man與Woman中operator + 的定義
再確認與int作運算表示什麼,再查一下書看看運算的順序的先後關係,如果operator
中又用到其他operator的過載,又要再去查,為了追一個問題,又引起n個問題,為
了確認n個問題,又出現n^2個問題…沒完沒了。程式很簡潔沒錯,但是要怎麼debug?
難道每一行程式都要猜猜看嗎?
好的物件導向遠比C好維護,不過C++決對不是好的物件導向語言(這句話一言難盡)
3.物件導向不適合底層程式
了解物件導向的人就知道,它是較貼進人類思維的程式寫作方法,反之,它就不是
一個貼近底層機器運作原理的編程原則,機器語言、組語才是最貼近底層運作機制的
語言,想要用OO來描述機器的行為、自然法則、各式各樣的protocol…等等諸如此類
的運作機制容易流於天馬行空,任意妄為。如果硬要用物件導向來實作底層機制,可
能十個人有十二種不同的見解,沒人看得懂彼此的程式,因為每個人對機制的感受都
不一樣,物件結構的分析各有各的看法,沒完沒了。
當然,不用物件導向也是可以寫C++程式,但那還不如用C來的單純
(但個人偏愛用完全無繼承機制的物件架構來寫C++,來當作是C的加強版)
4.C++的複雜度太高
C公認的聖經只有一本,內文也才兩佰多頁,一本C++的入門書就一仟多頁(C++ Primer)
C++的功能及其運作細節多如牛毛,寫了10年的程式也許還會看到自已不懂的語法,或是
debug時發現某個平常不會注意的細節在作怪,這如果只是開發一般的AP還好,如果是開
發OS這種大型、不易物件化的程式時,事情就大條了。因為:
a.開發人員太多,每人都用一種冷門的技巧,那要trace code就要買十本C++在身邊才行
b.總有人喜歡賣弄技巧,喜歡來個多重繼承,自行定義運算子,把程式的複雜度弄得很高
自以為很強,等到程式成長到自已無法控制(可能久了也忘了)才雙手一攤說:比爾蓋茲
對不起,我要去Google上班了
c.自已乖一點不要寫出太複雜的程式就好了嗎?不!因為C++支援太多種技巧、style,
所以有時候不得不乖乖配合別人的程式風格,想維持單一模組風格的一致性也很因難
OS不是少數幾個人就能寫出來的程式,一定要有不少人力來大量的分工才能完成
,但高度的分工之後又必需維持緊密的偶合關係,是一項複雜度很高,極易失敗的專案
,如果再用一個複雜度相對較高的C++工具來寫的話,就難上加難了
最後,我很好奇某人說:C++的sort大勝C的qsort,理由何在?
※ 引述《yoco315 (眠月)》之銘言:
: ※ 引述《yehsd (急)》之銘言:
: : [再次感謝版友 adrianshum 提醒, 我應該說的詳細點]
: : 和這句, 有沒有矛盾點?
: : [我想說的是, ctor 是空的, 還是會有 default ctor, 這點如同 adrianshum
: : 所言. 如果在 instantiation 時指定了自訂的 ctor, compiler 就不會去 generate
: : default ctor. 所以 littleshan 所說的: constructor 是 compiler 幫你自動
: : 呼叫的指的應該是 default ctor? 因為這個 ctor 才是 compiler 會自動呼叫的,
: : 希望我沒誤解 littleshan 所說的 ^^]
: 我覺得你這個人不錯,
: 雖然不太懂 C++,但是會唸書,也會想,以後會很強。
: 我覺得你不錯,
: 所以我現在願意花時間打字講些很基本的東西給你看,
: 首先,一「空的」函數,在經過最佳化以後是不會被呼叫的,
: 不管他是你自己手寫的,還是編譯器自動生成的都一樣,
: 這是非常基本非常常見非常簡單的最佳化,
: 也就是說你所謂那一百萬次的函數呼叫成本其實不存在。
: : 這是 C++的優點, 但是也有可能是雙面刃.
: 你不能這樣說話的,
: 你得告訴我另外一面是什麼?
: 不然這個句型太強大了,什麼都能套下去,
: 我可以說「C 的不用初始化是一個雙面刃」,或說「C 的速度是一個雙面刃」,
: 但是我不跟你講原因,你會不會覺得我很笑?
: C++ 出來的早,只是「建議你」初始化,
: 現在新出來的語言,幾乎都強迫你一定要初始化,
: 你看,C++ 很卑微的。
: : 看到這邊, 我只能說我可能真的沒你那麼懂 C++, 小弟不才,
: : 用 C++ 開發一個比 C 寫出來還快的OS, 這個重責大任就交給比較懂的人囉.
: 現在懂的不多沒關係,你可以再多念一點,
: 如果你 CPPPL 真的念得很透的話,應該不會講出上面那些話,
: 使戳使挫在書裡面對 C++ 的效能提到很多了。
: 最後是跟程式無關的……
: 自己書看不夠的時候,盡量少叫別人看書,感覺不太好,你知道我的意思。
: 一個人有料的時候,自己可能不會知道。
: 但是一個人沒料的時候,旁邊的人都看得很清楚。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.136.212.64
要要怪到語言頭上,版上的眾高手不會濫用語言,所以不會覺得C++不好,我可以理解
2.C++讓人看不懂,是指沒辦法像C一樣用瞄的就可以知道在寫什麼,C++存在太多種可能
性,當維護要trace code時就顯得麻煩
3.我也知道編譯器的好壞、編譯選項、目標平台的instruction set、library的實作方式
…等等都會影響程式的效能,不過我必須強調,本文主要講的是語言本身的特性,而非
強調C與C++的編譯器及編譯環境,我也知道這才是效能好壞的重點,不過我還是要把
我的命題鎖定在語言本身的特性上,我文中也都是以這個命題在討論
※ 編輯: guest0079 來自: 220.136.212.64 (03/07 12:05)
... <看更多>