YaST に依存しない理由
YaST が非 SUSE ディストリビューションに対して行うことは何もありません。あちこちに小さなツールがありますが、包括的なツールはありません。それは祝福と呪いです。 YaST に依存するようになった人々は、内部で実際にどのように機能するかを見逃しています。
別の松葉杖を探すのではなく、物事がどのように機能するかを実際に「学ぶ」ことに時間をかけます。意地悪を言っているのではありません。私は日常の仕事で YaST を使用していて、YaST が提供する機能に感謝していますが、これは松葉杖です。
代替
<強い>1. Yast4Debian本当にやる気があるなら、保留中のように見えるこのプロジェクトに出くわしましたが、他のディストリビューション用に YaST のようなものを開発することを本当に探しているなら、手に入れるのに適したコード ベースになるかもしれません。
- YaST4Debian
また、YaST for SuSE 13.1 の次期バージョンは Ruby 実装に移植されたようですので、この努力のおかげで移植が容易になるかもしれません.
- 近日公開:Ruby の YaST を使用した openSUSE 13.1
- openSUSE:YaST から Ruby への移植
抜粋
<ブロック引用>なぜYaSTをRubyに移植したいと思ったのですか?
YaST は YCP で開発されました。YCP は、カスタマイズされたシンプルで柔軟性のない言語です。長い間、多くの YaST 開発者は、それによって速度が低下していると感じていました。 OOP や例外処理などの多くの有用な概念をサポートしていませんでした。それに記述されたコードはテストが難しく、厄介な機能がいくつかありました (「堅牢」になる傾向があり、これは実際にはエラーを隠すことを意味します)。しかし、元の YCP 開発者は他のプロジェクトに移り、介入して言語を改善しようとする人はいませんでした。
この状況から抜け出す唯一の方法は、実装を他の広く使用されている言語に変更することであることは明らかでした (ほとんどの人は、C++ や Java などと比較して優れた柔軟性と短いコードを提供する Ruby や Python などのスクリプト言語について考えていました)。 .このような変更は、独自のカスタム言語を維持する必要がないことを意味します。また、多くのサードパーティ ライブラリを使用できるようになり、部外者がプロジェクトに貢献しやすくなります。 YaST があるからといって、まったく新しい言語を学ぶ必要はありません。
YaST のような大きなコードベースの実装言語を変更するのは大変な作業です。そのため、何年もの間、開発者がほとんどそれについてしか話さなかったのも不思議ではありません。チームの外部の誰か (デビッド) が、話すだけでは不十分であり、私たちはそれを行うべきだと判断する必要がありました :-)
結果はどうでしたか?
良い :-) 合計で 96 の YaST モジュールを翻訳しましたが、現在、YaST で使用されている YCP コードはありませんが、ドキュメント内の例のようないくつかの不明瞭な場所 (現在のベスト プラクティスを反映するために手動で書き直す必要があります) を除きます。 YCP は、一部のデータ ファイルや YaST コンポーネント間の通信のシリアル化形式としても使用されていますが、これは開発には影響しません。おそらく、これも時間の経過とともに取り除かれます。
- openSUSE wiki の YaST ポータル
- 開発者情報はこちら
Oracle には、RHEL + Unbreakable Linux で使用するための YaST の修正バージョンのように見えるこのホストされたプロジェクトがあります。その後、CentOS や Fedora にも使用できると思います。
- プロジェクト:Yast
状況はよくわかりませんが、一見の価値があるかもしれません。オリジナルの YaST コードベースで開発されている可能性がありますが、最初に Ruby の実装を確認することをお勧めします。
YaST for CentOS や Debian に匹敵するものはありません。最も近いアプリケーションは次のとおりです:
-
YUMEX :YUM の gui
-
ウェブミン
Webmin は非常に強力で、YaST でできることの多くを行う必要があります (v ホスト、ファイアウォール、ネットワーク マウント)。
Webmin に匹敵する他のオプションがいくつかあります。