これによるとグリーンネット記事kdbusはD-Busを置き換える必要があります。どのようにしてこれを確認できますか？
どちらも異なるAPIを持っていると思うので、これが簡単な作業になるのではないかと思います。私が理解したように、プログラムをD-Busの使用からkdbusに変換するには、いくつかのリワーク/アップデートが必要ですか？したがって、目標がLWNの記事で説明されているようにD-Busを交換することであれば、更新作業につながると仮定します。そうですか？
それともしばらくの間、両方のシステムが同時に動作しますか？
ベストアンサー1
この記事について私の考えを教えてください。
kdbusはD-Busを置き換える必要があります。どのようにしてこれを確認できますか？
これは明らかな意図でしたが、WRTはこれを「確認」しました。 「はい、これがGNU / Linuxの未来に対する私たちのタイムラインです」と言える中央機関はありません。カーネルを超えた異質で分散した分野です。
もちろん、核心的には、脱中央化分野の多くの意思決定者がコラボレーションに興味を持っているかもしれません。いいようですね。
簡単なことでしょう。
同時に使用できないという表示はありません。これまで最も健全な移行形態。したがって、「シンプルさ」は状況によって異なります。
両方に異なるAPIがあると想像してください。
最初に接続されたGreg KHの発表は、ユーザー空間互換性レイヤーに言及しています。これは遷移に関しても非常に正常です。一部のディストリビューションは両方を提供し、他のディストリビューションは互換性レイヤーに直接移動します。
時々、以前のバージョンとの互換性を犠牲にして前進することをお勧めします。 Perl 5対Perl 4またはPython 3対2を考えてみましょう。メジャーバージョン内では、次のメジャーバージョンの作業中に、以前のバージョンとの互換性を優先することで改善が行われます（新しいマイナーバージョン5.8、5.9、5.10など）。バージョン対応タスク（互換性はありませんが、現在のバージョンの経験に基づいてはるかに改善されている可能性があります）が進行中である可能性があります。
バージョンのあるディストリビューションは、現在のバージョンが維持され更新されている間に新しいバージョンでタスクが実行されるという点で似ています。これにより、kdbusなどの基本的な変更をはるかに簡単にマージできます。何が起こるのか見守るべきだと思います。