Debian 13「Trixie」をリリース

 (debian.org)
2 ポイント 投稿者 GN⁺ 2025-08-10 | 4件のコメント | WhatsAppで共有
  • Debianプロジェクトは約2年1か月30日の開発の末、**新しい安定版Debian 13「Trixie」**を公開
  • GNOME 48、KDE Plasma 6.3、LXDE 13、LXQt 2.1.0、Xfce 4.20など、複数のデスクトップ環境を標準でサポート
  • 14,100以上の新規パッケージが追加され、総パッケージ数は69,830個、8,840個のパッケージは陳腐化により削除
  • 44,326パッケージが更新され、コードベースの大規模なリファクタリングが実施された。全体のディスク使用量は403GB、コード行数は14億に達した
  • サポートアーキテクチャ: amd64, arm64, armel, armhf, ppc64el, riscv64, s390x
    • riscv64の公式サポートが初めて導入
    • i386サポートは中止されることが決定: 公式のカーネルおよびインストールツールは提供されず、64ビットCPUでのみ限定的に使用可能
    • armelアーキテクチャは本リリースが最終サポート
  • i386以外の全アーキテクチャで64ビット time_t ABIが適用され、2038年以降の日付にも対応

  • ソフトウェアおよび開発ツール

    • 全パッケージの63%以上が更新され提供
    • 代表的なソフトウェアと開発ツール: Apache 2.4.64、Bash 5.2.37、BIND 9.20、curl/libcurl 8.14.1、Emacs 30.1、GNU Compiler Collection 14.2、GIMP 3.0.4、LibreOffice 25.2、Linux kernel 6.12 LTS、LLVM/Clang 19、Python 3.13、Rustc 1.85、Systemd 257、Vim 9.1など
    • アーキテクチャ、サーバー、デスクトップ、クラスター、データベース、Webおよびストレージサーバーなどさまざまな用途に適している
    • 自動インストールおよびアップグレードテストなど、品質保証プロセスが強化されている

  • クラウドおよびライブインストールサポート

    • Amazon EC2、Microsoft Azure、OpenStack、PlainVM、NoCloudなどのクラウドサービス向けイメージを提供
    • クラウドイメージには、cloud-init自動化と高速なインスタンス起動のためのカーネル/ブートローダ最適化が反映
    • ライブイメージはamd64、arm64向けにDVD、USB、ネットワークブート形式で提供
    • ライブイメージでは複数のデスクトップ環境を選択して体験でき、GUIのない標準イメージも利用可能
    • Calamaresおよび標準Debian Installerでインストール可能で、HTTP Boot対応などさまざまなインストール方法が利用可能

関連記事

4件のコメント

 
zihado 2025-08-12

IRC の Debian チャンネルにいらっしゃった方々、元気かどうか分かりませんが。Debian Potato の頃は IRC でよく遊んでいましたが... w
 
jungmin1237 2025-08-12

Dockerタグもすでに出ているみたいですね。
https://hub.docker.com/layers/library/…
 
dongjinahn 2025-08-12

私も RAM 512MB の月額 $2.5 VPS で Ubuntu を使っていましたが、Debian に乗り換えてよかったです。Ubuntu から乗り換えたので当然慣れており、メモリ使用量も少なめでした。
 
GN⁺ 2025-08-10
Hacker Newsの意見

  • このコメントはDebianシステム上で書いています。個人的には普段使いのメイン環境として、Debianをかなり満足して使っています。Ubuntuが以前よりずいぶん悪化した後にDebian 6へ乗り換えましたが、後悔はありません。Debianは理念と実用性の両面でバランスが取れていること、基本的にはフリーソフトウェアを重視しつつ必要に応じてnon-freeソフトウェアやファームウェアを簡単にインストールできること、パッケージガイドラインとdpkg、そしてかなりしっかりしたドキュメント化も気に入っています（文書はArchが一番ですが）。stable/testingのパッケージストリームがあるため、古い版の安定性か、より新しいほぼ安定版かを選べるのも良いです。何より、私が間違えない限りDebian自体の欠陥でシステムが壊れたことは一度もありません。深刻な起動不能や問題が起きた場合も、ほとんどがサードパーティーリポジトリの追加や自分の設定ミスが原因でした。

    • Debianが優れていることは認めますが、システムが自分のミスがない限り決して壊れないという経験を共有しづらいです。特にDebian stableではカーネルに多くのパッチが当てられており、変化の速いDRMサブシステムでbackportする際に、デバッグが難しいクラッシュを何度も経験しました。名目上カーネルバージョンはリリース期間中ずっと同じですが、実際にはUbuntuのように継続的に最新カーネル（hwe系）を使う方がこのパッチの負荷は小さいです。なので私はVMではDebianを使い、ベアメタルではUbuntuを使っています。debian-backportsリポジトリでカーネルを使ったことはありません。

    • 私もUbuntu Serverを使っていたころ、アップグレードの問題でかなり苦労したので捨てました。75台以上のVPSを運用していますが、保守更新のたびに起動不能になる場合が出るのではないかと心配した経験が多かったです。その障害復旧だけでVPS1台あたり1〜2時間余分にかかることが多かったです。2015年ごろ8.x時代からDebianに移行してからはずっと安定しています。私が間違っていじらない限り、壊れたことはありません。

    • Ubuntuがかなり悪くなったというのは、どの点でそう感じるのでしょうか。

    • Debianの唯一の欠点なら、新しいサーバーソフトウェアをインストールするとすぐ実行しようとすることです。大半のデフォルト設定は安全ですが、私が設定する前にサービスが起動してしまうのが少し怖いです。Red Hatはインストールしてから私が自分で起動するまでサービスが立ち上がらない方式なので、その点のほうが気に入っています。

    • Debianは私のサーバー運用の基盤です。サーバーはOld Stableのままにし、新しいリリース機能は一時システムでテストします。Bookwormではnftablesを学び、Trixieではlabwcを試しました。labwcはWaylandをサポートしつつOpenboxスタイルの設定が可能です。

  • Debianコミュニティのボランティアの皆さんに感謝しています。DebianとDebianをベースにした数多くのプロジェクトを可能にしたのは皆さんのおかげです。本当に多くの人や企業が皆さんの努力から利益を得ています。個人的には、今回のTrixieリリースが特に楽しみです。私のサイドプロジェクトntfyがパッケージとして収録されてTrixieに入りました。

    ただ、リリースサイクル後半になってようやくntfyパッケージャからライセンス関連の問い合わせを受けて初めて知ったのですが、DebianパッケージではWebアプリが削除され、いくつかの機能がパッチで除外されています。Stripe、Firebase、WebPushなどを簡単に外せるようにbuild tagsも追加したので、次のDebianリリースではパッチがもっと少なくなることを期待しています。アップストリームのメンテナーとしては、Webアプリがなぜ削除されたのか明確な案内がないのが惜しいです。意図的に除去したのは分かりますが、次のリリースで入れようとするならどうすればよいかよくわかりません。apt install ntfyしてWebアプリが動かないと、多くのユーザーが失望すると思います。アドバイスやガイドは歓迎です。ソースコードも参照できます。

    • パッケージメンテナーは関連説明を追記しています。Webアプリはnodejsベースで、対応するnodejsパッケージがDebianにはありません。Debianの方針上、パッケージに依存ソースを直接含めることは避けます。そうすると依存パッケージも自分で作成・管理する必要があり、負担が大きかったようです。

    • Debianのnpmパッケージビルドは、必ずビルド可能でなければなりません。そのため、別のdebian-specific package.jsonでnpm依存をDebianパッケージに置き換えるか移植するか、別パッケージとして提供する必要があります。潜在的にかなり作業量が大きいです。lockfileが大きい場合は本当に手間がかかります。おそらくメンテナーはこの程度の分量を負担に感じたのだと思います。Debian的には、ntfy-webのような別パッケージとして提供するのがより自然に見えます。

    • ntfyに感謝しています。自宅ではMeshtasticノードでイベント通知を受けるときに毎日使っています。

    • ntfyソフトウェアは本当に良く使っています。

    • 依存関係の問題を解決したければ、コンテナイメージとして配布するのがより良い方法かもしれません。

  • Debianは私の自由なコンピューティング人生の安定した基盤です。Condorcet投票方式、手続き的合意、原則ベースの意思決定などで大きな影響を受けています。プロジェクトとその文化が世の中に与えた影響は本当に計り知れないほど大きいです。愛をこめてお祝いします。

  • i386アーキテクチャの一般サポートがついに終了したという内容です（最新カーネルやインストールプログラムがなく、64ビットCPUでの使用推奨、純粋な32ビットハードウェアはもはやアップグレード非推奨）。2025年8月までi386サポートが続いたのはすごいことです。私はまだPentium 3ベースのハードウェアでDebian 10 Busterを動かしていました（2024年6月EOL）。古いハードウェアで試せるように、サポートが長く続いたのはありがたいです。もしどうしてもi386で最新OSが欲しい人がいたら、OpenBSDも検討する価値があります。

    • 2007年ごろ、最後にPentium 3を使ったと思っていましたが、今はたった1ドルで100倍速いPCが手に入る時代です。

    • i386が最新Debian portsインフラ（例：m68kがある方）に移れば、Debian 14や15でも引き続き実験的に使えるはずです。

    • old stableはおよそ1年程度追加サポートされるはずです。つまり、2025年以降も完全に終わるわけではありません。

    • これはDebianサポートの話です。実際、Linuxカーネル自体はオリジナルPentium以降の32ビットCPUまで引き続きサポートしています（いくつかのクローンチップセットを除く）。

    • "386"と32bitを混同した話ではありませんか？通常は686が一般的な32bitアーキテクチャで、386は1980年代の話です。

  • sysvinitもまだ使用可能です。サーバーとデスクトップで既にテストしました。特定のパッケージの依存性問題で、次のようなコマンドを使い削除とインストールを同時に実施すると問題を避けられます。関連Debianバグでは、systemd-sysvとsystemdへ「-」を付けて削除するのが重要です。この方法でdebootstrapで作るsysvinitビルドは、bookwormのときとほぼ同じです（デスクトップを含む）。bookwormやbusterを使っていたときと同じく、apt preferencesでlibsystemd0だけを維持し、他のsystemdパッケージはpriority -1で遮断すればよいです。

    • debian 13でもsysvinitが本当に動作するのか本当に気になります。つまり、systemdを外してもsysvinitでサーバー運用ができるかどうかです。

    • 情報共有に感謝します。少なくともlxcコンテナでは試してみるつもりです。

    • ここまで徹底する必要があるのか気になります。

  • x86-64向け.torrentイメージをどこで探すか大変なので、リンクを整理しておきます
    Minimal: netinstall ISO
    Full: DVD ISO

    • ほとんどのユーザーはDVD（フル）イメージを必要としません。インストール時にパッケージをダウンロードするminimal netinst CDだけで十分です。

  • trixieで公式にサポートする7つのアーキテクチャをまとめました

    • amd64(64-bit PC)
    • arm64
    • armel(ARM EABI)
    • armhf(ARMv7 EABI hard-float)
    • ppc64el(64-bit little-endian PowerPC)
    • riscv64(64-bit little-endian RISC-V)
    • s390x(IBM System z)
      RISC-Vは実際に使えるハードウェアがあまりありませんが、ついに一級プラットフォーム扱いを受けるのが嬉しいです。最近のPowerPCやSystem zはどこで使われているのでしょうか。amd64/arm64/riscv64以外で他のアーキテクチャが実際に展開されている場所が気になります。

    • Powerとzは今も数十億ドル規模のビジネスです。両方とも金融業界や銀行で広く使われています。IBMはzに関しては今も誇りを保っていますが、Powerは最近はただ生き残るだけの印象で少し残念です。Powerはアーキテクチャもシステムも本当にうまく作られています。

    • メインフレームは、1台のサーバーで数十年間サービスを止めずに運用し続ける用途に定着しています。さらにプロセッサやメモリなどの部品もhot-swap（運用中交換可能）で、OSサービスと別にハードウェアの常時モニタリング/診断も可能です。ハードウェア問題が検知されると自動的に所有者とIBMに通知されます。IBMは2000年代初頭からメインフレームでLinuxを第1級OSとしてサポートしてきました。開発者の立場としては、s390xは最後に残ったビッグエンディアンアーキテクチャなので（SPARCはまだあるものの事実上メンテナンスモードで、OracleのみがSolarisを気にしている）、エンディアンバグの検出にも役立ちます。現在残る32ビットアーキテクチャはarmelとarmhfの2つだけで、今回のリリースがarmelサポートの最後です（参照）。まもなく公式な32ビットサポートも終了しそうです。

    • IBMはこの2つのアーキテクチャが主要ディストリビューションで引き続き正常動作するように、かなりの努力を注いでいます。そのため他のアーキテクチャのように生態系で自然発生的に維持されるというより、IBMの支援で残されている印象です。

  • systemdでNICの名前管理が心配な場合は、リリースノート（リンク）を参照するとよいです。udevadmコマンドでアップグレード後にインターフェース名がどう変わるかを事前に確認できます。bond/loインターフェースを除いた一覧も、以下のone-linerで確認可能です。今まで直接テストした範囲では、実際にアップグレードでインターフェース名が変わったことはなかったので、この方法で本当に名前変更を事前に捕捉できるかどうかは自信がありません。

    • たぶんインターフェース命名に関する最後の大きな変更になるでしょう。enoX表記は常に安定して維持されるべきで、これはBIOS（ACPIテーブルなど）からどのポートがどのIDかが示されるためです。ensX方式はPCIeスロットを基準にしていますが、PCIeツリー構造のため1スロットに複数のNICがある場合があり、複雑です。systemdはそのような例外ケースのためにインターフェース命名ロジックを何度も変更してきました。かつてPCIeスロット番号を間接的に読み取り衝突したこともありましたが、これはsystemd 257で修正されました。

    • アップグレード前にsystemdのPredictable Network Interface Namesを事前に無効化していた場合でもインターフェース名が変わる可能性があるか気になります。

  • slinkの頃からDebianを使っています。今でもapt-get ...を必ず入力するようになっており、今でもなんとかよく動いています。25年以上のアップグレードの中で大小の問題はありましたが、その時間と労力は他のLinuxやクローズドソフトと比べると本当にわずかでした。一つ残念なのはコミュニティへの貢献をもっとしなかったことです。Debianの大きな長所は、ユーザーがシステムの動作を最低限ある程度理解して使えるという点です。そのおかげで「できるだけシンプルだが、過度にシンプルになりすぎない」という哲学をきちんと守れていると思います。

  • Debianの代表的な強みは、stableからstableへ15分以内でアップグレードできる点です。私の最初のシステムは、パッケージのダウンロードと再起動まで10分もかからずに移行が完了しました。とくに性能の高いコンピューターではなく、ネットワークも50MbpsのミニPCでした