#linux

この症状は、報告された2件の issue で同じエラー文字列として現れています。いずれも `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=142 messages=141 range=[118,142))` で始まり、スタックトレースは `/$bunfs/root/src/entrypoints/cli.js` を指しています。少なくとも issue 上では、別々の使い方に見える2件が同じ症状としてまとまっています。 まず切り分けの起点になるのは、Claude Code の正常な会話中にこのエラーが出て、その後の振る舞いが不自然になるかどうかです。#84467 では、スキャナーからデータを取ろうとした途中で、モデルが「lower lesser models」に勝手に切り替わると報告されています。#84140 では、本人が所有するハードウェアへのアクセス支援を求めたところ、Claude がそれを脅威のように扱った、と書かれています。どちらも、単なる表示崩れではなく、会話の

この表示が出ると、クラウド側のセッションは立っているのに、ローカルのコンピュータへ結びつけられていません。結果として attached folder が使えません。少なくとも今回参照できた issue では、同じ文言の症状が2件報告されています。1件は Linux beta で local VM がそもそも起動せず、もう1件は VM 自体は起動しているのに device registration 側で止まっています。どちらも「リンクできない」という見た目は同じですが、壊れている場所は違います。 まず切り分けたいのは、あなたの環境がどちら寄りかです。 一方、[#97685](https://github.com/anthropics/claude-code/issues/97685) では、VM は起動して guest もつながるのに、Linux では cloud Cowork session が computer に bind できない、と報告されています。こちらは `hardwareKeyUnavailable: linux-not-yet-supported` という説明と、`de

まず、この症状に当てはまるかどうかは、エラーメッセージの出方でかなり絞れます。Issue には、VS Code 拡張が埋め込みの native binary を起動しようとして失敗する例と、認証後に「unsupported platform: linux-arm64. No compatible Claude Code binary found.」と出る例が報告されています。前者は [#97022](https://github.com/anthropics/claude-code/issues/97022)、後者は [#80574](https://github.com/anthropics/claude-code/issues/80574) です。 一方で [#80574](https://github.com/anthropics/claude-code/issues/80574) では、devcontainer 内で Claude を使っていて、再認証のあとに ```text Unsupported platform: linux-arm64. No compatible Cl

Linuxでプログラムを隔離したい場面は多いのに、実際には「隔離のための準備」が重くて使わなくなることがある。今回紹介する Drop は、その面倒をできるだけ減らしながら、coding agent や第三者が配布するパッケージを安全に試せる rootless sandbox をうたうツールだ。元の作業環境をなるべくそのまま残しつつ、危ないものだけを閉じ込める発想が中心にある。Docker や Podman とは少し違う立ち位置で、日々の開発作業に入り込ませることを狙っているのが面白い。 Drop のサイトは、まず「Linux sandboxing that doesn’t get in your way」という言い方で始まる。つまり、隔離はしたいが、普段使っている環境から離れたくはない、という開発者向けの問題意識が前提にある。説明によると、Drop は rootless の Linux sandbox で、開発者向けに作られている。隔離したい対象は大きく二つで、ひとつは coding agents、もうひとつは PyPI や npm などから入れる第三者のプログラムだ。 coding

まず、この症状に当てはまるかを切り分けます。今回の issue では、Claude Opus 4.6 で最近の更新以降に精度と信頼性が落ちたという報告が 2 件あり、その中に Gmail MCP 経由でメール添付を送るときに base64 文字列が壊れ、`Base64 decoding failed` になる、という内容が含まれていました。報告は [#96178](https://github.com/anthropics/claude-code/issues/96178) と [#96179](https://github.com/anthropics/claude-code/issues/96179) です。 この issue で確認できるのは、少なくとも次の 2 つです。ひとつは日付の取り違えで、2026 年 9 月の文面なのに 2025 年の日付を出したこと。もうひとつは base64 の再現文字列が壊れ、`Base64 decoding failed` に至ることです。つまり、単なる添付ファイル処理の失敗というより、モデルの出力自体が途中で崩れている可能性があります。現時点で

`claude -p "/usage" --output-format json` を投げた直後に `exit code 5` で落ちる、あるいは `is_error:false` の包みだけ返って `result` がない、という症状が [#87983](https://github.com/anthropics/claude-code/issues/87983) で報告されています。報告者の環境では、長い print-mode 実行のあとに間隔をおかず起きていました。しかも 3 回の観測のうち 2 回は `exit code 5`、1 回はエラーヘッダのようなものがありつつ結果本体が欠ける形だったとされています。 手元で確認できる一次情報は、環境メモだけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-23T08:51:27+09:00 ``` この時点では、こちらで同じ不具合を再現するところまではできていません。なの

この症状は、`auto mode is unavailable for your plan` という文言がそのまま出るケースです。今回の報告では、Claude Max で `Shift+Tab` から Plan mode に入ろうとしたとき、または `/plan` を打ったときに同じエラーが出ています。該当 issue は [#44708](https://github.com/anthropics/claude-code/issues/44708) です。 同じ文字列でも、報告内容を見る限り少なくとも 2 つのパターンがあります。ひとつは Max subscription で Plan mode を選んだのに、このエラーが出るケースです。もうひとつは Pro plan で Claude.ai OAuth でログインしているのに、Auto mode が利用不可と表示されるケースです。後者は [#66510](https://github.com/anthropics/claude-code/issues/66510) にあります。 まず切り分けたいのは、今見えているのが Plan mo

x86アプリをARM上で動かすとき、命令の互換性だけでなく「メモリがどう見えるか」まで合わせないといけない。FEX-Emuは、その中でも見落とされがちな x86-TSO の扱いが、実は性能を大きく左右していると説明している。この記事は、単なるエミュレータの実装話ではない。ARM側の世代差や拡張機能の違いが、同じx86アプリでも体感を変えてしまう現実を、かなり具体的に示している。 FEX-Emuは、Linux上でx86/x86-64アプリを動かすユーザーモードエミュレータだ。その開発チームが今回取り上げたのは、x86エミュレーション全体にのしかかる「x86 Total Store Ordering memory model（x86-TSO）」の問題だった。メモリモデルとは、読み書きの順序や見え方をどう保証するかというルールのことだが、x86はかなり厳格で、書き込みが他のCPUにもすぐ見える前提をプログラマが置きやすい。一方でARMは弱い整合性を前提にしていて、ハードウェアがより効率よく動ける代わりに、順序の保証は薄い。 FEXは最初、ARMv8.0-a環境ではx86のloadをARMのl

この症状は、少なくとも 2 つの報告に分かれていました。ひとつは、スリープ解除後に Desktop App が再接続を 3 回試したあとで止まり、それ以上の自動再試行をしなくなるケースです。もうひとつは、headless Linux 上で `claude` のサブコマンドが `--version` を除いて固まり続けるケースです。どちらも、ユーザー側から見ると「応答が返らない」「つながらない」という形で見えますが、現れ方はかなり違います。 まず、スリープ復帰まわりの報告は [#78666](https://github.com/anthropics/claude-code/issues/78666) です。報告では、クライアント機が sleep/wake したあと、ネットワークがまだ戻っていないタイミングで Desktop App が transport dead を検知し、その後に自動再接続がちょうど 3 回、約 6 秒の間に走るとされています。3 回とも `host is offline` で失敗し、その後は `Auto-reconnect exhausted` になって自動では再

この症状は、少なくとも issue 報告上では Claude Code の内部で `TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync` が出ているケースとしてまとまっています。手元で確認できるのは、同じエラー文字列を含む 2 件の issue と、そこに付いた限定的なコメントだけです。現時点では、再現手順や恒久対応は issue 側でも確立していません。 まず、自分のケースかどうかを見分けるなら、エラー本文がこの文字列に一致するかを確認するのがいちばん確実です。少なくとも報告された 2 件では、`itemKeys/messages` の件数が一致していないことがログに出ています。 ```text TelemetrySafeError: VirtualMessageList: itemKeys/messages length desync (keys=101 messages=100 range=[68,101)) at Tn_ (/$bunfs/root/src/entrypoints/cli

この症状は、Claude Code の起動時に `SIGILL` で落ちるケースです。手元で確認できた一次情報は Linux 環境の以下の出力だけで、Claude Code 自体の実行結果は取得できていません。 ```text OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64) Python : 3.8.13 検証日時 : 2026-09-14T08:51:11+09:00 ``` GitHub Issue では、同じエラーが Intel Westmere 世代の CPU で報告されています。[#34481](https://github.com/anthropics/claude-code/issues/34481) と [#37065](https://github.com/anthropics/claude-code/issues/37065) のどちらも、VS Code 拡張機能側で ```text Error: Claude Code process terminated by signal SIG

まず、この `ENOTDIR` は 1 つの症状に見えて、少なくとも issue 上では 2 つの壊れ方が報告されています。どちらも「ディレクトリとして扱うはずの場所が、そう扱えない」という点は共通ですが、起きる場所が違います。 ひとつは、デスクトップアプリでセッションを fork するときです。`~/.claude/projects/<project>` がシンボリックリンクになっている環境で、`LocalSessions.forkSession` の IPC ハンドラが `ENOTDIR` を投げ、UI 側でエラーが飲み込まれてしまう、という報告でした。結果として何も起きないか、親履歴のない空の新規セッションになるようです。これは [#90931](https://github.com/anthropics/claude-code/issues/90931) に書かれています。 もうひとつは Bash tool 側です。こちらはコマンドが走る前に落ちます。issue では、セッションディレクトリを `/proc/self/fd/N/` 経由で作ろうとして `ENOTDIR` になっ

この症状は、少なくとも GitHub Issue の報告上では、Claude Code の実行中に `TelemetrySafeError: task output swap refused (output is an unregistered symlink made during this session)` が返っているケースです。報告は2件あり、[#91435](https://github.com/anthropics/claude-code/issues/91435) は closed、[#91042](https://github.com/anthropics/claude-code/issues/91042) は open です。どちらも同じエラー文字列を含んでいますが、原因の説明や恒久的な解決策は issue 本文だけでは確定していません。 まず、あなたのケースがこのクラスタに当たるかを見るなら、エラー文に次の部分が入っているかを確認します。 ```text TelemetrySafeError: task output swap refused (output is

この症状でまず目に入るのは、Claude Code が大きなファイルを読み切れずに止まっている、という点です。issue では、`MaxFileReadTokenExceededError: File content (...) exceeds maximum allowed tokens (25000). Use offset and limit parameters to read specific portions of the file, or search for specific content` という文言が繰り返し出ています。報告されているのは [#73486](https://github.com/anthropics/claude-code/issues/73486) と [#68927](https://github.com/anthropics/claude-code/issues/68927) です。 ```text MaxFileReadTokenExceededError: File content (28289 tokens) exceeds maxim

このエラーは、少なくとも報告上は 2 つのまったく違う場面で出ています。ひとつは SSH でリモートフォルダに入るとき、もうひとつは Claude Desktop の Code タブで Cowork VM を作るところです。どちらも最終的には同じ文言ですが、引き金は同一とは限りません。 まず自分のケースに近いかを切り分けると、[#64425](https://github.com/anthropics/claude-code/issues/64425) は「同じホストでもホスト名の書き方で成否が変わる」例でした。`root@frigate.ahfp` や `root@pve.ahfp` では失敗し、`frigate.ahfp.local` や `orangepi@wait-room-kiosk.ahfp` では成功しています。つまり、少なくともこの報告では “接続先そのもの” より “ホスト名の表記” に症状が結びついています。 一方で [#64867](https://github.com/anthropics/claude-code/issues/64867) は Windows

まず切り分けたいのは、いま見ている `EADDRINUSE` が「自分の環境でも再現する、同じ系統の問題かどうか」です。今回の issue 群では、症状の出方が 2 通りあります。 ひとつは、Linux 上の daemon supervisor が control socket の `bind()` に失敗して落ちるケースです。[#72334](https://github.com/anthropics/claude-code/issues/72334) では、`EADDRINUSE` で `control.sock` を掴めず、`transient` 側の分岐がそのまま致命的終了する、という報告でした。コメントでは、同じ症状が `2.1.196` と `2.1.197` でも続いていたこと、`~52s` 間隔で supervisor が再起動し、競合が起きるときは `control.sock` まわりでレースが起きることが書かれています。実際のログ断片も示されています。 ```text ``` もうひとつは、Claude in Chrome の bridge が、同時に接続している

at makeRequest (/$bunfs/root/sr` が出るときに見えているもの この症状は、Claude Code の CLI 内部で `makeRequest` から `Connection error` が投げられている状態として、少なくとも 2 件の issue で報告されています。該当するのは [#83872](https://github.com/anthropics/claude-code/issues/83872) と [#82703](https://github.com/anthropics/claude-code/issues/82703) です。どちらも報告されたエラー文字列は同じで、いま手元で確認できる範囲では、このエラー文そのものだけでは原因を一つに絞れません。 見えている issue の内容はかなり違います。#83872 は、cybersecurity 系の safeguard に触れたあとで `/rewind` を実行すると、繰り返し同じエラーに落ちるという報告でした。報告者は「cybersecurity pentest のレポート作成用の

この症状は、Claude Code のプラグインを更新したのに、MCP server が古いファイルを掴んだままで新しい内容が反映されない、という報告です。参照できる報告は [#72678](https://github.com/anthropics/claude-code/issues/72678) と [#75674](https://github.com/anthropics/claude-code/issues/75674) の 2 件で、どちらも closed になっていますが、コメントを見る限り「再現手順が足りないので調査継続のために新しい issue を出してほしい」という扱いでした。 まず、自分のケースかどうかを切り分けるなら、次の見え方に一致するかを見ます。issue 本文では、プラグイン更新時に MCP server process が動いていると、新しいファイルが `~/.claude/plugins/data/<plugin>/` にコピーされず、`installed_plugins.json` だけは新しい version を指す一方で、実体の binary

この症状は、`Error: ELOOP: too many symbolic links encountered, open '/private/tmp/claude-...` で始まるエラーとして issue に上がっています。今回確認できたのは、どちらの報告も `/private/tmp/claude-...` 配下の一時パスを開く場面で `ELOOP` が出ていることです。少なくとも報告ベースでは、Claude Code の操作中に一時領域のファイルを開こうとして失敗しているように見えます。 参照できた issue は次の 2 件です。どちらも open で、解決済みではありません。 報告内容をそのまま見ると、`ELOOP` が出る直前のパスはどちらも似ています。1 件目は `competition-module` を含むパス、2 件目は `btf3k0ktq.output` を含むパスでした。完全な再現手順までは issue からは読めませんが、少なくとも「一時ディレクトリ下の対象ファイルを開くときにシンボリックリンクが絡んでいる」状態を疑うのが自然です。とはいえ、ここまでしか

Apple Silicon 上で Linux を動かす Asahi Linux が、M3 系 Mac への対応をインストーラーに取り込み、正式サポートに踏み出した。M1 や M2 で使えていた機能の多くがそのまま動く一方で、GPU まわりや一部の表示制御はまだ完成していない。とはいえ、ここまで来ると「試験的に触れる段階」ではなく、実用に向けた土台がかなり整ったと言ってよさそうだ。Apple の新しい世代が出るたびに追いかける難しさを知っている人ほど、この一報の重みは分かるはずだ。 Asahi Linux のブログによると、M3 series machines への対応が installer にマージされ、M3 系 SoC を積んだ Mac に対して Asahi Linux が正式にサポートを提供する状態になった。対象は M3 series の Mac で、M3、M3 Pro、M3 Max を搭載した MacBook と iMac が含まれる。一方で、Mac Studio に載る M3 Ultra はまだ未対応だ。 今回の対応で、M3 系では M1 や M2 系で動いていた機能のほとんど

まず切り分けたいのは、MCP 接続が本当に未認証なのか、それとも「未認証だと言われているだけ」なのかです。今回の症状は後者として報告されています。`claude.ai` の OAuth connector がすでに認証済みで、同じセッション内でツール呼び出しも成功しているのに、セッション開始時の system reminder に「requires authentication before their tools can be used」と出て、さらに > “Tell the user that these servers need to be authorized … and that the capability is unavailable until they do.” という指示まで載る、という内容です。該当する issue は [#76320](https://github.com/anthropics/claude-code/issues/76320) と [#77534](https://github.com/anthropics/claude-code/issues

`claude` を打った瞬間に何も表示されず終わる。`claude --help` も `claude --version` も同じで、終了コードが 139 になる。今回の issue 群は、この形にかなり近い症状です。 報告されているのは、Ubuntu 26.04 LTS の VirtualBox VM 上で `claude` が即死した例と、Linux x86_64 上で 2.1.243 が起動直後に SIGSEGV で落ちる例です。どちらも、通常の対話画面が出る前に失敗しています。[#63635](https://github.com/anthropics/claude-code/issues/63635) と [#89390](https://github.com/anthropics/claude-code/issues/89390) では、少なくともその挙動が一致しています。 今回の一次情報では、私の環境で再現確認はできていません。実際に取れたのは次の環境情報だけです。 ```text OS : Linux 3.10.0-1160.76.1.el7.x8

Spotifyを使うためのアプリはもう十分あるように見えますが、実際には「重い」「ブラウザの延長に見える」「キーボード操作がしづらい」といった不満が残りがちです。Fastpotifyは、そうした不満に真正面から応える形で出てきたデスクトップ向けクライアントです。Linux、macOS、Windowsに対応し、Rustで書かれたネイティブアプリとして、軽さと操作性を売りにしています。単なる再生ソフトではなく、Spotify Connectやライブラリ閲覧、Winamp風のミニプレーヤーまで含めているのが面白いところです。 Fastpotifyの説明はかなりはっきりしています。これは「Spotify, native and fast」を掲げる、軽量なSpotifyクライアントです。対応OSはLinux、macOS、Windowsで、ローカル再生、ライブラリへのアクセス、Spotify Connectの操作を一つのウィンドウで扱えるとしています。 まず強く押し出しているのが軽さです。ブラウザエンジンを使わないネイティブバイナリで、起動は1秒未満、メモリ使用量は通常100〜250MB程度だと書

USBメモリを抜き差ししたり、クラウドに上げて落としたりしなくても、近くにある2台のコンピュータならEthernetケーブル1本で直接つないでファイルを渡せる、というのが元記事の話だ。しかも必要なのは難しい専用機材ではなく、ふつうのpatch cableと、少しのIP設定だけだという。記事はかなり短いが、ファイル転送の「当たり前」を見直す内容として面白い。ネットワークはインターネット接続のためだけではない、と筆者は言いたいのだと思う。 元記事がまず示しているのは、2台のPCをEthernetで直結し、両方にIPv6アドレスを手で設定するやり方だ。送信側には `fd42:dead:beef::1/48`、受信側には `fd42:dead:beef::2/48` を `eth0` に割り当て、両方とも `ip link set dev eth0 up` でリンクを上げる。数秒待てば `ping fd42:dead:beef::1` が通るので、ここで疎通確認ができる。記事には、`icmp_seq=1` から `4` までの応答が `0.649 ms` などのごく短い遅延で返ってくる例が載っ

カリフォルニア州で、年齢確認を義務づける新しい法律の例外として、オープンソースのLinux系ソフトウェアを外す修正案が全会一致で通過しました。対象になるのは、GPL、MIT、BSD、Apache licensesで配布されるソフトウェアです。いわば、子どもの利用を想定した年齢確認の仕組みを広げる一方で、配布の形そのものが違うLinuxやオープンソースには、その義務をそのまま乗せないという判断です。 この話が面白いのは、単に「Linuxが守られた」というだけではないからです。オープンソースは、誰が作って誰が配るのかが商用ソフトと違うため、同じ規制を当てはめると現場が回らなくなることがあります。今回の修正は、その摩擦を州議会がどう扱ったかを示す材料でもあります。 Tom's Hardwareが伝えたのは、カリフォルニア州議会がAB 1856を全会一致で可決し、まもなく施行予定のDigital Age Assurance Actからオープンソースのオペレーティングシステムを除外した、というニュースだ。元の記事によれば、この修正でGPL、MIT、BSD、Apache licensesのもとで配

Linuxの開発基盤を運営する Konstantin Ryabitsev が、AIクローラーによる負荷の実態をかなり具体的に語っています。単なる愚痴ではなく、どれだけCPUを食われているのか、どんな対策をして、なぜそれでも追いつかないのかが数字付きで示されているのが重いところです。しかも問題は「アクセスが多い」では済まず、公開されているはずの技術情報が、学習用データを集める側の都合で無駄に消費されている点にあります。今この話を読む意味は、AI時代の“便利な公開”がそのまま“採取し放題”になっている現実が、かなりはっきり見えるからです。 元記事でまず示されるのは、git.kernel.org に来る “AI crawlers” の負荷が、もはや軽い迷惑ではなく、継続的なシステム負荷になっているという事実です。著者によれば、今は「スクレイパーのために commit を HTML にレンダリングする CPU サイクル」のほうが、git clone を含む他の正当なアクセスより多く使われています。5つの地理的に分散したノード全体では、常時14コアが commit の HTML 化だけに張り付い

まず、自分のケースかどうかを切り分けます。今回の `EISDIR` は、GitHub の報告を見る限り、少なくとも 2 系統あります。ひとつは Linux arm64 で Claude Desktop が Claude Code のバイナリを落とせず、起動のたびに「binary is missing or damaged」と出る件です [#89850](https://github.com/anthropics/claude-code/issues/89850)。もうひとつは Windows の VS Code 拡張で、`\\?\` 付きのワークスペースパスを開いたときにサイドバー復元が落ちる件です [#89775](https://github.com/anthropics/claude-code/issues/89775)。 Linux 側の症状は、報告では毎回同じです。ダウンロード対象を `open()` するところで `EINVAL: invalid argument` になり、アプリ側には次の文言が出ます。 ```text Claude Code couldn't start

この症状は、少なくとも報告上は 2 つの別パターンがあります。ひとつは、auto mode の判定が本来通してよいツール呼び出しを止めるケース。もうひとつは、コンパクション後の文脈を「まだ有効なユーザー指示」とみなしてしまい、その後の呼び出しを拒むケースです。いずれも、ユーザー操作そのものが禁止されているというより、Claude Code 側の自動判定が原因になっています。 まず切り分けの軸は、拒否が「どの場面で」出たかです。長いセッションの途中で自動コンパクションが入った直後なら [#77158](https://github.com/anthropics/claude-code/issues/77158) の報告に近いです。ここでは、auto-mode の safety classifier がコンパクション時の割り込み文を恒久的な指示として扱い、次の正当な tool call を拒否したとされています。報告本文では、`--permission-mode auto` の環境、`claude-opus-4-8` と `claude-fable-5` の両方で再現したと書かれています。

Linux界隈でちょっと胸が熱くなるニュースです。Nvidia向けのオープンソースVulkanドライバ「NVK」に、実験的ながらDLSS対応が入ったとTom's Hardwareが伝えています。しかも仕組みはかなり変わっていて、NvidiaのCUDAバイナリを“輸入”して使う形です。オープンソースとCUDAの合わせ技、というのがまず面白い。きれいな純正路線ではないけれど、現実的に前へ進めるための割り切りが見えます。 この記事のポイントは、NVKがDLSSに対応した、というより「対応の入口に立った」というほうが正確なことです。 NVKは、LinuxでNvidia GPUを使うためのオープンソースVulkanドライバです。Vulkanはゲームや3D描画で使われる低レベルのグラフィックスAPIで、ざっくり言うと「GPUに近いところまで細かく制御できる描画の共通言語」みたいなものです。 そこにDLSS、つまりNvidiaの画像アップスケーリング技術が加わった。アップスケーリングは、低い解像度で描いた映像をAIや専用処理で見た目よく引き伸ばす仕組みで、ゲームでは性能を稼ぎやすくする定番の技術です

For Claude and Claude Code developers, this GitHub issue lands on a very practical pain point: the desktop app is still where a lot of the interesting workflow lives, but Linux users are left out. That matters not just for casual chatting, but for plugin testing, desktop extensions, computer use, dictation, and other parts of the Claude desktop experience that the CLI cannot replace. What makes this request interesting is that it is not just “please support my favorite OS.” The author argues tha

NVIDIA GPUのVRAMをLinuxのswap領域として使うプロジェクト 対象はメモリ増設できないノートPCや、GPUのVRAMが遊んでいる環境 CUDAの`cuMemcpyHtoD/DtoH`とNBD(Network Block Device)を組み合わせて実現 カーネルモジュールを新規に書かないので、更新に強いのが強み 速度は用途次第で、大容量の連続転送ではNVMeに負けるが、たまに発生するswapアクセスでは低レイテンシが効く ただし、誰にでもおすすめできる万能解ではない。かなり“尖った”実験寄りの仕組み 今回紹介するのは、GitHubの `nbd-vram` というプロジェクトです。 一言でいうと、NVIDIA GPUのVRAMをLinuxのswapスペースとして使うための仕組みです。 「swapって何？」という人向けにざっくり説明すると、 PCのメモリ（RAM）が足りなくなったときに、一時的な退避場所としてSSDやHDDを使う機能です。 ただしswapはRAMよりずっと遅いので、使い

カリフォルニア州の新しい年齢確認ルールが、Linuxを含む多くの open-source OS を対象外にする方向で修正されようとしている きっかけは、「OSにユーザーの年齢を集めさせるのはやりすぎでは？」という強い反発 もとの法律は、アプリやWebサービスだけでなく、OS側にも年齢の取り扱いを求める内容だった ただし、SteamOS はまだ影響を受ける可能性があると記事は伝えている この修正案は、元の法律を書いた議員自身が提案したもの 米Tom's Hardwareによると、カリフォルニア州で進められている年齢確認（age-verification）の法律をめぐって、Linuxコミュニティや open-source 開発者たちが強く反発した結果、州議会が Linuxを対象外にする修正案 を出してきたそうです。 この話、地味に見えてかなり面白いです。というのも、最初の法律は「子どもの保護」を名目にしていたはずなのに、気づけば OSそのものにユーザーの年齢を把握させようとしていた わけです。 正直、これはかなり無理筋だと思います。OSはスマホやPCの土台であって、そこに年

Yes We Scan は、古いUSBスキャナーをブラウザ上で使えるようにするWeb app。 きっかけは、作者が先に作っていた古いプリンター向けアプリ printervention.app。 核心技術は v86。ブラウザ内で x86マシン全体をエミュレートし、Linux上で SANE を動かしている。 スキャナーとのやり取りは、USB/IP、WebUSB、そして tcpip.js でつないでいる。 かなり野心的で、正直「そこまでやる!?」と笑ってしまうレベルの力技。でも、そのぶん発想はめちゃくちゃ面白い。 この記事の主役は、「古いUSBスキャナーを、今のPCから使えない問題」をどうにかしようというWeb appです。 最近のパソコンは、昔の周辺機器に冷たいです。とくにスキャナーは、メーカーのドライバが古かったり、そもそもOSが変わってもう動かなかったりして、押し入れに眠りがち。 この記事の作者も、まさにそんな状況に遭遇していたようです。 きっかけは、もともと両親や義理の両親のために古いCanon製プリンタ

Linux kernel の脆弱性 CVE-2026-31635 に対する PoC（実証コード）が公開された 脆弱性は local privilege escalation（LPE）、つまり一般ユーザーが root 権限 を取れてしまう問題 CONFIG_RXGK が有効な Linux で影響し、Fedora / Arch Linux / openSUSE Tumbleweed などが対象になりうる 問題の本質は、`rxgk_decrypt_skb()` にある COW（copy-on-write）保護の欠如 すでに似た系統の Linux LPE が続けて出ており、kernel 側の“ミスの型”が見えてきている Linux kernel 開発者の間では、緊急時に危険な関数を止める killswitch という案も議論されている The Hacker News が伝えたところによると、Linux kernel の脆弱性 CVE-2026-31635 に対する PoC（Proof of Concept、攻撃の動作確認用コード）が公開さ

Doogee U10（RK3562搭載）で Debian 12 Bookworm を動かすためのビルドシステム ブートローダーのアンロック不要、SDカードから起動して使える SDカードを抜けば ふつうのAndroidに戻る ので、内部ストレージを汚さない 画面、タッチ、Wi-Fi、Bluetooth、音声、バッテリーなど、かなりの機能が動作 GPUは mali系のvendor stack が標準、panfrost も選べる RK3562の NPU を使ったローカルLLM推論にも対応している ただしカメラやGPUまわりなど、まだ調整中の部分もある GitHubの `tech4bot/rk3562deb` は、Doogee U10というAndroidタブレットを、Debian 12のLinuxマシンとして使うためのプロジェクトです。 ここでまず面白いのは、単なる「Linuxを入れてみた」話ではないこと。 このリポジトリは、SDカードに書き込んだイメージからタブレットを起動できるようにする“ビルドシステム”になっています。つまり

OpenBSD 7.9は、2026年5月19日に公開された「60回目」のリリース CPUや電源管理、仮想化、GPU、無線、各種ドライバがかなり広く強化された 特に arm64 と amd64、riscv64 まわりの進化が目立つ スケジューラやメモリ管理など、見えにくいけれど重要な土台部分も改善されている 一般ユーザー向けには、audioやXDG_RUNTIME_DIR、disklabel、fstat、login周りの細かな使い勝手向上がうれしい OpenBSD 7.9 が公開されました。 公開日は 2026年5月19日。これで OpenBSD は 60回目のリリースです。数字だけでも、かなり長く真面目に積み上げてきたプロジェクトだとわかります。こういう“地味だけど筋肉質”なOS、私はかなり好きです。 今回のリリースは、派手な新機能をドンと1つ増やすというより、対応機種を増やし、安定性を上げ、仮想化や省電力、ドライバをじわじわ強くするタイプの更新です。OpenBSDらしいと言えばOpenBSDらしい。とにかく「ちゃんと動く」を積み重ねています。 OpenBSD 7.9 の発表ペ

Linux kernelにCVE-2026-46300という新しい脆弱性が見つかった この脆弱性は Fragnesia と呼ばれ、root権限を奪われるおそれがある 影響を受けるのは、ローカルの攻撃者が権限を上げるケース 問題の場所は Linux XFRM EST-in-TCP / ESP-in-TCP subsystem 研究者は、/usr/bin/su の page cache を壊して root shell を取る PoC を公開している いちばん現実的な対策は、各ディストリビューションの kernel update をすぐ適用すること さらに、Linuxコミュニティでは将来のリスクを下げるための killswitch 的な仕組みも検討されている TechRadarが伝えているのは、Linux kernelにまたしても大きめのセキュリティ問題が見つかった、というニュースです。 新たに判明した脆弱性は CVE-2026-46300、通称 Fragnesia。これを突かれると、**一般ユーザー権限の攻撃者

Linuxの生みの親 Linus Torvalds が、AIを使って見つかった脆弱性報告の増えすぎに苦言を呈した 問題は「AIで見つかったこと」そのものではなく、重複だらけの報告が大量に届いていること Torvalds は、修正案なしの“投げっぱなし報告”は価値が薄いと指摘 ただし、AIツール自体を否定しているわけではなく、使い方次第だと強調している GitHubのセキュリティ担当者も、検証済みで再現できる報告が重要だと似た見解を示している Linux界のレジェンド、Linus Torvalds が、AI時代ならではの悩みをぶっちゃけました。 今回の話題は、Linuxのセキュリティ報告リストが、AI由来のバグ報告で「ほぼ管理不能」になっている、というものです。 ここでいう「バグ報告」は、ソフトウェアの不具合や脆弱性を見つけた人が開発者に知らせる仕組みのこと。 本来はとても大事で、こうした報告があるからこそLinuxの安全性は保たれています。 でも今回は、その報告が多すぎるうえに、似た内容の繰り返しが山ほどあるのが問題になっているわけです。 The

Linuxカーネルに、ローカルユーザーがroot権限を取れてしまう脆弱性が2件公開された 1つ目は Copy Fail（CVE-2026-31431）、2つ目は Dirty Frag（CVE-2026-43284 / CVE-2026-43500） どちらも page cache（ファイルの読み書きを速くするためのメモリ上のキャッシュ）を悪用する 以前大きな被害を出した Dirty Pipe と同系統の問題で、しかも多くの主要ディストリビューションに影響する 攻撃にはネット越しの侵入ではなく、ローカルの一般ユーザー権限が必要 とはいえ「一般ユーザーが入れれば終わり」なので、サーバーや共有環境ではかなり重い話 影響組織は即パッチ適用が必要 InfoQが伝えたのは、Linuxカーネルに見つかった2つのローカル権限昇格（local privilege escalation）の脆弱性です。 ざっくり言うと、普通のユーザー権限しか持っていない人が、OSの最強権限であるrootを取れてしまうという話です。これはかなり危ないです。roo

Linus Torvaldsが、Linuxのsecurity mailing listが「almost entirely unmanageable（ほとんど管理不能）」になっていると発言 原因は、AIを使って同じ脆弱性を見つけた研究者たちが、似た報告を大量に送ってくること その結果、重複チェックや振り分けばかり増え、「無駄な苦痛と意味のない作業」になっているという Torvaldsは、AIで見つけたなら“報告だけ”で終わらず、ドキュメントを読んでパッチも出せ、と注文 一方で、Linux maintainerのGreg Kroah-HartmanはAIをより前向きに評価しており、見方は割れている Linux kernelの生みの親であるLinus Torvaldsが、Linuxのsecurity mailing listについてかなり強い言葉で不満を表明しました。 要するに、「AIを使ってバグを探す人が増えたのはいいけれど、同じ発見が何通も何通も届いて、もう回らない」という話です。 security mailing listは、Linuxのセキュリティ問題を報告・議論するための場所です。