Nemotron 3.5 Lightning with Inference Snaps
8月11日（日本時間12日）に、NVIDIAから新しいオープンウェイトモデル、Nemotron 3.5 Lightning が登場しました。ライセンスはOpenMDW-1.1で、特に推論速度が重視されたモデルです。
そしてSnap経由でこのモデルを利用できる、Inference Snaps版 が同日に登場しています。
Inference Snapsによって抽象化されているため、Qwen 3.6の場合 とほとんど同じ操作（「 qwen3-6」を「nemotron-3-5-lightning」に読み替えるだけ）で推論環境を整えることができます。動作は一応CPUモードをサポートしているものの、ほぼNVIDIA製GPUが前提 です。
「同日に」提供開始されていることがポイントで、CanonicalとNVIDIAの連携が成熟していること、そしてInference Snapsの「モデルと実行環境をパックして頒布する」という設計がうまく機能した好例と言えるでしょう。
stonking（Ubuntu 26.10）の開発; 壁紙コンテストの開催
OpenSSL4への移行に伴う各種修正が実施され、Apache HTTPd、open-vm-tools、PHP、libp がOpenSSL4対応することになりました。どこまでのパッケージが対応できるのか（あるいは「コアパッケージがあまりにも非対応なので延期」という結論になるのか）は現状まだ不明な部分が多いものの、流れとしては良い方向と言えるでしょう。
Ubuntuの開発ではお馴染みになりつつあるイベントとして、stonkingでも壁紙コンテスト が開催されます。
これまでと同様、以下の3カテゴリーでの募集となっています。
マスコット（“ Stonking Stingray” をテーマにしたもの）
デジタル／抽象画
写真
投稿者自身が著作権を保持していること、そしてCC BY-SA 4.0もしくはCC BY 4.0での提供に同意すること、3840x2160ピクセルのPNGもしくはWebPが推奨されます。ISOイメージへの収録はカテゴリーごとの上位2作品、AIが生成した作品は禁止[1] 、ウォーターマークや名前・ロゴが存在しないことが前提と、これまでの壁紙コンテストとほぼ同じレギュレーションとなっています。
興味のある方はこのあたりを参考 に、ご自身の作品を投稿してみてはいかがでしょうか。応募は8月28日まで、その後一週間の投票期間を経て9月4日に受賞者が確定するという流れとなっています。
[1] AI生成物を受け付けない主な背景としては、「 多くの人気AIモデルが、アーティストの許可なく彼らの作品を使用していることが明らかになっています。これは、私たちのコミュニティの価値観や掲げる使命にそぐわないと考えています」（ Many popular AI models have been shown to include artwork from artists without their consent. We do not believe this aligns with our community's values and stated mission.）ということと、「 AIが生成した芸術作品の所有権、そしてそれが著作権で保護されるか否かについては、活発な法的議論が交わされています」（ There are active legal debates on the ownership of AI generated artwork and whether it can or can't be copyrighted.）ということが述べられています。CC BY-SA 4.0やCC BY 4.0での提供のためには複数の国で「著作者」として認められる必要があり、そうすると少なくとも現在の国際法整理ではAI生成の画像は適さない、といった整理でしょう。
Rust 1.94のバックポートとバックポートツールの整理
resolute（26.04 LTS）用のRust 1.94がnoble（24.04 LTS）にバックポート され、また、バックポートのためのユーティリティが強化されたことが報告されています（これにより、今後のメンテナンス負荷が下がることが期待されます） 。
UbuntuのRustはやや特殊な扱いで管理されており、「 最新のRustツールチェーンを3つまで」保持し、また、カーネルや主要コンポーネント内の重要なパッケージで特定の古いリリースが必要ならそれも残すという形で保持 されています。最新のRustが必要な場合は、「 バックポートされて新しいバージョンものを使うことができる場合がある」ということを覚えておくと安全です。
注目すべきセキュリティー的な視点： クライアントを最新に保つあらゆるソフトウェアにはバグがつきものです。たとえ（現実的にはありえない仮定ですが）作成された段階では問題がなかった実装であっても、周辺環境の変化によって新たな不具合が生まれることもありますし、ハードウェアにすら「ソフトウェア的な問題」が見つけられることがあります。たとえばCPUの脆弱性は「ハードウェアに存在する脆弱性」の典型的なもので、攻撃手法ごと新たに開発されることはほとんどです。
このため、あらゆるソフトウェアや変更可能なハードウェアは、継続的なアップデートが必要です。継続的なアップデートを実現するためには、ソフトウェアのメンテナンスが継続されていること、そしてリリースされたアップデータを適切なタイミングで取り込むことが必要になります。
アップデートを適用するためには、対象となる端末に電源が入っており、OSは正常に稼働している必要があり、つまり該当する端末がオンライン状態である必要があります。このことは、「 夏休みなどの長期休暇と衝突すると、タイムリーには更新されない」という問題をしばしば引き起こします。例えばWindowsであれば、今年はいわゆるPatch Tuesdayが8月11日（山の日）であり、さらにこの時期は本格的な夏休みシーズンでもあります。該当する端末にアップデートが適用されるのは夏休み明けになるでしょう。これは言い換えれば、その期間は攻撃者にとって大きなチャンスが与えられるということでもあります。
しかし一方で、世間的にはWindows Updateのための待ち時間は忌み嫌われており、建設的な方法で解決する必要があります。
企業内に設置されたデスクトップのような環境であれば、管理用のソフトウェア群を用いて強制的にリモートから電源を投入してアップデートするようなことも可能ですが、現代的なラップトップPC主体の環境ではこれも困難です。こうした問題を端末、つまりホスト単位である程度確実に解決するためには、MDMのような端末管理ソフトウェアを導入するか、自動的なアップデートを強制するかしかありません。
非常に残念ながら、Linux環境に対するMDMのサポートは非常に限定的で、「 アップデートされた状態を強制する」実装はメジャーではありませんし、そもそもLinuxを対象にしたMDMそのものが選択肢としてあまり多くありません。Intune がかろうじて「MDMとしては」サポートしているものの、現状では制限が多く、SSOまわりの刷新とあわせて今後発展が期待されるものの、実装として十分ではありません。
総じて、Ubuntuを用いて「最新の状態になっていなければゼロトラスト環境に接続できない」というような処理を実現するためには、相応の作り込みが必要です。
一方、「 必ず最新の状態にする」という方向性であれば、これはそこまで複雑ではありません。ただし、「 企業が中央で管理する」という条件を含めてしまうとやっかいな問題が発生します。
順に見ていきましょう。
まず、Ubuntuにおける「システムを最新状態にする」定番の実装はunattended-upgradeで、ユーザーの介在を必要とせず、パッケージ構成をリポジトリサーバーの状況にあわせて更新します。制約としては「パッケージ構成をアップデートしても、パッケージ以外の部分に未更新の部分が残る可能性がある」という点で、これはunattended-upgradeではほとんど解決されません。たとえばnode.jsやpythonなどの利用環境をパッケージ管理の外で導入している場合、さらにはユーザーのホームディレクトリ以下にバイナリが構成されているような場合、あるいはハードウェアの脆弱性まで含めて更新を検討しようとするとだいぶ厄介な問題になります。
さらにパッケージ構成そのものを最新にできたとしても、新しいバイナリで動作していることを保証するにはそれなりに壁があります。基本的に、勝手に再起動するようなことは行われないため、パッケージ構成として更新されているという状態と、実際に動作しているバイナリが最新状態であるということの間には距離があります。
また、「 最新パッケージ構成に『しようとすること』 」は保証されますが、「 最新パッケージ構成で『あること』 」を保証することは相応に困難です。アーカイブサーバーがうまく動作していなかったり、何らかの理由でアップデート処理がブロックされていたりするような場合、更新が滞る可能性があります。この状態は企業などで集中管理を行おうとする場合、非常に厄介です。
さらに、アップデートそのものには一定のリスクがあります。あらゆるソフトウェアにバグがある以上、アップデートそのものにバグが入り込む可能性もありますし、挙動に変化が起きてしまった場合、それが障害の原因になることもありえます。
こうした問題に対応するための典型的な手法としては、「 パッケージ構成の期待されるバージョン」をリストしておき、その結果をserverspec やgoss などのサーバー環境向けソフトウェアを用いて判定する、という方法論がありえます。あるいはLandscapeを用いて管理するという手もあるでしょう。こうしたソフトウェアを利用した事前チェック的なスクリプトを作り込むことは、以前は「適切な見切り」（ つまりは熟練）が必要だったものの、現代ではLLMに任せることで簡単に作成できるようになりました。また、Active Directory経由（つまりadsys ）を使ってGPO経由で識別のためのメタデータやスクリプトを配布することもできるようになっています。
現状としては「unattended-upgradeを使って最新状態になることを期待する」「 （ 必要であれば）Active Directory経由で最新状態が保たれていることを識別可能にする」「 （ 場合によっては）自前のアーカイブサーバーやミラーサーバーを保持する」といったことの組みあわせ（もしくはLandscapeを使う こと）で土台を作ることができるようになりつつある、というのがUbuntuでの現状と言えるでしょう。
ただし、こうしたスクリプトそのものにも問題が生まれる可能性があり、そこを狙われる可能性もまたあるという「いたちごっこ」構造がどうしても生まれてしまい、最終的には「利用者のリテラシーを引き上げるべきだ」という結論に逃げてしまいたくなります。一方で「パッケージ構成が最新になっていない」という事案はケアレスミスなどでも発生する性質のもののため、リテラシーだけで解決しようとすると問題解決としてはむしろ後退してしまう、というやっかいな構造があります。
