幹壞事是進步最大的原動力
在 Daily Hacker News 上看到「Berlin key」這個東西，用機械結構就可以強迫使用者一定要鎖門的鑰匙。
門平常都是上鎖的，要解鎖要先用鑰匙打開，然後從另外一邊鎖上後才能拿出來：
是個有年代的設計，但現在在柏林還是有不少這樣的設計：
Invented by the Berliner locksmith Johannes Schweiger, the Berlin key was massively produced by the Albert Kerfin & Co company starting in 1912. With the advent of more recent locking technologies, this kind of lock and key is becoming less common. It was estimated that 8000-10000 are still in use today in Berlin, Germany.
現代則是用自動門的門禁來管制，但這個設計還是很有趣...
Google Cloud Platform 一開始是提供 Premium Network，會透過 Google 自家的網路骨幹連到最近的點，然後再透過當地的機房交換出去，這樣可以確保頻寬的穩定性，但成本當然也就比較高...
後來提供了 Standard Network 則是從機房出去後就直接交換，成本會比較低 (參考「Network Service Tiers - Custom Cloud Network」這篇)，但在台灣的機房一直都沒有提供 Standard Network (好像是需要另外申請？)，所以我每個月月底的時候都會測一下看看開放了沒... 然後剛剛發現可以開起來了，不確定是已經全開了還是分批開。
測了一下發現網路相當... 爛？是還在調整嗎...
像是 1.1.1.1 的 latency 很高 (自家的 8.8.8.8 當然就沒這個問題)：
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=49 time=48.9 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=49 time=48.5 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=49 time=48.5 ms --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 48.554/48.691/48.964/0.193 ms
然後 168.95.1.1、139.175.1.1 也都很差 (61.31.1.1 不給 ping)：
PING 168.95.1.1 (168.95.1.1) 56(84) bytes of data. 64 bytes from 168.95.1.1: icmp_seq=1 ttl=239 time=21.2 ms 64 bytes from 168.95.1.1: icmp_seq=2 ttl=239 time=21.3 ms 64 bytes from 168.95.1.1: icmp_seq=3 ttl=239 time=21.4 ms --- 168.95.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 21.276/21.367/21.454/0.072 ms
PING 139.175.1.1 (139.175.1.1) 56(84) bytes of data. 64 bytes from 139.175.1.1: icmp_seq=1 ttl=53 time=63.4 ms 64 bytes from 139.175.1.1: icmp_seq=2 ttl=53 time=62.9 ms 64 bytes from 139.175.1.1: icmp_seq=3 ttl=53 time=62.9 ms --- 139.175.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 62.967/63.139/63.455/0.303 ms
不過學術網路倒是還不錯：
PING 140.112.2.2 (140.112.2.2) 56(84) bytes of data. 64 bytes from 140.112.2.2: icmp_seq=1 ttl=51 time=5.13 ms 64 bytes from 140.112.2.2: icmp_seq=2 ttl=51 time=4.40 ms 64 bytes from 140.112.2.2: icmp_seq=3 ttl=51 time=4.52 ms --- 140.112.2.2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 4.405/4.690/5.138/0.325 ms
PING 140.113.250.135 (140.113.250.135) 56(84) bytes of data. 64 bytes from 140.113.250.135: icmp_seq=1 ttl=55 time=5.87 ms 64 bytes from 140.113.250.135: icmp_seq=2 ttl=55 time=5.97 ms 64 bytes from 140.113.250.135: icmp_seq=3 ttl=55 time=6.11 ms --- 140.113.250.135 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 5.872/5.987/6.119/0.135 ms
PING 140.117.11.1 (140.117.11.1) 56(84) bytes of data. 64 bytes from 140.117.11.1: icmp_seq=1 ttl=242 time=9.52 ms 64 bytes from 140.117.11.1: icmp_seq=2 ttl=242 time=9.17 ms 64 bytes from 140.117.11.1: icmp_seq=3 ttl=242 time=9.20 ms --- 140.117.11.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 9.172/9.298/9.521/0.176 ms
有需要的人可以測試看看了...
其實網路上有一些教學，但大多數的作法都是把 port 80 空出來跑認證用的 HTTP 伺服器，而我這邊的作法是希望維持 nginx，用 webroot local folder 的方式認證。
在 pfSense 上先安裝 acme 套件，然後先用 Create new account key 產生出自己的金鑰：
然後選擇申請 Let's Encrypt Production ACME V2 的帳號：
接著填一下 Name 的部份，按下 Register ACME account key 註冊後就可以按下 Save 存進系統。
然後就是拿這個帳號申請網域名稱，重點在於，如果選擇 webroot local folder 時，需要填寫對應的 RootFolder 參數 (這塊做得很怪，沒有預設值 XD)：
然後按下 Save 後存起來，回到頁面上就可以按 Issue/Renew 申請了，申請成功以後就可以到最上方 tab 的 System，在裡面的 Advanced 就可以改 HTTPS 管理界面使用的憑證，改好後把瀏覽器關掉重開就可以確認是不是有設定好...
看到「An adblocker for live radio streams and podcasts. Machine learning meets Shazam.」這個專案，這個把 machine learning 用到「正途」上了啊...
不過畢竟是比較複雜的演算法，會吃不少 CPU 資源：
On a regular laptop CPU and with the Python time-frequency analyser, computations run at 5-10X for files and at 10-20% usage for live stream.
不過看用法還是偏向 library 性質，如果要大力推廣可能還是需要有其他人包個更好的界面...
這算是 AWS 的保護機制，在 Amazon EC2 上能開的機器數量都是有限制的。
打算要用新的 vCPU 數量限制取代舊的 Instance 數量限制：「Using new vCPU-based On-Demand Instance limits with Amazon EC2」，然後現在可以先加入：「vCPU-based On-Demand Instance Limits are Now Available in Amazon EC2」。
這次改善的問題是，以往 m5.large 與 m5.xlarge 是兩個不同的限制，所以用起來會比較卡，現在則改成用 vCPU 來管理。
這次的架構是改成，一般性的機器會有一個 vCPU 數量限制，其他不同特性的各自有自己的 vCPU 數量限制：
In addition to now measuring usage in number of vCPUs, there will only be five different On-Demand Instance limits—one limit that governs the usage of standard instance families such as A, C, D, H, I, M, R, T, and Z, and one limit per accelerated instance family for FPGA (F), graphic-intensive (G), general purpose GPU (P), and special memory optimized (X) instances.
9/24 可以先手動加入，會拿你現在的量會換算過去，然後 10/24 會全部都轉過去：
During a transition period from September 24, 2019, through October 24, 2019, you can opt in to receive vCPU-based instance limits. When you opt in, EC2 automatically computes your new limits, giving you access to launch at least the same number of instances (if not more) than you do currently. Beginning October 24, 2019, all accounts will switch to vCPU-based instance limits, and the current count-based instance limits will no longer be supported. Although the switchover will not impact your ability to launch EC2 instances, you should familiarize yourself with the new On-Demand Instance limits experience and opt into vCPU limits at a time of your choosing.
應該是會方便一些...
在「A web performance issue」這邊講到 Mozilla 的系統產生效能問題，後續的 trouble shooting 以及解決問題的方案。
這個系統跑在 AWS 上，在一連串確認後發現是 RDS 所使用的 EBS 的 IOPS 滿了：
After reading a lot of documentation about Amazon’s RDS set-up I determined that slow downs in the database were related to IOPS spikes. Amazon gives you 3 IOPS per Gb and with a storage of 1 Terabyte we had 3,000 IOPS as our baseline. The graph below shows that at times we would get above that max baseline.
然後大家對於解法都差不多，因為 Provisioned IOPS 太貴，所以直接加大空間換 IOPS 出來 (因為 General SSD 裡 1 GB 給 3 IOPS)：
To increase the IOPS baseline we could either increase the storage size or switch from General SSD to Provisioned IOPS storage. The cost of the different storage type was much higher so we decided to double our storage, thus, doubling our IOPS baseline. You can see in the graph below that we’re constantly above our previous baseline. This change helped Treeherder’s performance a lot.
然後再設警告機制，下次就可以提前再拉昇：
In order to prevent getting into such a state in the future, I also created a CloudWatch alert. We would get alerted if the combined IOPS is greater than 5,700 IOPS for 6 datapoints within 10 minutes.
不過 General SSD 的 IOPS 是沒有 100% 保證的，只有這樣寫：
AWS designs gp2 volumes to deliver 90% of the provisioned performance 99% of the time.
大多數的情況應該是夠用啦...
在 AWS Management Console 上切換服務需要用到滑鼠，而這個 Userscript 工具提供了 / 快速鍵可以直接拉出服務選單，另外也可以用 Esc 鍵關閉服務選單：「AWS Web Console Service Shortkeys」。
這個套件應該是支援多個瀏覽器，但是需要先安裝 Tampermonkey 這類可以跑 Userscript 的套件。
主要是常常在切的時候發現需要拿滑鼠，寫了這個 script 後多了一個方式可以用，而不需要把手移開鍵盤，會順手一些...
不過還是希望這個功能直接變成內建的 :o
這次 Amazon EC2 更新了 G 系列的機器，其實會特地寫文章主要是在複習 P 系列與 G 系列的差異 (每次都記不起來到底哪個是給科學運算用的)：「Now Available – EC2 Instances (G4) with NVIDIA T4 Tensor Core GPUs」。
EC2 上的 GPU Instances 分成兩條線在發展，一條是 P 系列，另外一條是 G 系列，都是使用 Nvidia 的產品線。
從「Amazon EC2 Instance Types」這邊的「Accelerated Computing」可以看到每條產品線用了哪些型號 (扣掉 FPGA 的 F1)：
查了資料發現雖然時間點不同，但這四個都列在「Nvidia Tesla」這邊，裡面也沒有太多說明，所以還是看不出來差異，之後要碰到的時候再來還這個知識債好了...
uBlock Origin 在 2016 的時候 porting 到 Safari 上，但在 2018 後就沒有再更新了，維護者在「Explanation of the state of uBlock Origin (and other blockers) for Safari #158」這邊說明了目前的情況。
主要就是蘋果要廢掉本來的 Extension API，而替代的框架裡沒有對應的 content filtering 能力，所以在新的框架內無法實做 uBlock Origin 的功能...
維護者的建議是換瀏覽器，但其實可以選擇的瀏覽器愈來愈少了 (因為 Google Chrome 這邊也在搞)，所以維護者的建議就是換成 Firefox。
另外我自己會建議用看看 Brave，因為 Brave 已經決定，如果 Google Chrome 修改 webRequest 的阻擋能力 (也就是這次的 Manifest V3)，他們會繼續維持本來的相容性，所以可以預期 uBlock Origin 應該還是會動 (參考之前寫的「Brave 試用」這篇)。
Amazon S3 推出了 Same-Region Replication：「Amazon S3 introduces Same-Region Replication」。
先前的功能只有 Cross-Region Replication，可以當作異地備份的功能，現在則是推出讓同一區也可以複製...
不過就這個功能的目標來說，看起來主要是避免被刪除而已？因為還是同一個區域。另外就是公司內因為組織架構的問題，也有可能會用這個功能...
Replicated objects can be owned by the same AWS account as the original copy or by different accounts, to protect from accidental deletion.