skmtkytr blog

KDE Plasma から Sway・COSMIC を試して戻ってきた話

Fri, 24 Apr 2026 00:00:00 GMT

きっかけ

KDE Plasma を使っていて、タイリングと軽量化をしたくなった。KDE のウィンドウマネージャー KWin にも KDE 6 からネイティブタイリングが入ったが、Quick Tile ショートカット（Meta+←→）とタイルエディタが別システムで連携しないという問題があった。「どうせならちゃんとしたタイリング WM を試してみるか」というのが出発点だ。

環境

| 項目 | 値 | |------|----| | OS | CachyOS | | GPU | NVIDIA RTX 4090 + AMD Raphael iGPU | | DM | plasmalogin | | Kernel | linux-cachyos 7.0.1 |

Sway を試す

インストール

まず Sway + 周辺ツールを入れた。

sudo pacman -S sway waybar wofi mako swaylock swayidle grim slurp

CachyOS の cachyos-sway-settings 相当のパッケージは存在しないので、設定は全部自前で書く必要がある。chezmoi で管理する形にした。

Nvidia で真っ暗になる問題

ログインすると真っ暗になって何も操作できない状態に。原因は2つあった。

① nvidia-drm.modeset=1 が未設定

Limine ブートローダーを使っているので /boot/limine.conf の cmdline に追記した。

cmdline: quiet nowatchdog splash rw rootflags=subvol=/@ root=UUID=... nvidia-drm.modeset=1

② --unsupported-gpu フラグが渡っていない

Sway は Nvidia proprietary ドライバーを公式サポートしておらず、--unsupported-gpu フラグなしでは起動を拒否する。

plasmalogin は ~/.local/share/wayland-sessions/ を読まずシステムの /usr/share/wayland-sessions/ しか参照しない。シンボリックリンクも pacman 更新時に上書きされる。

最終的に採用した解決策はラッパースクリプト + 別名 .desktop ファイルだ。

# /usr/local/bin/sway-nvidia
#!/bin/sh
exec sway --unsupported-gpu "$@"

# /usr/share/wayland-sessions/sway-nvidia.desktop
[Desktop Entry]
Name=Sway (Nvidia)
Exec=sway-nvidia
Type=Application
DesktopNames=sway;wlroots

sway パッケージとは別ファイルなので更新で上書きされない。/usr/local/bin/ も pacman の管理外なので永続する。

③ Nvidia 環境変数

~/.config/environment.d/20-sway-nvidia.conf に以下を追加した。

LIBVA_DRIVER_NAME=nvidia
GBM_BACKEND=nvidia-drm
__GLX_VENDOR_LIBRARY_NAME=nvidia
WLR_NO_HARDWARE_CURSORS=1
WLR_RENDERER=vulkan

使い心地

起動自体は成功し、タイリングも動いた。ただし KDE で当たり前に使えていた機能を一つずつ手動で揃える必要があった。

KWallet: kwalletd6 を autostart に追加しないと Chrome・Dolphin の認証情報が使えない
クリップボード履歴: cliphist + wl-clipboard を別途セットアップ必要
ダークモード: GTK・Qt それぞれに個別設定が必要
スクリーンショット: grim + slurp（Spectacle は xdg-desktop-portal 設定が必要）

「WM は軽量だが、DE として動かすための周辺整備コストが高い」という結論になった。

COSMIC DE を試す

インストール

CachyOS のリポジトリに v1.0.11 が入っていた。

sudo pacman -S cosmic

cosmic.desktop がセッション一覧に追加されてすぐ使えた。Sway のような --unsupported-gpu 問題は発生せず、Nvidia でもそのまま起動した。

良かった点

タイリングがファーストクラス機能として設計されている点が最大の利点だった。

| キー | 動作 | |------|------| | Super+←→↑↓ | フォーカス移動 | | Super+Shift+←→↑↓ | ウィンドウ移動 | | Super+G | タイル/フローティング切り替え | | Super+S | ウィンドウスタック（タブ化） | | hjkl | Vim ナビゲーション対応 |

KWin のように「タイルエディタと Quick Tile が別システム」という問題がない。ワークスペース単位でタイリングの ON/OFF も切り替えられる。

厳しかった点

GTK/Qt テーマ統合が未熟: ダークモードを設定しても Chrome のブックマークバー等に適用されない。KDE は kde-gtk-config が自動同期してくれるが COSMIC にはまだない
クリップボード履歴なし: KDE の Klipper 相当の機能がビルトインでない
カスタマイズ性: KDE に比べると設定項目が少ない

まとめ

| | KDE Plasma | Sway | COSMIC | |--|-----------|------|--------| | タイリング | △ Quick Tile とエディタが別 | ◎ ネイティブ | ◎ ファーストクラス | | Nvidia 対応 | ◎ | △ 要設定 | ○ | | 周辺統合 | ◎ KWallet・クリップボード等完備 | △ 全部手動 | ○ 標準で揃ってる | | テーマ統合 | ◎ | △ | △ GTK/Qt が課題 | | 成熟度 | ◎ | ◎ | △ v1.0 リリース直後 |

結論として今回は KDE Plasma に戻ることにした。タイリングの体験は COSMIC が一番良かったが、GTK テーマ統合・クリップボード履歴など日常使いに必要な機能の完成度がまだ KDE に及ばない。

COSMIC は成熟するのを待ってまた試したい。

Ryzen 7 7800X3D + CachyOS のパフォーマンスベースラインを記録する

Fri, 17 Apr 2026 00:00:00 GMT

なぜベースラインを取るのか

デスクトップ環境を一通り整え終えたタイミングで、「今のこのマシンがどれくらいの性能で動いているか」を数値で残しておきたくなった。理由は単純で、将来「なんか遅くなった？」と感じたときに比較する基準がないと、気のせいか本当に劣化しているかを判断できないからだ。

カーネル更新、BIOS アップデート、新しいメモリへの換装、Curve Optimizer の適用——どれも体感では数%の差しかわからない。ベンチマーク値があれば、あとから「この変更でどれだけ変わったか」を客観的に見返せる。

この記事は、そのための記録だ。

環境

| 項目 | 値 | | ------ | ----------------------------------------------------------- | | CPU | AMD Ryzen 7 7800X3D (8C/16T, Zen4 X3D, 96MB L3) | | Board | MSI MAG X670E TOMAHAWK WIFI (MS-7E12) | | BIOS | 1.KB (2026-03-17) | | RAM | Corsair CMK32GX5M2B5200C40 (DDR5-5200 CL40, 2×16GB) | | GPU | NVIDIA RTX 4090 + AMD Raphael iGPU | | OS | CachyOS (Arch 系) | | Kernel | linux-cachyos 7.0.0-1 (znver4 build, EEVDF + LTO + AutoFDO) |

BIOS 側は以下を有効化済み。

EXPO (DDR5-5200 CL40 プロファイル) → 5200 MT/s で動作確認
Re-Size BAR (RTX 4090 の BAR1 が 32GB で認識)
IOMMU (AMD-Vi)
SVM / Virtualization
Curve Optimizer: 未適用 (Auto)
PBO Limits: Auto / Scalar: 1X

Curve Optimizer はあえて入れていない。理由は後述。

測定するもの

ベースラインとして残す価値があるのは、時間経過や設定変更で変わりうる値で、かつ単発の測定で再現性のある値だ。以下の3つに絞った。

メモリ帯域 — EXPO 設定と FCLK の効きを見る (STREAM)
メモリレイテンシ — キャッシュ階層と DRAM のレイテンシを見る (pointer-chase)
CPU スループット — メモリと CPU の複合負荷を見る (7z benchmark)

STREAM: メモリ帯域

STREAM は John McCalpin による定番のメモリ帯域ベンチマーク。Copy / Scale / Add / Triad の 4 種類の単純なループで、持続的なメモリ帯域を測る。

Arch のリポジトリに stream パッケージはあるが、名前が ImageMagick の stream コマンドと衝突するので、ソースから小さく書き起こした。-march=znver4 で AVX-512 まで使わせて、OpenMP で 16 スレッド並列化している。

// 抜粋。完全版は記事末尾の再現コマンド参照
#pragma omp parallel for
for (long i=0; i<N; i++) a[i] = b[i] + scalar * c[i];  // Triad

結果

| Kernel | MB/s | | --------- | ---------- | | Copy | 35,071 | | Scale | 35,150 | | Add | 38,304 | | Triad | 38,800 |

DDR5-5200 デュアルチャネルの理論ピークは 5200 × 8 × 2 = 83.2 GB/s。実測 Triad はその 46.6% にあたる。STREAM は書き込みを伴うのでピークの 40〜50% が典型値、今回の数字はスペック相応だ。

もし DDR5-6000 CL30 に換装すれば、経験的に Triad は 55〜60 GB/s 付近まで伸びる。5200 CL40 構成の実力はこのあたりが天井。

Pointer-chase: メモリレイテンシ

帯域と並んでメモリ性能を決めるもう一つの軸がレイテンシ。ベンチマークとしてはリンクリストを辿るだけの単純なループで、各アクセスが前のアクセスの結果に依存するため キャッシュやメモリコントローラのレイテンシが直接そのまま見える。

配列サイズを L1 / L2 / L3 / DRAM それぞれに収まる大きさに変えながら測定することで、キャッシュ階層ごとのアクセスコストがわかる。

// 単一コアで、ランダムな順序に繋がったチェーンを辿る
for (size_t i=0; i<iters; i++) p = chain[p];

結果

| Region | Latency | 階層 | | ------ | ------- | ------------------ | | 32 KB | 1.0 ns | L1D (各コア 32KB) | | 256 KB | 3.1 ns | L2 境界 | | 1 MB | 5.8 ns | L2 (1MB/core) | | 8 MB | 10.9 ns | L3 (V-cache内) | | 32 MB | 11.7 ns | L3 (V-cache内) | | 96 MB | 32.1 ns | L3 境界 | | 256 MB | 70.9 ns | DRAM | | 1 GB | 87.1 ns | DRAM + TLB miss |

32MB アクセス時のレイテンシが 11.7 ns で粘っているのが 7800X3D の最大の特徴だ。通常の Zen4 (例: 7700X) だと L3 は 32MB で、32MB アクセス時にはすでに DRAM に近い 30 ns 超まで伸びてしまう。

7800X3D は 3D V-Cache によって 96MB の L3 を持っており、今回のベンチでもそれが忠実に可視化された。96MB を超えたところで急に 32 ns → 71 ns にジャンプするのが L3 → DRAM の境界だ。

DRAM レイテンシ 71 ns は DDR5-5200 としては標準的な値。EXPO が効いていないと JEDEC 4800 MT/s で動作し、レイテンシは 80 ns 近くまで悪化する。

7z benchmark: CPU + メモリ複合

7z b は CPU とメモリの両方を使う LZMA 圧縮ベンチで、Linux 環境で手軽に実行できる複合指標として便利だ。

7z b -mmt16 | tail -5

結果

| 項目 | 値 | | ------------- | ---------------- | | Compression | 112,687 MIPS | | Decompression | 129,503 MIPS | | Total | 121,095 MIPS | | 1T Freq | 4,795〜5,036 MHz | | 16T Freq | 4,395〜4,555 MHz |

7800X3D ストック設定の典型値。Curve Optimizer -20 を全コアに入れると、この値は +5〜8% 程度伸びる余地がある (16T 実効クロックが 4,700 MHz 付近まで上がるため)。

温度と Preferred Core

あわせて記録しておいた。

Idle 温度

Tctl:   47.5°C
Tccd1:  35.8°C

CCD 温度 35°C は 7800X3D としては相当涼しい部類。負荷時も 80°C に届かない構成になっている。

Preferred Core ランキング

amd-pstate は acpi_cppc/highest_perf の値を見て、シリコン品質が良いコアにシングルスレッド負荷を寄せる。値を見ればチップの個体差がわかる。

| Core | highest_perf | | ---- | ------------ | | cpu1 | 196 | | cpu5 | 196 | | cpu0 | 191 | | cpu3 | 186 | | cpu2 | 181 | | cpu4 | 176 | | cpu7 | 171 | | cpu6 | 166 |

最大値と最小値の差が 30 (= 5.05 GHz 換算で約 150 MHz) 程度。平均的な個体で、特に「ハズレ」でも「当たり」でもない。シングルスレッドは cpu1 / cpu5 に寄るのでここが一番伸びるコアだ。

なぜ Curve Optimizer を入れないか

Zen4 + X3D の定番チューニングとして Curve Optimizer (CO) がある。各コアの電圧曲線を負方向にオフセットすることで、同クロックで温度が下がり、結果的にブースト時間が伸びる——という仕組みで、上手くいけば 5〜8% 伸びる。

今回入れなかったのは以下の理由。

温度に余裕がありすぎる: Tctl 47°C は熱で全く律速されていない状態。CO の主目的 (温度↓ → クロック↑) の効果が薄い
X3D の不安定性は検出が厄介: 非X3D と違って、X3D の CO 失敗は「数週間に一度クラッシュ」という形で出やすく、CO のせいかどうか永遠に疑い続けることになる
体感差が小さい: devcontainer ビルドやコンパイルで +5% は人間には感じ取れない領域

「ベンチマーク趣味」としてやる価値はあるが、道具としてのマシンの安定性を優先するなら今回はスキップが正解と判断した。

将来メモリ換装 (DDR5-6000 CL30) と同時に CO もテストしたくなるかもしれない。そのときにこのベースラインが比較対象として効いてくる。

再現コマンド

以降、同じ条件で測定するための最小コマンド。

# === STREAM ===
cat > /tmp/stream_bench.c <<'EOF'
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <omp.h>

#define N (100L * 1024 * 1024)
#define NTIMES 10
static double a[N], b[N], c[N];

double wtime(void) {
    struct timespec t;
    clock_gettime(CLOCK_MONOTONIC, &t);
    return t.tv_sec + t.tv_nsec * 1e-9;
}

int main() {
    #pragma omp parallel for
    for (long i = 0; i < N; i++) { a[i] = 1.0; b[i] = 2.0; c[i] = 0.0; }
    double scalar = 3.0;
    double best_copy=1e30, best_scale=1e30, best_add=1e30, best_triad=1e30;
    for (int k = 0; k < NTIMES; k++) {
        double t;
        t = wtime(); _Pragma("omp parallel for") for (long i=0; i<N; i++) c[i] = a[i];
        t = wtime()-t; if (t<best_copy) best_copy=t;
        t = wtime(); _Pragma("omp parallel for") for (long i=0; i<N; i++) b[i] = scalar*c[i];
        t = wtime()-t; if (t<best_scale) best_scale=t;
        t = wtime(); _Pragma("omp parallel for") for (long i=0; i<N; i++) c[i] = a[i]+b[i];
        t = wtime()-t; if (t<best_add) best_add=t;
        t = wtime(); _Pragma("omp parallel for") for (long i=0; i<N; i++) a[i] = b[i]+scalar*c[i];
        t = wtime()-t; if (t<best_triad) best_triad=t;
    }
    double bytes = 2.0 * sizeof(double) * N;
    printf("Copy:  %8.1f MB/s\n", bytes/best_copy/1e6);
    printf("Scale: %8.1f MB/s\n", bytes/best_scale/1e6);
    printf("Add:   %8.1f MB/s\n", 3.0*sizeof(double)*N/best_add/1e6);
    printf("Triad: %8.1f MB/s\n", 3.0*sizeof(double)*N/best_triad/1e6);
    return 0;
}
EOF
gcc -O3 -march=znver4 -fopenmp /tmp/stream_bench.c -o /tmp/stream_bench
OMP_NUM_THREADS=16 /tmp/stream_bench

# === 7z ===
7z b -mmt16 | tail -10

# === 温度 ===
sensors | grep -E "Tctl|Tccd"

# === Prefcore ===
for c in (seq 0 7)
    echo "cpu$c: "(cat /sys/devices/system/cpu/cpu$c/acpi_cppc/highest_perf)
end

おわりに

ベンチマークは「マシンを褒める道具」として使うより、「将来の自分への差分情報」として残すほうが実用価値が高い。

CO を入れるかどうか、メモリを換装するかどうか、カーネルを更新するかどうか——どの判断も、この数字と比較できることで「本当に効いたのか」がはっきりする。

次に同じコマンドを叩くのは、たぶん DDR5-6000 CL30 に換装したときか、CachyOS のカーネルが 7.x 後半に上がったときだろう。そのときこの記事を開き直して、どれだけ変わったかを確認する予定だ。

BitTorrentクライアントをAIエージェントだけで作った話

Mon, 13 Apr 2026 00:00:00 GMT

はじめに

「BitTorrent クライアントを Go でゼロから書きたい」——そう思い立ってから完成まで、かかった時間は約 3.5 日だった。

成果物は stor。外部の torrent ライブラリに一切依存せず、bencode パーサーから DHT、uTP、暗号化まで全てスクラッチで実装した BitTorrent クライアントだ。Web UI、Chrome 拡張、Docker イメージまで含めて、129 コミット。

そしてこのプロジェクトは、コードの実装をほぼ全て Claude Code（AI エージェント）に任せて完成させた。

何を作ったか

stor が実装している主な仕様は以下の通り。

| カテゴリ | 内容 | |---------|------| | プロトコル | BEP 3 (BitTorrent Protocol), BEP 5 (DHT), BEP 29 (uTP/LEDBAT) | | 拡張 | BEP 6 (Fast Extension), BEP 9 (Metadata Exchange), BEP 10 (Extension Protocol), BEP 11 (PEX) | | トラッカー | BEP 12 (Multitracker), BEP 15 (UDP Tracker), BEP 23 (Compact Peers) | | その他 | BEP 19 (WebSeed), BEP 27 (Private Torrents), BEP 52 (v2 Hybrid) | | セキュリティ | MSE/PE (768-bit DH + RC4), DNS Rebinding 対策, Path Traversal 防止 |

14 の BEP をカバーし、ダウンロードからシーディング、暗号化、DHT によるトラッカーレス通信まで一通り動く。Web UI は SvelteKit で Deluge 風のレイアウトを作り、Go バイナリに embed して単一バイナリで配布できるようにした。Docker イメージは distroless ベースで約 9 MB。

人間がやったこと

コードを書いたのはほぼ全て Claude Code だが、人間（自分）の役割がなかったわけではない。自分がやったのは以下のようなことだ。

アーキテクチャの方向づけ

最初のプロンプトでプロジェクトの大枠を伝えた。「Go でゼロ依存の BitTorrent クライアントを作る」「デーモンモードで動かして JSON-RPC で操作する」「Web UI は SvelteKit で embed する」といった設計判断は人間が行った。

レビューと品質管理

実装がある程度進んだ段階で、こんなプロンプトを投げた。

goにおけるアンチパターンがないかコードを全部レビューして

Claude Code がコード全体を走査して問題点をリストアップしてくる。ただし AI のレビュー結果を鵜呑みにはしない。

HIGHのものが本当に起きているか詳細に確認して、パット見だけで言ってないか

「本当に起きるのか？」と突き返すと、誤検知が削ぎ落とされて本当の問題だけが残る。確認が取れたら修正を指示する。

対応して, TDD準拠 RED first

テスト駆動で直させる。この一連の流れ——レビュー → 精査 → TDD で修正——がセキュリティ強化のフェーズでは特に効いた。4/12 だけで 20 件以上のセキュリティ修正コミットが入っているが、SSRF、Path Traversal、DNS Rebinding、Integer Overflow、Race Condition といった脆弱性を体系的に潰せたのはこのプロセスのおかげだ。

デバッグの方向づけ

実際に動かしてみると当然バグは出る。例えば DHT 周りではこんなやり取りがあった。

DHTノードがずっと0なんだけどそんなことある？
delugeのときは300くらいずっとあったんだけど

既存クライアント（Deluge）との比較で「何かがおかしい」と気づくのは人間の仕事だ。Claude Code は原因を調査して修正するが、「おかしい」と感じるセンサーは人間にしかない。

DHTノードの情報は再起動すると揮発する？

必須だなそれは

DHT ルーティングテーブルの永続化が必要だと判断したのも人間。「それは必要だ」という一言で実装が走る。

リリース管理

意図ごとにcommit push

tag bumpして

docker image build push, ciに組み込みたいなこれ

コミットの粒度、バージョニング、CI/CD の構成も人間が指示した。

3.5 日の流れ

振り返ると、開発は大まかに 4 つのフェーズに分かれていた。

Day 1（4/10）: コア実装

bencode パーサー、ピアプロトコル、トラッカー通信、DHT の基本実装。同時に Web UI の骨格と Chrome 拡張も作った。この日だけで 50 コミット以上。デーモンモード、Docker 対応、日本語 README まで含めて一気に形にした。

Day 2（4/11）: 機能拡充

BEP 6 (Fast Extension)、BEP 19 (WebSeed)、BEP 27 (Private Torrents)、BEP 52 (v2 Hybrid) を追加。uTP の統合、アップロード機能の実装もこの日。「動くもの」から「ちゃんと動くもの」への移行期間。

Day 3（4/12）: セキュリティ強化とリリース

コード全体のレビューを実施。bencode の DoS 対策、トラッカーレスポンスのサイズ制限、SSRF 防止、Race Condition の修正など、セキュリティを体系的に強化した。goreleaser による自動リリース、Homebrew tap の設定もこの日。

Day 4（4/13）: 安定化

DHT ルーティングテーブルの永続化、PEX の panic 修正、goroutine リークの修正、データ競合の解消。最後の磨き込み。

エージェント駆動開発で見えたこと

プロンプトは短いほどいい

振り返ると、効果的だったプロンプトはどれも短い。「対応して, TDD準拠 RED first」「必須だなそれは」「commit push tag bump」。コンテキストが共有されている状態では、長い説明は不要だった。

人間の仕事は「判断」と「検証」

コードを書く速度では AI に勝てない。でも「何を作るか」「この品質で十分か」「これはおかしい」という判断は人間にしかできない。DHT ノードが 0 のままだと気づいたのは、Deluge での運用経験があったからだ。

レビューは二段階で

AI にレビューさせると、実際には起きない問題も指摘してくる。「本当に起きるか確認して」と一度突き返すだけで精度が大幅に上がる。このフィルタリングは今後も使えるパターンだと思う。

セキュリティは AI の得意分野

SSRF、Path Traversal、DNS Rebinding、Integer Overflow——こうした教科書的な脆弱性を網羅的にチェックするのは AI が圧倒的に得意だ。人間がひとつひとつ確認するのに比べて、漏れが少なく速い。

数字で見る stor

| 指標 | 値 | |------|------| | 開発期間 | 約 3.5 日 | | コミット数 | 129 | | 実装した BEP | 14 | | Go コード | 約 18,000 行 | | 外部依存 | 0（標準ライブラリのみ） | | Docker イメージ | ~9 MB | | Web UI | SvelteKit SPA（バイナリ埋め込み） |

おわりに

3.5 日で BitTorrent クライアントが作れたのは、AI エージェントのおかげだ。ただし「AI が全部やってくれた」わけではない。アーキテクチャの設計、品質の判断、バグに気づくセンサー、リリースの意思決定——これらは全て人間の仕事だった。

AI エージェント駆動の開発は、人間の役割を「コードを書く人」から「プロダクトの方向を決める人」に変える。それは制約ではなく、レバレッジだと思う。

リポジトリ: skmtkytr/stor

Hello World

Sun, 12 Apr 2026 00:00:00 GMT

はじめまして

技術ブログを開設しました。日々の開発で学んだことを記録していきます。