Linux 데스크톱에서 D-Bus 문제
Source: Hacker News
D‑Bus란 무엇인가?
모두가 D‑Bus에 대해 들어봤지만, 실제로 무엇인지 아시나요?
D‑Bus의 아이디어는 간단합니다: 애플리케이션, 서비스 및 기타 것들이 메서드나 속성을 버스라는 한 곳에 노출하도록 하여 다른 앱이 이를 찾아 사용할 수 있게 하는 것입니다.
예를 들어, 날씨 모니터링 서비스가 버스에 날씨 API를 노출할 수 있습니다. 그러면 어떤 애플리케이션이든 그 서비스를 발견하고 사용할 수 있게 되며, 각 앱이 별도로 날씨 제공자와 통신 로직을 구현할 필요가 없습니다.
무엇이 잘못됐는가?
D‑Bus는 관대하고, 조직되지 않으며, 관용적인 버스입니다. 이러한 특성은 근본적인 개념적 문제를 야기합니다:
- 버스에 있는 객체는 원하는 것을 자유롭게 등록할 수 있습니다.
- 객체는 원하는 방식으로, 원하는 시점에, 원하는 것을 호출할 수 있습니다.
- 프로토콜은 벤더‑특정 검증되지 않은 쓰레기를 허용하고 심지어 장려합니다.
실제로 이는 **“쓰레기 입력, 쓰레기 출력.”**이라는 결과를 낳습니다.
D‑Bus 표준
Part 1
앱은 서로 통신해야 하지만, 문서는 흩어져 있거나 미완성, 혹은 읽기 어려운 경우가 많으며, 많은 클라이언트가 이를 무시합니다.
기존(종종 혼란스러운) 문서의 몇 가지 예시:
표준은 엉망이며, 구현자는 자주 이를 따르지 않습니다.
Part 2
명세가 존재하더라도 강제력이 거의 없습니다. 임의의 데이터를 가진 익명 호출이 흔합니다.
스토리: xdg‑desktop‑portal‑hyprland를 작성하면서 포털 문서를 따라 필요한 D‑Bus 프로토콜을 구현했습니다. 구현은 정상적으로 동작했지만, “복원 토큰”(spec‑compliant 메커니즘)을 추가했을 때 이를 사용하는 애플리케이션이 없었습니다. 모두가 자체 문서가 없는 변형을 만들어 사용했으며, 저는 결국 KDE 구현을 그대로 복사해야 했습니다.
명세는 SelectSources와 Start에 restore_token 속성을 광고하지만, 실제로는 어떤 앱도 이를 사용하지 않고 대신 restore_data 필드를 사용합니다.
Part 3
많은 프로토콜이 variant(a{sv} – 문자열‑variant 쌍의 배열) 에 의존합니다. 이렇게 느슨하게 타입이 지정된 데이터를 허용하면 앱이 무작위 정보를 보내고 상대편이 해석하기를 기대하게 되며, 이는 X atom과 유사한 반복적인 실패를 초래합니다.
Part 4
권한 관리가 사실상 없습니다. 모든 사용자가 모든 것을 볼 수 있고 어떤 메서드든 호출할 수 있습니다. “거부”라는 보편적인 개념이 없으며, 각 프로토콜이 자체 오류 처리를 정의해야 합니다. 이러한 보안 부재가 Flatpak 앱이 세션 버스를 볼 수 없는 주요 이유입니다.
Part 5
kwallet이나 gnome‑keyring 같은 비밀 저장소는 비밀번호로 잠금을 해제하고 디스크에 데이터를 암호화합니다. 하지만 잠금이 해제되면 버스에 있는 모든 애플리케이션이 사용자 인식 없이 저장된 모든 비밀을 읽을 수 있습니다.
이제는 충분합니다
저는 D‑Bus에 지쳤습니다. 세션(그리고 이후 시스템) 버스가 제 생태계에 유용할 수는 있지만, 현재 D‑Bus의 상태는 견딜 수 없습니다.
따라서 저는 D‑Bus의 여러 문제적 설계 선택을 피하면서, 처음부터 새로운 버스를 만들고 있습니다.
XKCD 927
새 시스템을 구현할 때 이 XKCD 만화를 인용하는 사람이 많지만, 상황은 다릅니다. Wayland에서는 X11을 떠나면 X11 세션을 Wayland 세션과 동시에 실행할 수 없습니다. 그러나 D‑Bus와 유사한 세션 버스를 여러 개(두 개, 세 개, 그 이상) 동시에 실행할 수 있습니다. 프록시 클라이언트가 이들 사이를 번역하면 점진적인 마이그레이션이 가능해집니다.
Wire
제가 먼저 집중한 구성 요소는 **hyprwire*이며, 이는 hyprlauncher, hyprpaper 등 Hypr 도구들을 위한 와이어 프로토콜입니다.
와이어 프로토콜의 주요 강점:
- 일관성: 타입과 메시지 인수가 강제됩니다;
a{sv}나 “뭐든 보내라” 같은 것이 없습니다. - 단순성: 빠르고 직관적이며 복잡한 구조체 타입이 없습니다.
- 속도: 빠른 핸드쉐이크와 프로토콜 교환; 연결이 신속하게 설정됩니다.
Hyprwire는 이미 hyprpaper, hyprlauncher, 그리고 hyprctl의 일부에서 IPC 용도로 사용되고 있습니다.
Bus
버스 자체는 **hyprtavern**라고 합니다. 이는 D‑Bus를 직접 대체하는 것은 아니지만 비슷한 목적을 수행합니다.
- 애플리케이션은 버스에 객체를 등록하고, 해당 객체가 정의한 프로토콜과 핵심 속성을 노출합니다.
- 다른 애플리케이션은 버스에 연결해 이러한 객체들을 발견할 수 있습니다.
이 모델에서 hyprtavern은 선술집과 같습니다: 각 앱은 다른 앱이 등록한 객체와 상호작용할 수 있는 클라이언트가 됩니다.