Google 與 AWS 都釋出往 OpenTelemetry 靠攏的消息

前幾天看到 GoogleAWS 都釋出往 OpenTelemetry 靠攏的消息:「OpenTelemetry's First Release Candidates」以及「Public Preview – AWS Distro for OpenTelemetry」。

AWS 這邊的 AWS X-Ray 看起來跟 OpenTelemetry 有點關係,找了一下果然發現之前有些計畫在跑:「AWS X-Ray SDK w/ OpenTelemetry API」,不過看起來後續應該是由「AWS Distro for OpenTelemetry」這個計畫接手了。

另外 Google 這邊看起來則是 Cloud Trace 這個產品線,本來在推的 OpenCensusOpenTracing 從網站上可以看到決定會再支援兩年,但重心會改放到 OpenTelemetry 上:

OpenCensus and OpenTracing have merged to form OpenTelemetry, which serves as the next major version of OpenCensus and OpenTracing. OpenTelemetry will offer backwards compatibility with existing OpenCensus integrations, and we will continue to make security patches to existing OpenCensus libraries for two years.

翻了一下 Azure 相關的消息,先前有一些稿子是會往 OpenTelemetry 支援,但這一波沒看到新聞稿...

Debian 資助 PeerTube 發展

看到「Debian donation for Peertube development」這則消息,Debian 決定資助 10K 歐元提供給 PeerTube 發展。

不過更大的幫助應該是 PR 上的部份,這帶出來的曝光度以及「認可」的部份比 10K 歐元重要的多。

回到 Debian 決定資助的原因,是因為 DebConf20 需要一個非封閉式平台的直播架構,而 PeerTube 看起來很適合這個情境:

This year's iteration of the Debian annual conference, DebConf20, had to be held online, and while being a resounding success, it made clear to the project our need to have a permanent live streaming infrastructure for small events held by local Debian groups. As such, Peertube, a FLOSS video hosting platform, seems to be the perfect solution for us.

前幾天在「有風聲說司法部會把 Chrome 拆出 Google」這邊有提到 YouTube 很難取代的問題,這個算是其中的一個方向,試著在解決平台壟斷的問題...

有風聲說司法部會把 Chrome 拆出 Google

看到這則新聞時決定讓子彈飛了一陣子,但好像沒看到什麼新消息:「Feds may target Google’s Chrome browser for breakup」,Hacker News 上也有討論可以翻翻:「Feds may target Google's Chrome browser for breakup (politico.com)」。

GoogleChrome 上面做了不少看起來就很容易觸發反壟斷法的事情 (剛好這幾天又有像是「Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站」這樣的事情),會直接先把 Google Chrome 拆出來的消息不算太意外。

不過大家對反壟斷調查更有興趣的應該是 YouTube 會怎麼被處理。網路上經常會看到「如何逃離 Google」之類的文章,Google 很多服務都有其他平台可以提供,或是 open source 軟體可以使用,但每次一講到 YouTube 時大家都很頭痛,都會提到 YouTube 的難以取代性,因為目前其他平台沒有一個是堪用的...

不知道什麼時候會發動調查...

HashiCorp 推出 Boundary 與 Waypoint

HashiCorp 推出了兩個新的產品。

第一個是 Boundary,這個產品看起來還很早期,但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」):「Announcing HashiCorp Boundary」,這在 Hacker News 上有討論串,而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題:「HashiCorp Boundary (hashicorp.com)」。

這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation,不過傳統的 castle 在小一點的場合也還算夠用...

另外一個是 Waypoint,看起來是個 CI/CD 類的產品:「Announcing HashiCorp Waypoint」,在 Hacker News 上也有討論串,而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西:「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。

我自己看了一下設定的方式以及一些畫面,然後再回頭看 Hacker News 上的討論,以目前得到的資訊來看,這個產品似乎沒有很明顯解決到痛點,也許就是補產品線...

Percona 對 MongoDB 的建議

看到「5 Things DBAs Should Know Before Deploying MongoDB」這篇,裡面給了五個建議,其中第五點頗有趣:

5) Whenever Possible, Working Set < RAM

As with any database, fitting your data into RAM will allow for faster reads than from disk. MongoDB is no different. Knowing how much data MongoDB has to read in for your queries can help you determine how much RAM you should allocate to your database.

這樣的設計邏輯很奇怪啊,你不要扯其他 database 啊,你們家主力的 InnoDB 一直都沒有推薦要 Working Set < RAM 啊,反過來才是用 InnoDB 的常態吧,而且在 PostgreSQL 上也是這樣吧 XDDD

現在上面的文章真的是挑著看了... XD

RDS 推出 ARM 版本

Amazon RDS 推出了 ARM 的版本:「New – Amazon RDS on Graviton2 Processors」,包含了 MySQLMariaDBPostgreSQL 的版本都有支援,不過看起來需要比較新版的才能用:

You can choose between M6g and R6g instance families and three database engines (MySQL 8.0.17 and higher, MariaDB 10.4.13 and higher, and PostgreSQL 12.3 and higher).

官方宣稱可以提供 35% 的效能提昇,考慮費用的部份會有 52% 的 c/p 值提昇:

Graviton2 instances provide up to 35% performance improvement and up to 52% price-performance improvement for RDS open source databases, based on internal testing of workloads with varying characteristics of compute and memory requirements.

對於 RDS 這種純粹就是個服務的應用來說,感覺應該不會有什麼轉移成本,只要測過沒問題,換過去等於就是現賺的。看起來等 RI 約滿了就可以切...

Google Chrome 在結束清站台資料時 (像是 cookie) 不會清 Google 自家的網站

在「Chrome exempts Google sites from user site data settings」這邊看到的新聞,引用的網頁是「Chrome exempts Google sites from user site data settings」,然後這篇也有上到 Hacker News Daily 上,所以 Hacker News 上的討論也蠻熱鬧的:「Chrome exempts Google sites from user site data settings (lapcatsoftware.com)」。

作者實際在 macOS 上拿最新版的 Google Chrome (86.0.4240.75) 測試,發現就算你針對 Google 自家的網站選了「Clear cookies and site data when you quit Chrome」,只有 cookie 會清掉,但 database storage、local storage 與 service workers 都不會被清掉:

然後 Brave 那邊前陣子時做完 Sync v2 了,又是個機會看看那邊如何了... 結果發現在 2019 年的時候意外修正了一部分:「"Keep local data only until you quit your browser" only deletes cookies, not local storage #1127」、「Fixes: #870 Replaced logic to clear data with WebKit api. #883」。

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本),在網址列上的 Protocol (Scheme) 與 www subdomain 不見了,而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」,裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個,直接在網址列上選右鍵,可以看到 Always show full URLs 這個選項,這是整個 Google Chrome 的選項,而非單一站台選項,選下去後就生效了:

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。

Google Chrome 的 Cache Partition 生效

去年提到的「Google Chrome 要藉由拆開 HTTP Cache 提昇隱私」在最近推出的 Chrome 86 預設生效了:「Chrome changes how its cache system works to improve privacy」。

Google 的文章「Gaining security and privacy by partitioning the cache」這邊有提到不同瀏覽器都有打算要支援類似的架構,對應的差異:

Is this standardized? Do other browsers behave differently?

"HTTP cache partitions" is standardized in the fetch spec though browsers behave differently:

  • Chrome: Uses top-level scheme://eTLD+1 and frame scheme://eTLD+1
  • Safari: Uses top-level eTLD+1
  • Firefox: Planning to implement with top-level scheme://eTLD+1 and considering including a second key like Chrome

文章裡面看到了有趣的東西,是他提到了 Fetch 這個標準,然後是在「2.7. HTTP cache partitions」這邊出現了對應的說明:

To determine the HTTP cache partition, given request, run these steps:

Let key be the result of determining the network partition key given request.

If key is null, then return null.

Return the unique HTTP cache associated with key. [HTTP-CACHING]

所以看起來是訂 Fetch 時寫下一套方法,然後拿來擴大套用到整個瀏覽器...

BiglyBT 支援 BitTorrent v2

先前提到的「libtorrent 宣佈支援 BitTorrent v2」,BiglyBT 整合完了:「BiglyBT is the First Torrent Client to Support the BitTorrent V2 Spec」。

看了一下 BiglyBT 的介紹,主要是因為當初 https://en.wikipedia.org/wiki/Vuze 變成 adware 之後分支出來的:

BiglyBT is a feature filled, open source, ad-free, bittorrent client.

BiglyBT is the continuation of the Vuze/Azureus open source project first created in 2003, and is being actively developed by the original coders.

不過這是 Java 寫的 client,目前需求也不大,我自己應該還是會繼續等 qBittorrent 支援,看起來在這邊:「BitTorrent v2 #13344」,不過現在看起來沒什麼進展...