io_uring はいったいいつ頃安定化するんでしょうか。使ってみようかと思っても、CVE のニュースを見るたびに諦めて、もう 5 年目です……

いいねです。

デモ用に作成されたPoCがGitHubに公開されています。

https://github.com/ch4n3-yoon/CVE-2026-33033-PoC

このままだと、バイブコーディングの資格を取らないといけない時代が来るかも…。

これ、実際に試してみた人いますか？

正常化!!

適用するドメインによって違うのではないでしょうか?
私が現在進めている rhwp のように、1mm のレンダリング差を詰めて処理するときに Codex を使うと壊れます。現時点では高難度の作業は Claude Code のほうが優れていますが、手順に沿ってある程度のレベルまで処理できればよいワークフローとフレームワークだけで済む Web アプリ開発では、Codex を使うほうが精神衛生上よいと私は感じています.

まさに核心を突いた表現だと思います

ひとまず、非専門家はそういうものが存在することすら、なぜ必要なのかも分からないでしょう。

HKUDSは面白いものをたくさん作りますね
https://github.com/HKUDS/nanobot もそうですし

むしろ、TailscaleのDERPリレーの役割をCloudflare Edgeが担うことになるので、より強力な競合が現れたのではないかと思いました。TailscaleもP2Pができない場合はDERPリレー経由で通信を送るので。「リレーインフラのPoP(Point of Presence)が限定的だと、かなりの部分のトラフィックがリレーを経由することになり、遅延や信頼性の低下が発生する」という部分は、特にTailscaleのことを言っているように感じました。私は両方を混ぜて使うことになりそうです。さっそく実験してきます

Tailscaleの親DNSをAdGuardに指定すればいいのではないですか？

私もこのように使っています。ただ、役割を1つのモデルに固定するというより、クォータに最も余裕がありつつ強力なモデルへ先に割り当てる形で運用しています。

私もこうしています。もう少し詳しく言うと、100ドルのClaudeと200ドルのCodexを使う構成にして、Claude Code Opusで計画 → Sonnetで実装 → Codexでレビュー → Opusでレビューを検証 → 再びSonnetで実装 → Codexでレビュー（以下繰り返し）という形で回し続けるように、もうスキルとして作ってしまいましたが、満足しています。

model_context_window=800000 を使用した場合、コンテキストを50%消費した時点から、質問への回答が前の質問に対する回答として進んでしまう問題があります。ご参考までに。

Codexが細かいところまで丁寧なのは同意です。Claudeで書いてCodexでレビューするやり方をおすすめします。時間はかなりかかりますが、トイレに行く前や会議の前に走らせておくと、完了率も高いですね。

人工知能は『どのように（How）』はよく理解していますが、『なぜ』それをすべきかは分かっていません。仕事の根本的な目的を見極めようとし、試行錯誤をいとわず新しい道を探ろうとする探究心と、目的に向けた方向性を決めることは、人間にしかできません。責任感とは結果だけを追い求めることではなく、その過程で目的を見失わず、継続的に問い、探究する姿勢のことです。

私は Oracle Cloud の free tier を使っています。4 vCPU、24GB RAM、200GB で、Arm ベースなのでたまに互換性のないものがあるのを除けば、おもちゃとして最高です。

マニュアルや指示以外の方法を創造的に見つけ出す能力も、責任ある姿勢から生まれます。

人の業務能力を評価する際には、『態度』という要素があります。業務指針や上司の命令だけでなく、自分自身が仕事にどう向き合うかという姿勢が重要です。その態度は、業務に対する継続的な関心や洞察、責任感として表れます。中でも責任感が重要です。人工知能は他のことはまねできても、責任感はありません。人工知能は成果物を評価することはできても、プロセスにおける責任感を評価することはできません。