Bluesky 開放一般註冊了

Bluesky 宣佈開放一般註冊了,不再需要邀請碼:「Join Bluesky Today (Bye, Invites!)」。

想玩的先前應該都拿到邀請註冊過了,現在不知道會有什麼新的玩意出來。

對玩技術的人來說,就只是另外一個 protocol,而且目前沒什麼分散性;對一般人來說,就只是另外一個社群... 重點還是在怎麼經營吸引人。

往上升級或是用 Unlimited mode 撐

這個 blog 跑在 Amazon EC2t4g.micro 上面,以往跑起來 baseline 是 10% CPU credit 也還算夠用,但最近的 loading 特別的大,發現是有 bot 在砍站砍的比較兇 (參考「t4g 的 CPU credit 被吃完了」這邊),雖然擋掉後有降不少,但看起來還是比之前高不少:(這邊是一天的平均,拉三個月資料來看)

以往這種一陣一陣的可以靠 CPU credit 頂過去,但因為先前 CPU credit 被 bot 砍完後沒了,就常常撞到底,只好先開 Unlimited mode 擋著了。

另外一方面,當初買的三年 RI 時間也快到了 (居然),這幾天差不多要處理了:

Start
February 9, 2021, 17:43 (UTC+8:00)

Expires
February 9, 2024, 17:43 (UTC+8:00)

升級到 t4g.small 剛好會符合 AWS 的免費方案,看起來可以先掙扎一陣子:

Until December 31, 2024, all AWS customers will be enrolled automatically in the T4g free trial as detailed in the AWS Free Tier. During the free-trial period, customers who run a t4g.small instance will automatically get 750 free hours per month deducted from their bill during each month.

我記得我算過但沒找到文章,所以這邊還是算一下... 如果 t4g.small 要錢的話,與 Unlimited mode 的消費差異大概是多少。

us-east-1t4g.small 是 $0.0168/hr,用 720 小時換算是 $12.096/mo。

假設 CPU 使用率平均在 15%,那用 t4g.micro 的 $0.0084/hr 會是 $6.408/mo,另外加上 5% * 2vCPU = 10% 的 Unlimited mode 費用 ($0.04/hr/vCPU),會是 $2.88/mo。

假設 CPU 使用率平均在 20% (剛好跟 t4g.small 的 baseline 相同的話),會是 $5.76/mo,所以如果用不到對應的記憶體的話,跑 Unlimited mode 會比較划算。

先開一張票。年底的時候再來看看當時的機種與優惠方案...

Jetpack 的備份功能失效

發現 1/13 後 Jetpack 就會一直發信通知備份功能失效,像是這樣:

連到 WordPress.com 上把語系改成英文,抓了一下問題發現錯誤訊息是:

We could not back up your site because it appears to be offline
Backup failed

用這個當關鍵字去找可以找到這篇:「13.0 and backups?」,照著裡面的方法把 Jetpack 降版到 12.9.3 後,隔天再看備份就正常了...

先把版本卡在 12.9.3,之後有新版再測試新版...

FreeBSD 4 到 FreeBSD 5/6/7/8 年代的事情...

在「FreeBSD 4 Bug may be present in Playstation 4/5 (wololo.net)」這邊看到一堆考古的討論... 原文是在講 FreeBSD 4 的 bug 可能會是 PS4PS5 的 jailbreak 切入點,不過討論裡面倒是看到了很多考古...

當年 FreeBSD 4.11 在 kernel 裡還是 single thread,然後是對 multi-core architecture 的理念不合分家了,另外一派變成 Dragonfly BSD,兩邊都花了不少時間實作多核心的架構。

印象中 FreeBSD 剛推出 5.x 的時候很不穩定,然後一路到 7.x 才算整個穩定下來,查了一下維基百科上的版本日期資訊:

After almost three years of development, the first 5.0-RELEASE in January 2003 was widely anticipated, featuring support for advanced multiprocessor and application threading, and for the UltraSPARC and IA-64 platforms.

FreeBSD 7.0 was released on 27 February 2008.

是個懷舊的討論串...

在桌機上擋 Facebook 各種廣告與演算法推薦文章的 userscript

發現好像沒提過這個 userscript,由於 uBlock Origin 的條件式不足以擋 Facebook 的各種廣告機制,目前需要靠 userscript 擋:「FB - Clean my feeds」。

預設會擋掉 sponsored,像是這樣:

不過在點開左下角的 icon 後,可以看到更多選項可以擋,我是把所有列出來的都勾起來了,另外多增加一個 「Interested」(我這邊用的是英文版介面的 Facebook,看到的是 Interested 這個詞):

然後經過幾次 Facebook 反制的「改版」,作者也都蠻快就更新...

蒐集 Hacker News 上被不合理條件「消失」的連結

在「Stories removed from the Hacker News Front Page, updated in real time (github.com/vitoplantamura)」這邊看到的計畫,專案在 GitHub 上面:「vitoplantamura/HackerNewsRemovals」。

蒐集的條件是假設如果本來在第一頁上面 (top 30),不應該下一分鐘就調出 top 90:

The assumption is that a Story cannot go from the top 30 to a position higher than 90 in a single minute, without having been explicitly removed.

dangid=39231821 有解釋有些情況是會直接被 downrank 出去的:

The first two you listed were downranked by the flamewar detector. The last one was downranked by users. Admins didn't touch any of them.

其實 Hacker News 混久了大家心裡也都有底,這兩個很 buggy 的機制就是要夠 buggy 才能操弄,這點從某些特定主題 (像是 climate change 相關的) 會突然消失,然後被推給這兩個系統...

所以 Hacker News 被說黑箱也不是一天兩天了,隔壁 Lobsters 至少有 Moderation Log 可以看...

現在這樣可以撈出其他有用的連結來看了,另外應該也可以讓他變成類似 Hacker News Daily 的方法才對,每天整理出來後變成一篇 blog post,這樣可以訂起來看,來提議給作者看看好了?

Starlink 的雷射傳輸細節

在「Starlink's laser system is beaming 42 petabytes of data per day (pcmag.com)」這邊看到 Starlink 的雷射資訊,原文是「Starlink's Laser System Is Beaming 42 Million GB of Data Per Day」。

主要是這兩張圖的資訊:

文字與圖片有很多不一致的地方,所以先抓個概念就好... 目前看起來是個「可商用」的階段了,而上面提到的 5400km 光是真空單向傳輸就要 18ms latency,如果擺到地球上的話,台灣到澳洲中間差不多?到關島、北海道或是新加坡都差不多在 3000km 左右。

想像中,海洋上面的 client 應該會透過這個方式 relay 到附近的陸地...

t4g 的 CPU credit 被吃完了

這個站 blog.gslin.org 掛了三個多小時:

先連機器 SSH 看起來是正常的,但習慣性的 w 看一下情況發現 CPU load 有 6.x,用 top 看一下就看到幾隻 php82-fpm 跑滿 CPU,心裡大概有底是被砍站了...

先把 nginx 停下來,瞄了一下 /var/log/nginx 下面的 log 就知道是 ClaudeBot 造成的,看起來都是從 AWSus-east-1 機器打過來的。

然後翻一下 log 看看什麼時候開始打的,先看 log 已經被 gzip 起來的這些:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log.{?,??}.gz | xargs -n1 | xargs -n1 -I% sh -c "echo %; zgrep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log.2.gz
  13031  169403 1986719
/var/log/nginx/blog.gslin.org_ssl-access.log.3.gz
    459    5967   85350
/var/log/nginx/blog.gslin.org_ssl-access.log.4.gz
  14533  188929 2219819
/var/log/nginx/blog.gslin.org_ssl-access.log.5.gz
   6502   84526 1026178
/var/log/nginx/blog.gslin.org_ssl-access.log.6.gz
  32483  422279 4905919
/var/log/nginx/blog.gslin.org_ssl-access.log.7.gz
  21304  276952 3221877
/var/log/nginx/blog.gslin.org_ssl-access.log.8.gz
   7921  102973 1199356
/var/log/nginx/blog.gslin.org_ssl-access.log.9.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.10.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.11.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.12.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.13.gz
      0       0       0
/var/log/nginx/blog.gslin.org_ssl-access.log.14.gz
      0       0       0

看起來是從 blog.gslin.org_ssl-access.log.8.gz 這邊開始的,大概是 1/25 開始 (機器上面是 UTC 時間):

-rw-r----- 1 www-data adm   1894325 Jan 26 00:00 /var/log/nginx/blog.gslin.org_ssl-access.log.8.gz

然後再來看一下最近的 log,看起來是這兩天打的特別重,到五萬多:

$ echo /var/log/nginx/blog.gslin.org_ssl-access.log{,.?} | xargs -n1 | xargs -n1 -I% sh -c "echo %; grep ClaudeBot % | wc"
/var/log/nginx/blog.gslin.org_ssl-access.log
  29436  382668 4387703
/var/log/nginx/blog.gslin.org_ssl-access.log.1
  51712  672256 7852345

拉了 AWS 的圖來看跟預期的差不多:

機器是 t4g.micro 而且沒開 burstable,先前差不多都是略低於 10% 的線在跑,剛好利用 CPU credit 的概念,這幾天看起來就是被打而跑上去。

好像該補一下 alarm,丟到我自己的 Slack 以及 Pushover...

Slack 自己幹的 Cron System

在 HN 上看到「Executing Cron Scripts Reliably at Scale (slack.engineering)」,發現是去年九月的文章:「Executing Cron Scripts Reliably At Scale」(話說 Slack 的 engineering blog 可讀性變差好多,不過這又是另外一回事了...)。

夠大的組織的 cron job system 都會自己幹一套出來用,因為檯面上的都不好用 XD

Slack 的搞法是組合三個內部系統:

  • 一個 container-based 管理實際執行資源的系統,基於 Bedrock,而 Bedrock 則是基於 k8s 上的系統。
  • 一個 job queue 子系統,後面是 Kafka + Redis 組成的。
  • 一組在 Vitess 上的表格,所以後面是 MySQL

這樣的系統也注定這是 Slack-only 的系統了,看一下知道用什麼就好了...

把 AWS 上的 EC2 instance 改成 IPv6-only

因為「AWS 將開始收取 IPv4 的 Public IP 費用」的關係,先試著把其中一台 EC2 instance 改成 IPv6-only,結果遇到不少問題...

首先是對外服務的部分,本來想用 CloudFront 擋在前面,但 CloudFront 到現在還是不支援 IPv6-only origin:「CloudFront support for IPv6 origins」,所以這邊的選擇變成是 Cloudflare

第二個是 AWS 自家的 API 還是有些沒有 IPv6 address,像是取得 AWS 擁有的 IP pool 的 https://ip-ranges.amazonaws.com/ip-ranges.json (本來是要取得 CloudFront 的區段,用在 nginx 的設定裡)。

另外就是周邊的問題,很多服務都沒有 IPv6 address,像是 api.slack.com

各種 proxy 與 NAT 架構還是必要的措施...