目前 Reddit 的替代方案

看到「sub.rehab · Find your next diving spot」這個頁面,在整理目前 Reddit 社群的其他出處。

從目前的資料看起來,Lemmy 應該是主要方案,有些可能自架,但蠻多人就是跑去找一個 instance 掛?

第二多的是轉移到 Discord 上,這點蠻特別的...

而因為 Discord 的封閉性,也看到了「Answer Overflow - Index Your Discord Server Channels Into Google」這種服務,可以把 Discord 的內容轉成 html 頁面,讓搜尋引擎可以讀到內容。

所以這波 Reddit 決定來硬的到底會不會成呢...

Heroku 的替代方案

八月的時候提到了 Heroku 要開始淘汰掉免費方案 (參考「Heroku 公佈了廢止免費方案的時間表),其中第一波的時間差不多要到了,也就是沒在用的帳號會先在 2022/10/26 開始拔。

在「Heroku Free Alternatives」這邊則是有人整理的各家的替代方案,除了先前提到的 Fly.io 以外,Render 也是個有聲量的方案。

裡面還蠻多沒聽過的,可以找時間看一下有沒有什麼特別的功能...

Airtable 的 Open Source 替代方案 Baserow

Hacker News Daily 上看到的產品 Baserow,另外在 Hacker News 的討論也有蠻多有趣的東西:「Baserow.io – Self-hosted Airtable alternative (baserow.io)」。

Baserow 的後端是用 Django 寫的,前端則主要是用 Vue.js

可以看到討論裡 Airtable 的問題,先不講定價問題,只講其他的部份... (因為就如同討論裡面有提到的,有可能是公司故意把定價策略訂成讓不願意花大錢的人使用)

首先是每個月都有「穩定的 downtime」,不過這邊的描述到的數字明顯有問題,一個月當了七個小時也有 99% uptime (兩個九)。

不過先撇開這點,付費服務一般都可以看到 99.9% 的 Monthly SLA (三個九,一個月只允許 43.2 分鐘),這個情況的確是不太符合業界的標準:

Reliable 1-5 hours a month of downtime. There are months where it's literally 1 nine of uptime. Their status page was actually down for a while (I think they forgot to renew it?)

另外一個有很趣的是很奇耙的設計:

Booleans in the API are `true` or `undefined`. Seriously.

看起來要有蠻多背景知識才有可能知道為什麼這樣搞 XDDD

先丟給 data team 看看,如果他們有興趣的話再找機會架起來...

試著用 OsmAndMaps 的離線地圖

OsmAnd 是在「Why I quit using Google」這篇看到的東西,這篇文章在討論離開 Google 的 ecosystem 有哪些替代方案,裡面有提到其實這些轉移不是短時間轉完的,而是不斷嘗試,直到找到自己滿意的替代方案:

Migrating away from Google was not a fast or easy process. It took years to get where I am now and there are still several Google services that I depend on: YouTube and Google Home.

其中地圖這塊是這樣:

Google Maps → Bing Maps → OpenStreetMaps and OsmAnd

在 iOS 上面的應用程式叫做 OsmAndMaps,下載後內容大概是這樣:

基本的部份用起來還不錯,上面的店家資訊少了點而已,應該會用一陣子看看...

iOS 13 與 macOS 10.15 對憑證的限制

Slack 上看到同事丟出來的,關於之後要推出的 iOS 13 與 macOS 10.15 會對憑證限制的項目:「Requirements for trusted certificates in iOS 13 and macOS 10.15」。

主要是把不安全的演算法淘汰掉 (RSA 小於 2048 bits,以及 SHA-1 類的 hash algorithm),這兩個部份相關的新聞應該不少,沒有什麼太大問題:

TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits. Certificates using RSA key sizes smaller than 2048 bits are no longer trusted for TLS.

TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm. SHA-1 signed certificates are no longer trusted for TLS.

然後是要求憑證使用 SAN (Subject Alternative Name),舊的標準 CN (CommonName) 將不會再被信任。

如果是公開簽發的憑證應該都沒問題 (像是 Let's Encrypt,或是花錢買的那些),主要的問題應該會出現在自己建立的憑證,網路上蠻多舊資料還是產生 CN...

TLS server certificates must present the DNS name of the server in the Subject Alternative Name extension of the certificate. DNS names in the CommonName of a certificate are no longer trusted.

另外是 2019/7/1 之後發出的憑證,有額外兩個規範要注意,第一個是強制要透過 EKU 指定 id-kp-serverAuth,這是出自 RFC 5280

   id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
   -- TLS WWW server authentication
   -- Key usage bits that may be consistent: digitalSignature,
   -- keyEncipherment or keyAgreement

TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID.

再來是時間的限制,接下來的憑證最長只認得 825 天 (大約 27 個月多一些),以前都惡搞 -days 3650,現在得兩年簽一次了:

TLS server certificates must have a validity period of 825 days or fewer (as expressed in the NotBefore and NotAfter fields of the certificate).

整體看起來主要是影響自己簽的部份...

Google 內部的系統 (以及外部可能的 Open Source 替代方案)

Hacker News Daily 上看到的 jhuangtw-dev/xg2xg,整理了 Google 內部服務以及可能的替代方案。

主要是提供給離開 Google 的工程師,替代方案中包括了 Google 自己公佈的,已經其他的 open source 替代方案:

by ex-googlers, for ex-googlers - a lookup table of similar tech & services

A handy lookup table of similar technology and services to help ex-googlers survive the real world :) pull-requests very welcomed. Please do not list any confidential projects!

專案的發起人看起來是個台灣人...

各種 Java 的版本

看到這則 tweet,提到 Java 的支援度:

主要是裡面有張圖列出了目前市場上有的選擇,可以當關鍵字來查:

目前看起來如果要 Java 8 只有三個方案,其中有過 TCK 的只有兩個,看起來用 Amazon Corretto 算是個還不錯的選擇?

LinkedIn 忘記續約導致 SSL Certificate 過期

Netcraft 上看到 LinkedIn 出包的消息,這次是 country-mixed 的版本出包:「LinkedIn certificate blunder leaves users LockedOut!」。

在 DNS 上也可以看出來這兩個 CNAME 到不一樣的 load balancer 上:

;; ANSWER SECTION:
www.linkedin.com.       260     IN      CNAME   2-01-2c3e-003c.cdx.cedexis.net.
2-01-2c3e-003c.cdx.cedexis.net. 93 IN   CNAME   pop-ehk1.www.linkedin.com.
pop-ehk1.www.linkedin.com. 3560 IN      A       144.2.3.1
;; ANSWER SECTION:
de.linkedin.com.        86400   IN      CNAME   cctld.linkedin.com.
cctld.linkedin.com.     86400   IN      CNAME   mix.linkedin.com.
mix.linkedin.com.       213     IN      CNAME   pop-ehk1.mix.linkedin.com.
pop-ehk1.mix.linkedin.com. 3546 IN      A       144.2.3.5

SSL Labs 上也看得出來在 Alternative names 的地方是不一樣的:「SSL Server Test: www.linkedin.com (Powered by Qualys SSL Labs)」、「SSL Server Test: de.linkedin.com (Powered by Qualys SSL Labs)」。

然後因為 LinkedIn 有設定 HSTS,所以使用者在界面上完全無法登入:

Google Chrome 上可以用 badidea 繞過 (參考「在 Google Chrome 連上因 HSTS 而無法連線的網站」),但在 Mozilla Firefox 上的話目前沒找到方法可以在界面上 bypass,而是需要改 SiteSecurityServiceState.txt 這個檔案:「HTTP Strict Transport Security prevents me from accessing a server that I'm doing development on」。

不過也因為兩個 cluster 獨立運作,網址改一下應該就會動了...

這幾年比較很少看到大公司出這種包,還蠻有趣的 XD