幹壞事是進步最大的原動力
上次是 2018 年五月把 PHP 換到 7.2 (參考「把 Blog 換成 PHP 7.2」)，這次是在整理機器時發現 blog 這台機器還在跑 7.2，就更新一下系統把上面的站台都換到 7.3。
蠻多人都測過效能了 (像是「The Definitive PHP 5.6, 7.0, 7.1, 7.2 & 7.3 Benchmarks (2019)」)，目前看到的資料都會快一些，應該是沒有太大問題，之後可以考慮再把 OPcache 的可用空間大小再降一些 (預設是 128 MB，但用 opcache-status 看起來只用了 65 MB 左右)，把記憶體空間讓給其他程式用...
不過 7.4 也快出了...
在「Prepare For Fewer Cache Hits As Chrome Partitions Their HTTP Cache」這邊看到的，Google Chrome 打算要拆開 HTTP Cache 以提昇安全性與隱私性。
有 cache 跟沒有 cache 可以從讀取時間猜測出來，這樣就可以知道瀏覽器是否有這個特定 url 的 cache。
在原文的作者所給的例子沒有這麼明顯，這邊舉個實際一點的例子來說好了... 我想要知道你有沒有看過 zonble 的「返校」這篇文章，我就拿這篇文章裡面特有的資源來判斷。
以這篇文章來說，我可以選擇第一張圖片的網址 https://i0.wp.com/c1.staticflickr.com/1/603/31746363443_3c4f33ab18_n.jpg?resize=320%2C200&ssl=1 這個 url 來判斷讀取時間，藉此我就可以反推你有沒有看過這篇文章，達到攻擊隱私的效果。
解決的方法就是作者文章裡所提到的方法，把 HTTP cache 依照不同的網站而分開 (在 Safari 已經支援這個功能，而 Firefox 正在研究中)。
當然這樣做應該會對流量有些影響，但考慮到這些日子有很多新技術可以增加下載速度，這個功能應該是還能做...
AWS 這次在 CloudWatch 上推出了新功能，可以直接透過機器學習的演算法，對 CloudWatch 所記錄的值提供異常偵測 (anomaly detection) 的能力：「New – Amazon CloudWatch Anomaly Detection」，對應的文件則可以在「Using CloudWatch Anomaly Detection」這邊讀到。
這個功能可以抓一個預期的區間出來，然後針對超出區間時發出警報：
這邊感覺把以前很多工作自動化掉了，省了很多事情...
在 Facebook 上看到朋友貼的統計分析小工具：「A small tool to do the statistics legwork on benchmarks etc.」，看了一下原來是 phk 寫的，後來被拉出來獨立跑...
從兩個檔案讀取兩組數列，然後用 Student's t-test 分析的小工具，在 manpage 裡面可以看到說明：
Specify desired confidence level for Student's T analysis. Possible values are 80, 90, 95, 98, 99 and 99.5 %
雖然說有些人不喜歡 Student's t-test 被濫用，不過畢竟還是一套合理的數學方法，在分析的時候可以快速的判斷...
翻了一下發現 Ubuntu 也有得裝：「Ubuntu – Package Search Results -- ministat」。
看到 Ubuntu 在安裝時支援 ZFS 的消息：「A detailed look at Ubuntu’s new experimental ZFS installer」。另外 Twitter 上也有截圖了：
Thanks to the work from @didrocks and Jean Baptiste 🛠 a number of the #ubuntu flavours now have the experimental ZFS 💪 install option available in 19.10 😎 pic.twitter.com/Aux8iCri4p
— Martin Wimpress (@m_wimpress) October 8, 2019
看了一下授權問題，看起來是 Ubuntu 認定這樣做不會有問題，但目前還沒被 Oracle 出手，所以也不曉得真的出手後會發生什麼事情...
算是 AWS 的 PR 稿，在老闆對雲的宣示與政治正確下本來就會陸陸續續轉過去...
這次是 Amazon 的 Consumer Business 從 Oracle 的系統換到 AWS 自己的系統：「Migration Complete – Amazon’s Consumer Business Just Turned off its Final Oracle Database」。
原先有 75 PB 的資料與 7500 個 database：
We migrated 75 petabytes of internal data stored in nearly 7,500 Oracle databases to multiple AWS database services including Amazon DynamoDB, Amazon Aurora, Amazon Relational Database Service (RDS), and Amazon Redshift.
其中一個優點是省成本，但是也投入了超過一百個團隊一起參與轉移，會需要攤多久才會打平，這點在沒有看到內部財務資料其實沒辦法判斷，而且工程資源的稀缺性也是個沒有被看到的資訊：
Cost Reduction – We reduced our database costs by over 60% on top of the heavily discounted rate we negotiated based on our scale. Customers regularly report cost savings of 90% by switching from Oracle to AWS.
More than 100 teams in Amazon’s Consumer business participated in the migration effort.
然後 latency 的下降其實也只能參考，因為轉移系統的時候也會順便改寫，有多少是因為 AWS 服務本身帶出來，在沒有內部資料看不出來：
Performance Improvements – Latency of our consumer-facing applications was reduced by 40%.
管理成本算是裡面唯一可以參考的，畢竟是搬到可延展擴充的服務：
Administrative Overhead – The switch to managed services reduced database admin overhead by 70%.
另外，沒寫的東西比較有趣，像是他們沒有選擇 Athena 而是用 Redshift，看起來像是先轉上去，其他找機會再說...
在 Hacker News Daily 上看到在講 Intel CPU 因為各種安全性問題，而需要在 Linux Kernel 上修正，所產生的效能問題：「HOWTO make Linux run blazing fast (again) on Intel CPUs」。
這一系列的子彈也飛得夠久了 (雖然還是一直有其他的小子彈在飛)，所以回過頭來看一下目前的情況。
這邊主要的測試是針對 mitigations=off 與 SMT 的啟用兩個項目在測 (SMT 在 Intel 上叫做 Hyper-threading)，可以看到這兩份測試結果，目前的 mitigation 對效能的影響其實已經逐漸降到可以接受的程度 (小於 5%)，但關閉 SMT 造成的效能影響大約都在 20%～30%：
但是開啟 SMT 基本上是個大坑，如果有關注大家在挖洞的對象，可以看到一堆 Intel CPU 上專屬的安全性問題都跟 SMT 有關...
剛好岔個題聊一下，先前弄了一顆 AMD 的 Ryzen 7 3700X 在用 (也是跑 Linux 桌機)，才感受到現在的網頁真的很吃 CPU，開個網頁版的 Slack 與 Office 365 的速度比原來的老機器快了好多，差點想要把家裡的桌機也換掉...
uBlock Origin 是一個在瀏覽器上擋廣告的軟體，以前在推廣的時候都只提到可以過濾掉網站上的廣告，大家興趣其實都不太高 (還會有「留口飯讓別人吃」之類的 XDDD)，但最近跟同事推廣的時候改用「可以擋 YouTube 的影音廣告喔」，大家接受度意外的爆高，不過這有點扯遠了，回到原來的主題上...
先介紹一下 uBlock Origin 的開發模式，除了一般的 stable 版本外 (「uBlock Origin」這組)，另外會有另外一個 dev 版本上傳到 Chrome Web Store (CWS) 上 (「uBlock Origin development build」這組)，這樣讓使用者比較容易安裝與測試，這個方式也可以在 Tampermonkey 上看到。
這次主要維護者 Raymond Hill (gorhill) 在 1.22.5rc1 版上傳到 CWS 上後收到被拒絕上架的通知：「Dev build 1.22.5rc1 "REJECTED" from Chrome Web Store」。
拒絕的原因是 CWS 要求要有套件必須符合「目的單一性」，也就是不能把目的不同的東西強迫使用者綁在一起使用：
Your item did not comply with the following section of our policy: An extension should have a single purpose that is clear to users. Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator. If two pieces of functionality are clearly separate, they should be put into two different extensions, and users should have the ability to install and uninstall them separately. For example, an extension that provides a broad array of functionalities on the New Tab Page/ Start-up Page but also changes the default search are better delivered as separate extensions, so that users can select the services they want. For more information on the new Chrome extensions quality policy, please refer to the FAQ: https://developer.chrome.com/extensions/single_purpose
後續的 1.22.5rc2 也被拒絕，然後他回信詢問了 CWS 官方，得到的仍然是罐頭回應，然後他就決定丟著 (而這個作法還蠻聰明的)，接著這件事情就被丟著變成 PR 事件上了一些媒體，然後昨天就突然解了...
Google 最近的動作愈來愈多了，一方面在嘗試避免觸動反托拉斯法的情況，儘可能打壓這些擋廣告的套件...
剛剛改回用 beta channel 的 Google Chrome (78 版)，結果發現網址列裡的 www 被拿掉，而且本來可以關掉的方式 (omnibox-ui 系列的設定) 從 chrome://flags 裡面也拔掉了，代表你現在關不掉了...
搜了一下資料，發現在 Reddit 上有人討論過 78 版的這個問題 (當時還在 dev channel)：「Chrome 78 dev hide 'www' again」。
裡面有人提到可以安裝 Suspicious Site Reporter 讓 www 重現，當初看到還半信半疑，結果裝了發現真的會動，WTF...
看了一下 extension 的 source code 發現好大一包，以後應該會有人生一個小的 extension 出來專門做這件事情？
AWS 對 ARM 平台的採用速度比想像中快，昨天發表了 bare metal 版本 a1.metal：「Now Available: Bare Metal Arm-Based EC2 Instances」。
相較於 x86 系列提供的 bare metal，ARM 這邊提供的機器不算大台，只有 16 核心與 32 GB 的記憶體，所以主要的用途應該是在於可以存取系統底層的資訊，或是因為軟體的授權不支援虛擬化而需要租用 bare metal：
這次的 a1.metal 共八區可以用：
You can start using a1.metal instances today in US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt), Asia Pacific (Tokyo), Asia Pacific (Mumbai), and Asia Pacific (Sydney).