これによればLWN記事kdbus は D-Bus に代わるものとされています。これは何らかの方法で確認できますか?
結局のところ、両方とも異なる API を持っていると思うので、これは簡単な作業になるのだろうかと思います。私の理解では、プログラムを D-Bus から kdbus に移行するには、何らかの作業/更新をやり直す必要があるのでしょうか。したがって、LWN の記事で述べられているように、D-Bus を置き換えることが目標であれば、何らかの更新作業が必要になると思います。
それとも、両方のシステムが並行して動作する時期が来るのでしょうか?
答え1
この記事についての私の意見を述べます。
kdbus は D-Bus に代わるものとされています。これは何らかの方法で確認できますか?
それは明らかに意図されていることです。しかし、それを「確認する」という点では、「はい、これが GNU/Linux の将来のタイムラインです」と言える中央機関は存在しません。カーネルを超えると、それは異種混合で分散化された領域です。
もちろん、それがカーネルであることを考えると、その分散化された領域の多くの意思決定者が協力することに興味を持つでしょう。それは良いことのように思えます。
簡単な仕事になるだろう
両方を同時に使用できないという兆候は見当たりません。はるかに最も健全な移行形式です。したがって、「簡単」かどうかは状況によって異なります...
両方に異なる API があると想像してみてください。
冒頭でリンクされている Greg KH の発表では、ユーザーランドの互換性レイヤーについて言及されていますが、これも移行に関して非常に理にかなっています。最初は、一部のディストリビューションでは両方を利用できるようにし、他のディストリビューションでは直接互換性レイヤーに移行するなどです。
時には、下位互換性を犠牲にして前進することが良いこともあります。Perl 5 と Perl 4、または Python 3 と 2 を比較してみましょう。メジャー バージョン内では、下位互換性を優先して改良 (新しいマイナー バージョン 5.8、5.9、5.10 などで示される) が行われ、その間に次のメジャー バージョン (互換性はありませんが、現在のバージョンの経験に基づいて大幅に改善されていると思われます) の作業が進行している可能性があります。
バージョンを持つディストリビューションは、現在のバージョンが保守され、更新されている間に、新しいバージョンの作業も進行しているという点で似ています。これにより、kdbus のような基本的な変更の組み込みが容易になります。どうなるか見てみましょう。