D-Bus는 Linux 데스크톱에 대한 치욕이다

Source: Hacker News

D-Bus가 무엇인가?

Everyone has heard about D-Bus, but what is it, actually?

D-Bus’ idea is pretty simple: let applications, services and other things expose methods or properties in a way that other apps can find them in one place, on the bus.

Imagine a service that monitors the weather. Instead of each app knowing how to talk to each weather service—or worse, implementing one itself—it can connect to the bus, discover any service exposing a weather API, and use it.

Great, right? And yeah, the idea is wonderful.

무엇이 잘못되었나요?

D-Bus는 관대한, 조직되지 않은 그리고 관용적인 버스입니다. 이 세 가지 특성은 모든 프로토콜, 언어 또는 시스템에서 가장 크고 근본적이며 개념적인 실수 중 하나를 초래합니다.

가장 중요한 실수는 다음과 같습니다:

• 버스에 있는 객체는 원하는 것을 자유롭게 등록할 수 있습니다.
• 버스에 있는 객체는 원하는 것을, 원하는 방식으로, 원하는 시점에 호출할 수 있습니다.
• 프로토콜은 공급업체‑특정 검증되지 않은 쓰레기를 허용하고—심지어 장려하기까지 합니다.

실제로 이는 **“쓰레기를 넣으면, 쓰레기가 나온다.”**는 결과를 낳습니다.

D-Bus 표준, 파트 1

앱은 서로 소통해야 하죠? 그 방법은 어디서 찾을 수 있을까요?

음… 아마도 온라인 어딘가에 있을 겁니다. 실제로는 문서가 흩어져 있거나, 미완성이고, 읽기 어렵거나, 복잡하게 얽혀 있기 때문에 아무도 정확히 알지 못합니다. 클라이언트가 이를 일관되게 따르는 경우는 거의 없습니다.

몇 가지 “보석”(실제 문서)을 살펴봅시다:

정말 안전합니다.

서비스 구현자는 텔레파시를 배워야 할 것 같습니다.

이게 초안인가요, 아니면 널리 사용되는 건가요?

D-Bus 표준은 엉망입니다—양쪽 구현자가 실제로 이를 따른다고 가정한다면(실제로는 거의 따르지 않음, 곧 확인해 보겠습니다).

D-Bus 표준, 파트 2

좋아, 우리가 표준을 가지고 그것을 이해하고 있다고 가정해 보자. 멋지다! 이제…

아무도 신경 쓰지 않는다, 문자 그대로. 설명을 읽어도, 그것을 따르도록 안내하거나 강제하는 것이 전혀 없다. 원하는 대로 익명 호출을 보낼 수 있다.

개인적인 이야기

xdg-desktop-portal-hyprland를 작성하고 있을 때, 몇 가지 D‑Bus 프로토콜을 사용해야 했다 (xdg 포털은 D‑Bus 위에서 동작한다). 포털 문서에 프로토콜이 나열돼 있었으니, 나는 그것들을 구현했다. 대충 동작했다.

그 다음 나는 restore tokens을 추가했는데, 이는 앱이 이전에 저장한 공유 구성을 복원할 수 있게 해준다. 이때 D‑Bus가 무너진다.

어떤 앱도—제길, 전혀—스펙을 따르지 않았다. 나는 스펙에 맞는 메커니즘을 작성했지만 아무것도 사용하지 않았다. 왜일까? 그들은 모두 어디서 나온 건지 모를 다른 스펙을 사용했기 때문이다; 나는 그에 대한 문서를 하나도 찾을 수 없었다. 결국 KDE의 구현을 살펴보고 그것을 모방하게 되었다.

재미있는 사실: 아직도 이런 상황이다! 스펙은 SelectSources와 Start에 restore_token 문자열 속성을 명시하고 있지만, 이를 사용하는 앱은 없으며 대신 options 안에 restore_data를 사용한다.

D-Bus 표준, 파트 3

한 마디: variants. D‑Bus 프로토콜의 절반은 이 BS 또는 a{sv}(array of string + variant)를 어딘가에 전달하는 방식을 사용합니다.

핵심 사양에서 이렇게 느슨하게 타입이 지정된 데이터를 허용하는 것은 금지되어야 합니다. 이는 앱이 무작위 데이터를 전송하고 상대편이 이해하기를 기대하게 합니다.

이 패턴은 여러 차례 시도되었으며(예: X atoms) 반복적으로 재앙을 초래했습니다.

D-Bus 표준, 파트 4

권한에 대해 들어본 적 있나요? D‑Bus 개발자들은 그렇지 않습니다. D‑Bus는 가능한 한 불안정합니다: 모든 사람이 모든 것을 보고 무엇이든 호출할 수 있습니다. 앱에 특정 보안 메커니즘이 없으면 혼란이 발생합니다. 게다가 “거부”에 대한 보편적인 개념이 없습니다; 프로토콜은 자체적으로 만들거나 조용히 실패합니다.

이것이 Flatpak 앱이 세션 버스를 볼 수 없는 주요 이유입니다.

D-Bus 표준, 파트 5

KWallet이나 GNOME Keyring은 어떨까요? 서명 키, 비밀번호 등과 같은 “비밀 저장소”이며 비밀번호로 보호된다고 합니다.

실제로는 저장소가 잠금 해제되면 버스에 있는 any 앱이 all 비밀을 읽을 수 있습니다. 농담이 아니라—비밀번호를 입력하면 어떤 앱이든 조용히 모든 것을 읽을 수 있습니다.

충분히 충분합니다

내 앱에서 D‑Bus가 이제는 지긋지긋합니다. 내 생태계에 세션(그리고 나중에 시스템) 버스가 있으면 도움이 되겠지만, D‑Bus가 만든 절대적인 혼란은 용납할 수 없습니다.

그래서 나는 D‑Bus와 전혀 복사, 상호 운용, 혹은 다른 인식을 하지 않는 새로운 버스를 처음부터 직접 작성하고 있습니다. D‑Bus에는 너무나도 많은 어리석은 아이디어들이 얽혀 있어, 나는 그것들이 내 시스템을 오염시키는 것을 절대 허용하지 않을 것입니다.

XKCD 927

많은 사람들이 새로운 구현마다 이 XKCD 만화를 인용하지만 상황은 동일하지 않습니다.

예를 들어 Wayland의 경우 전환하면 X를 포기하게 됩니다; Wayland 세션과 X11 세션을 동시에 실행할 수 없습니다. 그러나 두 개, 세 개, 심지어 17개의 세션 버스를 실행할 수 있습니다. 이를 막는 것은 없습니다. 그래서 점진적인 마이그레이션이 가능한 것입니다. 버스들은 서로 직접 통신할 수 없지만, D‑Bus API를 새로운 API로 변환하는 프록시 클라이언트를 만들 수 있습니다.

Source: …

와이어

제가 가장 먼저 집중한 것은 hyprwire였습니다. hyprlauncher, hyprpaper 등 Hypr* 도구들을 위한 와이어 프로토콜이 필요했습니다.

Hyprwire는 Wayland의 접근 방식에서 영감을 받았습니다. 가장 중요한 장점은 다음과 같습니다:

• 일관성 – 와이어는 타입과 메시지 인자를 강제합니다. a{sv}도 없고, “뭐든지 보내라” 같은 상황도 없습니다.
• 단순성 – 프로토콜이 빠르고 간단합니다. 번거로움을 더하는 복잡한 구조체 타입이 없습니다.
• 속도 – 빠른 핸드셰이크와 프로토콜 교환; 연결이 신속하게 설정됩니다.

Hyprwire는 이미 hyprpaper, hyprlauncher, 그리고 hyprctl의 일부에서 IPC 용도로 사용되고 있으며, 우리에게 훌륭히 작동하고 있습니다.

버스

버스는 hyprtavern이라고 불립니다. D‑Bus와 정확히 같은 것은 아니지만, 더 가까이 말하자면 선술집과 같습니다.

앱은 버스에 객체를 등록하며, 이 객체들은 해당 프로토콜이 정의한 프로토콜 및 주요 속성을 노출합니다. 다른 앱은 버스에 연결함으로써 이러한 객체들을 발견할 수 있습니다.

어느 정도 hyprtavern은 선술집처럼 동작합니다: 각 앱은 자신이 구사할 수 있는 언어를 광고할 수 있는 클라이언트이며, 서로 같은 언어를 공유한다면 다른 앱과 대화를 시작할 수 있습니다.

D‑Bus 대비 전반적인 개선점 (특정 순서 없이)

• 권한 처리 (불완전한 목록)
  (간략히 생략된 추가 세부 사항.)