幹壞事是進步最大的原動力
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。
透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試，大約是從 10ms 變成 40ms)，但可以讓 ISP 看不到你查詢什麼，對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS)，但一直沒看到，結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。
Stubby 在 Ubuntu 18.04 上可以直接裝，但在 Ubuntu 16.04 上需要透過 PPA 裝，我是透過「DNS Utils : James Newell」這個安裝的，裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成：
upstream_recursive_servers:
- address_data: 1.1.1.1
tls_auth_name: "cloudflare-dns.com"
- address_data: 1.0.0.1
tls_auth_name: "cloudflare-dns.com"就可以走 port 853 的 DNS over TLS 了，而 Stubby 預設會聽 127.0.0.1 與 ::1 的 port 53，所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。
目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate)，Stubby 看起來只能用 tls_pubkey_pinset 鎖住，但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate)，之後看看有沒有可以吃 Root CA 架構的認證再來調整...
在 Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去，但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況，用的時候自己要注意。
另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來，但有 workaround 可以硬裝進去，要玩的人也可以參考一下 XD
這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04，做一些操作時才發現是 14.04...)
想用 CRON_TZ 這個變數但發現系統不支援 XD
找資料的時候發現一堆奇怪的文章，像是說可以在 Ubuntu 上用 apt install cronie 這種指令安裝 cronie 的，不知道他到底是用什麼系統... (參考「Debian -- Package Search Results -- cronie」與「Ubuntu – Package Search Results -- cronie」，應該是沒出現過？)
在 man cron 時可以看到 Ubuntu 還是用 Vixie Cron，而在 Launchpad 上可以看到，在 2009 年有人提案想要換成 cronie，但一直都沒有下文：「Replace (vixie) cron with cronie」，這麼久完全沒動靜，這大概沒救了 XD
還是乖乖的照 UTC 設吧，只是這樣 Trac 開票的時間好像不太好搞...
本來有做 dehydrated 的 PPA (在「PPA for dehydrated : Gea-Suan Lin」這邊)，後來在 17.10+ 就有更專業的人包進去了 (參考「Ubuntu – Package Search Results -- dehydrated」)，為了避免名稱相同但是內容物差很多，我把 PPA 的名字換成 dehydrated-lite 了 (參考「PPA for dehydrated (lite) : Gea-Suan Lin」)。
然後 0.6.2 的 dehydrated 針對 ACMEv2 有修正，這在 0.6.1 時會產生 certificate 裡有多餘資訊 (而 PPA 版的 gslin/dehydrated 只會停留在 0.6.1)，這點需要注意一下：
Don't walk certificate chain for ACMEv2 (certificate contains chain by default)
之後再找機會拔掉 gslin/dehydrated，也許會照著現在 APT 內的架構來做...
Ubuntu 兩年一度的 LTS 版本在前幾天放出來了，18.04 版的 code name 為 Bionic Beaver，官方有發出一篇介紹文章「Breeze through Ubuntu Desktop 18.04 LTS Bionic Beaver」，而下載可以在「Ubuntu 18.04 LTS (Bionic Beaver)」這邊抓。
因為不少新功能的穩定性沒跟上這次的 LTS (像是想要用 Wayland 換掉 X.org)，所以目前看到的改變沒有想像中的大...
最主要的改變應該是不再提供 i386 版本，不過 x86-64 (AMD64 & Intel 64) 推出都已經超過十年了，加上要使用超過 4GB RAM 應該都會裝 x86-64 版本 (有人用 PAE 撐著嗎？)，所以只要不是古董應該都沒問題...
另外一個則是預設從 Unity 換成 GNOME 了，用 Unity 已經算很習慣了，不知道之後換過去會有什麼感想... (到時再寫好了)
預定等一個版本再來換 (i.e. 18.04.1)，現在不想當白老鼠 XD 不過手上一些 PPA package 要先 porting 過去...
Twitter 上看到這則 tweet，Let's Encrypt 正式開放 Wildcard Certificate 了：
Let's Encrypt wildcard certificates and ACMEv2 are available today! More information can be found here: https://t.co/0SdH98Oabn
— Let's Encrypt (@letsencrypt) March 13, 2018
參考「ACME v2 and Wildcard Certificate Support is Live」這邊的說明，裡面有提到 Wildcard Certificate 需要有 ACMEv2 的 client：
Wildcard certificates are only available via ACMEv2. In order to use ACMEv2 for wildcard or non-wildcard certificates you’ll need a client that has been updated to support ACMEv2. It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet.
翻了一下「ACME Client Implementations」，我常用的 dehydrated 也支援 ACMEv2 了，而且剛好前幾天我更新了 PPA (參考「PPA for dehydrated : Gea-Suan Lin」)，把最新版 (0.5.0 後的 6e802dd) 包進去了，等下來測試看看要怎麼玩 XDDD
然後我之後打算把 letsencrypt.tw 的資料改丟到我的 Wiki 上，這樣改起來比較簡單...
剛剛收到信看到 Ubuntu 16.04.4 LTS 出版：「Ubuntu 16.04.4 LTS released」，與上個版本 Ubuntu 16.04.3 LTS 比較完整的差異可以在「XenialXerus/ReleaseNotes/ChangeSummary/16.04.4 - Ubuntu Wiki」這邊看到。
如果照慣例，這應該會是倒數第二個 16.04 的版本，在 18.04 推出後會推最後一包 Ubuntu 16.04.5 LTS。不過這也只是慣例而已... (從 12.04 之後都照這個方式在走)
看到「RFC: Ubuntu 18.04 LTS Minimal Images」這篇，在蒐集將來要出的 Ubuntu 18.04 LTS Minimal Image 的意見...
The Ubuntu Minimal Image is the smallest base upon which a user can apt install any package in the Ubuntu archive.
雖然應該還會有改變，不過以目前的版本來看，可以看出壓縮前後兩種版本都比 16.04 小了不少：
對需要這些 image 的人來說 (像是當作 Docker 的 base image)，小一點操作起來也比較開心...