看到這則 tweet，提到 Java 的支援度：
We've released version 2.0.0 of Java Is Still Free (https://t.co/VvAPtBYE1C) - giving you a full and balanced view of the #java and #openjdk choices you have going forwards, including commercial support, $free and free to use - read it today!
— Java Champions (@Java_Champions) March 3, 2019
主要是裡面有張圖列出了目前市場上有的選擇，可以當關鍵字來查：
目前看起來如果要 Java 8 只有三個方案，其中有過 TCK 的只有兩個，看起來用 Amazon Corretto 算是個還不錯的選擇？
Percona 在過節前推出 Percona Server for MySQL 8.0 了：「Announcing General Availability of Percona Server for MySQL 8.0」。
在 Oracle 版的 MySQL 8.0 多了不少功能，像是往 NoSQL 靠的功能與 GIS 相關的功能，但讓我注意到的是 Percona 自己的事情... TokuDB 因為 MyRocks 而要被放生了：
Features Being Deprecated in Percona Server for MySQL 8.0
TokuDB Storage Engine: TokuDB will be supported throughout the Percona Server for MySQL 8.0 release series, but will not be available in the next major release. Percona encourages TokuDB users to explore the MyRocks Storage Engine which provides similar benefits for the majority of workloads and has better optimized support for modern hardware.
在 Hacker News Daily 上看到「VirtualBox E1000 Guest-to-Host Escape」這篇，講 VirtualBox 5.2 的機器上 E1000 + NAT 模式的爆破... 另外在 Hacker News 上的討論也提到了很多這樣做的背景：「VirtualBox E1000 Guest-to-Host Escape | Hacker News」。
Oracle 對社群的態度 (無論是 open source community 或是 security community) 都一直是社群很不爽的事情。
這次爆破的發現人之前找到一個 VirtualBox 的 security bug (參考「SSD Advisory – VirtualBox VRDP Guest-to-Host Escape」)，回報後先是回應他們在處理中，然後被發現 VirtualBox 在 5.2.18 修掉了，但是完全沒有提到安全性問題的事情。所以這次作者也懶得囉唆了，找到就 full disclosure 出來。
作者給的 workaround 有兩個，優先建議暫時先用 PCnet 系列的界面，如果不行的話，至少不要用 NAT。
作者發表後沒多久馬上就有 5.2.22 推出，不過看 changelog 應該是沒有修正這個問題？(或是修掉又沒提...)
Percona 的 CTO Vadim Tkachenko 在比較 InnoDB 與 MyRocks 時意外發現了 binlog 會影響不少效能穩定性，再加上 MySQL 8.0 有改變 binlog 相關的預設值，所以他後續花了不少時間測試，寫了兩篇關於 binlog 對於 MySQL 效能的影響：「How Binary Logs (and Filesystems) Affect MySQL Performance」與「How Binary Logs Affect MySQL 8.0 Performance」。
第一篇是想要知道在 Percona Server 5.7 上開 binlog 的影響，做出來後可以看到明顯的效能波動 (因為 binlog 導致 flush 時效能暴跌)：
而其中的 workaround 就是調整 flush 參數，讓他比較頻繁的小量寫入，而不是突然要寫很多資料。這樣一來對平均效能也許比較差，但對前端應用衝擊會比較小：
在測試可以看到 sync_binlog=1000 是個妥協點。各單位要自己去找出適合的數字：
The strict setting also comes with noted performance penalties. I will also test sync_binlog=1000 and sync_binlog=10000, which means perform synchronous writes of binary logs every 1000 and 10000 transactions, respectively.
另外有測試 ext4 與 XFS 是否有影響，就測試的結果看起來 ext4 比 XFS 好一些，但差距有限：
第二篇則是拿 MySQL 8.0 與 Percona Server 5.7 比較，可以發現在 MySQL 8.0 開啟 binlog 時有時會有不少的效能損失：
It seems that binary logs have quite an effect MySQL 8.0, and we see up to a 30% performance penalty as opposed to the 13% for Percona Server for MySQL 5.7.
雖是推銷一下自家產品在這塊還不錯 XD
Twitter 上看到 Oracle 計畫在 MySQL 內包入 GraalVM：
Wooooow ! Stored programs in @MySQL in different languages thanks to @graalvm #perconalive pic.twitter.com/NTDa3vHLyn
— lefred (@lefred) April 25, 2018
#MySQL MLE [ˈɛmɪlɪ] @graalvm in @MySQL 8.0 #perconalive pic.twitter.com/PVNrcbJL8q
— lefred (@lefred) April 25, 2018
這能不能解決 MySQL 的 stored procedure 一直以來都很殘的問題就要多花些時間看看了... 另外 GraalVM 用 GPLv2，但沒有明確的專利授權條款也是大家很在意的問題 (參考 Hacker News 上「GraalVM: Run Programs Faster Anywhere | Hacker News」這邊的討論)，因為大家都很清楚，這家公司只要是沒有授權的東西就不要碰...
話說 Percona 都把 PostgreSQL 包進來吃了，來考慮多用用 PostgreSQL 好了... (把 blog 換掉？)
Oracle 推出了 MySQL 8.0 (GA，General Availability)：「MySQL 8.0 – Announcing GA of the MySQL Document Store」。在「What’s New in MySQL 8.0? (Generally Available)」這邊也花了一些篇幅介紹 MySQL 8.0 的新功能。
比較感興趣的是：
不過就實用性來說，效能的提昇還是最直接的... 接下來等 Percona 的人 porting 了。
Percona 介紹了 MySQL 8.0 將會推出的 innodb_dedicated_server 參數：「New MySQL 8.0 innodb_dedicated_server Variable Optimizes InnoDB from the Get-Go」，Oracle 官方的文件在「15.6.13 Enabling Automatic Configuration for a Dedicated MySQL Server」這邊可以翻到。
這是針對整台機器完全給 MySQL 用的情況所設計的參數。在這種情況下，可以透過 RAM 的大小以及一些簡單的公式，得到還算堪用的系統參數...
依照說明，可以看到系統會依照記憶體的大小自動計算出 innodb_buffer_pool_size、innodb_log_file_size 這兩個參數，並且把 innodb_flush_method 設為 O_DIRECT_NO_FSYNC (如果所在平台有支援這個值)。
不過看了一下公式，依照經驗可以設的更積極一點... 像是 Percona 文章裡提到的，當記憶體夠大時，其實可以考慮從 80% 開始調整大小 (innodb_buffer_pool_size)：
For InnoDB buffer pool size (based on this article), consider allocating 80% of physical RAM for starters. You can increase it to as large as needed and possible, as long as the system doesn’t swap on the production workload.
而 innodb_log_file_size 則應該要分析寫入的 pattern 而不是直接看 RAM 大小。有些機器雖然很大台但幾乎沒有寫入的量，照著公式的值就偏大很多：
For InnoDB log file size, it should be able to handle one hour of writes to allow InnoDB to optimize writing the redo log to disk. You can calculate an estimate by following the steps here, which samples one minute worth of writes to the redo log. You could also get a better estimate from hourly log file usage with Percona Monitoring and Management (PMM) graphs.
不過基本上 tune 出來的值還算堪用，對於剛入手的人頗有幫助。
1998 年就發現的 security issue 因為 workaround 也很複雜，所以不是每一家都修對方法，於是 19 年後又被爆破了。這次叫做 ROBOT：「1998 attack that messes with sites’ secret crypto keys is back in a big way」。
可以看到中獎的表：
這次的攻擊在 client 端無法修正，只能在 server 端修正：
Do I need to update my browser?
No. This is an implementation bug in servers, there is nothing clients can do to prevent it.
如果 server 端無法盡快修正的話，想辦法避開 RSA encryption 可以躲開這個問題，而且因為現代瀏覽器都有非 RSA 的替代方案，這樣做應該都還有退路，可以維持連線的可能性：
Disable RSA encryption!
ROBOT only affects TLS cipher modes that use RSA encryption. Most modern TLS connections use an Elliptic Curve Diffie Hellman key exchange and need RSA only for signatures. We believe RSA encryption modes are so risky that the only safe course of action is to disable them. Apart from being risky these modes also lack forward secrecy.
但使用 Cisco ACE 就哭了，因為 Cisco ACE 只支援 RSA encryption，而 Cisco 官方以產品線已經關閉，不再提供維護而沒有提供更新的計畫，所以就進入一個死胡同...
不過 Cisco 自己也還在用 Cisco ACE 就是了，不在意就不會痛的感覺 XD
I have a Cisco ACE device.
Cisco informed us that the ACE product line was discontinued several years ago and that they won't provide an update. Still, we found plenty of vulnerable hosts that use these devices.These devices don't support any other cipher suites, therefore disabling RSA is not an option. To our knowledge it is not possible to use these devices for TLS connections in a secure way.
However, if you use these products you're in good company: As far as we can tell Cisco is using them to serve the cisco.com domain.
看到「That time Larry Ellison allegedly tried to have a professor fired for benchmarking Oracle」這篇文章的講古，想起很久前就有聽過 Microsoft 有這樣的條款 (禁止未經原廠同意公開 benchmark 結果)，原來是 Oracle 在三十幾年前創出來的？而且這種條款還有專有名詞「DeWitt Clauses」，出自當初被搞的教授 David DeWitt...
Microsoft 的條款是這樣：
You may not disclose the results of any benchmark test … without Microsoft’s prior written approval
Oracle 的則是：
You may not disclose results of any Program benchmark tests without Oracle’s prior consent
IBM 的反而在 license 裡面直接允許：
Licensee may disclose the results of any benchmark test of the Program or its subcomponents to any third party provided that Licensee (A) publicly discloses the complete methodology used in the benchmark test (for example, hardware and software setup, installation procedure and configuration files), (B) performs Licensee’s benchmark testing running the Program in its Specified Operating Environment using the latest applicable updates, patches and fixes available for the Program from IBM or third parties that provide IBM products (“Third Parties”), and © follows any and all performance tuning and “best practices” guidance available in the Program’s documentation and on IBM’s support web sites for the Program…
Amazon RDS 的升級：「Amazon RDS Now Supports Database Storage Size up to 16TB and Faster Scaling for MySQL, MariaDB, Oracle, and PostgreSQL Engines」。
空間上限從 6TB 變成 16TB，而且可以無痛升。另外 IOPS 上限從 30K 變成 40K：
Starting today, you can create Amazon RDS database instances for MySQL, MariaDB, Oracle, and PostgreSQL database engines with up to 16TB of storage. Existing database instances can also be scaled up to 16TB storage without any downtime.
The new storage limit is an increase from 6TB and is supported for Provisioned IOPS and General Purpose SSD storage types. You can also provision up to 40,000 IOPS for Provisioned IOPS storage volumes, an increase from 30,000 IOPS.
不過隔壁的 Amazon Aurora 還是大很多啊 (64TB)，而且實際上不用管劃多大，他會自己長大：
Q: What are the minimum and maximum storage limits of an Amazon Aurora database?
The minimum storage is 10GB. Based on your database usage, your Amazon Aurora storage will automatically grow, up to 64 TB, in 10GB increments with no impact to database performance. There is no need to provision storage in advance.