客家人錯了嗎？
其實我很在意功能功耗比，可以減少總量能源的消耗的演算方式才是好的演算方式，在我的角度來看待的話。因為各種不同的應用環境的限制不一樣，有辦法在小資源部屬的服務彈性才會大。
有讀者說看到我那篇「可以從一個空房間…」的貼文，感觸很深。以前 CPU 啦，記憶體啦…是很珍貴的運算資源。所以設計程式，規劃架構的時候會小心地調整。不要浪費資源，也不要浪費電去訓練「無效」的模型只是為了「試試看」。現在會這樣思考軟體架構的人也漸漸消失了。
我最近看到某商業小公司自行開發的中文斷詞系統，可以在 RPi 這麼小的板子上運作。相較之下相較之下， xx 院的 xxIP 需要 16GB RAM (至少) 和多核的 CPU 以及 GPU 才能運行。我把這個特色和別人講的時候，收到的回應卻是「你們是客家人哦？省這些硬體幹嘛？從 AWS 上租又沒多少錢。我們訓練機器學習的模型時都直接假設頻寬無上限、CPU / GPU 無上線了。」
還有人問我為什麼有推薦這個東西，又不是開源又要收錢，我心裡滿滿碎念想著你是要一個可以真的放在你產品獨立運作的軟體服務，還是只要一個不用錢的玩具自己慢慢調整？你真的以為支援隱私權控制的裝置可以把資料送到雲端上去辨識之後再回來管理嗎？語音辨識跟斷詞在本地端的設備就要做完了啦！如果可以用 Pi 實作的功能為什麼要用 X86 去實作，你知道這個 BOM 跟電力的成本差多少嗎？你不知道！因為你只是花別人的錢在玩自己開心的事情而已。
我做過 embedded 產品開發相關所以才會這樣看待軟體服務設計，低消太高的服務基本上都難照顧，很多事情不需要這麼厲害，生活裡面常用的字詞就是那些，可以解決常見問題讓大家都買得起比較重要。消費型產品是要考慮價格，電量，體積的，所以那些東西永遠都在實驗室裡面是有原因的。
北海 SOP 的問題就是要做這個事情的人，簡單來說就是董事會。
北海跟 SOP 的合約會那樣簽的原因是因為北海的老闆希望透過跟 SOP 的合作開發一套全新世代的保險系統，一個人的核保稽核到出單可以在一個工作天完成，然後這一套系統自己用好棒棒之後拿出來賣給全世界的保險業者。大概是 AWS EC2 開始那個樣子。
但是問題是北海合作的顧問公司跟 SOP 原廠之間溝通問題很多，然後北海第一線測試人員跟顧問公司的人溝通問題也很多，所以很多基本介面跟資料輸入的問題一個月都改不出來一個進度。
然後導致第一線測試人員年輕的一大批離職，找中南部的人上去幫忙，結果公司給的住宿條件也很基本，所以不發年終獎金也不行，因為一個系統測試讓一群人離職，連續兩三年都這樣。當然系統沒有辦法回去用舊的，所以後來就是加硬體去支撐軟體設計反應時間的問題，財政部金管會罰錢的概念就是你這樣不行，我要罰錢做面子。
最後系統硬上了，狀況當然藏不住了，第一線業務人員跟保戶不爽，最後財務部金管會也知道了，才有今天的局面。舊的系統封存就是做資料查詢。所以現在變成北海內部全公司公測的概念，北海的保單還要亂個一兩年。
實作上就是顧問這一層出問題，本質上的問題就是老闆貪心，這一兩年保險業界排名變動一下也正常。剛剛看到那個一億的數字，那個是以月台幣為單位，所以這幾年北海的財報很難看。一億台幣一年是不可能的，北海是幾個樓層數百人在做這個事情，不過因為 1+1+1<1 的現實，其實真的就是人多反而事情做不好，一次要換掉公司所有系統真的是太貪心了。
這個案子我一開始就知道了，因為我有朋友有兩三年的時間每周通勤。老闆高興這樣玩公司下面的員工能怎樣？有錢怎麼亂搞都好 XD
你沒有辦法一次最佳化所有部分，因為事情不是人多好辦事，而是核心人員一步一步最佳化所有的流程。
我不會因為這種事情自殺的，比較可能「被自殺」。
不说别的，我们就说说华为的防水。上次我的华为mate30掉到马里亚纳海沟里了，我以为手机肯定完了，不是进水就是被水压压爆了。结果令我没想到的是，我的华为用徕卡镜头当眼睛，自动开启了手电筒照亮海底，以手机GPS当导航，凭借着玻璃机身的流线感，靠着手机震动不断划水，竟然又找到了我！麒麟990处理器散发的温暖，使我拿到我的华为的时候不是冰冷的触感，而是略带温热。这一刻，我真的感受到了祖国的温暖。此生入了大华为，来世还做中国人。
接下来说说华为的闪光灯，我下矿现在都不带头灯了，手机一拿出来，整个矿都亮。信号超给力，记得有一次当时我们矿透水踏了，地下6000多米，500多个工友手机都没信号，我拿出我的华为打通了求救电话。而且华为的电池特牛逼，当搜救员工找到我们时，由于塌方，电全断了，他们用绳索吊上去200多人。可是突然发生二次塌方，如果不快点救人，那就全完了。我拆下我华为的电池搭通升降机，当时全矿居然都通电了。升降机轰隆隆的，以前一次拉10个人就不行，用华为电池一次拉了50多个，5分钟就救出了所有人。 等救完人，把电池还我，装上电池还有98%。
福和橋機車專用道車禍紀錄。
我的結論是還好我緊急煞車成功沒有撞到人，突然覺得需要行車記錄器。
然後被警察問話的四個倒楣鬼都是男的，都沒有行車記錄器。
[-2][-1] 在酒測之後被警察要求到派出所做筆錄，[-2] 我要提醒他明天要去醫院檢查腦部，我擔心有腦震盪，他說他沒有撞到頭。[1] 在警察到之前就跑掉了，她如果自己有去醫院檢查就算了，沒有的話人怎麼樣就是自己的造化了。
台北市[-2][-1][我][1][2][3][黑色垃圾袋跟散落兩個車道的回收塑膠罐]往永和方向
[-2] 煞車不及，撞到 [-1]，在右邊的車道迴轉倒下，人在往永和方向躺下，車頭朝台北市方向，第一時間人倒在地上，把他的車先牽到靠近快車道的內側機車道，人先拖到分隔島等救護車來。
[-1] 沒有撞到我的機車，但是因為我為了要去台北市方向提醒大家減速，所以把機車熄火了。他指責我不應該把車子熄火，這樣後車燈就熄掉了，這邊我覺得他說的也沒錯，或許這樣他就不會急剎車讓 [-2] 撞到他。
[我] 緊急剎車沒有撞到 [1]，那個時候 [1] 已經倒在地上，靠近內側車道分隔島的位置，機車衝到機車專用道外側車道，我差一點點前輪就壓到 [1] 身上，我把 [1] 扶起來坐在分隔島之後，把 [1] 的機車牽到靠近分隔島的機車專用道內側車道。
然後我去 [2] 前面把塑膠罐踢開，這個時候 [2] 正在打電話報警，然後我覺得不對趕快往台北市方向移動要警告後面的來車，然後 [-2][-1] 大概是第一批第二批往永和衝的車流，我把 [-2] 拉到分隔島之後，我就繼續往台北市方向移動，剛開始揮動安全帽，後來揮動手機的手電筒，最後在救護車跟警車到之後才結束。回到救護車旁邊的時候 [1] 已經離開了。
[1] 騎一台小車身的檔車，依照身高跟體重來看，我個人認為有可能未成年，所以在救護車到之後，警車到之前就離開了。車禍發生的時候車子衝到機車專用道外側車道，人躺在內側車道靠在分隔島上。
[2] 沒有撞到 [3] 但是因為 [3] 緊急煞車閃躲垃圾袋跟塑膠袋的原因，導致 [1] 緊急煞車滑倒在地上，事情發生當下第一時間報警，很冷靜的一個人。
[3] 運氣好的人，緊急煞車沒事閃過那一堆塑膠罐，然後後面倒一片。
今天跟朋友吃漢堡王的時候聊到 IoT 裝置對 Thin-AP 的使用問題，因為很多 Thin-AP 架構為了效能最佳化的需求，所以原始的設計是把廣播封包全部攔截，控制器只針對需要的廣播風暴做轉送工作，就邏輯上來看就像是乙太網路交換器一樣。
通常要解決這樣的問題最快的方式是在特定範圍使用消費型的無線基地台做單點配置就可以解決，另外一個角度來說，IoT 裝置在有限的記憶體跟處理器規格設計下，針對單一 ESSID 有多重 BSSID 的狀況也是很極端，要不是死黏著一個 BSSID 不放，要不是 BSSID 一直輪跳網路一直瞬間斷線，這個時候可能的解決方案大概是找一個支援 wireless client 或者 wireless bridge 的基地台做乙太網路連線，這樣的問題可能相對簡單一點。
理論上基地台如果支援 wireless client 或者 wireless bridge 的話問題應該不會太大，只是這樣的東西可能比 IoT 裝置貴多了，入門款的無線網路基地台可能還比較便宜一點。
大部分的 IoT 裝置基本上都透過類似 Zero-configuration networking 的技術，像是 uPnP，SSDP， Bonjour，mDNS 等等。共同的特色在於利用廣播封包對區域網路內部的裝置告知自己的 IP，Hoetname，Service 等等。但是這樣也產生了很多問題。廣播封包會對區域網路的封包交換效能產生極大的影響，所以當電腦超過一台交換器實體連接埠數量的時候，就要開始做實體網路拓樸分割，避免廣播封包的數量太多變成廣播封包風暴，這個是有線網路連接的狀態。
同樣的問題在無線網路發生的時候，會變得非常嚴重，因為無線網路在同一個頻道範圍上面等於是單一一條網路線，跟有線網路交換器的每個連接埠是獨立的頻寬不同，所以在無線網路使用的時候，如果要同時間服務很多裝置，無線網路控制器必須要有效率地去判斷什麼封包需要被轉送，所以在無線網路控制器的設計上就會有一個需要被轉送的封包或者服務設定功能，在 Cisco WLC 控制器的設計而言，相關的功能就被稱之為 mDNS Snooping，WLC 會檢查所有 mDNS 相關服務的封包，然後針對管理者的設定去記錄特定的 mDNS 紀錄，再轉送到指定的無線網路介面上，所以一般有 mDNS Snooping 的設備通常也有 mDNS Proxy 的功能，在所有監聽 mDNS 的介面上面記錄並轉送 mDNS 的紀錄。
如果沒有設備支援大量 mDNS 監聽紀錄轉送功能怎麼辦，這個問題我也想過，這個時候就 GOOGLE，我就找到了一個專案叫做 Cluster，透過 gRPC 跟 mDNS 服務的組合，加上主從式架構做出一個監聽所有子網路並且共同維護同一份 mDNS 項目列表的分散式 mDNS ，如果你有需要在為了網路效能做子網路分割跟 mDNS 服務之間並存的狀況下維運你的基礎架構，我相信這個工具可以解決你不少問題。
Cluster
https://github.com/bah2830/cluster/blob/master/README.md
Controller node cluster management using gRPC and mDNS service discovery. Each node will watch for mDNS entries on the network. When the controller entry is found it will send a checkin message with it's details to the controllers gRPC service. From then on the controller and communicate with all nodes that have checked in.
Bonjour is Apple’s service discovery protocol which locates devices such as printers, other computers, and the services that those devices offer on a local network using multicast Domain Name System (mDNS) service records.
https://www.cisco.com/c/en/us/td/docs/wireless/technology/bonjour/7-5/Bonjour_Gateway_Phase-2_WLC_software_release_7-5.html
在軟體開發週期的差異上，讓我感覺跟現在最大的不同，在於 20 年前左右我在用 BSD 轉 Linux 的那個時候，大概是 Slackware Linux 1.0，然後 Debian Linux 2.0 的那個時代。
我覺得那個時候的軟體開發重視的是支援功能，就是現有的軟硬體很多，怎麼樣周全的支援現有的軟硬體是那個時候 Linux 相關開發套件的重要問題，也是因為這樣我從 BSD 轉到 Linux 去。會棄用 BSD 的原因就是因為相對於 Linux 來說 BSD 的穩定度更好，但是真的要做伺服器以外的用途是有困難的，桌面應用環境不夠完整。那個時候比較重視穩定度，畢竟功能上都是軟硬體相關的服務。所以開發周期相對長，但是軟體的重大問題比較少，效能也相對穩定，不見得是快，有的時候就是跑不快然後只好花錢用硬體換。而且那個時候的軟體功能沒有這麼多，相對來說對開發人員而言算是一個小確幸時代。
現在的軟體開發週期給我的感覺比較像是沒有新功能沒有梗就要擔心沒人用，但是變成公開測試的模式，然後有一些在內部測試應該要解決的問題到了公開使用的階段才發現。現在的軟體開發應該比以前重視流程呀！但是為什麼發現問題的時候，低級的問題常常出現呢？我覺得問題的本質在於市場節奏感的強度優先於軟體安全性跟完整度的問題，多數的服務都走向消費性的概念，像是作業系統一年一定要有一個大更新，兩個小更新之類的這種概念，然後一個功能要做到完善的話大概要三個小更新或者是兩個大更新之類的。
另外一個現實是現實中的 CI CD 概念，其實有一個重大的盲點在於產品階段的使用者測試，因為 CI CD 階段在大部分的軟體服務中並沒有在其中插入所謂的黑箱測試，都是白箱測試，白箱測試其實有很大的盲點，這些盲點在最後上市之後的使用者黑箱測試階段會一次爆發。你說 Windows Insider Program 的參與者能不能算是黑箱測試人員，在我看來是不能算的，因為會參加這個專案的人基本上都對作業系統有一定的了解或者是目的。
黑箱測試的人員基本上只能就自己的日常基本操作去使用，去確認日常生活中原來沒有問題的事情在新版本的作業系統上有沒有問題，所以如果 Windows 10 1903 開始部屬了，如果應用程式比較常見而且不用太多高效能 API，像是 Office 之類的，可以在新的電腦上面直接部屬 1903 是沒有問題的。但是如果工作環境當中有用到比較小眾的軟體，可能就要往前推到 1809 或者是 1803 的版本上，因為不是所有的軟體開發商都可以跟得上作業系統更新的頻率。
所以現在的軟硬體更新，在我的角度來看，除非有重大的資訊安全漏洞需要處理，不然我都會很保守的等到那個軟體版本的支援周期結束才會更換成新的，或者是新的設備跟新的工作環境直接上新的版本也沒有問題，畢竟更換新的軟硬體環境本質上是沒有生產效益的，在避免影響生產流程的前提下，頻繁的調整軟硬體環境其實不是一個好的做法。如果是網路服務的話，我會偏好做一個版本上線服務之後，做相關的安全性跟功能跟新，提供使用者這個服務最短會支援多久，然後在同時把這個服務使用者的意見收集起來，做下一個版本的服務，但是我不預告下一個版本什麼時候會走到正式上線服務的階段，因為需求改變了，不同的需求沒有辦法用一樣的測試時間去保證有一樣的測試品質。
我必須再次說明，軟體開發跟服務開發的結果是要滿足使用者的需求，讓使用者花錢來買這個東西，CI CD 的概念在我的角度來看比較偏向是滿足軟體跟服務開發流程，還有公司產品預期上市流程用的，但是 CI CD 做好只是保證軟體應該會正常運作，但是不保證軟體真的滿足使用者的需求或者是使用者真的會按照開發人員的想法去使用軟體跟服務。
2007 年 8 月份微軟 tcpip.sys 全球更新導致 skype 全球大斷線那個事情我也是受害者，那個時候工作的公司有功能是用被更新的漏洞開發的，所以有一個月的時間大家在研究用什麼方法可以重新實作那個功能。有的時候你覺得是漏洞別人覺得是功能呀！那個時候 tcpip.sys 的更新是微軟幾乎是強迫派送的，所以沒有關閉更新服務的電腦基本上都會被重開機一次，所以那個時候最早的共享經濟服務 skype 就全球大斷線了。結果現在 skype 變成微軟的產品了，真的是商場上沒有永遠的敵人跟朋友呀。
現在的狀況就變成某一個雲端系統服務障礙，我都開玩笑說雲端打雷了，然後日常生活中的特定服務就全球故障，我們都以為雲端服務應該要比較穩定，終究其然我們只是把自己裝網路線電源線伺服器硬體的事情委託給別人做，然後系望這一套系統不要壞掉，然後以前習慣會作容錯系統的服務就還是繼續作容錯，以前沒有作容錯系統的服務上雲端還是一樣沒有作容錯，會掛掉的還是會掛掉，只是這個時候可以把責任外包說 GCP AWS Azure 掛掉了我也沒辦法這樣。
雲端好棒棒。
Telegram 其實掌握了人性的矛盾點，到底怎麼樣的隱私才能稱之為安全。
實際上對 Telegram 投錢的人應該是三教九流都有，不管是恐怖分子，毒梟，非政府組織，人道救援組織，甚至於政府情報單位。為什麼我會這麼說呢？因為自己開發一個通訊服務要驗證其隱密性非常困難，如果你的同行有人用了一個服務，然後你們的行業又非常重視保密性，那如果他用了半年一年人都沒事，然後你又找不到好的通訊解決方案的話，你會不會跟著用？
另外一個現實的事情是合法的事情不代表可以被攤在陽光下討論，非法的事情不代表這個事情真的有傷害的別人，每個地區國家都有不同的習俗跟法律框架，如果你要突破這些法律框架，那就必須要有一個對私人訊息群組不審查的通訊服務。
你問我說 TON 會不會成為一個新的電子交易憑證的框架，我個人的看法是這樣的，如果可以維持進入門檻不要太高的話，TON 跟 Telegram 的組合應該在特定的次文化會很流行，這些次文化共同的特色就是在特定地區國家有法律或者道德問題，或者是需要高度隱密性的狀態，但是這樣是壞事嗎？我不確定。因為好事情壞事情的定義是依照人當時的立場去看待的，但是通訊服務跟電子交易憑證其實是工具，工具是中性的。
我個人的邏輯上，我不認同用稀有資源作為資本去建立貨幣系統的概念，例如比特幣挖礦的概念，我比較希望是透過我們對這個制度的信任狀態去建立貨幣系統。我們出生的地區國家政府建立了一個基本的貨幣系統，我們需要跨國購物轉帳所以有了信用卡跟 PayPal 西聯匯款這些服務，到最後如果我們需要一個即時的電子交易系統，可能就是建立在區塊鏈的電子金融商品上面。
到時候的交易方式可能是以基於小時或者基於日的匯率，根據本地本國跟 TON 的匯率去計算 TON 的費用，然後 TON 就會成為全球電子金融系統的一個獨立框架。既有金融系統的詐騙跟帳戶盜用問題 TON 也是會發生的，只能說非政府監管的金融系統都是金融商品的概念，沒有政府保障也是高風險，需要用的時候再大量長期買進比較好。
轉過頭來，各位可以思考，為什麼比特幣最近行情這麼好的原因，是不是有特定地區國家有強力的資產轉移需求，然後特定地區國家的金融管制限制又很強呢？比特幣的漲勢都是一個波段一個波段的，只是有的事情是檯面上看得到的，有的事情是在檯面下運作的，TON 應該會比比特幣更通用一點，現在檯面上的電子交易憑證服務公司應該都感受到壓力了吧？
你說 Telegram 有沒有用到區塊鍊，我會說 Telegram 其實是最早用到區塊鍊或者相近技術概念的應用服務之一，因為分散式的身分驗證技術基本上就是區塊鍊的一個重點，只是那個時候的區塊鍊概念還沒有這麼清楚。而且就現在的角度來說，區塊鍊跟匿名一點關係都沒有，匿名這件事情只建立在電子錢包跟其他的公開資訊沒有建立關係之前，在電子錢包跟其他公開資訊建立關係之後，匿名的狀態就消失了。
就像是現在的雲端管理技術 Kubernetes 在叫 Kubernetes 這個名字之前，Google 給的是一個敘述這個字的一大串概念的解釋，然後在 Kubernetes 這個字本身也是政府 Government 單字的前身，所以你加入不同的 Kubernetes 雲端服務的話，等於是加入不同的政府架構，這個很有趣吧！所以實際上雲端服務跟中央集權是相結合的，所以使用雲端服務就等於去去中心化這個現實是已經確定的，所以大型的網路服務公司怎樣做去去去中心化這個事情就會是一個嚴肅的課題了。
創辦的公司被政府強行收購，「俄羅斯祖克伯」憤而發明加密通訊神器 Telegram
https://buzzorange.com/techorange/2019/09/06/the-history-of-telegram/
USB 4 在我的認知上是 Thunderbolt 3 的實體層加上 USB 4 的協定層，不過被動線路只有 85 公分的長度實在是很慘，要更長就是主動式的光纖了。接下來 CPU 會內建 USB 4 指日可待，不過要低延遲的話，還是用 Thunderbolt 3 ，畢竟 PCIe 匯流排的反應時間比 USB 低得多。
本質上的問題是在於 Thunderbolt 跟 USB 要滿足的客群不同。
Thunderbolt 要滿足的客群基本上是高效能低反應時間的使用者，USB 要滿足的客群是消費型裝置的使用者，而且 USB 裝置的熱插拔裝置驅動程式已經很成熟了，但是 Thunderbolt 裝置做熱插拔這個事情其實到現在還是會遇到問題，所以 Thunderbolt 跟 USB 其實是互補的設計。實際上 Thunderbolt 裝置並沒有辦法像 USB 的設計一樣做頻繁的熱插拔，因為會遇到 Thunderbolt 服務當機的狀態，這個時候只能拔掉 Thunderbolt 裝置之後把電腦重開機，之後就會正常了。
實際上 Thunderbolt 3 的高效能低反應時間有其代價，第一代支援 Thunderbolt 3 的 Windows 筆記型電腦，如果用 i3 CPU 的話，可能會有跑不動的問題，因為 Thunderbolt 3 匯流排全速使用的狀況下，因為那個時候 i3 CPU 的效能不足，所以實際上那個 Thunderbolt 3 介面其實是不實用的，我相信在 USB 20Gb 跟 40Gb 的時代，USB 控制器一定會有硬體的卸載功能去降低 CPU 的負擔，但是 Thunderbolt 是 PCIe 裝置，所以所有的管理成本都會直接加在 CPU 上，然後因為要外接，所以還有一個 kernel message service 的成本，所以 Thunderbolt 沒有 i5 i7 CPU 的話基本上應該是不用期望效能的。
目前 Thunderbolt 3 的硬體規格授權，Intel 也已經在 2018 年完全開放了，不過就 PCIe 的驗證要求而言，短時間低價的整合型產品還很難看到，我們就再等看看吧!
讀者李先生表示:
感覺 USB 4.0 根本是半套版 TB3，Intel 平台將來乾脆直接內建 TB3 支援即可，反而讓 AMD 平台使用 USB 4.0 ( 不如 TB3 )
