이에 따르면그린넷 기사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와 같은 근본적인 변경 사항을 훨씬 쉽게 병합할 수 있습니다. 무슨 일이 일어나는지 지켜봐야 할 것 같아요.