たけうちひろあき @takke@fedibird.com

XのTOSはそうとっぴなものではないので、もしもこれが通るなら、あらゆるサイトでの活動が突然危機に瀕してしまうよ

XがXのアカウントの所有権を主張――というだけなら「まあそんなもんかもな」と思うかもしれないけど、企業が運営していたアカウントが買収で移動することに異議申し立てしたと聞くと「頭おかしくないか？」と思う人もいるだろう。
Xは訴状の中で「Xのアカウントの財産権は全てXが保有する」と述べていて、勝手に売却するなどまかりならん、と、InfoWarsの破産整理に関連したOnionの買取に口を挟んでいる。
陰謀論サイトを無力化しようとするOnionに「待った」をかけようということなんだろうが、やり方はなんだっていいというのか。
底が抜けてんなあ。

ATOK、かな入力画面で英語のフリックしてもちゃんと候補に出してくれる

体調が悪い時には躊躇せず病院に行けて、病気が見つかった時には安心して療養でき、療養の後には社会へ復帰していける…世の中であってほしい、と財布の中身を見ながら思うのです。

国は国民からこれだけ保険料だ年金だと召し上げているのだから、どうかどうか、安心をください。

現行のPleroma / Akkomaに、プロフィール補足情報（Misskeyだと追加情報）が多すぎるとアカウント情報の取得に失敗し、再取得を繰り返してしまうバグが存在します。

これにより、CPUが使い尽くされたり、データベースが肥大したり、相手サーバへ過大な負荷をかけてしまいます。

Pleroma / Akkoma全体でこれが発生するため、実質的にDDoSを仕掛けるような挙動となります。

デフォルトが20なので、これを設定（Instance の Max remote account fields）で大きく引き上げる方法でまず対応し、

指定数をオーバーしたら切り捨てて対応するパッチをあてる対応が必要です。
https://git.pleroma.social/pleroma/pleroma/-/merge_requests/4220

Pleroma / Akkomaの新バージョンがリリースされたら速やかにアップデートしましょう。

この不具合は、プロフィール補足情報の件数が多いActivityPub実装すべてで発生します。

Mastodonの標準は4件、Misskeyは16件、Fedibirdは8件ですが、独自に数を増やしているサーバであれば該当する可能性があります。

また、Misskey.ioのバナー機能はプロフィール補足情報で連合するので、こちらでも発生します。

M1 ProのMacBook ProとM4 ProのMac miniでRubyのビルド時間を計測してみたところ､実行時間で1.5倍ぐらいM4 Proが速かった。といっても､M1 Proでも1分切ってるわけでまだまだ使えるよな

MacBook Pro
make -j 136.99s user 30.53s system 331% cpu 50.524 total

Mac mini (M4 Pro)
make -j 108.82s user 52.57s system 466% cpu 34.583 total

io「バナー機能リリースしました！」
Fediverse「io内だけで実装するな！連合しろ！」
io「はぁ・・・連合するか・・・
とりあえずバナーって規格はないからユーザーのプロフィールに書かれてるURLとして連合するね」
Pleroma「URL多すぎる！これはエラー！リトライ！」
io「リクエストガガガガガ（お金が溶ける音）」
〜数ヶ月後〜
村上さん「バグってるので直らなかったらブロックします」
周囲「ブロックなんて無責任だ！」
村上さん「えぇ・・・」

と言うのが流れ