今日の注目トピック

Dependabotは通常のversion updateを公開から3日待たせる一方、security updateは待たせず、更新の速さと供給網リスクを分離する
DependabotSupply Chain SecurityGitHubDependency Management

Dependabotが通常更新を3日待つ既定へ

GitHubはDependabotのversion updateを、レジストリで公開されてから少なくとも3日待ってPR化する既定に変更しました。公開直後の壊れた版やサプライチェーン侵害の兆候が表面化する時間を確保する狙いで、security updateは従来どおり即時に作成されます。待機日数はdependabot.ymlのcooldownで変更・無効化できます。

なぜ重要か

依存更新の速度は安全性と独立ではありません。自動化のポリシーを、通常更新の観測期間と即時に必要なsecurity updateに分けることで、供給網リスクと修正遅延を別々に管理できます。

読むべき人
依存更新の運用担当、セキュリティエンジニア、GitHub管理者
HN
32 points / 10 comments
pg_re2はPostgreSQLとClickHouseの両方でRE2を使い、pushdown前後で正規表現の結果が変わる問題を抑える
PostgreSQLRE2ClickHouseQuery Pushdown

pg_re2は高速化だけでなく正規表現の実行差を消す

ClickHouseはPostgreSQL向けRE2拡張pg_re2を公開しました。RE2の有限オートマトンを使い、同社の測定ではPostgreSQL標準regexに対して1.8倍から8.6倍、インデックス利用では1.1倍から1.8倍の高速化を示します。より本質的なのは、PostgreSQLのPOSIX regexとClickHouseのRE2で異なる`\b`などの意味をそろえ、pushdownの有無で検索結果が変わる問題を避ける点です。

なぜ重要か

DB間のpushdownでは性能だけでなく意味論の一致が必要です。regex engineを替える変更は、対応構文・文字クラス・境界判定を回帰テストへ入れないと、速くなっても検索結果を壊します。

読むべき人
PostgreSQL利用者、データ基盤エンジニア、ClickHouse連携担当
HN
9 points / 1 comments
click-to-photonを実測すると、native WaylandとX11の差は小さく、XWayland経由の遅延が最大3.13msと目立った
LinuxWaylandX11LatencyDXVK

Linuxの入力遅延はX11対WaylandよりXWayland経路が効いた

Marco NettはUSBクリックから画面の明るさ変化までを光センサーで測る装置を作り、500Hz表示・RTX 4070 SUPER・Diaboticalという条件でX11、native Wayland、VRR、DXVK low-latencyを比較しました。native Waylandは同条件のX11より中央値で0.14〜0.22ms遅いにとどまる一方、XWaylandはnative Waylandより最大3.13ms遅く、VRRは0.26〜0.45ms短縮しました。単一環境の結果ですが、体感論を計測可能な経路差へ分解した点が有用です。

なぜ重要か

性能チューニングは平均FPSではなく、利用者が感じるend-to-endの経路で測る必要があります。仮想互換レイヤーを含む経路差を分けて測れば、環境変数の迷信より先に直すべき境界が見えます。

読むべき人
Linuxデスクトップ開発者、ゲーム/グラフィックスエンジニア、性能検証担当
HN
328 points / 204 comments
Bonsai 27Bは27B級モデルを1-bitで3.9GB、ternaryで5.9GBへ圧縮し、端末内の推論とagent実行を狙う
Local LLMQuantizationOn-device AIMultimodal

Bonsai 27B、27B級モデルを約4GBまで圧縮して端末内実行へ

PrismMLはQwen3.6 27Bを基にしたBonsai 27Bを発表し、1-bit版を3.9GB、ternary版を5.9GBとして公開しました。発表元の評価では1-bit版はフル精度ベースラインの90%、ternary版は95%を15ベンチマークで維持するとし、画像入力・262K token context・tool callingも掲げます。性能値はベンダー自身の測定なので独立検証が必要ですが、端末内agentを検討する際のメモリ、KV cache、品質、ライセンスを同時に比較する具体例になります。

なぜ重要か

大規模モデルを端末へ置けるかは重みのサイズだけで決まりません。品質低下、contextの実メモリ、端末性能、更新・評価の責任を測定して初めて、プライバシーとコストの利点を安全に使えます。

読むべき人
オンデバイスAI開発者、LLM基盤担当、プライバシー重視のプロダクトチーム
HN
310 points / 106 comments
生成文の表層語彙が自然でも、文長と段落の均質さを計測すると機械的なリズムを検出できるという提案
Japanese LLMEvaluationLintWriting Quality

日本語生成の検査を禁止語から文長リズムへ広げる

natural-japaneseは、語彙の禁止リストでは捉えにくい文長・段落構造の均質さをlintで検出し、生成後に書き直す工程を提案しています。著者は人間137本と7モデルによる406本のコーパスで閾値を校正し、GPT-5.6系で文長リズムの検出率が88〜95%だったと報告します。コーパスの偏り、同一データでの校正と比較、人間の知覚との対応は限定的だと著者自身も明示しており、絶対評価ではなく編集レビューを補助する計測として読むべきです。

なぜ重要か

生成品質の評価は主観だけにも禁止語だけにも寄せられません。測れる特徴をレビューの入口にしつつ、データの偏りとGoodhart化を明示して人間が最終判断する工程が必要です。

読むべき人
日本語LLMプロダクト担当、編集支援ツール開発者、AIライティング運用者
Zenn
137 signal / 0 comments