Linux
Linux 7.2リリース。キャッシュを理解するCPUスケジューラが到着
Linux 7.2が予定通り公開された。目玉はCPUスケジューラがキャッシュ構造を理解するCache Aware Scheduling。リリース直前まで膨らみ続けたパッチの波と、壊れたコードを差し戻す判断の両方が、いまのカーネル開発を映している。
Linux
Linux 7.2が予定通り公開された。目玉はCPUスケジューラがキャッシュ構造を理解するCache Aware Scheduling。リリース直前まで膨らみ続けたパッチの波と、壊れたコードを差し戻す判断の両方が、いまのカーネル開発を映している。
Linux
リーナス・トーバルズがLinux 7.2-rc7をリリースした。来週の安定版リリースはほぼ確実だが、rc7のパッチ量は通常の最終候補としては異例の多さだ。その原因をトーバルズ自身が名指しした。AIだ。
Linux
Linuxのネットワーク設定を担うソフトウェアが、コードだけでなくレビューの対話にまで踏み込んだAIルールを敷いた。
Linux
Linuxカーネルのネットワーキングメンテナが、直近9日間に投稿されたパッチの37%が修正だったと報告した。しかもLLM由来の投稿はタグ付けされないため、実際の修正比率はさらに高い。
Linux
Linuxカーネルの無線LANサブシステムを管理するヨハネス・ベルク氏が、AI生成パッチの大半を無視すると表明した。3秒見て正しさが自明でなければ読まない。
Linux
1999年から残っていたドライバーが消えた。理由はハードウェアの故障でもセキュリティの欠陥でもなく、LLMがこのコードにバグ報告を送り始めたからだ。カーネル開発のナンバー2は同日、新人向けの練習領域でもLLM生成パッチの受け入れ拒否を宣言した。
Linux
Linuxカーネルのナンバー2が、新人開発者の学びの場にLLM生成パッチが殺到している現状に線を引いた。
Linux
AMD CPUの周波数制御ドライバに、ゲーム中の周波数低下を防ぐ新機能が提案された。Steam Deckでの実測で、フレームレートの落ち込みが大幅に改善されている。 98%使っているのに、クロックが上がらない ゲームのメインスレッドは、毎フレーム短い待機を繰り返す。futex(スレッド間の同期に使われるLinuxの仕組み)やGPUフェンスで数ミリ秒ブロックされ、すぐに復帰して描画処理を再開する。CPUの利用率で見れば98%近い。 amd-pstateドライバのactiveモードで動作しているとき、この短い待機が問題になる。activeモードでは、カーネルがEPP(Energy Performance Preference)というヒント値をCPUに渡し、実際の動作周波数はCPU内部のファームウェアが自律的に決める。「省電力寄り」か「性能寄り」か、電力・温度の制約と照らし合わせて判断する仕組みだ。 スリープのたびにハードウェアの性能シグナルが減衰し、復帰後のバースト処理は低い動作点から始まる。次のスリープまでに周波数が上がりきらないまま、また減衰が起きる。Steam Deck(V
x86
https://youtu.be/aU0wG6bt3rU(2025年10月当時のYouTube動画。現在非公開) IntelもAMDもまだ作っていないはずの拡張実装が、すでにどこかで動いている。 9か月前のメッセージの続き 2025年10月、x86アーキテクチャの専門家であるクリスティアン・ルドロフ(Christian Ludloff)がLinuxカーネルのメーリングリストに投稿した内容は、控えめに言って異様だった。Intel、AMD以外の「企業体」がx86のオペコード、CPUID、MSR領域を使用中であり、衝突を避けよ、という警告を発していた。 ルドロフはGoogleやトランスメタ(Transmeta)等でx86関連の業務に携わった経歴を持ち、x86命令セットの技術資料サイトsandpile.orgを長年運営してきた人物だ。彼自身が何かを開発しているわけではない。投稿には「伝えるよう依頼された」と書かれていたが、依頼者は明かされなかった。 あれから約9か月。現地時間7月27日、同じルドロフがLinuxカーネルのメーリングリストに再び投稿した。今回の件名は「x86 AM
Linux
Linuxカーネル7.2の5番目のリリース候補が公開された。前サイクルの7.1に続き、rc5としては2回連続で規模が膨らんだが、リーナス・トーバルズ(Linus Torvalds)氏は内容に懸念はないとしている。 2サイクル連続の「大きなrc5」 トーバルズ氏は現地時間7月26日、Linux 7.2-rc5のリリースを告知した。前サイクルでも同様にrc5が膨らんでおり、これが常態化しつつある。 ただし今回は事情が異なるという。ネットワーキングツリーが前週、カンファレンスの影響で作業を溜め込んでおり、今週分と合わせて一気に流れ込んだ。その結果、パッチ全体の3分の1以上がネットワーキングで占められた。大半はドライバ側の修正だ。 ドライバ全般では珍しい傾向も出ている。今回はUSB関連の変更がGPUドライバを上回った。サウンド、tty、ブロック、FireWireなどの修正も含まれ、ドライバの変更は広範囲にわたる。 ドライバ以外では、テスト基盤(selftest、perf)、ファイルシステム(SMB、Btrfs)、Rustコード、アーキテクチャ固有の修正、ドキュメントの更新が入ってい
Linux
KVMの仮想メモリ管理を担う構造体kvm_mmuが、3つの独立した構造体に分割される。Linux 7.3のマージウィンドウに向け、KVM.gitのnextブランチへのマージが完了した。 「god data structure」にチェーンソーを入れる KVMメンテナーのパオロ・ボンジーニ(Paolo Bonzini)氏が、kvm_mmu構造体のリファクタリングをKVM.gitのnextブランチにマージした。ブランチ名はkvm-chainsaw。Linux 7.2の安定版リリースが8月中旬から下旬に予定されており、その直後に開くLinux 7.3のマージウィンドウで提出される見通しだ。 ボンジーニ氏はコミットメッセージの中で、kvm_mmuを"god data structure"(何でもやる万能構造体)と呼んでいる。1つの構造体が3つの異なる仕事を抱えていた。ゲストページテーブルのフォーマット記述とウォーク(走査)、そしてシャドウページテーブルの構築だ。 nested_mmuという構造体がguest_mmuより先に実装され、より直感的な名前を奪ってしまった経緯もある。コード中の
Debian
Debianがプロジェクト内でのLLM利用に関する正式な一般決議(GR)の討議期間に入った。全面禁止と条件付き容認という対照的な2案が提出されている。 5ヶ月前は「決めない」で終わった DebianがLLM利用の方針を定めようとするのは、今回が初めてではない。 2026年2月、元DPL(Debian Project Leader)のルカス・ヌスバウム(Lucas Nussbaum)氏がAI支援コード貢献に関するGR草案を提出した。著作権の不透明さから品質管理、コミュニティへの影響、環境負荷まで論点は出揃ったものの合意に至らず、GRは正式に提出されないまま議論が収束している。 5ヶ月が経ち、状況は変わった。現地時間7月24日、2つの正式なGR提案が討議期間に入った。提案者も賛同者もDebianの中核を担う開発者たちで、双方とも7名の賛同を得ている。「決めない」で先送りした課題が、ついに投票の俎上に載った。 全面禁止か、条件付き容認か Proposal Aは、LLMや生成AIツールで作成・補助された貢献をDebianから明示的に排除する。提案者はマティアス・ガイガー(Mat
Linux
7月19日から20日にかけて、Linuxカーネルの脆弱性識別番号(CVE)が432件、一気に公開された。セキュリティ担当者からは困惑と諦めの声が上がっている。 週末の洪水 日曜から月曜にかけて、linux-cve-announceメーリングリストに掲載されたCVEの数は432件。今月すでに公開されていた40件超とは別の数字だ。 Akamai Technologiesのチーフ情報セキュリティアーキテクト、ヤン・シャウマン氏(Jan Schaumann)は月曜、oss-securityメーリングリストにこの大量公開について投稿した。CVEシステムがセキュリティ変更の追跡に最善の手段ではないと指摘した上で、これだけの件数にどう対処すべきかを問いかけている。 個別のカーネル変更を優先順位付けしようとすること自体が、もう実行不可能だと今回の件数が示している(シャウマン氏のoss-securityメーリングリストへの投稿) LLMに優先順位を付けさせても、1日に12件、翌日に25件と出されるようでは追いつかない、とシャウマン氏は述べた。深刻な問題が浮上するのを数週間待つか、Linux環
セキュリティ
AI生成の脆弱性報告が大半を占める状況を受け、GNOMEがセキュリティ情報の開示ポリシーを改定する。担当者は11月での退任も表明した。 90日の形骸化 GNOMEのセキュリティイシュー追跡を担うマイケル・カタンザロ氏(Michael Catanzaro)が7月20日、脆弱性報告の開示期限を90日から30日に短縮すると発表した。2026年8月1日以降に報告されたイシューに適用される。 業界標準の90日は、GNOMEの実態に合っていなかった。カタンザロ氏によれば、メンテナーの対応は二つに分かれる。報告から1〜3週間で修正するか、まったく修正しないか。 90日間の猶予を設けても、メンテナーがその時間を活かすことはほぼなかった。修正が入るか期限が来るかのどちらかが先に起き、修正される場合は最初の数週間で片がつく。残りの期間は機密を維持しているだけで、誰の役にも立っていなかった。 カタンザロ氏自身、AI生成報告の増加がなくても「短い期限の方がGNOMEには合う」と述べており、今回の短縮はAI対応策にとどまらない判断だと位置づけている。 AI禁止ポリシーとの衝突 変更はもう一つあ