1P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • Xfce 팀이 Wayland 기반의 새로운 컴포지터 ‘xfwl4’ 개발 계획을 공개, 커뮤니티 기부금을 활용해 핵심 개발자 Brian Tarricone이 주도
  • 기존 xfwm4와 동일한 기능과 사용자 경험을 목표로 하며, 설정 대화상자와 xfconf 구성을 재사용해 전환의 연속성 확보
  • Rust와 smithay 프레임워크를 기반으로 완전한 신규 코드로 작성, 메모리 안정성과 맞춤형 그래픽·입력 파이프라인 제공
  • 프로젝트 범위에는 세션 관리 구조 변경, XWayland 및 xdg-session-management 지원, CI 빌드 시스템 개선이 포함
  • Xfce의 Wayland 전환을 위한 핵심 투자로, 첫 개발 릴리스는 연중 공개 예정

Xfce의 새로운 Wayland 컴포지터 계획

  • Xfce 팀은 커뮤니티 기부금을 활용해 새로운 Wayland 컴포지터 ‘xfwl4’ 개발을 시작
    • 개발은 오랜 핵심 기여자인 Brian Tarricone이 담당
    • 프로젝트 기금의 상당 부분이 이 개발에 사용될 예정
  • 목표는 xfwm4와 동일한 기능과 동작을 Wayland 환경에서 구현하는 것
    • 기존 xfwm4 설정 대화상자와 xfconf 설정을 그대로 활용해 사용자 경험의 일관성 유지
  • xfwl4는 기존 xfwm4 코드에 기반하지 않고, Rust로 완전히 새로 작성
    • smithay 라이브러리를 기반으로 구축

기존 코드 재활용 대신 재작성 결정 이유

  • 초기에는 xfwm4 코드 수정으로 X11과 Wayland를 병행 지원하려 했으나, 여러 이유로 부적합하다고 판단
    • xfwm4의 구조가 X11 종속적이어서 일반화된 인터페이스 구현이 어려움
    • 리팩터링 시 X11 버그 발생 위험이 높음
    • Wayland에서 지원되지 않는 X11 개념이 존재해 코드 유지가 복잡
    • 기존 코드 사용 시 C 언어와 wlroots에 의존해야 함
  • 별도 코드베이스로 개발하면 xfwm4 안정성 유지와 Wayland 실험적 개발 병행이 가능

smithay 선택 이유

  • Brian Tarricone은 wlroots와 smithay를 비교 평가 후 smithay를 선택
    • smithay는 공식 Wayland 프로토콜 확장 대부분wlroots·KDE 프로토콜을 지원
    • 고수준 추상화가 없어 그래픽·입력 파이프라인의 세밀한 제어 가능
    • 문서화가 우수하며, Rust 사용으로 메모리 관련 버그와 크래시 위험 감소
    • 개발자가 Rust 선호
    • wlroots는 C로 작성되어 Rust 바인딩 작성이 어려움

프로젝트 범위 및 기술 과제

  • xfwm4 기능 동등성 확보 외에도 다음 과제 포함
    • Wayland 환경에서는 컴포지터가 세션 루트가 되어야 하므로 세션 시작 구조 변경 필요
    • xdg-session-management 프로토콜 지원 추가
    • XWayland 지원 포함
    • CI 컨테이너 빌드 시스템을 Rust 코드 빌드가 가능한 meson 기반으로 업그레이드
  • Brian Tarricone은 이미 개발을 시작했으며, 연중 첫 개발 릴리스 공개 예정

커뮤니티와 후원

  • 프로젝트는 Open Collective US 및 EU 후원자들의 기부로 가능해짐
  • 개발 진행 상황과 기술 세부 사항은 GitLab의 xfwl4 이슈 및 소스 코드 저장소에서 확인 가능
  • 관련 문의는 Matrix 채널 #xfce-dev를 통해 가능
Hacker News 의견들
  • xfwl4가 xfwm4와 동일한 기능과 동작을 목표로 한다고 들었음
    하지만 X11과 Wayland의 구조적 차이를 고려하면, ‘동작’의 해석이 얼마나 엄격할지 궁금함
    예를 들어 포커스 훔치기 방지는 X11에서는 복잡한 휴리스틱과 타임스탬프 검사를 필요로 하지만, Wayland에서는 컴포지터가 포커스를 완전히 통제함
    결국 예전의 휴리스틱 느낌을 유지하면서도 Wayland의 권한 모델에 맞는 새로운 정책을 설계해야 하는 과제가 있음
    또 하나의 관심사는 컴포지팅 강제화로 인한 지연임. 저사양 하드웨어에서 X11의 비컴포지팅 모드만큼 반응성을 낼 수 있을지 궁금함

    • xfwl4 개발자임. “가능한 한 비슷하게”라는 문구 그대로임. 완전히 같을 수는 없지만 최대한 가깝게 만들 예정임
      포커스 훔치기 방지는 오히려 Wayland 쪽이 더 일관된 동작을 보일 수 있음. Xfwm4는 휴리스틱 기반이라 가끔 오작동했지만, Wayland의 xdg-activation 모델은 훨씬 명확함
      성능 면에서는, 최신 하드웨어에서는 큰 차이가 없을 것으로 보지만, 아주 오래된 기기에서는 부담이 될 수도 있음. 실제로는 테스트를 더 해봐야 알 것 같음
    • 예전에 400MHz 펜티엄 II + GeForce 2에서 xfwm의 컴포지터를 돌렸는데 문제없었음
      컴포지팅의 부담은 사실상 vsync 대기 시간뿐임. 펜티엄 클래식급이 아니라면 괜찮음
    • 솔직하게 이유를 밝히는 점이 좋음. 언어 섬처럼 Rust 도입이 빌드 툴링이나 생태계 통합에 마찰을 일으킬 수는 있겠지만, 그래도 GNOME보다 XFCE가 훨씬 만족스러웠음
    • 컴포지팅이 꼭 vsync와 함께 해야 하는 건 아님. 클라이언트가 새 콘텐츠를 보낼 때 바로 화면을 갱신할 수도 있음
    • 요즘은 저가형 Intel GPU에서도 컴포지터 오버헤드는 거의 문제되지 않음. 20년 된 노트북을 쓰는 사람만 예외일 뿐임
  • XFCE가 여전히 가벼운 데스크탑으로 남기를 바람
    KDE를 좋아하지만, 가볍다고 하긴 어려움
    Wayland와 Rust 모두 긍정적으로 보며, Wayland는 미래 방향이고 Rust는 크래시 방지에 도움이 된다고 생각함
    다만 XFCE의 전통적 사용자층은 보수적이라 새 기술에 회의적일 수 있음

    • 2007년부터 XFCE를 써온 입장에서, 사용자들은 언어나 기술보다 “그냥 잘 작동하는 것” 을 원함
      Wayland 전환은 불가피하고, 약간의 불평은 있겠지만 큰 문제 없이 진행될 것임
      X11 고집파는 결국 소수로 남을 것임. XFCE 팀을 신뢰함
    • Wayland가 왜 “미래처럼 느껴지는지” 모르겠음. 오히려 기능 회귀처럼 느껴짐
      이미 잘 작동하는 GUI가 있는데, Wayland는 불필요한 복잡성과 호환성 문제를 만들고 있음
      단순한 프로토콜이 오래 살아남는 법인데, Wayland는 그 반대임
    • “고치지 않아도 되는 걸 고치지 말자”는 입장임
      XFCE는 이미 빠르고 안정적임. Wayland로 전환해 느려진다면 가장 큰 장점을 잃는 셈임
    • XFCE의 Wayland 전환은 시간이 걸릴 것으로 봄
      안정성을 중시하는 커뮤니티라 X11을 기본으로 유지하다가, 완전한 기능 동등성이 확보되면 Wayland로 넘어갈 것임
    • 오래된 XFCE 사용자로서, X11을 서둘러 폐기하지 않는 한 이번 변화는 긍정적으로 봄
      언젠가 Wayland로 옮겨야 할 때 XFCE를 계속 쓸 수 있길 바람
  • 이 프로젝트 자체가 Wayland가 옳은 방향임을 보여준다고 생각함
    Xorg는 단일 구현이었지만, Wayland는 다양한 라이브러리 생태계(wlroots, Smithay 등)가 생겨남
    덕분에 1인 프로젝트도 몇 달 만에 개발자 프리뷰를 낼 수 있음
    이런 경쟁이 오픈소스 생태계를 발전시킬 것임

    • Wayland가 저수준 기능만 제공하다 보니, 공통 데스크탑 인터페이스를 급히 만들어야 했음
      하지만 이 과정이 너무 서둘러 진행돼 통합성이 부족함. 완전한 Linux 데스크탑 API가 자리잡으려면 10년은 더 걸릴 것이라 봄
    • 여러 구현이 생기면 경쟁이 생기지만, 유지보수 인력 부족으로 기능 누락과 번아웃이 생길 수 있음
      libcompositor 부재가 Wayland의 가장 큰 실수라고 생각함
    • 코드 중복은 늘겠지만, 그만큼 각 팀이 자신들의 철학에 맞는 구현을 할 수 있음
      XFCE 팀이 어떤 결과물을 낼지 기대됨
    • 이런 논리로 Rails가 남용되던 시절을 떠올림
      스택이 편리하긴 하지만, 결국 깊은 수정이 어려운 구조가 될 수 있음
    • Wayland의 핵심은 커널이 많은 일을 대신 해준다는 점임
      X는 사실상 두 번째 커널처럼 동작했지만, Wayland는 커널의 GEM, DMA-BUF, KMS 등 현대적 추상화를 활용함
      덕분에 훨씬 깔끔하고 효율적인 구조로 발전할 수 있음
  • 10년 넘게 XFCE를 메인으로 써왔음
    Wayland 지원 소식이 반가움
    Rust로 작성되면 기여자 유입에도 도움이 될 것 같음
    후원을 원한다면 Open Collectivexfce-eu에 기부하길 권함

    • 5년째 XFCE를 쓰고 있는데, 최근 매달 후원 시작했음. 좋은 소식이라 기쁨
  • X11에서 Wayland로의 전환이 리눅스 역사상 가장 고통스러운 변화라고 생각함

    • 커널 2.4에서 2.6으로 넘어갈 때도 꽤 힘들었음. 개발 모델이 완전히 바뀌었고, pre-git 시절은 혼란스러웠음
      KDE4 시절도 암흑기였음
    • 개인적으로는 GNOME 2 → GNOME 3 전환이 가장 괴로웠음. 결국 다른 WM으로 옮겼음
    • 나에겐 X11에서 Wayland로의 전환은 매우 매끄러웠음. 결국 필요에 따라 다름
    • 8년 후엔 Wayland도 X11만큼 오래돼서 Wayland 2가 나올지도 모름
    • systemd 전환도 만만치 않았음
  • Smithay의 Rust 클라이언트 툴킷을 써봤는데, 스레드 안전성이 완전하지 않음
    Arc<>로 감싸져 있어도 멀티스레드 호출 시 이상한 크래시가 남
    Wayland API를 직접 파고들어 안전하게 쓰는 법을 배우고 싶음

  • 현재도 대부분의 wlroots 기반 컴포지터에서 XFCE를 사용할 수 있음
    나는 Gentoo에서 Hyprland + XFCE 조합으로 사용 중임
    설정은 이 저장소에 있음

    • 레트로 테마가 마음에 듦
      Hyprland와 XFCE4 조합을 “저주받은 조합”이라 표현한 이유가 궁금함. 아마 XFCE가 자체 컴포지터를 만들기로 한 이유와 관련 있을 듯함
  • 한때 Wayland를 거부했지만, 구형 하드웨어에서의 성능을 보고 생각이 바뀜
    오래된 Thinkpad에서 Firefox가 X11보다 훨씬 부드럽게 스크롤됨
    터치패드 제스처도 추가돼 만족스러움. 설정은 조금 번거롭지만 가치 있는 트레이드오프

  • Wayland가 비리눅스 시스템에서도 동작하는지 궁금함. 예를 들어 BSD나 macOS에서 XQuartz처럼 원격 창을 띄울 수 있을까?

    • FreeBSD에서는 꽤 잘 동작함. OpenBSD에서도 wlroots 기반 컴포지터가 일부 작동함
      Mac용 Wayland 컴포지터도 존재하며, Brodie Robertson이 관련 영상을 올림
    • Microsoft의 WSL2 GUI 통합도 Wayland와 XWayland 기반임
      WSLg 프로젝트를 보면, Weston을 RDP로 렌더링해 플랫폼 간 윈도우 표시가 가능함
      GPU 가속도 유지돼 X11 포워딩보다 낫다고 생각함
    • Wayland는 네트워크 투명성이 없어서 원격 전송은 복잡함. Mac에서의 상태는 불확실함
    • FreeBSD 공식 핸드북에도 Wayland 설정법이 있음
      FreeBSD Handbook Wayland
    • OpenBSD에서도 Wayland_on_OpenBSD 문서로 실험 중임
  • 요즘 “Rust로 리라이트”라는 말은 유지보수 인력이 없다는 뜻으로 들림
    xfwm4를 패치할 사람이 없어서 새로 쓰는 것 같음
    이는 세대 교체의 신호일 수도 있음 — 새 개발자들이 단순하고 안전한 구조로 다시 짜려는 것임
    Wayland는 X11보다 단순하고, Rust는 실수를 줄여주니 자연스러운 흐름임
    하지만 그 대가로 네트워크 투명성, 성능, 안정성이 희생될 수도 있음. 시대의 흐름이라 받아들임