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

Atlassian 將消滅 Server 版本

Hacker News Daily 上看到 Atlassian 打算消滅 server 版本:「Moving to a cloud future, together」。

話說回來,之前工作時用 Jira 的時候 (雲端版本),所有人都抱怨 Jira 慢到爆炸的問題不知道解了沒,當時記得每個按鍵都要 10+ 秒才會反應,不管是在台灣還是在香港都很慢,然後在公司反應了十個月也都沒什麼改善 XD

至於官方說要推 cloud 版本的理由聽聽就好,Hacker News 上有些討論反而還蠻有趣的,像是講到裡面同時在維護 Cloud 與 Server 版本時遇到的問題,看起來團隊沒有足夠的能量處理這些東西:「Atlassian moving to cloud-only, will stop selling server licenses (atlassian.com)」。

另外一個是討論裡面提到的替代方案,看起來也不算很好的替代方案啊,出現 MediaWiki 作為 Confluence 的替代品,少了 WYSIWYG 其實門檻高不少耶...

來看看這波反應會有多大 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 時寫下一套方法,然後拿來擴大套用到整個瀏覽器...

打穿蘋果的企業網路

上個禮拜丟出來很轟動的一篇「side project」,三個月不斷的打穿蘋果的企業網路:「We Hacked Apple for 3 Months: Here’s What We Found」,對應的 Hacker News 討論可以在「We Hacked Apple for 3 Months (samcurry.net)」這邊看到。

在最後面有提到這本來是打好玩的,但後來就投入愈來愈多時間進去:

This was originally meant to be a side project that we'd work on every once in a while, but with all of the extra free time with the pandemic we each ended up putting a few hundred hours into it.

這是五個人通力合作打了三個月出來的成果,依照他們的回報數字,共打出了 55 個「洞」,考慮到週休的情況,幾乎是天天打洞出來玩:

There were a total of 55 vulnerabilities discovered with 11 critical severity, 29 high severity, 13 medium severity, and 2 low severity reports. These severities were assessed by us for summarization purposes and are dependent on a mix of CVSS and our understanding of the business related impact.

文章裡沒有對每個安裝漏洞都描述,但有針對一些比較「有趣」的漏洞說明,雖然看了以後知道是怎麼一回事,但對這些手法沒這麼熟,你叫我打我還是不會打啊 XDDD 反而是當作表演藝術來看...

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」,不過現在看起來沒什麼進展...

用 GitHub Actions 記錄 API 資料的變化

Hacker News Daily 上看到的方式,Simon Willison 利用了 GitHub Actions 定時去抓資料更新 git repository:「Git scraping: track changes over time by scraping to a Git repository」。

文章裡面測試了 JSON 檔案的變化:

這個方式利用了 GitHub 自家的架構做完所有的事情,因為他的範例是拉加州政府的資料,感覺 g0v 裡應該有些專案也用這個方式搞,翻了一下 Telegram 上的記錄,果然翻到記錄了:「零營運費用開源開發」。

另外我猜用 free-for.dev 這邊的資源應該也有機會堆出類似的東西...