Pgit:Linux カーネルを PostgreSQL にインポートしました。

2026/04/05 21:08

Pgit:Linux カーネルを PostgreSQL にインポートしました。

RSS: https://news.ycombinator.com/rss

要約

日本語訳:

概要:
20年間にわたるLinuxカーネルの歴史(1 428 882コミット)が、pgitと呼ばれるPostgreSQLベースのシステムに完全にロードされました。これはpg‑xpatchデルタ圧縮ツールを使用しています。140万件以上のコミットをインポートするには、AMD EPYCサーバーでわずか2時間しかかからず、テキスト内容は123 GBから約1.1 GB(≈53倍圧縮)に縮小しました。結果として生成されたデータベースは24 Mファイルバージョン、3.09 Mユニークブロブ、171 525パスを137 600のデルタグループに折りたたみ、ディスク上で約6.6 GB(実際のデータ量2.7 GB)を占有します。

リポジトリ指標とパターン:

  • 38 506人のユニーク著者 vs 1 540人のコミッタ(25:1比)。
  • コミットの90%が5つ以下のファイルに触れ、最大の単一マージは53 003ファイルに影響。
  • 結合分析では頻繁な共変更(例:i915/intel_drv.hintel_display.c, 1 117回)とBPFヘッダーなどの隠れた依存関係が浮き彫りになりました。

マージ活動:
主要メンテナ3名がマージを主導しています:David S. Miller(113 k)、Greg Kroah‑Hartman(105 k)、Linus Torvalds(102 k)。彼らのマージ比率は自身のコミット数の2.3倍から7.3倍です。

企業貢献:
Intelが83 kコミットでリード、Red Hatが次点(エンジニア1人あたり110コミット)、kernel.orgメンテナは平均約306コミット/人、Amazonの寄与はごくわずか(1人あたり14コミット)。

その他の観察事項:

  • 最も修正されたコミットには665件の「Fixes:」参照があり、2番目に多いものは196。
  • コミットメッセージ内の不適切語数:8 435件「workaround」、2 438件「hack」、2 161件「ugly」、533件「crap」、268件「stupid」、81件「damn」、29件「shit」、7件「fuck」。完全なFバンを使用したのはAl ViroとLinus Torvaldsのみ。
  • 三重リバートは3件だけで、すべてメモリ管理またはステージングサブシステムに関連しています。

パフォーマンスと将来利用:
ほとんどの分析は数秒で実行できます(例:結合解析48 s、著者解析34 s)。これはSQLが歴史的洞察を提供する力を示しています。チームはpgitをさらに深い依存関係解析に適用し、高影響ファイルペアの特定や回帰トラッキングを行いながら高速クエリ性能を維持する計画です。

インパクト:
カーネルメンテナはコミットパターンを照会してマージ戦略を洗練でき、企業はコード品質の監査やテスト対象となる重要ファイルを特定できます。このような大規模ソフトウェア履歴に対するSQLデータベースの成功は、他の大規模オープンソースプロジェクトにも同様の手法が有益であることを示唆しています。

本文

TL;DR
Linuxカーネルの全履歴を pgit に取り込んだ – 1 428 882コミット、24.4 百万ファイルバージョン、20年にわたる開発 ― を PostgreSQL 上でデルタ圧縮して保存しました。

  • 実データ量:2.7 GB(
    git gc --aggressive
    では1.95 GB)
  • インポート時間:専用サーバーで2 h
  • コミットメッセージに含まれる f‑bomb は 1.4 百万件中 7 件(全て 2 人から)
  • 665 件のバグ修正が同一コミットを指している
  • ファイルシステムは 13 年かけて統合

Linuxカーネルを SQL データベースとして扱う。


インポートについて

この投稿は pgit: What If Your Git History Was a SQL Database? を踏まえて書いたものです。
簡潔に言えば pgit は Git に似た CLI で、すべてのデータをファイルシステムではなく PostgreSQL 上に置きます。

pg-xpatch
を利用して透明なデルタ圧縮を行い、コミット履歴全体を SQL クエリで検索できるようにします。

HN のフロントページで Linux カーネルのインポートを発表した際、実際に何が起きたかをまとめました。

Linux カーネルは世界最大級のアクティブ開発リポジトリです。

  • 1.4 百万コミット(20 年)
  • 171 000 ファイル
  • 38 000 コントリビュータ

私が調べた限り、git 以外でカーネル履歴全体をインポートした VCS は数少ないです。Fossil(SQLite ベース)は未実装、Darcs と Monotone はパフォーマンス問題に直面しました。Mercurial では可能ですが、私の経験では pgit が最適でした。

pgit は以下のデータを扱いました。

指標
コミット数1 428 882
ファイルバージョン(file refs)24 384 844
ユニークブロブ3 089 589
ユニークパス171 525
パスグループ(デルタチェーン)137 600
インポート時間2 h 0 m 48 s

インポートはフィンランドの Hetzner 専用サーバーで実行。CPU は AMD EPYC 7401P、RAM 512 GB、ストレージは RAID 0 の SSD(合計 3.84 TB)です。

xpatch
コンテンツキャッシュは 350 GB を確保しています。


サーバー構成・git ベースライン・pgit 設定

サーバー

CPU: AMD EPYC 7401P (24 コア / 48 スレッド)
RAM: 16×32 GB DDR4 ECC (512 GB 合計)
ストレージ: 2×Micron SSD SATA 1.92 TB Datacenter (RAID 0)
NIC: 1 Gbps Intel I350
コスト: 約€272/月

OS インストール

  • Hetzner の installimage で Ubuntu 24.04 LTS をインストール
  • RAID 0 (
    SWRAIDLEVEL 0
    ) でスループット最大化(冗長性不要)
  • パーティション配置
    • /boot
      ext3, 1 GiB
    • swap
      swap, 4 GiB
    • /
      ext4, 残り (~3.5 TB)

OS チューニング

# パッケージ更新・インストール
apt update && apt upgrade -y
apt install -y tmux btop htop iotop cpufrequtils numactl git curl wget unzip build-essential ufw linux-tools-common linux-tools-$(uname -r)

# CPU governor → performance
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do echo performance > "$cpu"; done
cat > /etc/default/cpufrequtils << 'EOF'
GOVERNOR="performance"
EOF
systemctl enable cpufrequtils && systemctl restart cpufrequtils

# カーネルミティゲーションをオフ
sed -i 's/GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0"/GRUB_CMDLINE_LINUX_DEFAULT="consoleblank=0 mitigations=off"/' /etc/default/grub.d/hetzner.cfg
update-grub

# sysctl チューニング
cat >> /etc/sysctl.conf << 'EOF'
vm.swappiness = 1
vm.dirty_ratio = 5
vm.dirty_background_ratio = 2
kernel.numa_balancing = 1
EOF
sysctl -p

# Transparent Huge Pages を無効化
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag
cat > /etc/systemd/system/disable-thp.service << 'EOF'
[Unit]
Description=Disable Transparent Huge Pages
DefaultDependencies=no
After=sysinit.target local-fs.target
Before=basic.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag'

[Install]
WantedBy=basic.target
EOF
systemctl daemon-reload && systemctl enable disable-thp

# noatime を有効化
sed -i 's|relatime|noatime|g' /etc/fstab
mount -o remount,noatime /

# ファイアウォール設定
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw --force enable

# Go 1.26.0 をインストール
wget https://go.dev/dl/go1.26.0.linux-amd64.tar.gz
rm -rf /usr/local/go && tar -C /usr/local -xzf go1.26.0.linux-amd64.tar.gz
rm go1.26.0.linux-amd64.tar.gz
echo 'export PATH=$PATH:/usr/local/go/bin:$HOME/go/bin' >> ~/.bashrc
source ~/.bashrc

# Docker をインストール
apt install -y docker.io
systemctl enable docker && systemctl start docker

reboot

pg-xpatch コンテナ

docker pull ghcr.io/imgajeed76/pg-xpatch:latest

pgit バージョン

pgit v4
で、インポート時にまだリリースされていなかったローカル変更を加えました。主な変更点は
seq
列の追加(モノトニックタイムスタンプハックを置き換)と
--timeout
フラグの追加です。

pgit 設定

# PostgreSQL コア設定
pgit config --global container.shared_buffers 64GB
pgit config --global container.effective_cache_size 400GB
pgit config --global container.work_mem 256MB
pgit config --global container.wal_buffers 512MB
pgit config --global container.max_wal_size 32GB
pgit config --global container.checkpoint_timeout 60min
pgit config --global container.max_connections 50
pgit config --global container.port 5433
pgit config --global container.shm_size 450g

# 並列処理(24c/48t EPYC)
pgit config --global container.max_worker_processes 28
pgit config --global container.max_parallel_workers 24
pgit config --global container.max_parallel_per_gather 12

# Xpatch コンテンツキャッシュ (350 GB)
pgit config --global container.xpatch_cache_size_mb 358400
pgit config --global container.xpatch_cache_max_entries 41000000
pgit config --global container.xpatch_cache_max_entry_kb 16384
pgit config --global container.xpatch_cache_slot_size_kb 4
pgit config --global container.xpatch_cache_partitions 24

# Xpatch サブキャッシュ
pgit config --global container.xpatch_group_cache_size_mb 256
pgit config --global container.xpatch_tid_cache_size_mb 4096
pgit config --global container.xpatch_seq_tid_cache_size_mb 4096

# Xpatch 挿入 / エンコード
pgit config --global container.xpatch_insert_cache_slots 256
pgit config --global container.xpatch_encode_threads 2
pgit config --global container.xpatch_warm_cache_workers 24

# インポートワーカー数
pgit config --global import.workers 24

設定の根拠(概要)

パラメータ理由
shared_buffers
64 GBディスク上のデータセットは約20 GB、余裕を持って 3 倍に設定
effective_cache_size
400 GBshared_buffers + OS ページキャッシュ + xpatch キャッシュ
work_mem
256 MB1 接続あたりのソート/ハッシュ結合用メモリ(50 接続 × 256 MB = 12.8 GB)
wal_buffers
512 MBバルクインポート時の書き込みバーストを吸収
max_wal_size
32 GB大量書き込み時にチェックポイント遅延
checkpoint_timeout
60 min強制チェックポイントによる I/O スタール最小化
shm_size
450 GBshared_buffers + xpatch キャッシュ + 内部構造のオーバーヘッドを考慮

git ベースライン測定

cd /root
git clone --single-branch --branch master https://github.com/torvalds/linux.git
cd linux

git rev-list --count HEAD                               # 1,428,882
git gc --quiet && du -sb .git/objects/pack/*.pack       # 6 213 222 259 (5.79 GB)
git cat-file --batch-all-objects --batch-check='%(objecttype) %(objectsize)' \
  | awk '{sum += $2} END {printf "%.2f GB\n", sum/1024/1024/1024}'   # 144.43 GB
time git fast-export --reencode=yes --show-original-ids master > linux.fastexport   # 17m18s, 126 GB
time git gc --aggressive --quiet && du -sb .git/objects/pack/*.pack       # 2 093 181 079 (1.95 GB)
指標
未圧縮オブジェクトサイズ144.43 GB
git gc
後のパックファイル
5.79 GB
git gc --aggressive
1.95 GB
Fast‑export サイズ126 GB
インポート時間2 h 0 m 48 s

インポートプロセス

cd /root/linux-analysis
pgit init
time pgit import /root/linux --branch master --fastexport /root/linux.fastexport
フェーズ時間
コミットインポート39 m 57 s
コミットグラフ構築13 s (最大深さ 75,641)
パスグループ計算9.6 s (137,600 グループ)
ブロブインポート1 h 17 m
インデックス再構築38 s
合計2 h 0 m 48 s (壁時間)、336 m 50 s CPU、21 m 12 s システム

圧縮率

比率
未圧縮オブジェクト144.43 GB (1×)
pgit
(ディスク上)
6.6 GB (21.9×)
git gc
通常
5.79 GB (24.9×)
pgit
(実データ)
2.7 GB (53.5×)
git gc --aggressive
1.95 GB (74.1×)

git gc --aggressive
が最も圧縮率が高く、1.95 GB は pgit の実データ 2.7 GB より約38 % 小さいです。
Linux カーネルはコード再利用が多く、SPDX ヘッダーや
.c/.h
ファイルの共通パターンが豊富なため、ファイルレベルでのデルタ圧縮に非常に適しています。

テキストのみ: 114.4× の圧縮。
xpatch は 123 GB のソーステキストを 1.1 GB に圧縮し、残り 1.6 GB はメタデータ(ファイル ↔ コミットマッピング、パスマッピング、リファレンス)です。カーネル全歴史でバイナリブロブはわずか 52 個しか存在せず、ほぼ完全にテキストです。


ディスク上の詳細

コンポーネントサイズ
コミット(xpatch)600 MB
テキストコンテンツ(xpatch)1.3 GB
バイナリコンテンツ(xpatch)2.0 MB
ファイル refs(ヒープ)2.1 GB
パス(ヒープ)13.2 M B
その他(refs, メタデータ, sync)40.0 KB
インデックス2.7 GB
ディスク総計6.6 GB
  • 171,525 パスは 137,600 のデルタグループに圧縮(リネーム/コピー検出)
  • 24.4M ファイル refs は 3.1M ユニークコンテンツバージョンを指し、7.9× のブロブ重複除去が実現

1.4 百万コミットから分かること

すべてのクエリは PostgreSQL 上で直接実行され、ほとんどは 10 秒以内に完了しました。マテリアライズドビューや事前処理は一切行っていません。

著者

  • 38,506 ユニーク著者(メールアドレス)
  • 1,540 のみがマージ権限を持つ(25:1 の比率)
  • 14,000 が 1 件だけのパッチを寄与し、以後は戻っていない

コミットサイズ

ファイル数コミット数%
1 file875 54161.3 %
2–5 files414 01829.0 %
6–10 files70 9515.0 %
11–50 files49 7003.5 %
51+ files18 5231.3 %

「論理的変更は1コミットに収める」というカーネルの原則が守られています。最大で53,003ファイルを触ったコミットも、トップ5 の大きなコミットはサブシステムメンテナからのマージです。

ファイル結合(共変更分析)

  • 最高結合ペア:
    i915/intel_drv.h
    i915/intel_display.c
    – 1,117 回共変更
  • その他注目ペア:
    include/uapi/linux/bpf.h
    tools/include/uapi/linux/bpf.h
    (742回)、
    net/ipv4/tcp_ipv4.c
    net/ipv6/tcp_ipv6.c
    (739回)

マージ階層

  • David S. Miller – 113 456 コミット、15 617 マージ(7.3×)
  • Greg Kroah‑Hartman – 105 733 コミット、7 073 マージ(15×)
  • Linus Torvalds – 102 322 コミット、4 525 マージ(2.3×)

企業貢献

組織コミット数著者
Intel83 1871 704
Red Hat72 695658
kernel.org69 451227
Linaro43 524263
AMD42 2701 017
SUSE35 711222
Google29 276809
Huawei24 156540
Amazon1 688121

Intel がトップで、Red Hat チームは 1 人あたり平均110 コミットと最も生産的です。kernel.org のメンテナは平均 306 コミット。

Gmail vs 企業の傾向

  • 2010 年に「ハビエリスト」コミット(Gmail)がピークで、全体の約12 %
  • 2025 年までに 約8 % に減少
  • 絶対数は安定(年平均7 K 件)、ただしカーネルはより企業寄与が増加

バグ修正の進化

Fixes:
タグは 2013 年以前はほぼ無視されていたが、現在では >25 % のコミットに現れます。

  • 最も参照されたコミット:
    1da177e4c3f4
    (Linus の初期 git インポート、2005/04/16) – 665 バグ修正がこのコミットを指す
  • 次に多いのは
    dd08ebf6c352
    (Intel Xe GPU ドライバ)、約2 年で 196 修正

言語表現

7 件の f‑bomb がコミットメッセージに含まれ、全て Al Viro(5)と Linus Torvalds(2)から。
ソースコード内では

pgit search "fuck"
で現在ファイルは 8 件、履歴全体で 50 件以上が 44 秒で検索可能。

単語頻度(コミットメッセージのみ):

単語カウント
workaround8 435
hack2 438
ugly2 161
stupid533
crap268
damn81
shit29
fuck7

三重リバート

全履歴で 3 件だけが「リバートのリバートのリバート」。メモリー管理やステージングサブシステムに関係。


カーネルの物語

  • 週末ワーカー: Jonathan Cameron, Christophe JAILLET など、週末に 50 % 超のコミットを行う
  • 単一ファイル愛好家: Connor McAdams(89 件)や Lydia Wang(63 件)はそれぞれ 1 ファイルのみを対象
  • キャリア軌跡: James Bottomley は 20 年で 19 ドメインからコミット、Linus は 12、David S. Miller は 11
  • クリスマスコミット: 21 年のうち一度もゼロコミットのクリスマスはなく、2005 年でも少なくとも1件
  • 最忙しい日: 2022/11/18 – 662 コミット、Uwe Kleine‑König が 583 件

クエリ性能

すべてのクエリは 1.4 百万コミットを対象に実行しました。

クエリ時間
スタッツ & 圧縮情報2.1 s
ファイル変更量(24.4M refs)2.3 s
ホットスポット1.8 s
結合度(Goで計算)48.3 s
著者一覧(全スキャン)34.3 s
年次活動9.4 s
現在ファイルの全文検索25 s
全履歴の全文検索44 s

マテリアライズドビューや前処理は一切行っていません。すべて PostgreSQL と

pg-xpatch
のデルタ圧縮で実現。


分析に使用した SQL コマンド

-- ストレージ & 圧縮情報
pgit stats --xpatch

-- 変更量分析
pgit analyze churn --limit 30

-- ホットスポット
pgit analyze hotspots --depth 1 --limit 25

-- 著者リスト
pgit analyze authors --limit 30 --timeout 60m

-- 年次活動
pgit analyze activity --period year --limit 25 --timeout 60m

-- 結合度分析
pgit analyze coupling --limit 30 --timeout 60m

-- マージ階層(SQL)
SELECT committer_name,
       COUNT(*) AS merged,
       SUM(CASE WHEN author_name = committer_name THEN 1 ELSE 0 END) AS self_authored
FROM pgit_commits
GROUP BY committer_name
ORDER BY merged DESC LIMIT 15;

-- 企業寄与
SELECT CASE
         WHEN author_email LIKE '%@intel.com'    THEN 'Intel'
         WHEN author_email LIKE '%@redhat.com'   THEN 'Red Hat'
         WHEN author_email LIKE '%@kernel.org'   THEN 'kernel.org'
         /* … */
       END AS org,
       COUNT(*) AS commits,
       COUNT(DISTINCT author_email) AS authors
FROM pgit_commits
GROUP BY org
ORDER BY commits DESC;

-- Fixes: タグの進化
SELECT EXTRACT(YEAR FROM authored_at)::int AS year,
       SUM(CASE WHEN message ~* 'Fixes:\s+[0-9a-f]{12}' THEN 1 ELSE 0 END) AS fixes_commits,
       COUNT(*) AS total
FROM pgit_commits
GROUP BY year
ORDER BY year;

-- 最も修正されたコミット
SELECT SUBSTRING(message FROM 'Fixes:\s+([0-9a-f]{12})') AS broken_commit,
       COUNT(*) AS times_fixed
FROM pgit_commits
WHERE message ~* 'Fixes:\s+[0-9a-f]{12}'
GROUP BY broken_commit
ORDER BY times_fixed DESC LIMIT 10;

-- 言語表現(ワード境界)
WITH words(word) AS (
    VALUES ('fuck'),('shit'),('damn'),('stupid'),('crap'),
           ('ugly'),('hack'),('workaround')
)
SELECT w.word,
       COUNT(*) AS cnt
FROM pgit_commits c, words w
WHERE c.message ~* ('\\y' || w.word || '\\y')
GROUP BY w.word
ORDER BY cnt DESC;

-- ソースコード検索(現在ファイル)
pgit search "fuck" --path "*.c" --path "*.h"

-- ソースコード検索(全履歴)
pgit search "fuck" --path "*.c" --path "*.h" --all

-- 三重リバート
SELECT author_name,
       authored_at::date,
       LEFT(message, 200)
FROM pgit_commits
WHERE message ILIKE 'Revert \"Revert \"Revert%';

-- Kent Overstreet の軌跡
SELECT EXTRACT(YEAR FROM authored_at)::int AS year,
       COUNT(*)
FROM pgit_commits
WHERE author_name = 'Kent Overstreet'
GROUP BY year
ORDER BY year;

-- 週末ワーカー
SELECT author_name,
       COUNT(*) AS weekend_commits,
       (SELECT COUNT(*) FROM pgit_commits c2 WHERE c2.author_name = c.author_name) AS total
FROM pgit_commits c
WHERE EXTRACT(DOW FROM authored_at) IN (0, 6)
GROUP BY author_name
ORDER BY weekend_commits DESC LIMIT 15;

リンク

  • pgit
    は Linux カーネルを扱えます。
  • 投稿以降、xpatch をベースにした
    ripgit
    が作られました:Cloudflare Durable Objects 上で動く自己ホスト型 Git リモート(SQLite + デルタ圧縮)。
go install github.com/imgajeed76/pgit/v4/cmd/pgit@latest

同じ日のほかのニュース

一覧に戻る →

2026/04/09 0:40

私、macOS XをNintendo Wiiにポート(移植)いたしました。

## Japanese Translation: --- ## 改良された要約 Mac OS X 10.0(Cheetah)は、Nintendo Wii 上でネイティブに動作するようにポートされ、コンソールをキーボード/マウス入力と GUI サポート付きの完全機能型デスクトップへ変貌させました。プロジェクトのコアは、*ppcskel* をベースに最初から書き直されたカスタムブートローダーです。このブートローダーは、Wii の PowerPC 750CL CPU を起動し、メモリレイアウトを設定し、最小限のデバイスツリー(root → cpus → PowerPC,750; memory)を作成します。SD カードから XNU カーネルをロードし、実行中にカーネルバイナリをパッチ(MEM1/MEM2 用の BAT 設定と USB Gecko へのコンソール出力)し、制御を XNU に渡します。 ブートローダーが提供する主要ドライバーは次の通りです: - **SD‑カードドライバー**:Starlet MINI IPC コマンド(IPC_SDMMC_SIZE, READ, WRITE)を介して IOBlockStorageDevice を実装し、XNU が SD カードからルートファイルシステムをマウントできるようにします。 - **フレームバッファドライバー**:0x01700000 に RGB フレームバッファ(640×480 @ 16 bpp)を提供し、Wii のアナログテレビ出力用に YUV へ変換して Mac OS X GUI を実現します。 - **USB サポート**:PCI デバイスのニブ(NintendoWiiHollywoodPCIDevice)を作成し、AppleUSBOHCI をパッチして受け入れさせ、OHCI ドライバーからバイトスワップ処理を除去することでリバースレトルエンディアンハードウェアに対応し、USB キーボード/マウス機能をフル実装します。 ブートローダーは Apple Partition Map を解析し、起動可能なパーティションを一覧表示し、/chosen/memory‑map ノード経由でカーネル拡張を直接メモリにロードできるようにするため、改変されていない Mac OS X インストーラーパーティションからのインストールも可能です。必要なカーネル変更は最小限(BAT 設定、“hollywood” I/O ベース取得、フレームバッファキャッシュ整合性修正)で済み、その他すべてのドライバーはブートローダーが提供します。 この成果は、歴史的にサポートされていなかったプラットフォーム――Nintendo Wii――でも Mac OS X Cheetah をエンドツーエンドで動作させることを示し、ホビイストに低コストのレトロコンソールとして機能するデスクトップコンピュータを提供します。

2026/04/09 4:23

**ソフトウェア開発者のためのUSB:ユーザースペース USB ドライバー作成入門**

## Japanese Translation: ``` USB デバイスの操作は、libusb を使用してユーザー空間だけで完全に処理できるため、カーネルレベルのドライバ開発は不要です。 例として、Fastboot モード(VID 18d1 / PID 4ee0)にある Android フォンを挙げます。接続すると `lsusb` は「Google Inc. Nexus/Pixel Device (fastboot)」と表示し、カーネルドライバは付いていません。また、ベンダー固有クラスインターフェースが 2 つのバルクエンドポイントを公開します:コマンド送信用 OUT 0x02 とレスポンス受信用 IN 0x81。 libusb のホットプラグコールバックはこのデバイスの到着を検出し、Fastboot コマンドを自動的に発行できます。典型的な手順は次のとおりです: 1. `libusb_control_transfer` を使用して GET_STATUS リクエストを送信します。2 バイトの応答はデバイスがセルフパワーであり、リモートウェイクアップをサポートしないことを示します。 2. GET_DESCRIPTOR リクエストを送信して完全なデバイスディスクリプタ(ベンダー/プロダクト ID、USB バージョン等)を取得します。 3. バルク OUT 0x02 を介して Fastboot コマンドを発行します(例:「getvar:version」を 64 バイトにパディング)。 デバイスは IN 0x81 で 4 文字のステータス(「OKAY」または「FAIL」)と任意のペイロードを返します。 同じユーザー空間アプローチは、バルク転送に依存する他の USB プロトコルにも適用できます。主な作業はカーネルコードを書く代わりにプロトコルロジックを実装することです。これにより OEM 向けドライバ開発が簡素化され、ブートローダーのテストが迅速化し、カーネルモジュールなしでカスタム USB デバイスの高速プロトタイピングやデバッグが可能になり、組込み開発者と広範な USB エコシステムに恩恵をもたらします。 ```

2026/04/08 17:53

**コードを読む前に実行しておくべき一般的な Git コマンド** - `git fetch --all` *リモートの全ブランチとタグを取得します。* - `git status` *現在のブランチと未コミットの変更点を確認します。* - `git checkout <branch>` *対象となる機能やバグ修正用ブランチに切り替えます。* - `git pull --rebase` *ローカルブランチを最新の upstream コミットで更新します。* - `git log --oneline --graph --decorate -5` *簡潔なコミット履歴を表示し、文脈を把握します。* - `git diff origin/<branch>..HEAD` *まだプッシュしていない変更点を確認します。* - `git rev-parse HEAD` *現在のコミットハッシュを取得(参照に便利)。* - `git tag --list` *利用可能なタグ一覧を表示し、バージョン管理に役立てます。* - `git show <commit>` *特定のコミットの詳細と差分を調べます。* これらのコマンドで、コードを掘り下げる前にリポジトリの状態を素早く把握できます。

## 日本語訳: 以下の文章を日本語に翻訳してください。 ### 修正版要約 この記事は、ソースファイルを検査する前にコードベースの簡易監査が隠れた健康リスクを明らかにできる方法を示しています。これは5つの簡潔な Git コマンドを実行することで達成されます。 1. `git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20` 過去 1 年間で最も変更頻度が高い上位 20 ファイルを一覧表示し、潜在的な「ドラッグ」スポット(高い変更率)をフラグ付けします。 2. `git shortlog -sn --no-merges` コミット数で貢献者をランク付けします。単一人物が 70 % 超を占める場合はバスファクターが低く、過去 6 ヶ月にその貢献者がいない場合は危機的状況を示唆します。 3. `git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20` バグ関連コミットが最も多いファイルを特定し、変更率データと照合して最高リスクコードをピンポイントします。 4. `git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c` 月ごとのコミット数を表示し、活動の加速または減退(例:半月間のドロップ)が重要人物の離脱を示す可能性があります。 5. `git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'` リバートとホットフィックスの数をカウントします。頻繁なリバートはデプロイ/テストが不安定であることを示し、ゼロの場合は安定性またはコミットメッセージ不足を意味する可能性があります。 これらの指標(変更ホットスポット、バスファクター問題、バグクラスタ、プロジェクトモーメンタム、火災対策頻度)は、コード複雑度測定だけよりも欠陥予測精度が高いと示されています(Microsoft Research 2005)。記事はスクワッシュマージワークフローが著者データを歪めることを警告しています。最初の監査に1時間を費やした後、筆者は特定されたリスクスポットに対して週単位で詳細調査を計画しています。関連研究としてはエンジニアリングチーム速度、Vim 使用、レガシー Rails 監査、Rails `default_scope` が引用されています。この手法は開発者に迅速なコミット履歴ベースの診断を提供し、高リスクファイルへの詳細コードレビューを集中させることでバグ削減、チームレジリエンス、およびリリース信頼性の向上を実現します。

Pgit:Linux カーネルを PostgreSQL にインポートしました。 | そっか~ニュース