幹壞事是進步最大的原動力
雖然 GitHub 有提供 license 相關的 API 可以查，但因為準確度不高 (只要稍微改到，GitHub 就無法偵測到正確的 license)，所以有人決定用 machine learning 的方式另外分析：「Detecting licenses in code with Go and ML」。當然這邊是分析公開的部份：
最大包的是 MIT License，次之是 Apache-2.0 (問號那群先不管)，再來是 GPL 家族的各版本。沒有太特別的意外發生...
Google 發表了 gVisor，針對 Linux 所使用的 container 技術強化安全的部份：「Open-sourcing gVisor, a sandboxed container runtime」。
依照 Google 的說法，一般 container 的架構是這樣：
而具有強隔離性的 VM 技術則是這樣：
在 VM 的 overhead 偏重，但一般的 container 安全性又不夠。而 gVisor 則是這樣：
對於目前最常見的 Docker 系統上，在安裝 gVisor 後只需要指定 --runtime=runsc 就可以使用 (預設是 --runtime=runc)，像是這樣：
$ docker run --runtime=runsc hello-world $ docker run --runtime=runsc -p 3306:3306 mysql
其中 runsc 的意思是「run Sandboxed Container」。
另外而因為 gVisor 卡在中間，不認識的 syscall 都會被擋下來，所以目前並不是所有的應用程式都可以跑，但開發團隊已經測了不少應用程式可以在上面運作，算是堪用的程度：
gVisor implements a large part of the Linux system API (200 system calls and counting), but not all. Some system calls and arguments are not currently supported, as are some parts of the /proc and /sys filesystems. As a result, not all applications will run inside gVisor, but many will run just fine, including Node.js, Java 8, MySQL, Jenkins, Apache, Redis, MongoDB, and many more.
看到有人實做 Seam Carving (接縫裁剪) 了，用 Golang 寫的，放在 GitHub 的 esimov/caire 這邊，副標題「Content aware image resize library」。實做了「Seam Carving for Content-Aware Image Resizing」這篇論文。
Seam Carving 指的是知道內容的 resize，像是把上面這張變成下面這張：
或是變大：
馬上可以想到的應用是需要保留資訊內容，但又想要大量提供資訊的地方，像是 Nuzzle 的縮圖 (或是以前的 Zite)，或是網路新聞媒體的首頁所用的縮圖。不知道還有沒有其他地方可以用...
AWS Lambda 要支援 Golang 的資訊在官網上沒看到消息，但是 Twitter 上看到現場的照片提到了 Golang：
"...and Go" native support in AWS Lambda @Werner AWS #reInvent pic.twitter.com/M8FuJKWYkh
— Eric Hammond (@esh) November 30, 2017
再來等看看吧... 看起來還沒支援，只是先放話？
Cloudflare 測試 ARM 新的伺服器 (是由 Qualcomm 與 Cavium 提供工程樣品給 Cloudflare 測試)：「ARM Takes Wing: Qualcomm vs. Intel CPU comparison」。
原文有很多測試數據，可以看出來跟以前比起來好很多。系統程式的效能都還不錯，跟 Intel 平台各有輸贏，但 Go 對 ARM 的最佳化好像不太好，有點慘...
不過這樣至少表示了有機會互拼，如果考慮電力使用情況，加上這還是工程樣板的話，應該是可以拉板凳了？
CockroachDB 推出 1.0 版：「CockroachDB 1.0 is Production-Ready」。CockroachDB 是希望在分散式環境裡打造出有 ACID 特性的服務，這點類似於 Google 的 Spanner 架構。
整個系統主要是用 Go 寫成，支援 PostgreSQL 協定，這讓許多現成的應用可以接上去：
Use existing PostgreSQL client drivers or supported ORMs.
而另外一邊有支援 MySQL 協定的 TiDB (剛好也是用 Go 寫的)，整個 NewSQL 領域東西愈來愈多了...
在「zetcd: running ZooKeeper apps without ZooKeeper」這邊介紹了用 etcd 當作 ZooKeeper 伺服器。程式碼在「Serve the Apache Zookeeper API but back it with an etcd cluster」這邊可以看到。
不過可以看到有不少 overhead：
但 etcd 用 Go 寫 (省下 JVM tuning？)，可能是個不錯的誘因...
Dgraph 在推銷自家發展出來的 Badger：「Introducing Badger: A fast key-value store written natively in Go」。
標靶是 RocksDB，號稱比 RocksDB 快好幾倍：
Based on benchmarks, Badger is at least 3.5x faster than RocksDB when doing random reads. For value sizes between 128B to 16KB, data loading is 0.86x - 14x faster compared to RocksDB, with Badger gaining significant ground as value size increases. On the flip side, Badger is currently slower for range key-value iteration, but that has a lot of room for optimization.
不過我覺得有些重要的功能在 Badger 不提供，這比起來有種橘子比蘋果的感覺... 像是 RocksDB 提供了 Transaction，而 Badger 則是直接講明他們不打算支援 Transaction：
Keep it simple, stupid. No support for transactions, versioning or snapshots -- anything that can be done outside of the store should be done outside.
Google 放出 Grumpy，可以把 Python 2.7 的程式碼轉成 Go：「Grumpy: Go running Python!」。
下面看到一個留言頗有趣的：
This sad to see that Grumpy is mean to be a replacement of CPython 2.7 instead of CPython 3.x . I presume the code from youtube was written in python 2.x hence the reason but I hope we'll see Grumpy supporting python 3.x :)
回到原文，這次的需求主要是出自 YouTube 的需求：
The front-end server that drives youtube.com and YouTube’s APIs is primarily written in Python, and it serves millions of requests per second! YouTube’s front-end runs on CPython 2.7, so we’ve put a ton of work into improving the runtime and adapting our application to work optimally within it.
然後 Python 的 GIL 又被拿出來鞭屍：
除了 C extension 不支援外，還是有些「過於動態」的語法不支援：
exec,evalandcompile: These dynamic features of CPython are not supported by Grumpy because Grumpy modules consist of statically compiled Go code. Supporting dynamic execution would require bundling Grumpy programs with the compilation toolchain which would be unwieldy and impractically slow.
這樣可用的範圍少不少，這個專案可以當作 YouTube 這種規模的網站所做的改善，而不是什麼可以拿來用的工具 :o
Cloudflare 這次閏秒炸掉：「How and why the leap second affected Cloudflare DNS」，影響範圍包括了 DNS query 與 HTTP request：
At peak approximately 0.2% of DNS queries to Cloudflare were affected and less than 1% of all HTTP requests to Cloudflare encountered an error.
主要的原因在於 Go 的 time.Now() 不保證遞增：
RRDNS is written in Go and uses Go’s time.Now() function to get the time. Unfortunately, this function does not guarantee monotonicity. Go currently doesn’t offer a monotonic time source (see issue 12914 for discussion).
修正的方式是針對時間回朔時處理：
In this patch we allowed RRDNS to forget about current upstream performance, and let it normalize again if time skipped backwards.
應該是因為 Cloudflare 這段程式還沒遇過 leap second 造成的...