這對 server-side 的開發者也很傷，本來 build docker image 已經是跑在 VM 裡了，現在 VM 變成要用 Arm emulate x86。
追更新都是被迫的，k8s 生命週期太短
看樣子會有 Yearly Support，算好消息。因為哪有人幾個月就升一次 cluster，k8s 的人自己都不架站才會有這種白吃決定。
但還看不出會 support 多久。LTS 少說也要三年吧
短期內沒救了
但可以像 thunderbolt 一樣, 就另外取個名字和 logo. 雖然接頭一樣但找線的時候會多注意一下這個規格
不要什麼都叫 usb c, 還有 gen 1 gen 2 根本是來亂的
2 月時的整理，還不錯的參考
6 月的現在各家支援的 k8s 版本又升了一些 (才幾個月就變天, k8s 更新的太快了)
最近比較大條的新聞是 GKE master plan 現在要錢。還有升到 1.16 版時會遇到一堆舊的 API 被移除
k8s 一大部份的複雜度來自於管理 control plane，不過大部份的人都還是給 cloud 管吧。
我自己則是 k3s 越架越多台，一個指令一個 binary 就裝好了，單機很好用，有那種 vagrant up 的爽度。
quote from hn:
ridruejo [–]
It makes a bit more sense if you see Kubernetes as the new Linux: a common foundation that the industry agrees on, and that you can build other abstractions on top of. In particular Kubernetes is the Linux Kernel, while we are in the early days of discovering what the "Linux distro" equivalent is, which will make it much more friendly / usable to a wider audience
他是說以前一定要寫 finally 去回溯/移除 自己放在 ThreadLocal 的變數，因為 Thread 多半有 pool，是大家共用的。
之後用 virtual thread 就沒人在共用了，所以 ThreadLocal 不用怕碰到別人塞的值，也不用 finally 去處理。
而你講的 sharing 是該 thread 被用的當下，很多人都想塞變數，這個的確沒變，要靠 Scope Variable 的結構減少忘記互蓋的問題。
Even basic control flow, like loops and try/catch, need to be reconstructed in “reactive” DSLs, some sporting classes with hundreds of methods.
RxJava 就是你
一個 class 有上百個 method 就是錯錯錯，沒什麼好說的
能夠寫正常的程式的話，誰要寫 reactive，誰要寫 async/await
Project Loom 走在正確的道路上，成功後就會換其他平台來學