其中在講為什麼不選擇 GitLab 而是選擇 Forgejo 這段提到 2024 年 Forgejo 換授權的事情：

As of v9.0 in August 2024 the project relicensed from MIT to GPLv3+, with the explicit goal of staying copyleft and resisting future commercial capture of the codebase. The fork from Gitea in December 2022 happened precisely because Gitea Ltd took control of the trademarks and domains in a way the community had not consented to. The lesson learned shows up in the license.

在沒有 CLA 的情況下，要從 MIT 換成 GPLv3+ 會需要幾乎所有 contributor 的同意，然後還要把不同意的人的 code 拿掉改寫，我很好奇以 Forgejo 跟 Gitea 的關係，是怎麼取得 relicense 同意的，所以找了一下當初的文章，看起來裡面沒寫到 relicense 的過程：「Forgejo is now copyleft, just like Git」。

在「[Discussion] Relicensing Forgejo as copyleft #86」這邊看起來比較清楚，本來 Gitea 的檔案還是 MIT 授權，並沒有取得 Gitea 這邊的 relicense 同意：

Files which originate from Gitea remain MIT-licensed, so bug fixes and Gitea-only features can be contributed back.

另外就是明明看到 AGPLv3+，但最後是 GPLv3+ 的問題了，看起來在 https://codeberg.org/forgejo/meta/issues/183#issuecomment-843515 這邊的意見被同意：

I should have written:

A Forgejo decision cannot be made by Forgejo community members who are not impacted by the decision: a licensing decision must be made with an explicit consensus among the Forgejo community members who are also copyright holders.

Otherwise the Forgejo community could end up making decisions that go against the majority of the members impacted by it (the copyright holders in this instance). Which would not make much common sense, even though it would be legally allowed.

relicense 的決策應該由持有版權的人決定，而不是讓沒有版權的社群投票決定。另外提到當初在 2023 年的 https://codeberg.org/forgejo/governance/commit/bcbf058d0988023c9455e4c5e4c8f509a1a9a76d 裡面提到的是 GPLv3+：

Forgejo accepts contributions compatible with the [GPLv3-or-later](https://spdx.org/licenses/GPL-3.0-or-later.html) license. The license under which Forgejo is distributed will be changed upon the acceptance of such contributions. See the [LICENSE file](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/LICENSE) for the current license.

加上其他後續的討論，社群共識最後收斂到 GPLv3+。

所以整理下來，看起來不是整包 relicense，而是把 default license 切過去的感覺。

Python ecosystem 的好處是 (1) 好寫，(2) ecosystem 也很大，(3) 所以找問題也快。但這三點在 LLM 前面被清除的差不多了，可以透過 WebSearch 與 WebFetch，再加上其他 MCP 串起來直接讓 LLM 跑 reasoning 打通 (像是 Opus 4.7 的 max effort)，以往要花很多力氣的事情變成花很多 token 就可以解。

所以用 Python 唯一的「優點」可能就是讓人 review 比較方便？但這件事情看起來也是快被替代的感覺了...

Hacker News 上的 comment 看到了一個有趣的點子，在 id=48103303 這邊提到：

Surprisingly, LLMs are actually much worse at reasoning in Python than other common programming languages for agentic coding tasks.

Data here: https://gertlabs.com/rankings?mode=agentic_coding

連結裡面的東西我覺得很怪就不提了，但指出來「LLM 不一定會對主流語言處理的比較好」這件事情倒是蠻有趣的，雖然現在各家的旗艦模型應該都超過合格線蠻多的。

這樣是不是可以考慮全 assembly 開發拼速度...？(啥)

Developers and organizations now have the choice to access Anthropic's native Claude Platform experience, including APIs, console, and early-access beta features, directly through their existing AWS account, without managing separate accounts, billing, or tracking.

有直接說明資料的部分不是由 AWS 管的：

Claude Platform on AWS is operated by Anthropic, and customer data is processed outside the AWS security boundary.

第一波就開了不少區，不過有東京但沒有新加坡：

Claude Platform on AWS is available in US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), South America (São Paulo), Europe (Dublin), Europe (London), Europe (Frankfurt), Europe (Milan), Europe (Zurich), Europe (Paris), Europe (Stockholm), Asia Pacific (Tokyo), Asia Pacific (Seoul), Asia Parcific (Melborune), Asia, Pacific (Jakarta), Asia Pacific (Sydney), and Asia Pacific (Melbourne).

計價方式看起來是透過 Marketplace 收費，而且只有 API-based 的，官方是放在「Pricing」這邊「Claude Platform on AWS pricing」這段的說明。

不過有點微妙，不是直接列出 pricing，而是透過 CCU 計算，每個 CCU 是 US$0.01：

Claude Platform on AWS bills through AWS Marketplace using Claude Consumption Units (CCUs). Anthropic rates your token usage in USD at standard per-model, per-feature rates, applies any negotiated discount, converts the result to CCUs at $0.01 per CCU, and reports the CCU quantity to AWS Marketplace hourly. Your AWS bill shows a single CCU line item.

另外如果指定要在美國內 inference 的話，Opus 4.6 (以及之後的版本) 與 Sonnet 4.6 (以及之後的版本) 都要加收 10% 的費用；另外 fast mode 則是本來六倍的費用。

如果是 developer 用的情況，本家的 subscription-based 方案補貼還是不少，這邊 API-based 用途看起來有點微妙... 加上我記得 Bedrock 一直都有跟上啊？像是「Introducing Anthropic’s Claude Opus 4.7 model in Amazon Bedrock」這篇。

大概要看的是這邊 CCU 是不是有比較便宜，可能要再看看後續其他人的測試了？

Debian 宣佈下一版要強制 reproducible packaging 了：「bits from the release team (via)」，看起來先在 testing 上開始了：

Aided by the efforts of the Reproducible Builds project [1], we've decided it's time to say that Debian must ship reproducible packages. Since yesterday, we have enabled our migration software to block migration of new packages that can't be reproduced [2] or existing packages (in testing) that regress in reproducibility.

查了一下，Debian 很久以前就已經試著讓 package system 是 reproducible，但這次是變成強制要求，得把之前編不出來的想法辦解決掉。

-	    args->endp - args->begin_argv + consume);
+	    args->endp - (args->begin_argv + consume));

嗯...

從 security advisory 裡面可以看到回報者是「Ryan Austin of Calif.io」，而看 calif.io 的官網是有提到 AI 類的 startup：

Pushing the frontier of vulnerability research with AI.

不過在 calif.io 官方的 blog 上有文章提到這次的 CVE-2026-7270，看起來沒有作者署名資訊，裡面看起來比較像是傳統人力看到找出來的：「CVE-2026-7270: How I Get Root on FreeBSD with a Shell Script」。

其實就是老問題，如果 model 比較有效率，減少了 token 的消耗量，哪麼不能單看 token 的價錢。而 OpenRouter 剛好手上有資料 (而且是真實資料) 可以分析...

先從規格上看，input 與 output 都漲了一倍 (原來的兩倍)：

We replicated the cost analysis we did on Opus on the new GPT-5.5 model. GPT-5.5 launched with a 2x price increase over GPT-5.4: input tokens increased from $2.50/M to $5.00/M and output tokens from $15/M to $30/M.

首先是發現只有比較長的 prompt 才會讓輸出變簡潔：

用成本看的話，可以看到沒有到漲一倍，但也還是不少：

算是個參考，如果 GPT-5.4 夠用的情況下未必要升級上去...

Starting February 18, 2027, new smartphones and tablets must be designed so that end users can remove and replace the battery themselves using standard tools.

主要是看例外條款，其中這條：

Extremely long lifespan: To avoid the replacement requirement, a battery would have to be extremely durable. The battery must retain at least 80% of its original capacity after 1,000 charge cycles. That is significantly more than many batteries on the market today can achieve (often around 500–800 cycles).

iPhone 在「About the battery and performance of iPhone 11 and later」這邊宣稱 iPhone 15 以及之後的機型都有 1000 次 80% 的標準：

Batteries of iPhone 14 models and earlier are designed to retain 80 percent of their original capacity at 500 complete charge cycles under ideal conditions.* Batteries of iPhone 15 models and later are designed to retain 80 percent of their original capacity at 1000 complete charge cycles under ideal conditions.*

Samsung 的也類似：「Check how many battery charges your Samsung phones can survive (EU Data)」。

看起來因為例外條款，大多數的新手機應該都不會支援了...

其中 session limit 加倍放送：

First, we’re doubling Claude Code’s five-hour rate limits for Pro, Max, Team, and seat-based Enterprise plans.

然後尖峰時段的權重也拿掉：

Second, we’re removing the peak hours limit reduction on Claude Code for Pro and Max accounts.

主要是因為從 SpaceX 那邊補上了大量的資源：

We’ve agreed to a partnership with SpaceX that will substantially increase our compute capacity. This, along with our other recent compute deals, means that we’ve been able to increase our usage limits for Claude Code and the Claude API.

We’ve signed an agreement with SpaceX to use all of the compute capacity at their Colossus 1 data center. This gives us access to more than 300 megawatts of new capacity (over 220,000 NVIDIA GPUs) within the month.

剛好快到期了，這樣下個月也許可以先降回 Max 5x 方案？

開頭提到了 PHP License 3.01 一開始是沒有在 OSI 列表內的 (只有 PHP License 3.0 有)，導致有些公司內規要求軟體授權需是 OSI 列出來的而導致問題，這點 Ben Ramsey 去走 OSI 流程「The License Review process」中的「Request for approval of a legacy license」，這個是給「既成事實」的授權跑的：

I contacted the OSI to request legacy approval for 3.01, and the OSI Board voted to approve it in May 2020. Problem solved.

這樣先解決了現有授權沒有在 OSI 裡面的問題。

後面就有提到目前的 PHP License 授權的問題，看起來最主要就是與 GPL 不相容，所以打算推動往現有 OSI 已經審過的授權走，而選擇了 BSD-3-Clause。

理論上下一個版本 PHP 8.6 就會是 BSD-3-Clause 了，在打包 binary packaging 時會更自由。

很久以前 session limit 的五小時是切齊整點的，像是 00:xx 送出第一個 token 使用後，reset 的時間都會設定在 05:00，最近改成切齊十分鐘了，也就是 00:0x 送出第一個 token 的會是 05:00，但 00:1x 的會是 05:10，如果啟動時間是均勻分佈，平均的 session duration 從本來的 4:30 變成 4:55，大概是算力不夠，想辦法壓榨出來？

而以前「養」這些 session limit 的方法就是跑 cron job 定時觸發，對於我們本來就有 24h 在開的機器的 Linux server 就蠻簡單的。

不過最近有些改變... 以前是跑起來 claude 的時候就會送出 request 觸發 current session，現在這個行為看起來改掉了，得至少送個 noop 出去，所以我的 user cron job 變成 (我這邊是用 mise)：

1,11,21,31,41,51 * * * * /bin/bash -l -c "eval \$(mise activate --shims); cd work/claude; timeout 10 script --return --quiet -c \"claude --model sonnet -p noop\" > ~/tmp/claude.log 2>&1"

先這樣跑跑...