ハクソク

世界を動かす技術を、日本語で。

Debian 13「トリクシー」

289日前原文(debian.org)

概要

  • Debian 13 "trixie" が正式リリース、5年間のサポートを提供
  • 合計 69,830パッケージ、新規14,100超・更新44,326・削除8,840
  • 7つのアーキテクチャ 公式サポート、新たにriscv64追加
  • i386は通常サポート終了、armelも今リリースが最後
  • 多言語対応・クラウド/コンテナ/ライブイメージ など幅広い展開

Debian 13 "trixie" リリース概要

  • Debianプロジェクト が約2年1ヶ月30日の開発期間を経て Debian 13 "trixie" をリリース
  • 5年間の長期サポート をDebian Security TeamとLong Term Support Teamが提供
  • 対応デスクトップ環境 ：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億6千万超
  • manページ多言語化強化、特にRomanianとPolish翻訳が向上

主要技術・新機能

  • i386以外の全アーキテクチャ で64bit time_t ABIを採用、2038年問題解消
  • パッケージのバイト単位での再現性 向上、debian-repro-statusパッケージで確認可能
  • 主な更新ソフトウェア ：
    • Apache 2.4.64、Bash 5.2.37、GCC 14.2、Linuxカーネル6.12 LTS、OpenSSH 10.0p1
    • LibreOffice 25.2、Python 3.13、Rustc 1.85、PostgreSQL 17、MariaDB 11.8など
  • 7つの公式サポートアーキテクチャ ：
    • amd64、arm64、armel、armhf、ppc64el、riscv64、s390x
  • i386は通常アーキテクチャから除外、amd64 CPU上でのみ限定利用
  • armelは今回が最終リリース

クラウド・ライブイメージ・インストール

  • Debian Cloud Team がAmazon EC2、Azure、OpenStack、PlainVM、NoCloud向けにtrixieを提供
  • ライブイメージ ：amd64とarm64向け、DVD/USB/ネットブート対応
    • GNOME、KDE Plasma、Cinnamon、MATE、LXDE、LXQt、Xfceから選択可能
    • Calamares独立インストーラと標準Debian Installer搭載
  • Docker Hubでマルチアーキテクチャ対応コンテナイメージ も提供
  • HTTP Boot対応、多様なインストールメディア（Blu-ray/DVD/CD/USB/ネットワーク）選択可能
  • 78言語にインストーラ対応、テキスト・グラフィカル両方利用可能
  • BitTorrent推奨 でイメージ配布、物理メディアでも近日提供

アップグレードと注意事項

  • Debian 12 "bookworm"からのアップグレード はAPTツールで自動対応
    • 事前バックアップ推奨、特に/etc, /var/lib/dpkg, /var/lib/apt/extended_states, dpkg出力
  • アップグレード報告はupgrade-reportsパッケージ経由でバグトラッカーへ
  • Debian Installerの進化 ：ハードウェア対応強化、スピーチシンセサイザ対応、btrfsサブボリューム救出機能追加
  • OpenLDAPのTLSサポートがGnuTLSからOpenSSLに変更
    • デフォルトでシステムのCAストア利用、詳細はldap.conf.5 manページ参照
  • リリースノートの「既知の問題」セクション を事前に必ず確認
  • bookworm-backportsのAPTエントリはアップグレード前に削除推奨
  • APT::Default-Releaseやピン設定利用時は調整が必要

Debianプロジェクトについて

  • Debianは世界中のボランティアが開発する自由なOS
  • Debian Social ContractとFree Softwareへの献身 が特徴
  • 詳細情報・問い合わせ ： https://www.debian.org/ または press@debian.org

Hackerたちの意見

おめでとう！Debianは、私のフリーコンピューティングライフの安定した基盤として30年も支えてくれたんだ。彼らのアプローチは、コンドルセを見せてくれたり、安定した混沌を整理したり、慎重なコンセンサスで前に進んだり、しっかりした原則に基づいているところが、技術面から社会面まで、いろんな影響を与えてくれた。私はこのプロジェクトが大好きで、彼らのリリースや文化を通じて世界に与えた計り知れない影響に感謝してる。愛を込めて、g’o xx

sysvinitはまだ使えるよ。サーバーやデスクトップのビルドもテスト済み。私のビルドボックスから: chroot $MOUNTPOINT/ /bin/bash -c "http_proxy=$aptproxy apt-get -y --purge --allow remove-essential install sysvinit-core sysvinit-utils systemd-sysv- systemd-" ちょっと変な依存関係があって、同時に削除とインストールをしないと回避できないんだ。Debianのバグがこれを指摘していて、systemd-sysv- systemd-の修正として「-」が必要だったり、allow remove essentialが必要だったりする。これを修正した後、sysvinitのビルドはbookwormとほぼ同じになったよ。デスクトップ用も含めてね。bookwormからbusterにかけて、これも必要になるよ: $ cat /etc/apt/preferences.d/systemd # これは唯一必要なsystemdパッケージだから、優先度を上げる... パッケージ: libsystemd0 Pin: release trixie Pin-Priority: 700 # 残りを除外 パッケージ: systemd Pin: release * Pin-Priority: -1 パッケージ: systemd Pin: release * Pin-Priority: -1 パッケージ: systemd:i386 Pin: release * Pin-Priority: -1 パッケージ: systemd:amd64 Pin: release * Pin-Priority: -1

└

え、Debian 13でsysvinitが本当に動くの？つまり、systemdを外してもsysvinitで動くサーバーOSが持てるってこと？

i386はもはや通常のアーキテクチャとしてサポートされていない。公式のカーネルもi386システム用のDebianインストーラーもない。i386アーキテクチャは、今や64ビット（amd64）CPUでのみ使用されることを意図している。i386システムを運用しているユーザーはtrixieにアップグレードしない方がいい。代わりに、可能であればamd64として再インストールするか、ハードウェアを引退させることを推奨している。i386のサポートが2025年8月まで続くのはすごいね。私はPentium 3でDebian 10 Busterを動かしていて、これが2024年6月にEOLになったばかりなんだ。そのハードウェアでもまだ役に立ってるし、サポートが続いてくれて感謝してる！古い32ビットハードウェアでモダンなOSを探している人にはOpenBSDがi386をサポートしているよ。

└

できればi386（あるいは64ビットの時間値を追加サポートした新しいi386風のポート）が、Debian 14（forky）やDebian 15（duke）のために非公式のDebian Portsインフラに移行できるといいな。Debian Portsにはm68kポートがあるから、i386用のサポートも大きな問題にはならないはず。

└

そういえば、古い安定版にはもう1年くらいのサポートがあるんじゃなかったっけ？2025年以降も。

└

AFAICT、これはDebianのサポートを指してるみたい。Linuxカーネルは32ビットCPUをサポートしてるけど、オリジナルのPentium以降のみ（いくつかのクローンを除く）。

└

「386」と「32bit」を混同してない？686が普通の32bitアーキテクチャだよね。386は1980年代のものじゃない？

Debianシステムからこれを書いてるけど、日常使いに最高のディストロだよ。Ubuntuがひどくなった後にDebian 6に切り替えたけど、後悔したことはない。Debianのイデオロギーに対する慎重な実用主義が好きで、デフォルトでフリーソフトウェアのディストロだけど、非フリーソフトウェアやファームウェアのインストールも簡単にできるところがいいね。Debianのパッケージガイドラインも好きだし、dpkgも好き。Archがその面では一番だとしても、Debianのドキュメントもいいと思う。安定版とテスト版のパッケージストリームもあって、古いけど超安定か、ちょっと古いけどほぼ安定かを選びやすいのもいいところ。しかも、私のせいじゃない限り、Debianシステムが壊れたことは一度もない。Debianが起動しなくなったり、他の深刻な問題が起きたのは、サードパーティのリポジトリから何かを追加しようとしたり、設定を間違えたりした時だけで、Debianシステム自体のせいじゃないんだ。

└

Ubuntuがひどくなった後に後悔したことはない。具体的にUbuntuはどのようにひどくなったの？

└

ずっとFedora派だったけど、今もそうだよ。でも2023年にPCがProxmox（Debian）に移行したんだ。今はFedora AtomicがVMでflatpaksとpodmanコンテナを動かしてるよ :D

└

「自分のせいじゃない限り、Debianシステムが壊れたことはないよ。Debianは素晴らしいけど、これはみんなの共通体験とは言えないな。特に、Debian stableのカーネルの重いパッチにやられたことがある（具体的には、急速に変化するDRMサブシステムでのバックポートの不具合が原因で、デバッグが難しいクラッシュにつながった）。Debianのリリースは技術的には「同じ」カーネルを持っているけど、Ubuntuは新しいカーネルを使っていて、-hweはパッチの摩擦をかなり避けてる。だから、DebianのVMは使ってるけど、ベアメタルではUbuntuを使ってる。Debian-backportsリポジトリのカーネルは試したことないけどね。」

└

うん、アップグレードの頭痛が多すぎてUbuntu Serverをやめたよ。アプリホスティングのために75以上のVPSインスタンスを管理してるけど、メンテナンスアップデートをするのは神経使う。再起動しない可能性があるからね。それだけでVPSごとに1〜2時間余分にかかることもある。2015年の8.xの頃にDebianに切り替えたけど、ずっと順調だよ。自分が壊した以外は壊れたことがない。

Debianとその派生版を可能にしてくれるすべてのDebianボランティアに感謝！あなたたちの仕事でどれだけ多くの人や企業が助けられているか、すごいことだよ。ありがとう！個人的には、Trixieがすごく楽しみなんだ。なぜなら、私のサイドプロジェクトであるntfy [1]がパッケージ化されて、今Trixieに含まれているから。これが含まれていることを知ったのは、パッケージメンテナがライセンスの確認を求めてきた時で、サイクルのかなり遅い段階だった。結果として、Debian化されたntfyにはウェブアプリが含まれていない（これは本当に残念）し、いくつかのものが「パッチアウト」されている（これはまあいいけど）。メンテナにアプローチして、最近、Stripe、Firebase、WebPushを削除しやすくするためのビルドタグ [3] を追加したんだ。次のDebian化されたバージョンには（そんなに）変なパッチが含まれなくて済むようにね。「アップストリームメンテナ」として言わせてもらうと、ウェブアプリが含まれなかった理由は全く明らかじゃない。明らかに意図的に削除された [4] けど、次のDebianリリースに入れるために何をすればいいのか全然わからない。「apt install ntfy」をやっても、ウェブアプリが動かなかったら大半の人はがっかりするだろうし。何か助けやアドバイスがあれば大歓迎だよ！ [1] https://github.com/binwiederhier/ntfy [2] https://tracker.debian.org/pkg/ntfy [3] https://github.com/binwiederhier/ntfy/pull/1420 [4] https://salsa.debian.org/ahmadkhalifa/ntfy/-/blob/debian/lat...

└

ntfyに感謝したい！毎日、家のMeshtasticノードからのイベント通知に使ってるよ。

└

メンテナーがここで簡単に説明してるよ: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10

「ウェブアプリはnodejsアプリで、現在Debianにはないパッケージが必要なんだ。Debianではパッケージ内に依存関係を持つのはあまり好ましくないから、メンテナーは自分でそのパッケージを追加して管理する必要があったと思う。多分、彼らはその手間をかけたくなかったんじゃないかな。」

└

ウェブの部分について: Debianのソースはビルドに十分でなきゃいけない。だからnpmプロジェクトでは、通常はDebian特有のpackage.jsonがあって、各npm依存関係（ビルドに必要なdevDependenciesも含めて）は、Debianパッケージに置き換えるか、ベンダリングする必要がある（後者は特にサードパーティのコードだとあまり理想的じゃない）。あ、バージョンを合わせるのも楽しんでね。それはできるけど、かなり大変な作業だよ、こんなに大きなロックファイルがあるとね。メンテナーはその追加の手間を正当化できなかったんじゃないかな。どちらにしても、Debianのやり方はおそらく、ntfy-webパッケージとして分けることになると思う。

systemdでのNIC変更を心配している人へ、リリースドキュメントからの情報だよ: https://www.debian.org/releases/trixie/release-notes/issues.... 例: udevadm test-builtin net_setup_link /sys/class/net/eno4 2>/dev/null ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link ID_NET_LINK_FILE_DROPINS= ID_NET_NAME=eno4 これ、bondインターフェースとloを除外した一行スクリプト。変更前後のリストがきれいに出るよ。 for x in $(cat /etc/network/interfaces | grep auto | cut -d ' ' -f 2 | grep -Ev 'lo|bond0'); do echo -n $x:; udevadm test-builtin net_setup_link /sys/class/net/$x 2>/dev/null | grep NET_NAME| cut -d = -f 2; done ドキュメントの論理は、trixieにアップグレードした後、再起動前に、再起動後にインターフェースがどう名付けられるかを見るために十分なsystemdが動いているってこと。今のところ、アップグレードによるインターフェースの変更はなかったから、上記がそれを検出するかはわからないな。

ナビゲートがちょっと難しいかもだけど、x86-64用の.torrentリンクはこれだよ。Minimal: https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/deb... Full: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/de...

└

DVD（"フル"）イメージは多分必要ないよ。ほとんどのユーザーは"minimal"ネットインストールCDを使って、インストール時にパッケージをダウンロードすればいいと思う。

"trixie"では合計7つのアーキテクチャが公式にサポートされてるよ: "trixie" 64ビットPC (amd64)、64ビットARM (arm64)、ARM EABI (armel)、ARMv7 (EABIハードフロートABI, armhf)、64ビットリトルエンディアンPowerPC (ppc64el)、64ビットリトルエンディアンRISC-V (riscv64)、IBM System z (s390x) RISC-Vが一級市民になってるのはいいことだね。今のところハードウェアがあまり使われてないのが残念だけど。最近、PowerPCやIBM System zはどこで使われてるんだろう？amd64、arm64、（もうすぐ？）riscv64以外の現代的なLinuxシステムが展開されてるのかな？

└

Powerとzはそれぞれ何十億ドルのビジネスだよ。銀行や他のハイファイナンスが両者の強みだね。IBMはまだzを誇りに思ってるみたいだけど、Powerは最近はただ許容されてるだけって感じがして残念。いいISAだし、システムもすごくいいのに。

最近のリリースでDebianとUbuntuの違いは減ってきてるね。1年前に出た自分のノートパソコンのハードウェアコンポーネントをDebianがすぐに認識してくれて、びっくりしたよ。ハードウェアサポートも良いし、UIも素晴らしい！Ubuntuよりもサクサクしてる気がするのは、snapがないのと、デフォルトでインストールされるサービスやアプリが少ないからかも。

Debianが大好きで、このプロジェクトに関わっている人たちにはものすごく敬意を持ってる。今はDebianを使ってないけど、利益追求の企業に過度に依存せず、真にコミュニティ主導のLinuxディストリビューションが必要だと思う。