記事中で出てくる計測等は以下のリポジトリで実施した。 GitHub - wasuken/pg-offset-bench · GitHub はじめに lobste.rsで “All you need is PostgreSQL” という記事を読んだ。 「Redisやイベントストア、マイクロサービスに安直に逃げる前に、PostgreSQL単体で解決できないか考えろ」という主張を、金融システムをサンプルに証明する内容だった。 詳細については元記事を読んでくれ。 その中でキーセットページネーションに触れていて、私もOFFSETを使っていたので本当にまずいのか気になり、実際に環境を作って計測してみた。 ただし先に結論を言っておく。OFFSETが遅いのは事実だが、特定のページ番号に直接ジャンプする処理が必須な場合はOFFSETを使うしかない。キーセットは「前のページの続き」しか取れないため、任意のページへのランダムアクセスには対応できない。 逆に言えば、次へ,前へや無限スクロールで十分なケースであれば、間違いなくキーセットページネーションを使うべきだ。本記事はその判断材料として読んでほしい。 環境 PostgreSQL 17（Docker） WSL2 / ArchLinux # compose.yml services: postgres: image: postgres:17 container_name: pg-offset-bench environment: POSTGRES_USER: bench POSTGRES_PASSWORD: bench POSTGRES_DB: bench ports: - "5432:5432" volumes: - pgdata:/var/lib/postgresql/data - ./init:/docker-entrypoint-initdb.d command: > postgres -c shared_buffers=256MB -c work_mem=16MB volumes: pgdata: テーブルは100万件のarticlesテーブルを用意した。中身はどうでもいいので適当。 CREATE TABLE articles ( id BIGSERIAL PRIMARY KEY, title TEXT NOT NULL, body TEXT NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT now() ); INSERT INTO articles (title, body, created_at) SELECT 'Article ' || i, repeat('body text ', 10), now() - (random() * interval '365 days') FROM generate_series(1, 1000000) AS i; CREATE INDEX idx_articles_created_at ON articles (created_at DESC, id DESC); ANALYZE articles; OFFSETページネーションとは もっとも一般的なページネーション実装。 ...

面白い記事を読んだ。 Don’t verify email addresses by sending spam to them — milek7.pl 要約すると、AI検出サービス「Pangram」のサインアップフォームにメールアドレスを入力すると、謎の送信元からスパムメールが届くというものだ。著者がPostfixのログを確認したところ、複数のドメイン・IPをローテーションしながら配信を試み、DNSBLに弾かれたら別のIPで即リトライするという、本格的なスパム業者のインフラが動いていたとのこと。 「届いた＝有効なアドレス」として検証完了とみなす設計らしく、著者は「スパムを送ることがメール検証になっている」と皮肉っている。詳しくは元記事を読んでほしい。技術的な詳細（Postfixログや送信ドメイン一覧）もすべてそちらに載っている。 気になったので Pangram 自体を調べてみた。 Pangram とは 公式サイトによると、AI生成コンテンツを検出するサービスだ。ChatGPT・Claude・Geminiなどを99.98%の精度で検出するとうたっており、大学・企業向けに展開している。 About ページによれば、創業者のMaxとBradleyはStanfordの同期で、それぞれNuro・Google・Teslaなどでキャリアを積んだMLエンジニア。学生スタートアップではなく、業界経験者が立ち上げたサービスだ。シカゴ大学・メリーランド大学の研究者による第三者検証も受けており、SOC2 Type2認証も取得している。 それなりに本格的なサービスなので、元記事で指摘されているメール検証の実装が余計に不可解になる。 なお日本語ページも用意されているが、翻訳の品質はかなり怪しい。「のグローバルブランドから信頼されています」「AI生成コンテンツ（　）および盗用を検出する」など、テンプレート変数の埋め忘れや機械翻訳そのままと思われる箇所が散見される。他の言語は見てないし、調べることもしてないのでまあ日本語が難しいとはいえばそうかもしれない。 日本のXでの使われ方 日本のXでAI判定ツールとしてそこそこ広まっていることがわかった。 使われ方は「この投稿AI臭い → Pangramで判定 → AI！」という流れがしばし見られる。 また、この記事はAIかどうかについては知りたいという意見も散見された。 誤検知は確率的に必ず起きる Princetonの研究者Arvind Narayananは、誤検知率1万件に1件という数字を前提にしても、大学4年間で数百〜1000件の提出物をチェックすれば、学生の一定割合が誤って不正行為を疑われる計算になると指摘している。 SNSの投稿を個人特定の「証拠」として使えば、誤検知による風評被害は避けられない。 生成AIを利用してる私がいうのもなんだが、事実として知っておきたい人たちは存在しつつも 現状のインターネットを見る限り、いわゆる魔女狩りに利用されそうだ。 とはいえ、生成AIを利用していないことを明記しないほうが悪いので 私もこれからは記事に明記しようと思う。 ツール自身も断定を戒めている Pangram自身も「AI検出はひとつのシグナルであり、追加の証拠収集と組み合わせて使うべき」と公式に述べている。個人のX投稿に対して「これはAIが書いた」と断定する用途はそもそも想定されていない。 サービスの信頼性自体に疑問符がついた 元記事の指摘が事実であれば、メールアドレス検証のためにスパム業者へアドレスを渡している可能性がある。現時点でPangram側からの公式コメントは確認できておらず、あくまで一個人の調査に基づく疑惑の段階だ。ただ、AI判定ツールとして人を断罪する根拠に使うには、信頼性の検証が先だろうという気持ちにはなる。 元記事の著者は「どうやってこんな実装に辿り着いたのか謎。LLMエージェントが暴走した可能性もある」と書いていた。AI検出ツールが、AIの暴走疑惑を持つインフラを抱えているとしたら、皮肉としては出来すぎている。 参考 Don’t verify email addresses by sending spam to them — milek7.pl Pangram 公式サイト（日本語） Pangram About Us Arvind Narayanan — 誤検知率についての指摘

RSSで Stop Naming Your Variables “Flag”: The Art of Boolean Prefixes という記事が流れてきた。bool変数の命名規則の話。 記事の要点 主張はシンプルで、bool変数にflagやdoneのような中身のない名前をつけるな、というもの。flagやdoneは「何の」フラグなのか、「何が」完了したのかが変数名から一切わからず、読み手は呼び出し元や定義側のコードを読みに行かないと意味が取れなくなる。 これを解消するために、is（状態）、has（包含）、can（機能）、should（意図・ビジネスルール）の4つのプレフィックスで命名すれば大半のケースをカバーできるとしている。あわせて「ネガティブな名前を使うな」というルールも強調されていて、isDisabledのような名前は将来!isDisabledという二重否定を生むので避け、isEnabledのように常にポジティブな形で持つべきだとしている。 もう一つ面白かったのが、これらのルールは状態を表すプロパティにはよく効くが、引数として渡されるboolには効かないという指摘。意味の伴わないbool引数を複数並べたメソッドは、呼び出し側のコードを読んだだけでは何が起きるか判断できない設計上の欠陥で、これを解消する手段としてメソッド分割・Enum・Configオブジェクトの3パターンが挙げられている。 詳細は元記事を読んでほしい。 「メソッド分割って結局引数じゃないの？」を考えた ここから自分の考察。メソッド分割・Enum・Configオブジェクトの3パターンが並列に挙げられているのを見て、「メソッド分割だけ毛色が違うのでは」と思った。EnumもConfigオブジェクトも結局は引数として何かを渡している。メソッド分割だけが「引数を使わない」解決策に見える。 整理すると、これは「引数を使うかどうか」の話ではなく「型に意味を持たせているかどうか」の話になる。bool単体は型として「真か偽か」以上の情報を持たない。これを呼び出し側で見た時に何を意味するか判断できないのが元の問題で、3パターンはどれも「呼び出し側だけで意味が完結する形に情報を昇格させる」という同じ操作をしている。メソッド名に意味を込めるか、Enumの値に意味を込めるか、オブジェクトのプロパティ名に意味を込めるかの違いでしかない。 この観点で見ると使い分けの基準も見えてくる。状態が二択でこの先も増えない見込みならメソッド分割で呼び出し側の読みやすさを最大化できる。一方、状態が3つ以上ある、または今後増える見込みがあるならメソッド分割は破綻しやすい。「即時送信」と「キュー送信」の2メソッドに「リトライあり」という軸が加わると、組み合わせの数だけメソッドが必要になり、命名が事故る。こうなったらEnumかConfigオブジェクトに切り替えるべきサイン。 経験則として、メソッド名に「And」を入れたくなった瞬間が分割すべきタイミングだと思っている。「送信かつキュー投入」のような名前は、本来排他な選択肢を無理やり1つの操作として表現しようとしているか、1つの関数が複数の責務を抱え込んでいるかのどちらかで、どちらにせよ設計を見直すべきサインになる。 長い変数名・関数名はなぜダメなのか ここからは命名の話を少し広げる。booleanの話とは別に、変数名や関数名が長すぎることそのものを問題視する意見もよく見る。これはbooleanの「曖昧すぎる」問題とは逆方向の弊害で、原因は大きく2つに分けられると思う。 一つは、命名で背負わせている責務が多すぎること。getUserDataAndValidateAndSendNotificationのような名前は、まさに「And」がそのまま並んでいる例で、これは命名の問題ではなく関数の設計自体の問題。複数の責務を1つの関数に詰め込んだ結果として名前が膨張している。この場合、長い名前を短くしようとするのではなく、関数自体を分割して短い名前に戻すのが正しい対処になる。 もう一つは、文脈の不足を変数名で無理やり補おうとしていること。例えばuserServiceUserIdForBillingCalculationのような名前は、本来クラス名や引数の型、コメント、あるいはスコープの狭さで伝えられるはずの文脈を、変数名一つに全部押し込めようとして起きる。クラス名がすでにBillingCalculatorなら、そのメソッド内でuserIdとだけ書けば文脈はクラス名から自然に補完される。長い名前が必要になっている時点で、実はそのクラスやモジュールの設計自体が文脈を提供できていない、というシグナルとして読むこともできる。 つまり長すぎる名前は、それ単体の修正対象というより「設計のどこかに無理が生じている」ことを教えてくれる兆候として扱うのが妥当だと思う。 デザインパターンとの接続 Boolean Trapの3パターン(メソッド分割・Enum・Configオブジェクト)は、実はそれぞれ古典的なデザインパターンの入り口になっている。 メソッド分割を突き詰めると、状態ごとに振る舞いを切り替えるクラス設計が必要になる場面が出てくる。状態の数がさらに増え、状態遷移そのものに意味を持たせたくなったら、Stateパターン(状態をオブジェクトとして切り出し、状態ごとに振る舞いをカプセル化する)に近づいていく。 Configオブジェクトは、複雑な初期化や生成のロジックを切り出したくなった時点でBuilderパターン(オブジェクトの組み立て手順そのものを別オブジェクトに任せる)と接続する。new ExportOptions { ... }のようなオブジェクトリテラルで足りているうちはConfigオブジェクトのままでいいが、必須項目とオプション項目が増えて初期化の組み合わせ自体が複雑になったら、Builderへ移行するタイミングになる。 Enumで振る舞いを切り替える設計が増えてくると、Strategyパターン(アルゴリズムや処理そのものを差し替え可能なオブジェクトとして扱う)とも近づく。Enumの値でswitch文を量産し始めたら、それは「Enumに対応する振る舞いをオブジェクトとして注入する」設計に切り替えるサインになる。 いずれも、最初からこれらのパターンを持ち出す必要はなく、Boolean Trapの3パターンで対処しているうちに複雑さが増した時に「次に進む先」として用意されている、という位置づけで捉えるのがちょうどいいと思う。 クリーンアーキテクチャとの接続 もう一段引いて見ると、これらの命名・設計判断は層の責務分離とも関係してくる。 クリーンアーキテクチャでは、ドメイン層(ビジネスルール)とインフラ層(外部APIやDBとのやり取り)を明確に分離する。「ネガティブな名前は外部APIとの境界線だけに押し込めて、ドメイン層には持ち込まない」という元記事のルールは、まさにこの境界の話そのものになっている。外部の都合(ネガティブな命名、bool引数の羅列)はインフラ層やアダプタ層で吸収し、ドメイン層には意味の伴った型(Enum、Stateオブジェクト、Configオブジェクト)だけを渡す、という設計にすれば、層をまたぐたびに命名の濁りが伝播するのを防げる。 逆に言うと、ドメイン層の奥深くまでbool引数の羅列やネガティブな命名が浸透している場合、それは単なる命名の問題ではなく、本来インフラ層で吸収すべき外部の都合がドメイン層まで漏れ出している設計上の兆候として読むこともできる。 まとめ booleanの命名規則自体はそこまで難しい話ではないが、そこから「なぜそのルールが効くのか」を自分で詰めていくと、長い変数名の話、デザインパターン、層の分離まで地続きにつながっている。命名は単体の作法というより、設計全体の健全さを映す表面の一つだと捉えておくとよさそうだった。 元記事

RSSを流し見してたら littlefs の DESIGN.md が流れてきた。マイコン向けのファイルシステムで、停電耐性を本気で解こうとした設計が面白かったので読んだ。 詳細な設計の話は DESIGN.md に全部書いてあるのでそっちを読んでほしい。ここでは要点だけ。 littlefs とは マイコン向けの組み込みファイルシステム。ターゲットは RAM 約 32KiB、ROM 約 512KiB 程度の 32bit マイコン + SPI NOR フラッシュ。 設計上の制約が 3 つある。 停電耐性 — 書き込み中のどのタイミングで電源が落ちても壊れないこと ウェアレベリング — フラッシュの特定ブロックに書き込みが集中して早死しないこと RAM 上限保証 — ファイルシステムのサイズが増えても RAM 使用量が増えないこと マイコンは「シャットダウン処理」という概念がないので、停電耐性は必須要件になる。 既存 FS の問題点 DESIGN.md では既存のアプローチを 4 つ整理している。 方式 例 停電耐性 ウェアレベリング ブロックベース FAT, ext2 ✗ ✗ ログ型 JFFS, SPIFFS ✓ ✓ ジャーナリング ext4, NTFS ✓ ✗ COW btrfs, ZFS ✓ △（ルートに集中） ログ型は GC が O(n²) か O(n) RAM のどちらかになる。COW は更新がルートまで伝播して特定ブロックにウェアが集中する。どれも一長一短。 ...

yay v13 が出た yay は Go 製の AUR ヘルパー。内部的に pacman をラップしていて、公式リポジトリと AUR の両方を扱える。 v13 のリリースノート を読んだのでまとめる。 PKGBUILD 最終更新時刻の表示 パッケージ検索・アップグレードメニューに、PKGBUILD が最後に更新されてからの経過時間が表示されるようになった。 aur/brave-nightly-bin 1.93.67-1 (+42 1.10) [6h17m] [6h17m] の部分が新表示。最近更新されたからといって危険とは限らないが、「より注意して PKGBUILD を読め」というシグナルになる。 Lua による設定・フック ~/.config/yay/init.lua に設定やフックを書けるようになった。ファイルが存在しなければ Lua は一切実行されない。config.json は引き続き読み込まれるが init.lua で上書き可能で、CLI フラグが最優先。 フックの種類は以下の3つ。 フック タイミング UpgradeSelect -Syu でアップグレード候補確定後、除外メニュー前 AURPreInstall PKGBUILD フェッチ直後、ビルド前 AURPostDownload makepkg --verifysource 後、ソースファイルにアクセス可能な状態 たとえば「最近3日以内に更新された AUR パッケージはアップグレードをスキップ」を自動化できる。 yay.create_autocmd("UpgradeSelect", { desc = "skip recently modified AUR upgrades", callback = function(event) local exclude = {} local recent_cutoff = os.time() - (3 * 24 * 60 * 60) for _, pkg in ipairs(event.data.upgrades) do if pkg.repository == "aur" and pkg.last_modified >= recent_cutoff then table.insert(exclude, pkg.name) end end return { exclude = exclude, skip_menu = false } end, }) AURpocalypse とは 今回の v13 リリースの背景にあるのが、AUR でのマルウェア混入インシデント（通称 AURpocalypse）。 ...

元記事 21 Zero-Days in FFmpeg — For $1,000 セキュリティスタートアップのDepthfirst社が開発したAIエージェントが、FFmpegから21件の未公開脆弱性（ゼロデイ）を発見した。かかった費用はわずか1,000ドル。 人間が数ヶ月かけて監査する規模のコード（約150万行のC言語）を数日でスキャンし、実際にクラッシュやコード実行を起こせる実証コード（PoC）までAIが自動生成したらしい。 その中でもAV1 RTPデパケタイザのバグが、ハッカーにとって都合が良すぎる完璧な仕様だった。 特別なフラグも不要で、以下の ordinary なコマンドで罠URLを開かせるだけでリモートコード実行（RCE）が成立する。 ffmpeg -i rtsp://attacker/stream わずか183バイトのパケット1つでPCが乗っ取られる仕組みが面白かったのでメモ。 原因 トラック用カーソルの「勘違い」 問題は libavformat/rtpdec_av1.c のAV1 RTPデパケタイザ（パケット組み立て処理）にある。 AV1の仕様では、フレームの区切りを示す1バイトのマーカー Temporal Delimiter (TD) を「無視して削除（ignore and remove）」せよ、と書かれている。この処理部分のロジックがバグっていた。 FFmpegは、パケットの書き込み位置を制御するカーソル pktpos を動かしながら処理を行うが、TDを見つけたときに以下のような挙動をしていた。 // libavformat/rtpdec_av1.c:250 if ((obu_type == AV1_OBU_TEMPORAL_DELIMITER) || (obu_type == AV1_OBU_TILE_LIST)) { pktpos += obu_size; // 書き込みカーソル（矢印）だけを先に進める rem_pkt_size -= obu_size; // インプットカウンターを減らす obu_cnt++; continue; // メモリ確保（割り当て）は行わない！ } データを無視する（メモリを確保しない）のに、書き込みカーソル（pktpos）だけを先に進めてしまった。これにより、確保されたサイズより遥か先を指す「ポイズンカーソル」が生まれる。 さらに、インプット側のポインタを進め忘れたため、次のループ処理で同じTDのデータを再パースし、攻撃者が用意した任意のデータを、はみ出た未来のメモリ番地へピンポイントに書き込める状態（ヒープバッファオーバーフロー）が完成する。 詳しくてちゃんとした解説については21 Zero-Days in FFmpeg — For $1,000の最後らへんを見てほしい。 綺麗すぎるメモリ配置 通常ならクラッシュして終わるが、FFmpegのアロケータの並びがハッカーにとってお宝だった。 動画データを置くバッファのすぐ隣（オフセット152）には、内部の管理用構造体 AVBuffer が隣接して割り当てられる決まりになっている。この中には、データの片付け（メモリ解放）を行うための「関数ポインタ」（void (*free)(...)）が格納されている。 ...

2026年6月、Arch Linux の AUR (Arch User Repository) で大規模なマルウェア混入事件が発生したらしい。 Arch Linux ユーザーとして、自分の環境への影響を確認したメモ。 何が起きたか Phoronixの報道によれば、400以上のAURパッケージが今週の大規模マルウェアキャンペーンで侵害されたとのこと 参考: https://www.phoronix.com/news/Arch-Linux-AUR-400-Compromised 事件は Arch Linux の公式メーリングリスト aur-general で報告・追跡されている 公式スレッド: https://lists.archlinux.org/archives/list/[email protected]/thread/FGXPCB3ZVCJIV7FX323SBAX2JHYB7ZS4/ 攻撃の手口 セキュリティベンダーSonatypeの分析(通称 “Atomic Arch”)によると、攻撃者はメンテナーが放棄した(orphaned)AURパッケージの所有権を奪い、ビルド手順(PKGBUILD)を改変して atomic-lockfile という悪意あるnpmパッケージをインストールさせる、というパターンが確認された。 参考: https://www.sonatype.com/blog/atomic-arch-npm-campaign-adds-malicious-dependency この atomic-lockfile は preinstall フックで Rust製のELFバイナリ(deps)を自動実行し、ブラウザやDiscord、GitHub、SSH、Dockerなど開発環境の認証情報を狙う情報窃取マルウェア 参考: https://ioctl.fail/preliminary-analysis-of-aur-malware/ 具体例として、VRストリーミング用パッケージ alvr に npm 関連の不自然な処理が追加されていたことが報告されている 参考: https://linuxiac.com/arch-linux-aur-malware-campaign-hits-multiple-user-contributed-packages/ 自分の環境を確認した paru -Qm でAUR(foreign)パッケージ一覧を出し、第三者がgit logから抽出した影響パッケージ一覧(gr.ht/aur_pkg_list.txt)と照合しました。手元の環境(google-chrome, postman-bin, ngrok など17パッケージ)はリストに一件も含まれてなかった ただしこのリストは非公式・暫定的なもので、対象期間も「直近48時間」程度のため、今後も対象が増える可能性がある。 今後の運用方針 緊急対応は不要と判断したが、完全に無視するのではい。 次回 paru -Syu 実行時に、各パッケージのPKGBUILD差分(特にbuild/installセクション)をざっと確認する binパッケージ(google-chrome, postman-binなど)はメンテナー変更の有無を paru -Si <pkg> で時々確認する というくらいのライトな運用はしようかなと思った。 今回のパターンは「放棄パッケージの乗っ取り」が中心なので、現役メンテナーがついているパッケージなら当面のリスクはかなり低いだろうがね。 所詮メモなので、注意喚起とかやりましょうとか強く推奨はしないがやったほうがいいとは思うかな。

元記事 svg-line: Better Status Bars for Emacs Emacsのmode-line、header-line、tab-bar、tab-lineはそれぞれネイティブAPIレベルで挙動が違い、多段表示・右寄せ・アイコン・マウスイベントの扱いがバラバラという問題がある。svg-lineはこれらをSVG画像として描画することで挙動を統一するパッケージ。 SVGにすることで座標ベースのマウスイベント検出ができるのも地味に大きい。ネイティブAPIだとクリックやホバーが*-lineごとに対応がバラバラだったのが一気に解決される。 この記事に触発されて私も少し触ってみようと思った。 あわよくばこのまま置き換えてもいいかとも思う。 やったこと 既存パッケージの整理 svg-lineを試すために一旦以下を削除・調整した。 nyan-mode → 削除 minions → 削除 spacious-padding → :mode-line-widthの行だけ削除（他の余白設定は残す） svg-lineの導入 (use-package svg-line :straight (:host github :repo "chiply/svg-line")) mode-lineを書いてみた 最小構成から始めて、バッファ名・git branch・メジャーモード・マイナーモード・行列数の2行構成を目指した。 (svg-line-define 'my-mode-line :target 'mode-line :active #'mode-line-window-selected-p :background (lambda () (face-background 'mode-line nil t)) :foreground (lambda () (face-foreground 'mode-line nil t)) :content (lambda () (list (list :left (list (if (buffer-modified-p) "● " " ") (buffer-name)) :right (list (or (and (fboundp 'vc-git--symbolic-ref) (buffer-file-name) (vc-git--symbolic-ref (buffer-file-name))) ""))) (cons (list (symbol-name major-mode)) (list (format-mode-line "%l:%c")))))) (svg-line-activate 'my-mode-line) シンプルにはなったが、やはりnyan-modeがないとさみしい。 ...

きっかけ Life is too short for a slow terminal を読んだ。 とりあえず「自分のzshも計測してみるか」となった。 流石にTerminalとかGPUパワーでFPS改善するとかフレームワーク使うのやめるだとか、ガッツリオリジナルコード書きまくるほどではないにしても明確にコレは駄目だというものがあれば改善したい。 先程の記事の筆者はoh-my-zshもpreztoも使わない主義で30msを達成しているが、私はp10kのUIを捨てるコストは払いたくなかったので、フレームワーク（zinit + p10k）は維持したまま改善できる部分だけ潰す方針にした。 まず計測 time zsh -i -c exit zsh -i -c exit 0.09s user 0.07s system 75% cpu 0.203 total 203ms。遅くはないが伸びしろがある気がする。 zprof で犯人を特定する .zshrc の先頭に： zmodload zsh/zprof 末尾に： zprof を追加して新しいシェルを開くと、関数ごとの所要時間テーブルが出る。上位30件だけ見れば十分。 zprof | head -n 30 num calls time self name ----------------------------------------------------------------------------------- 1) 1518 209.95 0.14 15.98% 153.70 0.10 11.70% :zinit-tmp-subst-zle 2) 60 107.81 1.80 8.20% 87.84 1.46 6.68% _zsh_autosuggest_async_request 3) 4 146.30 36.57 11.13% 67.91 16.98 5.17% _zsh_autosuggest_bind_widgets 4) 796 78.39 0.10 5.96% 67.84 0.09 5.16% _zsh_autosuggest_bind_widget 5) 34 98.12 2.89 7.47% 63.19 1.86 4.81% -fast-highlight-process 6) 2407 59.89 0.02 4.56% 59.89 0.02 4.56% .zinit-add-report ... zinit-tmp-subst-zle が1518回呼ばれていて1位。zinit がZLEウィジェットを差し替えるオーバーヘッドで、これはフレームワーク起因なので直接は触れない。 ...

環境 ラズパイ（Linux）がルーター兼 WireGuard クライアント 配下のデバイス（タブレット等）は eth0 経由でラズパイを通してインターネットへ ラズパイは wlan0 で ISP ルーター（192.168.x.1）に接続 全トラフィックを WireGuard（wg0）経由で VPS に流す構成 VPS は国内 VPS サービス タブレット(192.168.x.x) └─ eth0 ─ ラズパイ(ルーター) ├─ wlan0 ─ ISPルーター ─ インターネット └─ wg0 ─ VPS(国内) ─ インターネット 症状 WireGuard 経由の WiFi で UNEXT が一切見れない YouTube・Amazon Prime Video は問題なし UNEXT の生配信は見れる、VOD だけ駄目 調査 tcpdump で通信を確認 タブレットが UNEXT に接続しようとしたタイミングで tcpdump を仕掛けた。 sudo tcpdump -i eth0 -n 'src <タブレットIP> or dst <タブレットIP>' 2>/dev/null UNEXT のサーバーへの SYN が2回送られているが SYN-ACK が返ってこないことを確認。接続確立できていない。 ...