YAST は Agama、Cockpit、Myrlyn に変わりました。これが openSUSE の世代交代です。

SUSEとopenSUSEのエコシステムは、近年最大の変化の1つを経験している。システムのインストールと管理の中心コンポーネントとしてのYaSTが徐々に撤退し、その役割を担うことになる3つのツール、Agama、Cockpit、Myrlynが登場しました。長年openSUSEを使用してきた人にとっては、これはほとんど冒涜的な行為のように聞こえるかもしれませんが、この動きには非常に明確な技術的および戦略的根拠があります。

この変更は単なる外観の刷新ではなく、根本的な再構築です。 このドキュメントでは、コミュニティ環境（openSUSE LeapおよびTumbleweed）とエンタープライズ環境（SUSE Linux Enterprise）の両方において、SUSE Linuxベースのシステムをインストール、設定、および保守する方法について説明します。その結果、YaSTと後継製品であるインストーラとしてのAgama、管理センターとしてのCockpit、そして新しいグラフィカルパッケージマネージャとしてのMyrlynが、時に緊張感を伴いながら共存する移行シナリオが生まれました。

YaSTから新しい管理モデルへ

数十年にわたり、YaSTはSUSEの象徴となってきましたそれはモノリシックで非常に強力、そして高度に統合されたツールであり、システムのインストール、ソフトウェア管理、そして高度なネットワーク、ハードウェア、セキュリティ、そしてサービス設定を一元管理していました。FTPサーバーの設定、Active Directoryドメインへの参加、グローバルプロキシの調整、プリンターの管理など、すべて同じインターフェースから行うことができました。

その汎用性には、大量のレガシー コードという大きな代償が伴いました。、古い依存関係、そしてメンテナンスの複雑さが増していました。時間の経過とともに、その機能の多くは、より現代的なデスクトップツール（KDE Plasma、GNOMEなど）や、 はるかに軽量なコンソールユーティリティそのため、YaST「モンスター」全体を長期的に維持することは不可能になりました。

そのため、SUSEの経営陣はYaSTの歴史的役割を分割することを決定した。 これは、最新の技術を用いて構築された複数の専用コンポーネントで構成されています。システムインストール用のAgama、インストール後の管理用のCockpit、そしてlibzyppを直接ベースとしたグラフィカルパッケージ管理インターフェースであるMyrlynです。その目的は、業界標準への依存を高め、単一のディストリビューションからのプロプライエタリツールへの依存を減らすことです。

この分離は新しいトレンドにも適合する 不変のシステム、クラウド展開、ブラウザ経由のリモート管理など、Web 経由でアクセス可能な一連のモジュール式サービスとフロントエンドよりも YaST のようなモノリシック ツールに適さない領域です。

問題は、YaST のように統合されたベテランを廃止することが、2 つのバージョンの問題ではないということです。そして、それが今日でも、Leap、Tumbleweed、SUSE Linux Enterprise のどれを話しているのかによって、非常に異なる世界が共存している理由を説明しています。

openSUSE Leap 16: 転換点

openSUSE Leap 16はこの移行の転換点となるこれは、YaST がコアツールとして完全に廃止され、新しいトリオ Agama + Cockpit + Myrlyn がインストールされたシステムの管理の中核となる、Leap の最初のバージョンです。

Leap 16.0はSUSE Linux Enterprise Server 16を直接ベースとしています。 新しいSUSE Linux Framework One（SLFO、ALPプロジェクトの後継）を統合しています。これにより、従来のパッケージベースのディストリビューションモデルは維持されつつ、近代化された技術基盤が採用され、より長いリリースサイクルが明確に実稼働向けに設計されています。

ユーザーにとって最も目に見える変更点の一つは、新しいAgamaインストーラーです。従来の YaST インストーラーに代わる Agama は、ユーザー インターフェイスを内部インストール ロジックから完全に分離し、リモート Web インターフェイス経由でもインストールを調整できるため、自動展開やプロフェッショナル環境に最適です。

デスクトップに関しては、Leap 16はWaylandに完全にコミットしている。インストール時には、主要なデスクトップ環境（GNOME、KDE ​​Plasmaなど）ではWaylandセッションのみが提供され、Xorgは残存機能として扱われます。SysV initスクリプトのサポートも完全に廃止され、systemdが唯一のinitシステムとなります。

もう一つの困難だが一貫した変化は、アーキテクチャの飛躍です。Leap 16.0 は x86_64-v1 マシンでは動作しなくなり、x86_64-v2 との互換性が必須となります。これは実際には比較的新しいプロセッサ（例えば Nehalem 以降の Intel プロセッサ）を意味します。これは、パフォーマンスを最適化し、現在のハードウェア能力をより有効に活用することを目的としています。

Agama: 新しいシステムインストーラー

Agamaは、従来のYaSTインストーラーを引き継ぐものです。そして、これはよりモジュール化され、クラウドフレンドリーな哲学に基づいて実現されています。Rustを含む最新のテクノロジーで記述されており、さまざまな製品やシナリオに合わせてインストールエクスペリエンスを適応させることができるAPIを備えています。

ユーザー エクスペリエンスの点では、Agama は YaST から移行したユーザーを困惑させることはありません。言語選択、パーティション分割、ソフトウェアパターン（デスクトップ、サーバースタックなど）の選択、ユーザー作成など、お馴染みのインストールフローが維持されています。安定性とパフォーマンスに関しては、多くの報告で、このプロセスにおけるYaSTの性能に匹敵するようになったと評価されています。

AgamaはベテランインストーラYaSTに比べてやや劣っている それは、YaST がインストール中に提供した「追加」機能にあります。例えば、Agama ではソフトウェアパターン全体を選択できますが、パッケージごとにフィルタリングしたり、同じ詳細レベルでサービスを有効化または無効化したりすることはできません。これらは高度なオプションであり、現時点では利用できません。

これは、Agama が制限されているという意味ではなく、むしろ本質的な部分に重点を置いているという意味です。必要なコンポーネントを備えた堅牢なシステムをインストールし、残りの作業はCockpitやパッケージマネージャ自体などの後続の管理ツールに委ねます。YaSTの微調整オプションの一部を最終的に継承するかどうかは不明ですが、現時点では目的を十分に果たしています。

自動化された展開環境では、Agama は古いインストーラでは不可能だったシナリオへの扉を開きます。その Web インターフェイスと API は、オーケストレーター、プロビジョニング ツール、およびインストーラーがサーバー画面からではなくリモートで「制御」されるモデルに非常によく適合しているためです。

Myrlyn: YaSTソフトウェアモジュールの後継

Myrlyn 1.0は、openSUSEの新しいグラフィカルパッケージマネージャの最初の安定バージョンです。これは、YaST ソフトウェア モジュールの直接的な代替として考えられていますが、YaST インフラストラクチャ自体への依存は一切ありません。

YaSTの背後にいる大物の一人、Stefan Hundhammerによって開発されたMyrlyn は当初、SUSE Hack Week 中に非常に具体的な目標を掲げて誕生しました。その目標とは、Qt パッケージ セレクターを YaST から分離し、SUSE および openSUSE のパッケージ管理バックエンドである libzypp に基づく独立した Qt アプリケーションにすることです。

機能レベルでは、MyrlynはYaSTのソフトウェアマネージャの進化したクローンです。個別または複数のパッケージのインストール、更新、削除、ソフトウェアパターン（パッケージグループ）の操作、リポジトリの集中管理が可能です。これらすべてを単一のアプリケーションで実行でき、リポジトリとパッケージ用の個別のモジュールは必要ありません。

インターフェイスは Qt6 で構築されており、「昔ながらの」メッセージ マネージャーのクラシック スタイルを維持しています。パッケージリスト、フィルター、詳細パネル、そして適用される変更内容を確認できるエリアを備えています。また、これらのフロントエンドがLinuxエクスペリエンスの中心だった時代を彷彿とさせる、魅力的なウィザードアイコンも搭載されています。

YaST ソフトウェアとの主な違いは、Myrlyn が YaST エコシステム全体に依存しないことです。代わりに、libzypp の軽量フロントエンドとして機能します。実際、通常のユーザーとして読み取り専用モードで動作することも、システムに実際の変更を加える必要がある場合は権限を昇格することもできます。

Myrlynの機能: 単なるパッケージマネージャ以上のもの

最初のベータ版から Myrlyn 1.0 まで、機能のリストは大幅に拡張されました。 それが提供するものは、今日では詳細な制御でソフトウェアを管理することを好む人々にとって非常に本格的かつ実用的な代替手段となっています。

パッケージに関しては、Myrlyn ではすでに YaST Software が提供するほぼすべての機能が許可されています。: 名前、説明、またはその他のフィールドで検索し、詳細情報 (バージョン、ソース、依存関係、技術データ) を表示し、インストール、更新、または削除する内容を選択し、異なるリポジトリに複数のパッケージがある場合は特定のバージョンを選択し、ソフトウェア パターンを操作してグループ全体をインストールまたは削除します。

パッチとアップデートも統合的に管理しますこれにより、保留中のパッチを確認し、リポジトリ、種類、重要度でフィルタリングして、適用するパッチを決定できます。デスクトップシステムだけでなく、より高度な機能を備えながらもグラフィカルインターフェースで管理されているマシンにも便利なツールです。

Myrlyn が古い YaST モジュールと比べて飛躍的に進歩しているのは、リポジトリの操作性です。最初からリポジトリのメタデータを自動的に更新し、実行内容 (ダウンロード、更新など) の視覚的なフィードバックを表示し、各リポジトリの名前、優先度、ステータス (有効かどうか)、自動更新、関連サービス、URL など、非常に明確なビューを提供します。

同じインターフェースから、優先順位を変更したり、リポジトリを有効化または無効化したりすることができます。自動更新のオン/オフを変更したり、名前とURLをリアルタイムで編集したりできます。また、libzypp変数（$releasever、$arch、$basearchなど）の有無にかかわらずURLが表示されるため、パッケージの入手先を正確に把握できます。

もう 1 つの興味深い機能は、よく知られているコミュニティ リポジトリの管理です。Myrlyn では、数回クリックするだけで Packman、NVIDIA ドライバー、OpenH.264、LibDvdCss などの一般的なリポジトリを追加でき、ディストリビューションのバージョン (Leap 15.x、Leap 16.x、Tumbleweed、Slowroll、SLE-15 SPx など) に応じて正しい URL が自動的に選択されます。

最後に、Myrlyn は、ルート権限がない場合に非常に便利な読み取り専用モードを提供します。これにより、何かを壊すリスクなしにリポジトリやパッケージを探索できます。このオプションはYaSTソフトウェアでは利用できなかったため、管理者に変更を依頼する前に、何がインストールされているか、または利用可能なのかを確認したいユーザーにとって非常に便利です。

Myrlynと他のソフトウェア管理ツールの比較

今日のデスクトップでは、多くのユーザーは従来のパッケージ マネージャーをほとんど使用しません。GNOME Software、KDE ​​Discover、そして類似のアプリケーションを利用すれば、ユーザーは人気のプラグインをインストール、アップデート、管理するための十分なリソースを利用できます。さらに、Flatpakのようなユニバーサルフォーマットも大きな注目を集めています。

ただし、Myrlyn や古い YaST ソフトウェアなどのツールは、依然として非常に明確なニッチ市場を持っています。 リポジトリ、バージョン、依存関係をより細かく制御する必要がある場合、または「きれいな」アプリ ストアでは不十分なタスクの場合、Myrlyn は Debian/Ubuntu の世界の Synaptic と同等の役割を果たします。

ミルリンに対する繰り返しの批判は、その許可モデルに関するものである。多くの現在のマネージャーのように、重要な操作を実行する必要がある場合にのみ権限を要求するのではなく、読み取り専用モードとフルモードを区別しています。大きな問題ではありませんが、やや時代遅れの感があります。

視覚的には、YaST ソフトウェアとの違いは一部の人が主張するほど劇的ではありません。どちらもQtを使用しており、読みやすさと外観はアプリケーション自体よりも、ユーザーアカウントまたはルートに設定されたテーマに大きく依存します。多くの人にとって、改善点はインターフェースの抜本的な再設計よりも、アーキテクチャのクリーンアップにあります。

バックエンドに関しては、Myrlyn は単なる zypper の GUI ではないことを覚えておく価値があります。libzypp のインターフェースであり、コマンドライン版の zypper と同等の機能です。これにより、openSUSE ユーザーが zypper で既に慣れ親しんでいる依存関係解決や動作を、一貫した操作性で提供できます。

これらすべてにより、Myrlyn は上級デスクトップ ユーザーや管理者にとって特に魅力的なものとなっています。 YaST フレームワーク全体に依存せずに強力なグラフィカル ツールを必要とし、簡素化された「ソフトウェア ハブ」以上のものを必要とするユーザー。

コックピット: 新しいシステム管理スイート

YaST代替のもう一つの主役はコックピットですは、ビジネスの世界で長年使用されており、多くのサーバー指向のディストリビューションで事実上の標準となっている Web 管理インターフェイスです。

SUSE エコシステムでは、Cockpit が YaST の管理部分によって残された大きなギャップを埋めるために登場します。ユーザー管理、サービス、ストレージ、ネットワーク、アップデート、コンテナなど、ブラウザからアクセスでき、プラグインを通じてモジュール方式でアクセスできます。

Myrlynとは異なり、Cockpitはすべての環境にプリインストールされているわけではない。これは特にデスクトップシステムに当てはまります。多くの機能がグラフィカル環境自体のツール（ユーザー管理、ディスクなど）と重複しているからです。しかし、サーバーやリモート展開においては重要なコンポーネントです。

Cockpit が YaST が実行した機能の 100% をカバーしているわけではないことを強調しておくことが重要です。非常に特殊な設定、モジュール、タスクには直接対応するものが存在せず、場合によってはサードパーティ製ツールやターミナルに委譲されています。現在、クラウドとコンテナに注力しているため、SUSEは過去のYaSTカタログ全体を複製するのではなく、最も有用で標準的な機能に注力することを選択しました。

SUSE戦略におけるコックピットの価値は、統一された最新の管理機能を提供することにあります。これは、YaST の場合のようにすべてを単一のローカル グラフィカル プログラムに結び付けることなく、今日のデータ センター、ハイブリッド展開、エンタープライズ環境で期待されるものにさらに沿ったものです。

SUSE Linux Enterpriseと今後の移行

SUSE Linux Enterprise Server 16はopenSUSE Leap 16の直後に登場しました。しかし、当初はサーバー版のみの提供でした。スタンドアロンのSUSE Linux Enterprise Desktop 16についてはほとんど情報がありません。サーバー上にグラフィカルインターフェースをインストールすることは可能ですが、スタンドアロン製品については依然として不透明です。

ビジネスの世界では、ミルリンの存在はさらに控えめです。現時点では、SUSE Linux Enterprise に完全に統合されていないため、openSUSE は SLE で正式な動きをする前にテストの場として機能していることは明らかです。

一方、SUSE 15では、YaSTが完全に機能し、ライフサイクルは継続されます。そして、現在Leap 16で改良が進められている代替手段の多くは、本番環境のブランチには採用されない可能性が高いでしょう。これは奇妙な共存と言えるでしょう。ベテランのYaSTは、それを置き換えるはずだったソリューションが市場に投入された後も、システムに残ることになるのです。

戦略は明確だ: openSUSEでAgama、Cockpit、Myrlynを安定させるは、Leap を「本格的」でありながらコミュニティ ベースのバリアントとして特に重視し、そのモデルを SUSE Linux Enterprise 16 以降のバージョンに最小限のリスクで導入します。

しかしながら、コミュニティ内の議論はまだ終わっていません。一部のユーザーや管理者は、YaSTからワンクリックであらゆる操作を実行できた時代を懐かしみ、新しいモデルをより断片化したものだと感じています。一方、全く逆の、単一の「コントロールセンター」への依存を減らし、より互換性のある標準ベースのコンポーネントを重視する人もいます。

タンブルウィードとスローロール：YaSTが離れることを拒否する場所

この移行が特に顕著なシナリオがあるとすれば、それはopenSUSE Tumbleweedである。は、近年最も成長したローリングリリースエディションであり、後に Leap および SLE に導入されるテクノロジの先駆けとして機能します。

継続的かつ最先端のアップデートを理念としているにもかかわらず、Tumbleweed は引き続き YaST を使用してインストールおよび管理されています。そして、この状況が短期間で変化するという明確な兆候は見られません。LeapとTumbleweedの中間ブランチであるSlowrollでさえ、YaSTを基本コンポーネントとして維持しています。

コミュニティ内では、この相対的な慣性に関して反対の意見がある。YaST が「故障するまで」使い続けることを好む声がある一方で、技術的に実行可能な代替手段がすでに存在する場合に YaST が障害となるのは間違いだと考える人もいます。

興味深いのは、TumbleweedのリポジトリにMyrlyn 1.0がすでに入っていることだ。、YaST2 (コマンドラインにリンクされたグラフィカル レイヤー) へのいくつかの更新とともに、後者の継続性がかなり長い間保証されていることが明らかになっています。

同時に、「古い」YaST では関連する変更はほとんど行われません。しかし、誰もそれを心配していないようです。インストーラーとしても、管理モジュールのセットとしても引き続き正常に動作しており、それが当てはまる限り、ローリング エディションからそれを削除するために特に急ぐ必要はありません。

実際には、Myrlyn は YaST ソフトウェアをどこで置き換えても対応できるということを意味します。そして実際、彼はすでに Leap 16 でその役割を担っていますが、Tumbleweed と Slowroll での決定的な飛躍には細心の注意を払って臨んでいます。

このシナリオを考えると、openSUSE と SUSE における管理の将来は明らかに Agama、Cockpit、Myrlyn へと向かうことになります。YaST の完全な廃止は、多くの世代が共存する長い段階的なプロセスになりますが、エンド ユーザーへのメッセージは明確です。古い YaST は段階的に廃止されますが、その遺産はより現代的で特殊なツールとして生き続けます。

SUSE エコシステムを初めて知る人にとっては、新しい 3 つが標準のように思えるかもしれません。しかし、YaST の成長を見てきた人なら、その哲学の変化に気付くでしょう。単一の「スイス アーミー ナイフ」ではなく、連携して openSUSE と SUSE の管理を強力かつ柔軟にし、可能な場合は便利にするという、これまでと同じ目標を維持する、より特化したピースが加わったのです。