說到 IoT （物聯網）很多人第一時間就會想起 Google Home ，Apple HomeKit，Amazon Echo 之類的智能喇叭（音箱），但是他們並不是真的跟 IoT 有關，他們比較像是一個輸入裝置或是一個 gateway 去控制其他裝置而已。 另外比較有技術背景的人可能會想起一些 IoT 的技術，好像說 Bluetooth BLE，Zigbee，2.4Ghz RF 跟 IR 之類的傳輸技術，也有另外一些人會想起 IFTTT、MQTT 之類的通訊協議。可是我們這次不是要說這個，而是 怎樣從零開始自己幹一套 IoT 控制系統出來 嘛，雖然說是從零開始但是總不能從沙開始煉硅晶吧？所以這裡的零界定為： 不使用任何專門為 IoT 設計的產品或軟件來制作這套 IoT 系統。 托比 因為之前我在高中畢業到大一之間的暑假我也曾經研究過一套叫 Home Dynamic 的 IoT 系統，所以這套東西就沿用這個名字叫做 Home Dynamic v2 吧！ 選擇硬體平台 如果要開發物聯網系統，最基本的話就是需要有「物聯網」中「物」的部分吧？所以我就先由硬體開始選擇。這裡我有幾個要求 便宜，而且容易買到體積要夠小，而且輕便省電（因為要 24/7 的運作） 所以這裡就直接省卻了基於 ARM 處理器的開發板了。剩下的就只有 Arduino 系列用的 ATmega 或是更省電的 ATtiny 或者 ESP 系列的 ESP8266 或 ESP32 選擇連接協議 到了「物聯網」中「聯」的部分，到底要怎樣讓這塊板子連接到其他裝置上？市面上有很多不同的 IoT 連接協議及相關的硬體，常見的包括： Zigbee （通常用在 Mesh 網絡上 ）Bluetooth BLE （通常用在需要超省電的裝置上）LoRa （通常用作長距離通訊）2.4Ghz RF （通常用作即時控制，如搖控車）WiFi （對，就是你手機筆電在用的那個 WiFi） 這裡的選擇其他也滿簡單的。首先，LoRa 一定用不上，香港的房子連轉身的空間也沒有，能連接數公里距離的 LoRa 一點用途都沒有。 Zigbee 的確是其中一個可以考慮的選擇，但是因為我也想透過現有的 ArozOS 系統控制它，而 Android、Windows 等作業系統都沒有原生支援 Zigbee，所以在這裡也不作考慮。 最後只剩下 3個選擇：BLE，2.4Ghz RF 跟 WiFi ，不過反正大家都是 2.4Ghz，而且因為我的 IoT 裝置都是用來控制電源、或是用來檢測太陽能板等很容易都抓到電源的地方，那當然選擇最容易可以透過不同手提裝置控制的選擇：WiFi 選擇網絡連接方式 說到「物聯網」的「網（絡）」，既然都跑 WiFi 了當然是用 HTTP 啊！雖然也有其他連接方式例如 MQTT 之類的，但是在選擇這個技術之前要考慮到幾點 這種技術會不會有 SPOF （Single Point of Failure）這種技術會不會需要額外的伺服器 / 硬體這種技術開發起來方不方便（畢竟是寫給自己用，賺不了錢所以太複雜了反而沒意思） 所以就用最簡單的 GET request 就好了啦。而且這方法也不需要 ESP32 內置的藍牙硬體，所以我們可以直接選擇最便宜的 ESP01 來做我們的控制器，一石二鳥。 可是，我們怎樣從網絡中找到 IoT 裝置？ 這是一個好問題，而且之前我在開發 Home Dynamic 系統的時候也遇過類似的問題。但是作為剛剛升大學的我，當時我使用了一個最原始的方法：每個 IP ping 一次 但是在這次的開發計劃中（我把它叫做 Home Dynamic v2），我打算使用 mDNS 來取代這個（爛）IP 掃描方法。畢竟比起一次過把整個區網 ping 一次，例不如讓裝置自己 broadcast 自己的信息好了。剛好 ArozOS 也有內置到 mDNS 掃描器，所以就直接拿來做 IoT 掃描器不就行了嗎？ 於是，我把 mDNS 的 transponder 塞到 ESP8266 裡面，然後跟據 ArozOS 的 mDNS transponder 結構寫了個這樣的 metadata 到 transponder 的回應信息裡面。以下為 hdsv2 的電源開關控制器的代碼： //Inject zeroconf attr into the MDNS respond (For scanning by ArozOS) void…

話說最近因為有使用者提出想把 ArozOS 放到 Cloud VM 上面跑，所以想盡量壓縮 bandwidth 使用量，經過一大堆討論之後的結論就是在伺服器主要的檔案傳送之前先加個 gzip 壓縮器。 現時網上對於要應用 gzip middleware （我把它譯做「中繼器」，畢竟叫他做「中介軟體」好像怪怪的，跟中國大陸的叫法叫「中間件」又好像不太能表達意思） gzip middleware 原理 這個原理很簡單，就是在資料發出去之前先經過一層 gzip 以減少傳送的資料量，系統由原本的 要求 --> Mux / Router --> Handler --> 回傳 變成 要求 --> Mux / Router --> Handler --> gzip 壓縮 --> 回傳 因為要解釋起來很麻煩所以我就直接把 Go module 放這裡了： https://gist.github.com/tobychui/e31ca5be46e266cf52fc247dd38c9181 以下是一些使用例子： if *enable_gzip { http.HandleFunc("/media/", gzipmiddleware.CompressFunc(serverMedia)) }else{ http.HandleFunc("/media/", serverMedia) } fs := http.FileServer(http.Dir("./web")) if *enable_gzip { //Gzip enabled. Always serve with gzip if header exists http.Handle("/", gzipmiddleware.Compress(fs)) } else { //Normal file server without gzip http.Handle("/", mroutner(fs)) } 效果 以 ArozOS 的 desktop.system 界面來看，節省的流量大約如圖所示 上：有開啟 gzip 中繼器 下：沒有開啟 gzip 中繼器 嘛，基本上就這麼簡單而已。

就是因為與 Alanyeung 說到要不要在 ArozOS 1.0 首個 Stable release 的時候興祝一下，於是說著說著就說到了關於「不如畫一張賀圖出來」這樣的話題。 嘛，畫賀圖倒是沒問題啦，問題是誰畫？ 結果因為只有 500 港幣預算問題，香港和台灣的繪師都敲不動，跑去了外國看看有沒有人願意接。想不到以同樣的金額還意外的多人畫，而且有的質素也十分不錯。 來自某 Freelance 網站截圖 結果我們就把繪圖要求外判出去，然後最近成品終於回來了。 這比我想像中的還要好啊啊啊（咳咳 就是這樣，我們就用這張立繪來做 1.110 Release 賀圖了！ 設計中的 ArozOS 1.110 Release 賀圖

近年來不少本來用於物聯網開發的主板已經差不多具備 10 年前電腦主機的 IO 速度和處理水平了。在網上不難看到具備 1000Mbps 網絡接口並同時使用多核心的處理器的單片電腦（SBC），價格上也不太貴（約 100 - 120HKD 一塊），可玩性還是很高的。 其中我使用過的兩種開發板：ZeroPi 跟 OrangePi Zero Plus 然後，我想用它來組網絡儲存系統 對，理論上你是可以用這種 SBC 來做網絡儲存器（NAS），我們一個一個來看： ✔️ CPU: H3 / H5 處理器 ( 1.3Ghz ，一般作為文件伺服器完全沒問題) ✔️ 1000Mbps Ethernet / 網絡接口 ✔️ USB2.0 接口（480Mbps，對於家中只有 100Mbps 上下載的我來說完足夠） ✔️ 40 x 42 cm，可以直接黏在硬碟盒後面 ✔️ 運行時只需要 5V 0.2 - 0.3A，超級省電 可是問題就是它只有 512MB 的 RAM 啊！！！ 現在這年代連最便宜的 Synology DS118 都要比它多 512MB RAM 啊！ 可是，要這麼多 RAM 到底用來幹麼？ Golang 網頁伺服器的文件上載的運作原理 一般來說使用 Golang 處理文件上載的邏輯都長這樣 r.ParseMultipartForm(10 << 20) file, handler, err := r.FormFile("myFile") if err != nil { fmt.Println("Error Retrieving the File") fmt.Println(err) return } defer file.Close() //然後用 io.Copy 把暫存檔案複制到目的地，這裡我就不仔細寫了 在一般電腦上運行這段代碼是完全 OK 的，在上載檔案時 Golang 會把 multipart form data 中的檔案緩存到 RAM，然後在 io.Copy 之後，defer 的 file.Close() 會把 Reader 關掉，之後交由 GC 處理刪除。 這情況只能適用於上載的檔案比系統能用的 RAM 還要細的情況，對於像 ZeroPi / Orange Pi 這種 SBC 要上載大型檔案，就不能用這傳統的方法，而需要特別處理了。不然就會出現以下情況 就是所謂的「爆 RAM」 那讓我們先來了解一下 parseMultipartForm 的原理吧，簡單來說是 你的 browser 把檔案塞到了一個 HTTP FORM 裡面browser 把 FORM 的資料連同你要的檔案在同一個（或多個） Request 裡面送到伺服器因為檔案太大，沒有辦法使用同一個 HTTP REQUEST 處理，所以到達的時候檔案可能被切成幾個 「區塊」，而這個就是 Multipart FormGolang 把這些「 區塊 」寫到 RAM 裡面（在 Debian 的情況下就是寫到 /tmp 裡面）然後如果檔案大小比RAM 大，/tmp 就會被塞爆，出現「no space left on device」錯誤如果 Golang 繼續把東西塞進去，它就會被作業系統殺掉（Killed） 要解決這個問題，我們可以使用兩個方法，首先是不要使用 Golang 內置的 Request library，自己重新寫一個。但是那樣實在太麻煩了，所以我決定直接在前端作更改 WebSocket 是個好東西 說到 WebSocket 很多人會想起類似 Chatroom 或是 Web 的 online game 之類，但是…

在 Raspberry Pi 上面執行類似 arozos 之類的大型系統不免會出現一個問題，就是當要處理大量 IO 的時候總會卡住（畢竟最快的儲存器（ RAM、記憶體） 只有那 2 - 4GB，雖然說現在已經出到 8GB 了，但是那個價格我倒不如買台二手的 ThinkCentre M73？），所以要如何在有限 RAM 的情況下讓檔案上下載速度最佳化是其中一個很有趣的研究方向。 上載的方式 Single-thread Upload （單執行緒上載） 我們就先由正常的上載情況說起吧，我在這裡說的就是一般的 HTML5 Form 的檔案上載。每次一個檔案，很簡單吧？可是這速度實在太慢了，例如 Google Drive 之類的很久之前就已經用了多執行緒上載了，所以要一個一個檔案上載的話，速度是無法接受的。 Multi-thread Upload (多執行緒上載) 就是如此，我在這文章裡說的主要是多執行緒上載模式。簡單來說 Multi-thread Upload 就是由 Browser 對伺服器的上載接點打開多個 request，並同時向接點上載資料的方式。 那 Multi-thread Upload 又有甚麼問題？ Multi-thread Upload 雖然能夠縮短使用者上載檔案的時間，能夠盡用 bandwidth，但是伺服器也要處理短時間內同時上載的檔案，導致系統的開發有點考功夫，有時候甚至要考慮 Race Condition 問題。 在以前純 PHP 5 + Apache 2的年代，伺服器每次只能夠同時處理一個要求，因此很少會出現資源不足的這個問題。但是到現在，很多人都轉用更先進的語言來開發網頁伺服器了，自然也需要處理到資源分配的問題。以下我就以 Go 作為「思考語言」來分析一下吧。 先 Buffer （緩存）到 RAM 不就行了嗎？ Buffering 是一個常用來處理 IO 的方法，由於下載的時候就是由作業系統跟硬碟的緩存機制處理，所以我們只需要處理上載就好。我們就先假設系統採用以下的一個邏輯處理使用者上載的檔案 //建立一個 25MB 的 Buffer r.ParseMultipartForm(25 << 20) //從 POST 中取得 file file, handler, _ := r.FormFile("file") //建立儲存的檔案 dest, _ := os.Create(handler.Filename) //從 File 把內容複制到 dest if _, err := io.Copy(dest, file); err != nil { panic(err) } //關閉打開了的 file descriptor (通稱 fd，即檔案描述符) file.Close() dest.Close() 你那看到，在檔案上載到伺服器的一刻，伺服器已經分配了 25MB 的記憶體給這個 request 了。而這個 request 會把這空間卡住，直到 file.Close() 之前都不會把記憶體還給作業系統，因此每上載一個檔案 = 吃掉一個不少於檔案大小的記憶空間。而在 file.Close() 之前還有一個 blocking 的 io.Copy() 把上載的資料複制到最終的儲存位置（例如硬碟），所以最後就是要等硬碟寫完才能把記憶體釋放出來。 簡單來說就是這樣 所以，這東西很慢！ 為了解決慢的問題，我們來做多執行緒的檔案搬運吧！Go-routine 是一個很神奇的東西，不需要幾行我們就可以寫出支援 Multi-threading 的程式，只要我們把 io.Copy 的部分改成： //建立儲存的檔案 dest, _ := os.Create(handler.Filename) //把複制的部分放到 Go routine，讓客戶端繼續上載下一個檔案 go func(dest *os.File, file *os.File) //從 File 把內容複制到 dest if _, err := io.Copy(dest, file); err != nil { panic(err) } //關閉打開了的 file descriptor (通稱 fd，即檔案描述符) file.Close() dest.Close() }(dest, file) 新的方法看起來像這樣，比起上面的方法快多了 對，這樣檔案上載的速度快多了，而且還能同時發起幾個上載的要求，但是這還在檔案比較小，RAM 裝得下的情況下都還好，但是檔案大的時候該怎麼辦？ 例如說，在只有 2GB…

此筆記是一個簡單純粹的快速參考目錄，方便我（或是你？）在開發時使用 os/exec 之用。如需要詳細的教學或 API 資料，請直接參閱 https://golang.org/pkg/os/exec/ 此文中有部分例子參考自： https://colobu.com/2017/06/19/advanced-command-execution-in-Go-with-os-exec/ 執行指令並回傳結果 func main() { cmd := exec.Command("ls", "-lah") out, err := cmd.CombinedOutput() if err != nil { log.Fatalf("cmd.Run() failed with %s\n", err) } fmt.Printf("combined out:\n%s\n", string(out)) } 加入額外的環境參數再執行指令 cmd := exec.Command("programToExecute") additionalEnv := "FOO=bar" newEnv := append(os.Environ(), additionalEnv)) cmd.Env = newEnv out, err := cmd.CombinedOutput() if err != nil { log.Fatalf("cmd.Run() failed with %s\n", err) } fmt.Printf("%s", out) 指定 CWD 並執行指令 cmd:= exec.Command("git", "log") cmd.Dir = "your/intended/working/directory" out, err := cmd.Output() 注意：使用上術的方式時請確保相關的指令存在於 ENV 參數內（或 Windows 的 %PATH%），如果不是，請使用 binary 的 Absolute Path，例如： abspath, _ := filepath.Abs("./mybinary") cmd:= exec.Command(abspath, "log") cmd.Dir = "your/intended/working/directory" out, err := cmd.Output() 在 Linux 下使用 os/exec + Pipe 或 Bash 運算式 rcmd := `iw dev | awk '$1=="Interface"{print $2}'` cmd := exec.Command("bash", "-c", rcmd) out, err := cmd.CombinedOutput() if err != nil { log.Println(err.Error()) } log.Println(string(out)) 在 Windows 下使用 os/exec + Batch 運算式 cmd := exec.Command("cmd", "/c", "ffmpeg -i myfile.mp4 myfile.mp3 && del myfile.mp4") out, err := cmd.CombinedOutput() if err != nil { log.Println(err.Error()) } log.Println(string(out)) 使用 String Slice 為指令傳進 os/exec args := []string{"hello", "world"} cmd := exec.Command("echo", args...)…

你有沒有想過到底怎樣可以把檔案由 DOM ELEMENT 拖放下載到桌面？ 由本地的檔案管理員或是桌面拖放檔案到網頁上的話大家應該都很容易在一些網站如 facebook 或 youtube 看到可是說由網頁端拖放檔案到桌面就更少見了。 為甚麼我從來都沒看過有網站用這個方法讓使用者下載檔案？ 這當然是有原因的，因為這個功能只有 Google Chrome 支援而已。對於不能跨平台用的 API 沒人用那當然很正常吧？但是作為研究最新技術的 imuslab，這個有趣的功能當然要加進去 ArOZ Online 系統吧？但是，要使用這個檔案由網頁拖放到桌面卻是有這麼堆特別要求： 拖放的元件必須是連接 (<a>)元件的 href 一定要填寫不能留空，但是也可以填 javascript:void(0); draggable 需要設為 true不能使用DOM 屬性 ondragstart ，需要使用 JavaScript 來 加 EventListener 如果你的情況符合上面的條件，你就可以把檔案透過這個 <a> Element 拖放到本地檔案系統了。以下為一個簡單的 Example： $("#element")[0].addEventListener("dragstart",function(evt){ var targetMime = "plain/text"; $.ajax({ url: "media/getMime/?file=" + encodeURIComponent(properties.filepath), success: function(data){ if (data.error !== undefined){ targetMime = "text/directory"; }else{ targetMime = data; } }, async: false }); evt.dataTransfer.setData("DownloadURL",targetMime+":"+ properties.filename +":"+ "http://" + location.hostname + ":" + location.port + "/media/?file=" + encodeURIComponent(properties.filepath)); },true); 到這裡有幾點值得注意 MIME Type 必須符合檔案的內容，不然拖放之後會出現 Internet Shortcut 檔案而不是檔案本身如果要在 event 裡使用 AJAX，那 Request 必須為 Synchronize ，就好像上面的例子中用來要求取得檔案 MIME Type 的 AJAX request 一樣當設定 DownloadURL 參數時時必需使用完整 URL 而不能使用 Relative PathaddEventListener 的 Option 值必須為 true 就是這樣，你就能成功的做出一個可以拖放到桌面的 HTML5 DOM Element 了喔！ 19/6/2020 補充 如果你在下載的時候遇到這個問題 失敗 已封鎖的例子 一般是因為以下兩個原因 你寫入的 URL 不正確或檔案不存在上面的例子裡的一個小 Bug （Hard code 了 http 的問題） 對於非 http 的使用者來說，你可以把這一行 evt.dataTransfer.setData("DownloadURL",targetMime+":"+ properties.filename +":"+ "http://" + location.hostname + ":" + location.port + "/media/?file=" + encodeURIComponent(properties.filepath)); 改成 evt.dataTransfer.setData("DownloadURL",targetMime+":"+ properties.filename +":"+ location.protocol + "//" + location.hostname + ":" + location.port + "/media/?file=" + encodeURIComponent(properties.filepath)); （注意多出來的 location.protocol)來自動 Detect 目前是使用 http: 還是 https: 協議

說到高自由度的網上平台，你會想起哪一些網頁 / 平台？ Google Drive？ Facebook？ Youtube？ 還是說可以 post 奇怪照片的網站 Twitter（？） 平台自由度與用途 一般網頁都不會給予用家太高的自由度，這理由很簡單，一個網頁就是為了提供一種服務，無論那種服務所覆蓋的範圍是廣還是窄，以下是一些例子： draw.io → 網上圖表制作easyEDA → 網 上 PCB 制作與設計onlinesequencer → 網 上音樂制作facebook / twitter → 網 上社交分享Youtube / viemo / po***** → 網 上影片分享平台Office 365 / Google Document → 網上辦公軟件 所以，以商業角度來說，每一個平台必須要有他們的獨立功能才能夠有辦法營運，然而這亦會導致一些問題，就是平台依賴性 (Platform dependencies) 跟 供應商鎖定 (Vendor Lockdown) 問題。 為甚麼我應該擔心這些問題？ 由於這篇文章不是說關於這些 WebApps 的問題，所以我也不詳細解釋這些問題了。簡單來說就是： 如果 A 網頁系統用的格式跟 B 網頁系統用的格式不一樣，你是沒辦法把檔案移動到另一平台上面如果提供 A 網頁系統的公司倒閉了，那你使用 A 系統編寫的檔案全部都再用不了 要解決這個問題，除了使用開放格式 / 標準格式（如 IEEE 制定的格式）外，就是開源系統本身了。但是， 真的這麼不幸擁有 A 系統的公司倒了，我想應該不太多人會懂得用開源的系統重建一套新系統出來吧？比較有可能的是會有人開發一個轉接器把 A 系統的格式轉成另一家 B 系統，但是這個也不是這麼容易可以做到，特別對於重度依賴 A系統並有大量 A 系統格式的檔案的人來說。有甚麼可能更槽糕？就是連檔案本身也是儲存在 A 系統裡面的，當 A 系統倒的時候檔案就跟著系統消失了。 以本地運作為前提設計的 WebApp 所以另一個想法，也就是 ArOZ Online 裡面一直在用的系統，就是把 WebApp 的擁有權取回來的方法。由用者擁有 WebApp 而不是由網頁提供者所擁有。這樣，就算供應該服務的公司倒了，WebApp 依舊能用，檔案也不會消失。例如好像說能在主機啟動的時候檢查更新，並把 WebApp 模組下載到啟動資料夾之類的。當然，你也可能會問： 這不就是 React Native 了嗎？ 不對喔！ (´・ω・`) 這裡就是 ArOZ Online 設計的不同了。React Native 針對的是本地的作業系統，例如 iOS，Windows 或是 MacOS，不同的作業系統會有不同的安裝檔，裡面各包一個 Chromium。那既然是這樣，那為甚麼不直接讓用家在 Chromium ( 或 Firefox / Chrome /Edge 之類的瀏覽器）打開你的 WebApp 呢？這樣不但省空間還能直接用標準 Web Standard 來開發模組。 而這個就是 ArOZ Online 的設計理念：屬於自己的 WebApp 伺服器；而且由於是使用 Web Protocol 傳送的，所以也跟其他 WebApp 一樣去到哪裡，甚至不需要是自己的電腦，都可以透過網絡存取到 WebApp 的內容。 論高自由度平台的條件 然而，因為這種設計已經脫離了一般 Web 開發的範圍，所以要開發一個這麼高自由度，多用途的系統會產生一大堆的問題，例如說 要重新設計 WebApp要想辦法解決本地檔案儲存問題怎樣以人性化的方式尋找及啟動 WebApp （aka 代替 Google 找 WebApp 的過程）怎樣讓使用者不用學習也能適應使用這套系統？ 嗯？你有沒有覺得這些要求跟你平常在用的東西很像？沒錯，那就是作業系統 （Operating System），而作業系統本身也的確是一個很高自由度的東西，你可以把它用作 Media Center，可以用來辦公，遊戲，開發等等的用途。 我們需要的是一個能夠在網頁上運作的作業系統！ 這個也是我開發 ArOZ Online 的理由：把自己需要的服務放到 Web Desktop 上，那去到世界各地，只要有網絡連接都能用自己的系統和存取到自己主機上的檔案。這跟 NAS 系統很像，只不過不同的地方在於這系統不單單用來放檔案，它亦能用來做其他事情。 這說起來簡單，做起來卻很複雜。這是因為自由度太高會導致很想意想不到的錯誤。好像說只是要處理使用者上載的檔案名稱就已經是一個大麻煩了。由於要跟其他系統兼容，所以不能隨便把檔案改名然後把原檔名放進資料庫這種 wordpress 般的操作；也不能讓使用者隨便把 ../ 放進去檔案路徑裡，就結果而言就是很多很多的麻煩。（有興趣的話可以參考這篇文章） 但是，經過了 Beta + 1.0 preview 差不多 5 年的開發和測試，最終於出來的效果也超乎了我的想像：一個用起來跟本地作業系統一樣的高自由度網頁桌面系統！ 很有 Ubuntu…

Golang 跟 PHP 或 Nodejs 不一樣，是一種需要預先 compile 的語言，相信這個大家都知道了。然而，這有一個很大的問題，就是無法像 php 那樣動態載入插件 / 模組。 那如果我想在已經 Compile 好的 Golang 程式上加上額外的功能應該怎樣做？ 一開始我就為這問題煩惱了很久，然而最後我發現了一個不錯的解決方法，就是使用 Reverse Proxy。舉個例子，如果你能夠設定動態的 Reverse Proxy ，然後把一個新的模組指向一個新的 subdirectory ，那樣看上去不就跟新增了功能很相近了嗎？ 所以，就在新的 ArOZ Online Core 裡面加入了這樣的一個結構，這裡我把它稱為 Subservice： Subservice 的概念很簡單，就是把 Reverse Proxy 的 process 拼進去跟 Core 共用同一個 STDIN 跟 STDOUT，然後網頁的部分就是用 Reverse Proxy 來處理，看上去所有模組都是由同一個程式所執行似的（實際上卻不是），它的運作邏輯大約是這樣： 掃描所有存在的資料夾，看看裡面有沒有可執行檔案使用 cmd.exec 加上 -info argument 啟動，等待回傳 JSON 格式的啟動設定把 working directory 轉換到資料夾內，並以 cmd.exec -port {指派的端口} 執行該程式把程式的 STDERR 跟 STDOUT 都指向 parent 的 STDOUT把服務要求的 Reverse Proxy 終端指向到該程式在用家存取該終端的時候進行 URL rewrite【在 Reverse Proxy 下使用模組】在parent 遇上 SIGKILL 的時候把 SIGKILL 都傳送到子服務並關掉程式 問題：可是這樣就存取不了伺服器的 DB 跟 File System API 對，所以這方法後來改成了只讓非兼容 ArOZ Online 的模組使用（例如 Aria2）。對於真的有需要存取系統核心部分 API 的模組來說，這個方法無法處理到 Database 存取跟 File System Virtualization 的部分，如果把 系統核心 API 都用 RESTful 的方式開出來錄又會有另一些安全問題，所以得想另一個方法去處理這個部分。 欸，那我內嵌一套 JavaScript Interpreter 不就可以了嗎？ AJGI 架構 沒錯，所以後來就使用了一個新的架構，暫名 AJGI。這是一個可以讓系統執行 Javascript 的方法，同時讓 JavaScript 存取到系統內部的 function，可謂一舉兩得，至於效率嘛，既然你都是在寫插件就不要介意這麼多了。簡單來說邏輯是這樣的 由 front end 呼叫 AJGI ，並從檔案系統載入一段兼容的 JavaScript 代碼在 JavaScript 虛擬機中執行代碼透過 轉接器 使用 JavaScript 存取 ArOZ Online Core Golang 部分的核心功能（如需要）回傳資料到 frontend結束虛擬機 至於功能和限制之類的就要等之後的開發再進行測試才知道了

ArOZ Online BETA 與 Pre 1.0 版本的差別 在 ArOZ Online Pre-1.0 裡面，我幫 ArOZ Online 系統加上了一層虛擬層；你可能會問：為甚麼要加這個東西？這真是一個好問題，如果不是我開發過一個這樣的系統我也不知道檔案路徑虛擬化的重要性 問題一：檔案路徑安全性 一般如果你用 PHP 來寫系統，你很容易會使用一個檔案的真實路徑。舉個例子，你想讓用家選擇一個檔案，然後打開讓用家下載那個檔案，一般來說你會使用 realpath() 這個功能。然而，這有一定的危險性，例如有人在傳給伺服器的資料中加入 "../" ，讓他能離開你指定的存取範圍。 在 ArOZ Online Beta 的 implementation 中，由於所有檔案都是使用真實路徑存取的，這導致使用者很容易就可以在 path 裡面偷塞一點奇怪的字符以存取一些本來不應該被存取的東西。當然，你可以加一點東西來避免這問題，好像 Stack Overflow 上就有這樣的答案 Stack Overflow 上避免 PHP Directory Traversal 的方法 然而，每次都要透過一個特定的 function 來處理，總會有一天出問題的。（好像說某個開發者忘了用這個 function 或是這個 function 本身有 bug） 問題二：外置存取裝置 由於 ArOZ Online Beta 系統由原本的小網頁變成了一個類似作業系統的物體，它也需要去管理外置的存取裝置（如外接硬碟，或是 www root 所 mount 在的硬碟）。然而 PHP 並不是設計來做這樣的跨硬碟存取的，所以自然有不少的 Bug 存在，而開發起需要存取外置裝置的時候也特別麻煩，需要為。 在 ArOZ Online Beta 的 implementation 裡，使用者需要在 Apache conf 裡面設定 modXSendFile 來讓 PHP 可以在外置硬碟提供（serve）大型檔案如影片，音樂等等。然而，由於外置存取位置的路徑被直接寫進了 Apache conf，即使使用者想更改存取路徑也沒有辦法簡單完成。 解決方案：檔案路徑虛擬化 甚麼是路徑虛擬化？簡單來說就是把 file 的存取路徑進行轉換，讓不同的裝置也能夠輕易的讓模組使用 Virutalized path 來存取。簡單來說是這樣： 請求 Virtual Path模組把 Virtual Path 掉到 file system 的轉換 function回傳真實路徑處理資料 以 ArOZ Online Pre-1.0 的 File system listdir 功能來說，先假設你有兩隻 HDD mount 在了 /media/storage1 跟 /media/storage2，並把 storage.json 設定成以下的樣子： [ { "name":"Storage 1", "uuid":"S1", "path":"/media/storage1", "access":"everyone", "hierarchy":"users", "automount":true }, { "name":"Storage 2", "uuid":"S2", "path":"/media/storage2", "access":"everyone", "hierarchy":"public", "automount":true } ] 然後你可以傳入以下虛擬路徑用來處理檔案 S1:/video/ S2:/ user:/Music user:/Desktop/test 然而實際上，上術的虛擬路徑卻是在存取以下的真實路徑 /media/storage1/users/{username}/video /media/storage2/ ./files/users/{username}/Music ./files/users/{username}/Desktop/test/ 而設定當中，hierarchy 就是決定了虛擬路徑構造的元素，裡面的原理有點複雜，但是作為開發者，你只要存取 virtualPathToRealPath() 這個功能就能夠取得真實路徑了，簡單吧？