Skip to main content

Home/ Larvata/ Group items tagged 工作

Rss Feed Group items tagged

Filter: All | Bookmarks | Topics Simple Middle
張 旭

第 06 章 - 計算機概論 - 作業系統概論 - 0 views

dic.vbird.tw/...2020unit06.php

system

shared by 張 旭 on 22 Jun 21 - No Cached
  • 自行參考電腦硬體來設計出運算的軟體，當時的系統並沒有『作業系統』的概念，因為應用程式與作業系統是同時設計的。
  • 電腦裡面有儲存設備 (不論是硬碟還是記憶體)， 所以電腦硬體裡面會執行一隻監督程式 (monitor)，使用者可以預先將自己的程式讀進系統，系統先儲存該程式到佇列 (queue)，等到輪到該程式運作後， 就將該程式讀入讓 CPU 開始運作，直到運作結束輸出到印表機之後，將該工作丟棄，然後開始讀入在 queue 裡面的新的程式，依序執行。
  • 將 CPU 與 I/O 分離開
  • ...38 more annotations...
  • 透過卡片與讀卡機，將程式碼一次性的讀進大機器，然後就是等待大機器的運作， 結果再交由印表機印出。如果打卡紙打洞錯誤呢？只好重新打洞，重新排隊去運作程式了。
  • 允許兩個以上的程序在記憶體中等待被 CPU 執行，當 CPU 執行完其中一隻程式後， 第二隻程式就可以立刻被執行，因此效能會比較好。
  • 程序的狀態進入中斷狀態，CPU 不會理會該程序
  • CPU 的排程 (cpu scheduling)
  • 早期單核 CPU 的運作中，CPU 一次只能運作一個工作，因此，若有多個工作要同時進行， 那麼 CPU 就得要安排一個 CPU 運作時間給所有的工作，當該程序達到最大工作時間後，CPU 就會將該工作排回佇列，讓下一隻程序接著運作。
  • 你會覺得 CPU 是同時運作所有的程序，其實不是的！而是 CPU 在各個程序之間切換工作而已。
  • 分時系統其實與多元程式處理系統有點類似， 只是工作的輸入改為透過終端機操作輸入，CPU 可以在各個用戶操作間切換工作，於是每個使用者感覺似乎都是在同步操作電腦系統一般， 這就是分時系統。
  • 早期的程式設計師要設計程式是件苦差事，因為得要了解電腦硬體，並根據該電腦硬體來選擇程式語言，然後根據程式語言來設計運算工作、記憶體讀寫工作、 磁碟與影像輸入輸出工作、檔案存取工作等。等於從硬體、軟體、輸入輸出行為都得要在自己的程式碼裡面一口氣完成才行。
  • 在 1971 年開始的 unix 系統開發後，後續的系統大多使用 unix 的概念
  • 將硬體管理的工作統一交給一組程式碼去進行，而且這組程式碼還提供了一個開發界面
  • 軟體工程師只要依據這組程式碼規範的開發界面後，該軟體開發完成就能夠在這組程式碼上面運作了
  • 程式的執行
  • 作業系統需要將使用者交付的軟體程序分配到記憶體中， 然後透過 CPU 排程持續的交錯的完成各項任務才行。
  • CPU 中斷 (interrupt) 的功能
  • CPU 根據硬體擁有許多與週邊硬體的中斷通道， 當接收到中斷訊號時，CPU 就會嘗試將該程序列入等待的狀態下，讓該硬體自行完成相關的任務後，然後再接管系統。
  • 記憶體管理模組
  • 舊的環境底下，程式設計師需要自己判斷自己的程式會用到多少記憶體，然後自行指定記憶體使用位址的任務。
  • 系統會自動去偵測與管理主記憶體的使用狀態，避免同一個記憶體位址同時被兩個程序所使用而讓程序工作損毀
  • 作業系統核心也在記憶體中， 因此核心也會被這個子系統放入受保護的記憶體區段，一般用戶是無法直接操作該受保護的記憶區段的。
  • 虛擬記憶體 (virtual memory)
  • 主記憶體當中的資料並不是連續的，主記憶體的資料就像磁碟一樣，重複讀、刪、寫之後， 記憶區段是不會連續的
  • CPU 主要讀出虛擬記憶體，記憶體管理模組就會主動讀出資料
  • 一隻程序的資料是連續的 (左側)，但是實際上對應的是在主記憶體或其他位置上
  • CPU 排程
  • 作業系統好不好的重要指標之一！如何讓 CPU 在多工的情況下以最快速的方式將所有的工作完成，這方面的演算法是目前各主要作業系統持續在進步的部份。
  • 磁碟存取與檔案系統
  • 作業系統則需要驅動磁碟(不論是傳統硬碟還是 SSD)，然後也需要了解該磁碟內的檔案系統格式， 之後透過檔案系統這個子系統來進行資料的處理。
  • 裝置的驅動程式
  • 作業系統必須要能夠接受硬體裝置的驅動，所以硬體製造商可以推出給各個不同作業系統使用的驅動程式 (dirver / modules)， 這樣作業系統直接將該驅動程式載入後，即可開始使用該硬體，而不需要重新編譯作業系統。
  • 網路子系統
  • 使用者界面
  • 現代 CPU 設計的主要思考依據，讓一個 CPU 封裝 (單一一顆 CPU 硬體) 裡面，整合多個 CPU 核心，也就是多核心 CPU 製造的思考方向。
  • 對於單執行緒的程式來說， 多核心的 CPU 不見得會跑得比單核的快！這是因為單執行緒只有一個程序在進行，所以 CPU 時脈越高，代表會越快執行完畢。
  • 軟體會將單一工作拆分成數個小工作，分別交給不同的核心去執行，這樣每個核心只要負責一小段任務， 當然 CPU 時脈不用高，只要數量夠大，效能就會提昇很明顯
  • 由於 CPU 是由作業系統控制的，因此，你要使用到多核心的硬體系統，你的作業系統、應用程式都需要設計程可以支援多核心才行！
  • 所謂的平行處理功能，讓一件工作可以拆分成數個部份，讓這些不同的部份丟給不同的 CPU 去運算， 然後再透過一支監控程式，將各別的計算在一定的時間內收回統整後，再次的細分小工作發派出去，持續這些動作後，直到程式執行完畢為止。
  • 對於 Linux 來說，大部分都可以支援到 4096 個 CPU 核心數。
  • 銀行商用大型主機 Unix 系統
張 旭

鳥哥的 Linux 私房菜 -- 第零章、計算機概論 - 0 views

linux.vbird.org/...0105computers.php

system

shared by 張 旭 on 22 Jun 21 - No Cached
  • 但因為 CPU 的運算速度比其他的設備都要來的快，又為了要滿足 FSB 的頻率，因此廠商就在 CPU 內部再進行加速， 於是就有所謂的外頻與倍頻了。
  • 中央處理器 (Central Processing Unit, CPU)，CPU 為一個具有特定功能的晶片， 裡頭含有微指令集，如果你想要讓主機進行什麼特異的功能，就得要參考這顆 CPU 是否有相關內建的微指令集才可以。
  • CPU 內又可分為兩個主要的單元，分別是： 算數邏輯單元與控制單元。
  • ...63 more annotations...
  • CPU 讀取的資料都是從主記憶體來的！ 主記憶體內的資料則是從輸入單元所傳輸進來！而 CPU 處理完畢的資料也必須要先寫回主記憶體中，最後資料才從主記憶體傳輸到輸出單元。
  • 重點在於 CPU 與主記憶體。 特別要看的是實線部分的傳輸方向，基本上資料都是流經過主記憶體再轉出去的！
  • CPU 實際要處理的資料則完全來自於主記憶體 (不管是程式還是一般文件資料)！這是個很重要的概念喔！ 這也是為什麼當你的記憶體不足時，系統的效能就很糟糕！
  • 常見到的兩種主要 CPU 架構， 分別是：精簡指令集 (RISC) 與複雜指令集 (CISC) 系統。
  • 微指令集較為精簡，每個指令的執行時間都很短，完成的動作也很單純，指令的執行效能較佳； 但是若要做複雜的事情，就要由多個指令來完成。
  • CISC在微指令集的每個小指令可以執行一些較低階的硬體操作，指令數目多而且複雜， 每條指令的長度並不相同。因為指令執行較為複雜所以每條指令花費的時間較長， 但每條個別指令可以處理的工作較為豐富。
  • 多媒體微指令集：MMX, SSE, SSE2, SSE3, SSE4, AMD-3DNow! 虛擬化微指令集：Intel-VT, AMD-SVM 省電功能：Intel-SpeedStep, AMD-PowerNow! 64/32位元相容技術：AMD-AMD64, Intel-EM64T
  • 若光以效能來說，目前的個人電腦效能已經夠快了，甚至已經比工作站等級以上的電腦運算速度還要快！ 但是工作站電腦強調的是穩定不當機，並且運算過程要完全正確，因此工作站以上等級的電腦在設計時的考量與個人電腦並不相同啦
  • 1 Byte = 8 bits
  • 檔案容量使用的是二進位的方式，所以 1 GBytes 的檔案大小實際上為：1024x1024x1024 Bytes 這麼大！ 速度單位則常使用十進位，例如 1GHz 就是 1000x1000x1000 Hz 的意思。
  • CPU的運算速度常使用 MHz 或者是 GHz 之類的單位，這個 Hz 其實就是秒分之一
  • 在網路傳輸方面，由於網路使用的是 bit 為單位，因此網路常使用的單位為 Mbps 是 Mbits per second，亦即是每秒多少 Mbit
  • (1)北橋：負責連結速度較快的CPU、主記憶體與顯示卡界面等元件
  • (2)南橋：負責連接速度較慢的裝置介面， 包括硬碟、USB、網路卡等等
  • CPU內部含有微指令集，不同的微指令集會導致CPU工作效率的優劣
  • 時脈就是CPU每秒鐘可以進行的工作次數。 所以時脈越高表示這顆CPU單位時間內可以作更多的事情。
  • 早期的 CPU 架構主要透過北橋來連結系統最重要的 CPU、主記憶體與顯示卡裝置。因為所有的設備都得掉透過北橋來連結，因此每個設備的工作頻率應該要相同。
  • 前端匯流排 (FSB)
  • 外頻指的是CPU與外部元件進行資料傳輸時的速度
  • 倍頻則是 CPU 內部用來加速工作效能的一個倍數
  • 新的 CPU 設計中， 已經將記憶體控制器整合到 CPU 內部，而連結 CPU 與記憶體、顯示卡的控制器的設計，在Intel部份使用 QPI (Quick Path Interconnect) 與 DMI 技術，而 AMD 部份則使用 Hyper Transport 了，這些技術都可以讓 CPU 直接與主記憶體、顯示卡等設備分別進行溝通，而不需要透過外部的連結晶片了。
  • 如何知道主記憶體能提供的資料量呢？此時還是得要藉由 CPU 內的記憶體控制晶片與主記憶體間的傳輸速度『前端匯流排速度(Front Side Bus, FSB)
  • 主記憶體也是有其工作的時脈，這個時脈限制還是來自於 CPU 內的記憶體控制器所決定的。
  • CPU每次能夠處理的資料量稱為字組大小(word size)， 字組大小依據CPU的設計而有32位元與64位元。我們現在所稱的電腦是32或64位元主要是依據這個 CPU解析的字組大小而來的
  • 早期的32位元CPU中，因為CPU每次能夠解析的資料量有限， 因此由主記憶體傳來的資料量就有所限制了。這也導致32位元的CPU最多只能支援最大到4GBytes的記憶體。
  • 在每一個 CPU 內部將重要的暫存器 (register) 分成兩群， 而讓程序分別使用這兩群暫存器。
  • 可以有兩個程序『同時競爭 CPU 的運算單元』，而非透過作業系統的多工切換！
  • 大多發現 HT 雖然可以提昇效能，不過，有些情況下卻可能導致效能降低喔！因為，實際上明明就僅有一個運算單元
  • 個人電腦的主記憶體主要元件為動態隨機存取記憶體(Dynamic Random Access Memory, DRAM)， 隨機存取記憶體只有在通電時才能記錄與使用，斷電後資料就消失了。因此我們也稱這種RAM為揮發性記憶體。
  • 要啟用雙通道的功能你必須要安插兩支(或四支)主記憶體，這兩支記憶體最好連型號都一模一樣比較好， 這是因為啟動雙通道記憶體功能時，資料是同步寫入/讀出這一對主記憶體中，如此才能夠提升整體的頻寬啊！
  • 第二層快取(L2 cache)整合到CPU內部，因此這個L2記憶體的速度必須要CPU時脈相同。 使用DRAM是無法達到這個時脈速度的，此時就需要靜態隨機存取記憶體(Static Random Access Memory, SRAM)的幫忙了。
  • BIOS(Basic Input Output System)是一套程式，這套程式是寫死到主機板上面的一個記憶體晶片中， 這個記憶體晶片在沒有通電時也能夠將資料記錄下來，那就是唯讀記憶體(Read Only Memory, ROM)。
  • BIOS對於個人電腦來說是非常重要的， 因為他是系統在開機的時候首先會去讀取的一個小程式
  • 由於磁碟盤是圓的，並且透過機器手臂去讀寫資料，磁碟盤要轉動才能夠讓機器手臂讀寫。因此，通常資料寫入當然就是以圓圈轉圈的方式讀寫囉！ 所以，當初設計就是在類似磁碟盤同心圓上面切出一個一個的小區塊，這些小區塊整合成一個圓形，讓機器手臂上的讀寫頭去存取。 這個小區塊就是磁碟的最小物理儲存單位，稱之為磁區 (sector)，那同一個同心圓的磁區組合成的圓就是所謂的磁軌(track)。 由於磁碟裡面可能會有多個磁碟盤，因此在所有磁碟盤上面的同一個磁軌可以組合成所謂的磁柱 (cylinder)。
  • 原本硬碟的磁區都是設計成 512byte 的容量，但因為近期以來硬碟的容量越來越大，為了減少資料量的拆解，所以新的高容量硬碟已經有 4Kbyte 的磁區設計
  • 拿快閃記憶體去製作成高容量的設備，這些設備的連接界面也是透過 SATA 或 SAS，而且外型還做的跟傳統磁碟一樣
  • 固態硬碟最大的好處是，它沒有馬達不需要轉動，而是透過記憶體直接讀寫的特性，因此除了沒資料延遲且快速之外，還很省電
  • 硬碟主要是利用主軸馬達轉動磁碟盤來存取，因此轉速的快慢會影響到效能
  • 使用作業系統的正常關機方式，才能夠有比較好的硬碟保養啊！因為他會讓硬碟的機械手臂歸回原位啊！
  • I/O位址有點類似每個裝置的門牌號碼，每個裝置都有他自己的位址，一般來說，不能有兩個裝置使用同一個I/O位址， 否則系統就會不曉得該如何運作這兩個裝置了。
  • IRQ就可以想成是各個門牌連接到郵件中心(CPU)的專門路徑囉！ 各裝置可以透過IRQ中斷通道來告知CPU該裝置的工作情況，以方便CPU進行工作分配的任務。
  • BIOS為寫入到主機板上某一塊 flash 或 EEPROM 的程式，他可以在開機的時候執行，以載入CMOS當中的參數， 並嘗試呼叫儲存裝置中的開機程式，進一步進入作業系統當中。
  • 電腦都只有記錄0/1而已，甚至記錄的資料都是使用byte/bit等單位來記錄的
  • 常用的英文編碼表為ASCII系統，這個編碼系統中， 每個符號(英文、數字或符號等)都會佔用1bytes的記錄， 因此總共會有28=256種變化
  • 中文字當中的編碼系統早期最常用的就是big5這個編碼表了。 每個中文字會佔用2bytes，理論上最多可以有216=65536，亦即最多可達6萬多個中文字。
  • 國際組織ISO/IEC跳出來制訂了所謂的Unicode編碼系統， 我們常常稱呼的UTF8或萬國碼的編碼
  • CPU其實是具有微指令集的。因此，我們需要CPU幫忙工作時，就得要參考微指令集的內容， 然後撰寫讓CPU讀的懂的指令碼給CPU執行，這樣就能夠讓CPU運作了。
  • 編譯器』來將這些人類能夠寫的程式語言轉譯成為機器能看懂得機器碼
  • 當你需要將運作的資料寫入記憶體中，你就得要自行分配一個記憶體區塊出來讓自己的資料能夠填上去， 所以你還得要瞭解到記憶體的位址是如何定位的，啊！眼淚還是不知不覺的流了下來... 怎麼寫程式這麼麻煩啊！
  • 作業系統(Operating System, OS)其實也是一組程式， 這組程式的重點在於管理電腦的所有活動以及驅動系統中的所有硬體。
  • 作業系統的功能就是讓CPU可以開始判斷邏輯與運算數值、 讓主記憶體可以開始載入/讀出資料與程式碼、讓硬碟可以開始被存取、讓網路卡可以開始傳輸資料、 讓所有周邊可以開始運轉等等。
  • 只有核心有提供的功能，你的電腦系統才能幫你完成！舉例來說，你的核心並不支援TCP/IP的網路協定， 那麼無論你購買了什麼樣的網卡，這個核心都無法提供網路能力的！
  • 核心程式所放置到記憶體當中的區塊是受保護的！ 並且開機後就一直常駐在記憶體當中。
  • 作業系統通常會提供一整組的開發介面給工程師來開發軟體！ 工程師只要遵守該開發介面那就很容易開發軟體了！
  • 系統呼叫介面(System call interface)
  • 程序管理(Process control)
  • 記憶體管理(Memory management)
  • 檔案系統管理(Filesystem management)
  • 通常核心會提供虛擬記憶體的功能，當記憶體不足時可以提供記憶體置換(swap)的功能
  • 裝置的驅動(Device drivers)
  • 『可載入模組』功能，可以將驅動程式編輯成模組，就不需要重新的編譯核心
  • 驅動程式可以說是作業系統裡面相當重要的一環
  • 作業系統通常會提供一個開發介面給硬體開發商， 讓他們可以根據這個介面設計可以驅動他們硬體的『驅動程式』，如此一來，只要使用者安裝驅動程式後， 自然就可以在他們的作業系統上面驅動這塊顯示卡了。
  • 張 旭 on 22 Jun 21
     
    "但因為 CPU 的運算速度比其他的設備都要來的快，又為了要滿足 FSB 的頻率，因此廠商就在 CPU 內部再進行加速， 於是就有所謂的外頻與倍頻了。"
張 旭

跳出运维，才能做好运维（凤凰项目）书评 - 0 views

book.douban.com/9346219

devops system

shared by 張 旭 on 29 Dec 18 - No Cached
  • 1. 业务项目：这些通常是公司业务部门，比如产品研发部门或销售部门所提出的需求，比如新产品发布上线、为客户做实施、双十一这种大促活动的规划等等。这些工作通常具有一定的系统性，需要部门间通力合作。2. 内部项目：运维部门内部围绕业务项目所实施的一些列基础设施研发，部署自动化、多环境构建、持续交付、监控报警等等。3. 变更：根据其它部门申请，对运维组件进行变更操作，相对于业务项目，变更通常都会比较零散，比如加权限、开端口、开机器等等。对于变更，我们要维护好操作记录，做到有迹可寻。4. 计划外的工作：无法预料的问题处理，即“救火”。
  • 计划外的工作越多，就会占用其它三种工作的时间，导致其它三种工作大量积累。
  • 运维内部的基础建设跟不上，无法从根上去思考和解决计划外的工作，就会造成一种恶性循环，做不完的工作越堆越多（书中喜欢叫这玩意儿"半成品"）直至让人崩溃。
  • ...4 more annotations...
  • 一些周期性的工作对于运维其实也是非常重要的，比如对组件进行周期性的巡检、压测、像ChaosMonkey那样对分布式系统进行随机破坏、灾难演习、备份演习等等。不过这些也可以归结在内部项目之中
  • 流水线可视化了后，除了解决掉瓶颈节点，其它的诸如任务优先级、任务的依赖关系、每批次解决的任务数量，也都会显示出来并得到解决。
  • 反馈和朔源。我们需要知道每种任务流水线的每个环节的执行情况，效率、质量，然后与该环节相关的部门一起去探讨和优化改进的措施，比如部署时间过长，那么就要与开发团队一起优化打包流程和部署所依赖的中间件架构；线上故障太多，那么就需要联合开发和QA部门一道，去审视这些故障所爆发的源头，定制解决方案，等等
  • 第三步，就需要建立一种文化机制，努力把这种工作方式延续下去，做到持续改进，越来越好！
張 旭

从《凤凰项目》谈一谈"业务IT一体化" - 知乎 - 0 views

zhuanlan.zhihu.com/27662792

devops system

shared by 張 旭 on 29 Dec 18 - No Cached
  • IT能多大程度上参与到业务系统中去帮助到业务部门，甚至影响到业务部门，你的价值就有多大。这项工作列为紧急并且重要
  • “IT内部的项目”，有一些IT部门很热衷做这方面的项目，在我看来部分的原因是因为做这些东西相对来说是IT比较好玩或者擅长的。
  • 重要但不紧急的工作，例如认真地研究和建立devops的基础环境。
  • ...11 more annotations...
  • 但变更虽然不可避免，我个人觉得应该尽可能减少（至少做到可预测），并且将变更流程自动化。
  • 最容易被人忽视的是“计划外工作”，它偷走了我们的时间。这就等于我们经常在讲的那些紧急但不重要，或者那些不紧急也不重要的事情。
  • 约束管理（ Theory Of Constrain ）理论
  • 他太厉害，所以不屑于写文档；他太重要，所以可以随心所欲地改东西而不走流程；他太忙，所以很多事情都要排队等他的时间来做。
  • 需要布伦特这样的人才，只是说布伦特成为了团队的约束点，怎么利用好他成为工作成败的关键（建立一些好的机制，确保他们能够更好地工作，而不是在一些低价值的内容上），而怎么帮助他提高到一个新的水平（或者培养更多的布伦特）才是长治久安的方法。
  • “业务IT一体化”与传统的模式有一个根本的区别，就是大量地使用了自动化的技术，减少中间环节。
  • IT部门内部开发、测试、运维、安全等环节的信任
  • 第一步，从产品构想、设计、开发、测试、运维到客户，这个正向的工作流，一定要理顺
  • 第二步，从客户往回推，如何建立一个健康和高效的反馈流。这里我总结为快速试错和迭代
  • 第三步，我觉得是讲到点子上了—— 业务IT一体化当然是好啊，但流程再合理，工具再强大，领导再重视，如果没有一个所有员工都认同的企业文化来做支撑，都将流于形式。没有信任来谈创新，终究是扯淡。
  • 各部门只关注自己的小目标，以自己干了多少事为荣，而不管这些事到底对于整个公司的目标实现意味着什么。
張 旭

第 05 章 - 計算機概論 - 主機系統與 I/O 界面 - 0 views

dic.vbird.tw/...2020unit05.php

shared by 張 旭 on 21 Jun 21 - No Cached
  • 接受使用者輸入指令與資料，經由中央處理器的數學與邏輯單元運算處理後，以產生或儲存成有用的資訊
  • CPU 為一個具有特定功能的晶片， 裡頭含有微指令集，如果你想要讓主機進行什麼特異的功能，就得要參考這顆 CPU 是否有相關內建的微指令集才可以。
  • CPU 讀取的資料都是從主記憶體來的！ 主記憶體內的資料則是從輸入單元所傳輸進來！而 CPU 處理完畢的資料也必須要先寫回主記憶體中，最後資料才從主記憶體傳輸到輸出單元。
  • ...49 more annotations...
  • 算數邏輯單元與控制單元。其中算數邏輯單元主要負責程式運算與邏輯判斷，控制單元則主要在協調各周邊元件與各單元間的工作。
  • 資料會先寫入到主記憶體，然後 CPU 才能開始應用
  • CPU 其實內部已經含有一些微指令，我們所使用的軟體都要經過 CPU 內部的微指令集來達成才行。
  • 世界上常見到的兩種主要 CPU 架構， 分別是：精簡指令集 (RISC) 與複雜指令集 (CISC) 系統。
  • 微指令集較為精簡，每個指令的執行時間都很短，完成的動作也很單純，指令的執行效能較佳； 但是若要做複雜的事情，就要由多個指令來完成。
  • CISC在微指令集的每個小指令可以執行一些較低階的硬體操作，指令數目多而且複雜， 每條指令的長度並不相同。因為指令執行較為複雜所以每條指令花費的時間較長， 但每條個別指令可以處理的工作較為豐富。
  • 最早的那顆Intel發展出來的CPU代號稱為8086
  • AMD依此架構修改新一代的CPU為64位元
  • CPU 位元指的是CPU一次資料讀取的最大量！64位元CPU代表CPU一次可以讀寫64bits這麼多的資料
  • 因為CPU讀取資料量有限制，因此能夠從記憶體中讀寫的資料也就有所限制
  • ：(1)北橋：負責連結速度較快的CPU、主記憶體與顯示卡界面等元件；
  • (2)南橋：負責連接速度較慢的裝置介面， 包括硬碟、USB、網路卡等等。不過由於北橋最重要的就是 CPU 與主記憶體之間的橋接，因此目前的主流架構中， 大多將北橋記憶體控制器整合到 CPU 封裝當中
  • CPU 與可接受的晶片組是有搭配性的，尤其目前每種 CPU 的腳位都不一樣
  • 時脈越高，代表單位時間內可進行的工作越多
  • 大概都只看總頻寬或基準時脈
  • CPU 時脈越高的情況下，會產生很多諸如散熱、設計及與週邊元件溝通的問題。
  • 其他的程序還在等待 CPU ，但是 CPU 又在等待 I/O
  • Intel 在同一個運算核心底下安裝兩個暫存器來模擬出另一個核心，實際上是兩個暫存器 (可以想成是程式的執行器) 共用一個實體核心。 這就是超執行緒的簡易認知
  • 時脈的意思是每秒鐘能夠進行的工作次數，而每次工作能夠讀進的資料量就是位元數
  • 每個用戶端大多是短時間的大運算，所以通常不會有一隻程序一直佔用著系統資源。
  • CPU 的所有資料都是從記憶體讀寫來的，所以記憶體的容量與頻寬就相當的重要了
  • DRAM 根據技術的更新又分好幾代，而使用上較廣泛的有所謂的 SDRAM 與 DDR SDRAM 兩種。 這兩種記憶體的差別除了在於腳位與工作電壓上的不同之外，DDR 是所謂的雙倍資料傳送速度 (Double Data Rate)
  • 晶片組廠商就將兩個主記憶體彙整在一起，如果一支記憶體可達 64 位元，兩支記憶體就可以達到 128 位元了，這就是雙通道的設計理念。 在某些比較多核心的伺服器主機上面，甚至還使用了 3 通道到 4 通道的設計
  • CPU 內部的暫存器與少量記憶體被稱為第一、第二層快取 (L1, L2 cache)，而放在核心間的快取記憶體就被稱為第三層快取記憶體 (L3 cache)
  • CPU 的暫存器是直接設計在 CPU 核心內部，可以用來幫助 CPU 的運算。
  • 在多核心 CPU 的核心之間，會有另一個共享的快取記憶體存在，讓所有的 CPU 核心可以共享某些資源。
  • 靜態隨機存取記憶體 (Static Random Access Memory, SRAM)
  • 各項參數， 是被記錄到主機板上頭的一個稱為 CMOS 的晶片上，這個晶片需要藉著額外的電源來發揮記錄功能， 這也是為什麼你的主機板上面會有一顆電池的緣故。
  • BIOS(Basic Input Output System)是一套程式，這套程式是寫死到主機板上面的一個記憶體晶片中， 這個記憶體晶片在沒有通電時也能夠將資料記錄下來，那就是唯讀記憶體(Read Only Memory, ROM)。
  • BIOS對於個人電腦來說是非常重要的， 因為他是系統在開機的時候首先會去讀取的一個小程式喔
  • 韌體(firmware)很多也是使用ROM來進行軟體的寫入的。 韌體像軟體一樣也是一個被電腦所執行的程式，然而他是對於硬體內部而言更加重要的部分。例如BIOS就是一個韌體， BIOS雖然對於我們日常操作電腦系統沒有什麼太大的關係，但是他卻控制著開機時各項硬體參數的取得！
  • 現在的 BIOS 通常是寫入類似快閃記憶體 (flash) 或 EEPROM
  • 顯示卡能夠傳輸的資料量當然也是越大越好！這時就得要考慮到傳輸的界面了！當前 (2018) 主流的傳輸界面為 PCI-E，這個 PCI-E 又有三種版本， version 1, 2, 3 ，這三個版本的速度並不相同
  • PCI-E (PCI-Express) 使用的是類似管線的概念來處理，在 PCI-E 第一版中，每條管線可以具有 250MBytes/s 的頻寬效能，管線越多(通常設計到 x16 管線)則總頻寬越高
  • 通常 CPU 製造商會根據 CPU 來設計搭配的南橋晶片，由於現在只有一個晶片 (北橋整合到 CPU 內了)，所以目前只有一顆主機板晶片組。
  • 插槽上面的資料要傳輸到 CPU 就得要經過晶片組，然後透過 DMI 通道傳上去！所以，在某些情況下，系統的效能會被卡住在這條通道上喔！
  • 晶片組接的設備相當多喔！有 PCI-E 插槽、USB設備、網路設備、音效設備、硬碟設備等，這全部的裝置共用那一條 DMI 喔！ 所以，整個系統效能的瓶頸通常不在 CPU 啦！通常就是在南橋接的設備上面！所以，當你有非常複雜的程式要運作的時候，讓這些程式越少通過南橋， 他的系統效能就會比較好一點
  • 物理組成
  • 讀寫主要是透過在機械手臂上的讀取頭(head)來達成
  • 由於磁碟盤是圓的，並且透過機器手臂去讀寫資料，磁碟盤要轉動才能夠讓機器手臂讀寫。
  • 磁碟的最小物理儲存單位，稱之為磁區 (sector)，那同一個同心圓的磁區組合成的圓就是所謂的磁軌(track)。 由於磁碟裡面可能會有多個磁碟盤，因此在所有磁碟盤上面的同一個磁軌可以組合成所謂的磁柱 (cylinder)。
  • 通常資料的讀寫會由外圈開始往內寫
  • 目前主流的硬碟連接界面就是 SATA
  • 雖然 SATA III 界面理論傳輸可到達 600Mbytes/s，不過傳統硬碟由於物理設計的限制因素，通常存取速度效能大多在 150~200Mbytes/s 之間
  • 串列式 SCSI (Serial Attached SCSI, SAS)
  • 傳統硬碟有個很致命的問題，就是需要驅動馬達去轉動磁碟盤～這會造成很嚴重的磁碟讀取延遲
  • 快閃記憶體去製作成高容量的設備
  • 沒有讀寫頭與磁碟盤啊！都是記憶體！
  • 各個繪圖卡的運算晶片 (GPU) 設計的理念不同，加上驅動程式與軟體搭配的問題，並不是一張高效能繪圖卡就可以完勝其他的繪圖卡， 還得要注意相關的軟體才行。
張 旭

今天拜飛機了沒？ - 談敏捷開發中的貨物崇拜 - 敏捷進化趣 Agile FunEvo - 0 views

funevo.com/...-cult-agile-min-jie-bai-fei-ji

project

shared by 張 旭 on 08 Nov 18 - No Cached
  • 張 旭 on 08 Nov 18
     
    "沒有溝通（產品的）願景和策略 產品藍圖和發佈日期在一年前就由CTO規劃好了 組織內沒有人跟顧客對談 CTO和利害關係人堅持所有的改動都要經由他們批准 因為保密資安等理由，禁止使用實體的看板或告示 利害關係人直接跟CTO對談，跳過Product Owner 由利害關係人來決定交付產品增量，而不是Product Owner 專案/產品只有在完成時才交付，而不是增量式的交付 避免利害關係人直接跟開發團隊對談 Product Backlog是由一個產品委員會決定的 就算對功能的價值有所懷疑，但還是硬上了（為了年終獎金…） 業務為了成交，答應客戶增加目前不存在的功能，而Product Owner不知情 就算是不重要的問題，也有固定的進度表和期限 負責產品管理的角色沒有取得商業智能（BI）資訊的權限，沒有充足的資訊和數據幫助決定 利害關係人使用需求文件來和產品與工程部門溝通 Product Owner大部分的時間都在撰寫和管理使用者故事（User Stories） 在Sprint開始後不久Sprint Backlog就變了 專門成立一個開發團隊來修Bugs和處理小的需求 利害關係人沒有參加過Scrum活動（例如Sprint Planning和Sprint Review） 主要是用『速率（Velocity）符合當初的承諾』來當指標評估Scrum是否成功 開發人員沒有參與創造使用者故事 同時處理的專案數量和工作會改變開發團隊的人數跟組成方式 在Daily Stand up中團隊成員對ScrumMaster報告 定期舉行自省會議（Retrospectives），但沒有改變隨之發生 開發團隊並不是跨功能（Cross Functional），而要靠其他團隊或部門才能完成工作"
張 旭

鳥哥的 Linux 私房菜 -- 第二章、主機規劃與磁碟分割 - 0 views

linux.vbird.org/...0130designlinux.php

linux system

shared by 張 旭 on 23 Jun 21 - Cached
  • BIOS會依據使用者的設定去取得能夠開機的硬碟， 並且到該硬碟裡面去讀取第一個磁區的MBR位置。 MBR這個僅有446 bytes的硬碟容量裡面會放置最基本的開機管理程式， 此時BIOS就功成圓滿，而接下來就是MBR內的開機管理程式的工作了。
  • 開機管理程式的目的是在載入(load)核心檔案， 由於開機管理程式是作業系統在安裝的時候所提供的，所以他會認識硬碟內的檔案系統格式，因此就能夠讀取核心檔案， 然後接下來就是核心檔案的工作，開機管理程式與 BIOS 也功成圓滿
  • 開機管理程式除了可以安裝在MBR之外， 還可以安裝在每個分割槽的開機磁區(boot sector)
  • 張 旭 on 23 Jun 21
     
    "BIOS會依據使用者的設定去取得能夠開機的硬碟， 並且到該硬碟裡面去讀取第一個磁區的MBR位置。 MBR這個僅有446 bytes的硬碟容量裡面會放置最基本的開機管理程式， 此時BIOS就功成圓滿，而接下來就是MBR內的開機管理程式的工作了。"
張 旭

20 年軟體工程生涯所學到的 20 件事 (摘譯) - Ant ATField - 0 views

blog.gcos.me/...0-years-as-a-software-engineer

architecture programming

shared by 張 旭 on 04 Jun 22 - No Cached
  • 你永遠無法償還所有的技術債、你永遠無法設計出完美的界面、你的測試總是太慢。
  • 這不是一個不把事情做得更好的藉口，而是給你一個視角，不要擔心優雅和完美
  • 有新團隊成員要加入？注意他們在哪裡感到困惑，以及他們問了什麼問題。
  • ...14 more annotations...
  • 軟體是達到目標的手段，而不是目標本身。目標是定向的，但手段要可隨時變通。
  • 不需要維護的程式
  • 10 倍工程師是愚蠢神話。有人能在 1 天內完成另一個有能力、努力工作、有類似經驗的工程師在 2 週內完成的工作，這種想法很愚蠢。
  • 。一個人能夠成為 10 倍工程師的唯一方法，是你把他們和 0.1x 的工程師相比。
  • between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be
  • 沒有什麼比一個對自己的工具或如何建構軟體沒有意見的資深工程師更讓我擔心了。
  • 如果你正在使用你的工具，而你對它們不愛也不恨，那麼你需要去體驗更多。
  • 你的資料可能會比你的程式長壽。花點精力保持秩序和乾淨
  • 存活下來的老技術是鯊魚，不是恐龍。
  • 軟體工程師應該定期撰寫部落格、日記、文件，總之做任何需要他們保持書面溝通能力之事。
  • 如果你把一個人從他們的工作成果中抽離，他們就會對他們的工作不那麼關心。這也是跨職能團隊運作良好的主要原因，也是 DevOps 變得如此流行的原因。從頭到尾擁有整個過程，並直接負責交付價值。讓一群充滿熱情的人對設計、建構和交付一個軟體 (或任何東西) 擁有完全的自主，這終將發生令人驚奇之事。
  • 面試最好是用來瞭解某人是誰，以及他們對某一專業領域的興趣如何。嘗試找出他們會成為多好的團隊成員是一個沒有結果的努力。
  • 你在建構一個系統的過程中會學到很多東西，你最終會迭代成一個比你當初設計的更好的系統。
  • stop sharpening the saw, and just start cutting shit
張 旭

GitLab Auto DevOps 深入淺出，自動部署，連設定檔不用？！ | 五倍紅寶石・專業程式教育 - 0 views

5xruby.tw/...gitlab-auto-devops

devops gitlab auto

shared by 張 旭 on 15 Apr 21 - No Cached
  • 一個 K8S 的 Cluster，Auto DevOps 將會把網站部署到這個 Cluster
  • 需要有一個 wildcard 的 DNS 讓部署在這個環境的網站有 Domain name
  • 一個可以跑 Docker 的 GitLab Runner，將會為由它來執行 CI / CD 的流程。
  • ...37 more annotations...
  • 其實 Auto DevOps 就是一份官方寫好的 gitlab-ci.yml，在啟動 Auto DevOps 的專案裡，如果找不到 gitlab-ci.yml 檔，那就會直接用官方 gitlab-ci.yml 去跑 CI / CD 流程。
  • Pod 是 K8S 中可以被部署的最小元件，一個 Pod 是由一到多個 Container 組成，同個 Pod 的不同 Container 之間彼此共享網路資源。
  • 每個 Pod 都會有它的 yaml 檔，用以描述 Pod 會使用的 Image 還有連接的 Port 等資訊。
  • Node 又分成 Worker Node 和 Master Node 兩種
  • Helm 透過參數 (parameter) 跟模板 (template) 的方式，讓我們可以在只修改參數的方式重複利用模板。
  • 為了要有 CI CD 的功能我們會把 .gitlab-ci.yml 放在專案的根目錄裡， GitLab 會依造 .gitlab-ci.yml 的設定產生 CI/CD Pipeline，每個 Pipeline 裡面可能有多個 Job，這時候就會需要有 GitLab Runner 來執行這些 Job 並把執行的結果回傳給 GitLab 讓它知道這個 Job 是否有正常執行。
  • 把專案打包成 Docker Image 這工作又或是 helm 的操作都會在 Container 內執行
  • CI/CD Pipeline 是由 stage 還有 job 組成的，stage 是有順序性的，前面的 stage 完成後才會開始下一個 stage。
  • 每個 stage 裡面包含一到多個 Job
  • Auto Devops 裡也會大量用到這種在指定 Container 內運行的工作。
  • 可以通過 health checks
  • 開 private 的話還要注意使用 Container Registry 的權限問題
  • 申請好的 wildcard 的 DNS
  • Auto Devops 也提供只要設定環境變數就能一定程度客製化的選項
  • 特別注意 namespace 有沒有設定對，不然會找不到資料喔
  • Auto Devops，如果想要進一步的客製化，而且是改 GitLab 環境變數都無法實現的客製化，這時候還是得回到 .gitlab-ci.yml 設定檔
  • 在 Docker in Docker 的環境用 Dockerfile 打包 Image
  • 用 helm upgrade 把 chart 部署到 K8S 上
  • GitLab CI 的環境變數主要有三個來源，優先度高到低依序為Settings > CI/CD 介面定義的變數gitlab_ci.yml 定義環境變數GitLab 預設環境變數
  • 把專案打包成 Docker Image 首先需要在專案下新增一份 Dockerfile
  • Auto Devops 裡面的做法，用 herokuish 提供的 Image 來打包專案
  • 在 Runner 的環境中是沒有 docker 指令可以用的，所以這邊啟動一個 Docker Container 在裡面執行就可以用 docker 指令了。
  • 其中 $CI_COMMIT_SHA $CI_COMMIT_BEFORE_SHA 這兩個都是 GitLab 預設環境變數，代表這次 commit 還有上次 commit 的 SHA 值。
  • dind 則是直接啟動 docker daemon，此外 dind 還會自動產生 TLS certificates
  • 為了在 Docker Container 內運行 Docker，會把 Host 上面的 Docker API 分享給 Container。
  • docker:stable 有執行 docker 需要的執行檔，他裡面也包含要啟動 docker 的程式(docker daemon)，但啟動 Container 的 entrypoint 是 sh
  • docker:dind 繼承自 docker:stable，而且它 entrypoint 就是啟動 docker 的腳本，此外還會做完 TLS certificates
  • Container 要去連 Host 上的 Docker API 。但現在連線失敗卻是找 http://docker:2375，現在的 dind 已經不是被當做 services 來用了，而是要直接在裡面跑 Docker，所以他應該是要 unix:///var/run/docker.sock 用這種連線，於是把環境變數 DOCKER_HOST 從 tcp://docker:2375 改成空字串，讓 docker daemon 走預設連線就能成功囉！
  • auto-deploy preparationhelm init 建立 helm 專案設定 tiller 在背景執行設定 cluster 的 namespace
  • auto-deploy deploy使用 helm upgrade 部署 chart 到 K8S 上透過 --set 來設定要注入 template 的參數
  • set -x，這樣就能在執行前，顯示指令內容。
  • 用 helm repo list 看看現在有註冊哪些 Chart Repository
  • helm fetch gitlab/auto-deploy-app --untar
  • nohup 可以讓你在離線或登出系統後，還能夠讓工作繼續進行
  • 在不特別設定 CI_APPLICATION_REPOSITORY 的情況下，image_repository 的值就是預設環境變數 CI_REGISTRY_IMAGE/CI_COMMIT_REF_SLUG
  • A:-B 的意思是如果有 A 就用它，沒有就用 B
  • 研究 Auto Devops 難度最高的地方就是太多工具整合在一起，搞不清楚他們之間的關係，出錯也不知道從何查起
crazylion lee

10大螢幕錄影軟體推薦比較！搞定電腦手機錄影教學 - 電腦玩物 - 0 views

www.playpcesor.com/...-android-screen-recording.html

錄影 screencapture

shared by crazylion lee on 27 Feb 16 - No Cached
  • crazylion lee on 27 Feb 16
     
    "最近我在電腦玩物上開始嘗試錄製「我的教學影片」，輔助對一款軟體或工作方法的說明，尤其有些圖文解釋不清楚，或者圖文需要長篇大論之處，用一段教學影片更加簡潔明白。"
張 旭

MySQL 到底能不能放到 Docker 里跑？ - 0 views

mp.weixin.qq.com/s

mysql server docker

shared by 張 旭 on 07 Aug 17 - No Cached
  • 忙碌又容易出错的工作其实是无意义的
  • 单机多实例运行 MySQL
  • MySQL 运行的就是个进程而且对 IO 要求比较高
  • ...12 more annotations...
  • Docker 的资源限制用的就是 cgroups
  • Percona：我们的备份、慢日志分析、过载保护等功能都是基于 pt-tools 工具包来实现的。
  • Consul：分布式的服务发现和配置共享软件
  • 容器调度的开源产品主要有 Kubernetes 和 mesos
  • 适合自己现状的需求才是最好的
  • 有机会做到计算调度和存储调度分离的情况下我们可能会转向 Kubernetes 的方案
  • 根据这个需求按照我们的资源筛选规则 (比如主从不能在同一台机器、内存配置不允许超卖等等)，从现有的资源池中匹配出可用资源，然后依次创建主从关系、创建高可用管理、检查集群复制状态、推送集群信息到中间件 (选用了中间件的情况下) 控制中心、最后将以上相关信息都同步到 CMDB。
    • 張 旭
      張 旭 on 07 Aug 17
       
      感覺用 K8S 就不用那麼麻煩了。
  • 每一个工作都是通过服务端发送消息到 agent，然后由 agent 执行对应的脚本，脚本会返回指定格式的执行结果
  • 备份工具我们是用 percona-xtrabackup
  • zabbix 来实现监控告警
  • grafana 是监控画图界的扛把子，功能齐全的度量仪表盘和图形编辑器，经过简单配置就能完成各种监控图形的展示。
  • (MariaDB 不支持写 table，只能写 file)，极大减少了从库复制带来的 IOPS。
張 旭

[Elasticsearch] 分散式特性 & 分散式搜尋的機制 | 小信豬的原始部落 - 0 views

godleon.github.io/...icsearch-distributed-mechanism

elasticsearch database

shared by 張 旭 on 17 Apr 21 - No Cached
  • 水平擴展儲存空間
  • Data HA：若有 node 掛掉，資料不會遺失
  • 若是要查詢 cluster 中的 node 狀態，可以使用 GET /_cat/nodes API
  • ...39 more annotations...
  • 決定每個 shard 要被分配到哪個 data node 上
  • 為 cluster 設置多個 master node
  • 一旦發現被選中的 master node 出現問題，就會選出新的 master node
  • 每個 node 啟動時就預設是一個 master eligible node，可以透過設定 node.master: false 取消此預設設定
  • 處理 request 的 node 稱為 Coordinating Node，其功能是將 request 轉發到合適的 node 上
  • 所有的 node 都預設是 Coordinating Node
  • coordinating node 可以直接接收 search request 並處理，不需要透過 master node 轉過來
  • 可以保存資料的 node，每個 node 啟動後都會預設是 data node，可以透過設定 node.data: false 停用 data node 功能
  • 由 master node 決定如何把分片分發到不同的 data node 上
  • 每個 node 上都保存了 cluster state
  • 只有 master 才可以修改 cluster state 並負責同步給其他 node
  • 每個 node 都會詳細紀錄本身的狀態資訊
  • shard 是 Elasticsearch 分散式儲存的基礎，包含 primary shard & replica shard
  • 每一個 shard 就是一個 Lucene instance
  • primary shard 功能是將一份被索引後的資料，分散到多個 data node 上存放，實現儲存方面的水平擴展
  • primary shard 的數量在建立 index 時就會指定，後續是無法修改的，若要修改就必須要進行 reindex
  • 當 primary shard 遺失時，replica shard 就可以被 promote 成 primary shard 來保持資料完整性
  • replica shard 數量可以動態調整，讓每個 data node 上都有完整的資料
  • ES 7.0 開始，primary shard 預設為 1，replica shard 預設為 0
  • replica shard 若設定過多，會降低 cluster 整體的寫入效能
  • replica shard 必須和 primary shard 被分配在不同的 data node 上
  • 所有的 primary shard 可以在同一個 data node 上
  • 透過 GET _cluster/health/<target> 可以取得目前 cluster 的健康狀態
  • Yellow：表示 primary shard 可以正常分配，但 replica shard 分配有問題
  • 透過 GET /_cat/shards/<target> 可以取得目前的 shard 狀態
  • replica shard 無法被分配，因此 cluster 健康狀態為黃色
  • 若是擔心 reboot 機器造成 failover 動作開始執行，可以設定將 replication 延遲一段時間後再執行(透過調整 settings 中的 index.unassigned.node_left.delayed_timeout 參數)，避免無謂的 data copy 動作 (此功能稱為 delay allocation)
  • 集群變紅，代表有 primary shard 丟失，這個時候會影響讀寫。
  • 如果 node 重新回來，會從 translog 中恢復沒有寫入的資料
  • 設定 index settings 之後，primary shard 數量無法隨意變更
  • 不建議直接發送請求到master節點，雖然也會工作，但是大量請求發送到 master，會有潛在的性能問題
  • shard 是 ES 中最小的工作單元
  • shard 是一個 Lucene 的 index
  • 將 Index Buffer 中的內容寫入 Segment，而這寫入的過程就稱為 Refresh
  • 當 document 被 refresh 進入到 segment 之後，就可以被搜尋到了
  • 在進行 refresh 時先將 segment 寫入 cache 以開放查詢
  • 將 document 進行索引時，同時也會寫入 transaction log，且預設都會寫入磁碟中
  • 每個 shard 都會有對應的 transaction log
  • 由於 transaction log 都會寫入磁碟中，因此當 node 從故障中恢復時，就會優先讀取 transaction log 來恢復資料
張 旭

鳥哥的 Linux 私房菜 -- 第一章、Linux是什麼與如何學習 - 0 views

linux.vbird.org/...0110whatislinux.php

system linux

shared by 張 旭 on 22 Jun 21 - Cached
  • Linux就是核心與系統呼叫介面那兩層
  • 核心與硬體的關係非常的強烈
  • Linux提供了一個完整的作業系統當中最底層的硬體控制與資源管理的完整架構， 這個架構是沿襲Unix良好的傳統來的，所以相當的穩定而功能強大
  • ...31 more annotations...
  • Linux的核心是由Linus Torvalds在1991年的時候給他開發出來的， 並且丟到網路上提供大家下載，後來大家覺得這個小東西(Linux Kernel)相當的小而精巧， 所以慢慢的就有相當多的朋友投入這個小東西的研究領域裡面去
  • 1960年代初期麻省理工學院(MIT)發展了所謂的： 『相容分時系統(Compatible Time-Sharing System, CTSS)』， 它可以讓大型主機透過提供數個終端機(terminal)以連線進入主機，來利用主機的資源進行運算工作
  • 為了更加強化大型主機的功能，以讓主機的資源可以提供更多使用者來利用，所以在1965年前後， 由貝爾實驗室(Bell)、麻省理工學院(MIT)及奇異公司(GE, 或稱為通用電器)共同發起了Multics的計畫
  • 以組合語言(Assembler)寫出了一組核心程式，同時包括一些核心工具程式， 以及一個小小的檔案系統。那個系統就是Unix的原型！ 當時Thompson將Multics龐大的複雜系統簡化了不少，於是同實驗室的朋友都戲稱這個系統為：Unics。(當時尚未有Unix的名稱)
  • 所有的程式或系統裝置都是檔案
  • 不管建構編輯器還是附屬檔案，所寫的程式只有一個目的，且要有效的完成目標。
  • Dennis Ritchie (註3) 將B語言重新改寫成C語言，再以C語言重新改寫與編譯Unics的核心， 最後正名與發行出Unix的正式版本！
  • 由於Unix是以較高階的C語言寫的，相對於組合語言需要與硬體有密切的配合， 高階的C語言與硬體的相關性就沒有這麼大了！所以，這個改變也使得Unix很容易被移植到不同的機器上面喔！
  • AT&T此時對於Unix是採取較開放的態度，此外，Unix是以高階的C語言寫成的， 理論上是具有可移植性的！亦即只要取得Unix的原始碼，並且針對大型主機的特性加以修訂原有的原始碼(Source Code)， 就可能將Unix移植到另一部不同的主機上頭了。
  • 柏克萊大學的Bill Joy (註4)在取得了Unix的核心原始碼後，著手修改成適合自己機器的版本， 並且同時增加了很多工具軟體與編譯程式，最終將它命名為Berkeley Software Distribution (BSD)。
  • 每一家公司自己出的Unix雖然在架構上面大同小異，但是卻真的僅能支援自身的硬體， 所以囉，早先的Unix只能與伺服器(Server)或者是大型工作站(Workstation)劃上等號！
  • AT&T在1979年發行的第七版Unix中，特別提到了 『不可對學生提供原始碼』的嚴格限制！
  • 純種的Unix指的就是System V以及BSD
  • AT&T自家的System V
  • 既然1979年的Unix第七版可以在Intel的x86架構上面進行移植， 那麼是否意味著可以將Unix改寫並移植到x86上面了呢？在這個想法上， 譚寧邦教授於是乎自己動手寫了Minix這個Unix Like的核心程式！
  • 『既然作業系統太複雜，我就先寫可以在Unix上面運行的小程式，這總可以了吧？』
  • 如果能夠寫出一個不錯的編譯器，那不就是大家都需要的軟體了嗎？ 因此他便開始撰寫C語言的編譯器，那就是現在相當有名的GNU C Compiler(gcc)！
  • 他還撰寫了更多可以被呼叫的C函式庫(GNU C library)，以及可以被使用來操作作業系統的基本介面BASH shell！ 這些都在1990年左右完成了！
  • 有鑑於圖形使用者介面(Graphical User Interface, GUI) 的需求日益加重，在1984年由MIT與其他協力廠商首次發表了X Window System ，並且更在1988年成立了非營利性質的XFree86這個組織。所謂的XFree86其實是 X Window System + Free + x86的整合名稱呢！
  • 譚寧邦教授為了教育需要而撰寫的Minix系統！ 他在購買了最新的Intel 386的個人電腦後，就立即安裝了Minix這個作業系統。 另外，上個小節當中也談到，Minix這個作業系統是有附上原始碼的， 所以托瓦茲也經由這個原始碼學習到了很多的核心程式設計的設計概念喔！
  • 托瓦茲自己也說：『我始終是個性能癖』^_^。 為了徹底發揮386的效能，於是托瓦茲花了不少時間在測試386機器上！ 他的重要測試就是在測試386的多功性能。首先，他寫了三個小程式，一個程式會持續輸出A、一個會持續輸出B， 最後一個會將兩個程式進行切換。他將三個程式同時執行，結果，他看到螢幕上很順利的一直出現ABABAB...... 他知道，他成功了！ ^_^
  • 為了讓所有的軟體都可以在Linux上執行，於是托瓦茲開始參考標準的POSIX規範。
  • POSIX是可攜式作業系統介面(Portable Operating System Interface)的縮寫，重點在規範核心與應用程式之間的介面， 這是由美國電器與電子工程師學會(IEEE)所發佈的一項標準喔
  • 因為托瓦茲放置核心的那個FTP網站的目錄為：Linux， 從此，大家便稱這個核心為Linux了。(請注意，此時的Linux就是那個kernel喔！ 另外，托瓦茲所丟到該目錄下的第一個核心版本為0.02呢！)
  • Linux其實就是一個作業系統最底層的核心及其提供的核心工具。 他是GNU GPL授權模式，所以，任何人均可取得原始碼與可執行這個核心程式，並且可以修改。
  • Linux參考POSIX設計規範，於是相容於Unix作業系統，故亦可稱之為Unix Like的一種
  • 為了讓使用者能夠接觸到Linux，於是很多的商業公司或非營利團體， 就將Linux Kernel(含tools)與可運行的軟體整合起來，加上自己具有創意的工具程式， 這個工具程式可以讓使用者以光碟/DVD或者透過網路直接安裝/管理Linux系統。 這個『Kernel + Softwares + Tools + 可完整安裝程序』的咚咚，我們稱之為Linux distribution， 一般中文翻譯成可完整安裝套件，或者Linux發佈商套件等。
  • 在1994年終於完成的Linux的核心正式版！version 1.0。 這一版同時還加入了X Window System的支援呢！且於1996年完成了2.0版、2011 年釋出 3.0 版，更於 2015 年 4 月釋出了 4.0 版哩！ 發展相當迅速喔！此外，托瓦茲指明了企鵝為Linux的吉祥物。
  • Linux本身就是個最陽春的作業系統，其開發網站設立在http://www.kernel.org，我們亦稱Linux作業系統最底層的資料為『核心(Kernel)』。
  • 常見的 Linux distributions 分類有『商業、社群』分類法，或『RPM、DPKG』分類法
  • 事實上鳥哥認為distributions主要分為兩大系統，一種是使用RPM方式安裝軟體的系統，包括Red Hat, Fedora, SuSE等都是這類； 一種則是使用Debian的dpkg方式安裝軟體的系統，包括Debian, Ubuntu, B2D等等。
張 旭

Larry Cai - Travis CI会替代Jenkins吗？ - 0 views

www.larrycaiyu.com/...travis-ci-is-evolution.html

travis jenkins system CI test

shared by 張 旭 on 06 Sep 16 - No Cached
  • Jenkins能够让通过主从模式（master/slave）多台机器一起构建。
  • 一切都可以在Web界面中运行。
  • 当然你可有使用虚拟机的技术vagrant/virtualbox，参见使用vagrant+jenkins来管理虚拟机的技巧。可以工作，不太优雅。因为它不是原生的，有点复杂。
    • 張 旭
      張 旭 on 06 Sep 16
       
      現在應該有 Docker Container 跑測試的整合了。
  • ...5 more annotations...
  • 在CI服务器创建任务（记住：这些配置文件不是有版本控制的）
  • 构建的配置文件直接就和源码放在一起，而且配置文件使用DSL写的，可读性更高。
  • 要求在两个Ruby环境中运行，它就帮我做到了，我并不关心它是怎么切换的
  • Travis CI使用的Ruby语言，一开始考虑的就是分布式构建
  • 它的虚拟机部分只是Vagrant/Virtualbox，但是这一块是很容易迁移到其他的技术的。
    • 張 旭
      張 旭 on 06 Sep 16
       
      Docker! Docker! Docker!
張 旭

How to Report Bugs Effectively - 0 views

www.chiark.greenend.org.uk/...bugs-tw.html

bug debug

shared by 張 旭 on 04 Dec 14 - Cached
  • 有個理由可以解釋為什麼技術支援工作這麼難做, 原因就是這些亂七八糟的錯誤報告
  • 希望全世界的人在報告任何錯誤前都能讀讀這篇短文
  • 錯誤報告的目的是要讓程式師能親眼目睹程式出錯
  • ...26 more annotations...
  • 如果他們無法重現問題, 就只能要你幫他們收集資訊
  • 必須要把真實發生的事實(我在電腦前看到這個狀況)和臆測(我認為問題可能是)很明顯的區分開來. 必要時可以把臆測略過不提, 不過事實絕對不能漏.
  • 資訊過多往往好過資訊不足
  • 報告錯誤的最佳方法之一就是直接示範給程式師看. 讓他們站到你的電腦前面, 執行他們的軟體, 然後指出問題所在
  • 可能會要你說明整個操作過程, 以便他們能自己重複重現問題
  • 也可能會改變操作過程多試幾次, 看看問題只在某一種狀況發生, 還是在相關的多種狀況下都有出現
  • 可能得坐下來花上幾個小時拿出整組開發工具真正深入調查
  • 最重要的還是讓程式師看到電腦出錯. 只要他們能看到問題發生, 通常都可以由此開始嘗試修正問題
  • 向一個不可能到你身旁的程式師報告錯誤, 首要目標是讓他們能重現問題. 希望讓程式師執行自己的那份程式, 進行相同的操作, 然後以相同的方式出錯.
  • 如果這是個有圖形介面的程式, 告訴他們你按了哪些按鈕以及按各按鈕的次序.
  • 如果是輸入命令執行的程式, 就要精確地告知你所輸入的命令
  • 在目前這個階段, 程式師只是想找出問題所在, 並不會嘗試去修正問題. 他們必須知道什麼地方出錯, 而那些錯誤訊息正是電腦對問題的最佳敘述
  • 不過如果不能同時報告錯誤訊息的內容, 光說程式出錯是沒有意義的
  • 程式師喜歡那些能重複產生的問題. 這時候快樂的程式師能更快更有效率地修正問題.
  • 並不是程式師以外的人才會寫出爛錯誤報告
  • 對程式師也一樣. 提供你自己的診斷有時可能有幫助, 不過一定要先敘述症狀. 診斷是可有可無的, 絕不能取代症狀敘述
  • 用你的聰明智慧幫助程式師是很好. 即使你的推論不對, 程式師也應該心存感謝, 因為至少你已經試著讓他們更好過. 不過記得要報告症狀, 否則你可能會讓他們過得更痛苦
  • 程式師要確認他們處理的是真正的偶發性問題還是與機器相關的錯誤. 他們會要知道很多有關你的電腦的細節
  • 很多報告來自非英語系地區, 而且很多人為英文寫得不好致歉. 通常有為英文不好而致歉的錯誤報告實際上都非常清楚有用
  • 寧願多給資訊而不要少給
  • 閱讀你寫的東西
  • 自己把報告重新讀一遍, 看看有是否夠清楚. 如果你有寫出了重現問題的步驟列表, 試著照做一遍確定沒有漏掉任何步驟.
    • 張 旭
      張 旭 on 04 Dec 14
       
      自己的報告自己看
  • 一份錯誤報告的首要目標是要讓程式師親眼看到問題
  • 如果你不能到他們面前把問題顯示出來, 就得提供詳細的指示讓他們能自己做出來
  • 如果你自認能力夠的話可以儘量嘗試自己診斷問題, 不過即使你做了診斷, 還是應該報告問題的症狀
張 旭

一位开发者的 Linux 容器之旅-技术 ◆ 学习|Linux.中国-开源社区 - 1 views

linux.cn/article-6594-1.html

linux docker container system development devops

shared by 張 旭 on 22 Nov 15 - No Cached
  • 容器是一个 Linux 进程，Linux 认为它只是一个运行中的进程。该进程只知道它被告知的东西。
  • 容器进程也分配了它自己的 IP 地址。
  • 在容器化方面，容器进程有它自己的 IP 地址。一旦给予了一个 IP 地址，该进程就是宿主网络中可识别的资源
  • ...20 more annotations...
  • 使容器 IP 映射到主机中能访问公网的 IP 地址。建立了该映射，无论出于什么意图和目的，容器就是网络上一个可访问的独立机器，从概念上类似于虚拟机。
  • 容器是拥有不同 IP 地址从而使其成为网络上可识别的独立 Linux 进程
  • CPU、内存和存储空间的分配是动态的，和典型虚拟机的静态方式不同。所有这些资源的共享都由容器管理器来管理。
  • 容器能非常快速地启动
  • 托管容器的计算机运行着被剥离的只剩下主要部分的某个 Linux 版本。
  • 操作系统被所有容器所共享，减少了容器足迹的重复和冗余。每个容器只包括该容器特有的部分
  • 层是一个容器镜像
  • 一个容器组件被称为层（layer）
  • 容器的各种功能都由一个称为容器管理器（container manager）的软件控制
  • 流行的容器管理器是 Docker 和 Rocket
  • 镜像存储在注册库（registry）中，注册库通过网络访问
  • 镜像代表了你的容器需要完成其工作的容器模板
  • 应用程序所需镜像的容器配置文件
  • 每个容器有一个独立的 IP 地址。因此，能把它放到负载均衡器后面。将容器放到负载均衡器后面，这就上升了一个层面。
  • Deis 的容器配置技术
  • 可以部署一个或多个容器镜像到主机上的负载均衡器下
  • 每次添加实例到环境中时，你不需要手动配置负载均衡器以便接受你的容器镜像。你可以使用服务发现技术让容器告知均衡器它可用。
  • 类似 CoreOS、RHEL Atomic、和 Ubuntu 的 Snappy 宿主操作系统
  • 类似 Docker 和 Rocket 的容器管理技术结合起来
  • 类似 Deis 这样的配置技术使容器创建和部署变得更加简单
張 旭

七个你无法忽视的Git使用技巧| 编程派 | Coding Python - 0 views

codingpy.com/...t-hacks-you-just-cannot-ignore

git development version

shared by 張 旭 on 27 Nov 15 - No Cached
  • 撤销最近一次代码提交
  • $ git reset --soft HEAD~1 # 对工作文件进行必要的更改 $ git add -A . $ git commit -c ORIG_HEAD
張 旭

数据库水平分片心得 · ScienJus's Blog - 0 views

www.scienjus.com/database-sharding-review

database mysql system

shared by 張 旭 on 29 Oct 18 - No Cached
  • 水平分片（也叫水平分库）指的是将整体存储在单个数据库中的数据，通过某种策略分摊到多个表结构与其相同的数据库中，这样每个数据库中的数据量就会相对减少很多，并且可以部署在不同物理服务器上，理论上能够实现数据库的无限横向拓展。
  • 当遇到第一次数据库性能问题时，最先想到的方案应该是读写分离，将所有写操作都放在主数据库上，所有读操作都放在从数据库上
  • 配置一主多从
  • ...16 more annotations...
  • 主从关系（Master-Slave），此时所有操作还是由主数据库完成，主数据库再同步到从数据库上，而从数据库只需要在主数据库挂掉之后代替其工作。
  • 一般来说读写分离加上缓存已经可以应付绝大多数情况了，并且几乎不需要对业务层面进行修改。
  • 对数据库进行垂直分库，将业务彼此无关的表放在单独的数据库中，分库后不同库中的表无法进行联合查询等操作，但是可以平摊压力，并且独立做读写分离。
  • 对数据库进行水平分表，建立多个结构相同的表分摊数据，使得每个表的数据量减少从而提升速度。
  • 分表却只能在单台机器的单个数据库上，如果是服务器本身的性能达到瓶颈，则分表不会有明显作用。
  • 分表后各个子表还是可以通过 union 等命令联合查询，分库后则不行
  • 基于 id 的区间分片，例如：将 id 为 1-2w 的数据存放在 A 数据库，2w-4w 的数据存放在 B 数据库。
  • 基于 id 的 hash 分片，例如：将 id%2=0 的数据存放在 A 数据库，id%2=1 的数据放在 B 数据库。
  • 基于时间的区间分片，大部分软件都会有一个特征：越新的数据被操作的几率越大，老数据几乎不会被操作。所以通过数据的插入时间进行分库（也称为冷热分离）
  • 基于检索表分片，通过额外建立一张检索表保存 id 与所在数据库节点的对应关系，优点是逻辑简单，自由且不会有迁移问题，缺点是每次查询都需要额外查询检索表，所以一般会选择将检索表缓存到内存中。
  • 基于地理位置分片
  • 分库策略
  • 在数据库表设计时，为了保证 id 唯一，大部分人都会将主键设为自增的 int 类型。但是由于 auto\_increment 是和表所绑定的，所以在分库后每个表的自增 id 也是独立的。这样就肯定会发生主键冲突
  • 但是很多人都希望主键即使不是连续自增，也是一个有序的整数，这样在排序等情况下会有用。这时候就需要自己实现一个 id 生成算法了，一般都会使用 unix 时间戳保持有序，混入 Mac 地址等保证唯一。
  • 在分库情况下，需要将大部分联合查询都替换为至少两次查询，先从关联的表中查询出符合条件的 id，在根据 id 去对应的数据库里查询主体信息。
  • 数据库水平分片作为数据库性能瓶颈的最终解决方案，确实可以有效的解决这个问题。但是它将业务逻辑变得非常复杂（主要是关联表冗余和字段冗余，以及这些数据的更新），并且有分布式事务这个难题。所以不到必要时刻，尽量不要轻易尝试数据库分片。
張 旭

Scrum懶人包 - 10分鐘讀懂Scrum與敏捷軟體開發入門（含中文英文名詞對照） - 敏捷進化趣 Agile FunEvo - 1 views

funevo.com/...hao-xin-shou-zhi-nan-introduce

project scrum

shared by 張 旭 on 08 Nov 18 - No Cached
  • Daily Scrum（每日站立會議）：每天10-15分鐘不能超時
  • Sprint（衝刺）：顧名思義，當團隊決定要哪些 Item 後，就著手去衝。
  • 大原則是 Sprint 內的 Sprint Backlog 不改變（有原則就有例外）。
  • ...6 more annotations...
  • Sprint 開始時，討論一下這個 Sprint 團隊可以交付哪些Item。
  • Sprint 結束時針對產品的會議，PO邀請利害關係人對產出給意見，是要可用的軟體才算產出。
  • Sprint Review 後，Scrum Team 成員（Dev Team 或包含 PO），針對這個 Sprint 團隊的工作模式討論改善，并定出下個 Sprint 改善事項。
  • Product Owner（PO，產品負責人）
  • ScrumMaster
  • Development Team（Dev Team，開發團隊）
張 旭

打造高效的工作环境 - Shell 篇 | | 酷 壳 - CoolShell - 0 views

coolshell.cn/19219.html

system shell linux devops

shared by 張 旭 on 25 Mar 19 - No Cached
  • 对于一些字符串变量，使用引号括起，避免其中有空格或是别的什么诡异字符。
  • 使用 $() 而不是 “ 来获得命令行的输出，主要原因是易读。
  • 对于 rm -rf 这样的高危操作，需要检查后面的变量名是否为空
  • ...2 more annotations...
  • find . -type f | while read F ; do echo $F ; done 不但可以容忍空格，而且还更快。
  • 防御式编程，在正式执行命令前，把相关的东西都检查好，比如，文件目录有没有存在。
1 - 20 of 25 Next ›
Showing 20▼ items per page