我的 Ubuntu 桌機在登入後的螢幕設定是這樣，設定在 ~/.config/monitors.xml 裡：
但登入時還是預設值 (四個螢幕都是打橫的)，雖然只是輸入個密碼沒有什麼大礙，但還是想找個方法讓登入畫面吃到正確的 monitors.xml。
查了文件在「Fixing Ubuntu’s Login Resolution」這邊發現 Ubuntu 16.04 (Unity) 是用 LightDM，在登入畫面是透過 lightdm 權限在跑，所以去 ~lightdm/.config/monitors.xml 下設定就可以了，如果用 symbolic link 的話要注意權限的問題。
不小心搞爛的話，可以用 Ctrl-Alt-F1 切到 command line 下登入修正...
在 Twitter 上看到 Ondřej Surý 因為得到協助 (包括 Microsoft)，所以會繼續支援 PHP 5.6 與 PHP 7.0 的 PPA 更新：
PHP 5.6 and PHP 7.0 will stay (for now): https://t.co/iMkbVQdn5x
// Big kudos to @RemiCollet and @weltling for backporting the security fixes for EOL versions of PHP in @Microsoft @github repository: https://t.co/IWRJHlDFqo
— DEB SURY ORG (@debsuryorg) March 8, 2019
在「PHP 5.6 and PHP 7.0 will stay (for now)」裡面有提到這是 best effort，沒有保證會維持多久：
Please note that this is based on best effort and without any warranty.
對於還在這兩個版本掙扎的人再多了一些時間...
前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞，但沒讀完就一直放著沒寫：「Remote Code Execution in apt/apt-get」。
漏洞出在實作上的問題，對於 HTTP 重導的程式碼沒有處理好外部字串，在還沒修正的機器上用這個指令關閉 redirect，避免在修正的過程反而被 RCE 打進去：
sudo apt update -o Acquire::http::AllowRedirect=false sudo apt upgrade -o Acquire::http::AllowRedirect=false
但也不是 HTTPS 就能避免這個問題，因為 HTTPS 連線用的程式碼又是另外一份，裡面不知道有沒有問題 (像是之前經典的 Heartbleed)，所以應該還是會繼續爭吵吧...
居然有個獨立的網站在說明：「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護，但會使得維護的複雜度變高很多。
首先是被竄改的問題，APT 本身就有簽名機制 (參考「SecureApt」)，即使 mirror site 被打下來也無法成功竄改內容，反而比起單純的 HTTPS 保護還好。
而對於隱私問題，由於內容是可以公開取得的，這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法)，加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高)，所以隱私的保護上其實有限。
而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack)，APT 降低風險的解法是把時間簽進去，當用戶端發現太久沒更新時，就當作過期失效而提出警告。
就以上來看，把所有的 APT 伺服器都加上 HTTPS 的工程太浩大，而得到的效益太小。所以願意提供 HTTPS 的站台就提供，但主要的保護還是從本來的 SecureApt 機制上提供。
在 Mac 上還蠻常直接在 Spotlight 上打簡單的算式看計算的結果，但我的桌機是在 Ubuntu 上，沒看到這個功能，所以都是用 search engine 幫忙算 (以前是 Google，現在是 DuckDuckGo)，但還是想要找個類似的東西看看能不能在本機處理掉...
後來在「Can you get something like Unity Dash--especially the instant calculator--in other distros?」這邊看到 screenshot 的效果應該就是我想要的：
不過發現預設好像不會開 (跟文章裡面提到的不太一樣)，所以又找了一段時間，發現在「How to permanently enable in-dash calculator in 13.10」這邊，River Satya 提到的方式是我要的：
sudo apt install dconf-editordconf-editorinfo-calculator.scope to the always-search list改完後就會像 screenshot 出現了...
之前用 HiNet 固定制 (不需要 PPPoE，直接設 IP 就會通的那種)，跑起來順順的也沒麼問題，最近剛好合約滿了就打算換成非固定制 (需要撥 PPPoE 才會通)，結果換完後發現有些網站常常連不上 (不是一直都連不上)，但只要設了 proxy.hinet.net (今年年底要停止服務了) 或是改從 cable 線路出去就正常。
測了不少設定都沒用 (像是改 tcp timestamp 設定，或是 sack 之類的設定)，後來發現 MTU 的值不太對，用 ifconfig 看發現我的 ppp0 是 1500 而不是 1492，直接先 ifconfig ppp0 mtu 1492 改下去測，發現本來不能連的網站就通了...
(補充一下，我看了 Windows 的設定是 1480，所以也沒問題，但不知道怎麼算的...)
查了一下 MTU 相關的問題，發現在「wrong mtu value on dsl connection」這邊有討論到。裡面提到的 workaround 是到 /etc/NetworkManager/system-connections/ 裡找出你的 PPPoE 設定檔，然後在 ppp 區域的裡面寫死 mtu 參數：「mtu=1492」(這邊的 1492 是從 1500 bytes 扣掉 PPPoE 的 8 bytes 得出來的)，不過我測試發現在修改設定檔時會被改回來，加上測試發現沒用，只好自己寫一個 /etc/network/if-up.d/pppoe-mtu 惡搞了：
#!/bin/sh -e
if [ "$IFACE" != "ppp0" ]; then
exit 0
fi
/sbin/ifconfig ppp0 mtu 1492放進去後要記得 chmod 755。
從 ticket 上面看起來還是沒有解 (2009 年就發現了)，看起來 PPPoE 不是絕對多數而且又有 workaround，短期應該不會修正...
先前在『在 AWSUG Taiwan 上講的「用 AWS CodeDeploy 解決程式佈署」』這邊有分享過 CodeDeploy 在 Ubuntu 18.04 下 codedeploy-agent 會認為系統內建的 ruby 是 codedeploy-agent 不支援的版本：「Support for ruby 2.5 (Ubuntu 18.04) · Issue #158 · aws/aws-codedeploy-agent」。
剛剛總算看到修正後的版本被推出去了：
這樣就不需要自己修正惡搞了...
看到 Travis CI 的「Ubuntu Xenial 16.04 is available!」這篇讓人痛哭流涕啊... 五年的支援期偷已經過了兩年半，總算想起來要推出了 16.04 的 image 了？還是是因為 14.04 剩不到半年？不然好像很有可能繼續撐...
下一次要出 18.04 又是兩年後了嗎...
Ubuntu 14.04 是 LTS 版本，在明年四月底 (也就是 2019 年四月) 將會滿五年的維護期，之後就不會有任何公開更新了 (包括安全性更新)。
在前一次的 Ubuntu 12.04 是第一次提供 ESM (Extended Security Maintenance) 服務，讓沒辦法即時轉及到新版的單位可以付費繼續收到安全性更新，算是 LTS 的一個重要服務。
而官方這次也對 Ubuntu 14.04 推出了 ESM：「Announcing Extended Security Maintenance for Ubuntu 14.04 LTS – “Trusty Tahr”」。
Ubuntu 14.04 LTS – ESM will become available once Ubuntu 14.04 reaches its End of Life on April 30, 2019.
價錢應該會跟之前類似吧...
TCP BBR 是 Google 發表的 TCP congestion control 演算法，是一個純伺服器端就能夠改善 TCP 壅塞處理的機制。在 Linux Kernel 4.9 之後被納入了。
而 Spotify 有大量資料要傳到使用者端 (像是音檔)，剛好是 TCP BBR 改善的對象之一，實際測試後得到了很不錯的改善數據：「Smoother Streaming with BBR」。
Spotify 公佈的資料沒有提到平台，所以先稍微了解一下他的音質，也就是「Audio settings」這篇。
在 Desktop 是 160kbps/320kbps Ogg (Standard/HQ)。在 Web Player 則是 128kbps/256kbps AAC (Standard/HQ)。
行動平台部份比較複雜，在 iOS 上是 96kbps/160kbps/256kbps Ogg (Normal/High/Extreme)，另外有 Automatic 自動調整的設定。在 Android 平台則是 24kbps HE-AACv2 (Low) 與 96kbps/160kbps/320kbps Ogg (Normal/High/Very high) 以及 Automatic。
而最後 Chromecast 則是 128kbps/256kbps (Standard/Premium)。
測試時可以發現 shutter (指跟不上播放速度) 的情況降低了 6%～10%，而且下載速度增加了 5%～7% (對於慢速的裝置改善更多，10%～15%)：
Taking daily averages, stutter decreased 6-10% for the BBR group. Bandwidth increased by 10-15% for the slower download cohorts, and by 5-7% for the median. There was no difference in latency between groups.
而各地區的差異也可以看出來改善很多：
另外他們在測試時，剛好遇到秘魯的機房連外發生問題，結果意外發現 BBR 還是可以穩定在這種網路環境下運作：
In Peru, the non-BBR group saw a 400-500% increase in stutter. In the BBR group, stutter only increased 30-50%.
In this scenario, the BBR group had 4x bandwidth for slower downloads (the 10th percentile), 2x higher median bandwidth, and 5x less stutter!
在 Ubuntu 18.04 上可以直接設定 BBR，在 Ubuntu 16.04 則可以參考「Ubuntu 16.04 用 speedtest-cli 測試 TCP BBR 效能」這篇的方式升級 kernel 後設定 BBR。