▲

Flatpak은 systemd에 의존하게 될 예정

 (osnews.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Flatpak은 “모든 배포판용 앱 빌드”를 장점으로 내세워 왔지만, 다음 주요 버전에서 systemd 의존성이 생길 가능성이 커짐
  • Flatpak Next 또는 Flatpak 2.0은 기존 1.x의 수십 년 된 설계 한계를 넘기 위한 재작성에 가까우며, 아직 계획 단계에 있음
  • 새 서비스 systemd-appd는 앱 식별자와 권한을 저장하고 다른 구성요소가 조회하게 하며, 하위 샌드박싱을 가능하게 하는 핵심 역할을 맡음
  • 비 systemd 배포판을 위해 elogind 같은 독립 데몬 구현 여지가 있었지만, 논쟁이 커진 뒤 개발자들의 배려 의지가 약해진 것으로 보임
  • systemd 의존성이 엄격해지면 Void, Guix, Alpine 같은 배포판에서 Flatpak 사용이 어려워지고 배포판 중립성도 약해질 수 있음

Flatpak의 배포판 중립성 변화 가능성

  • Flatpak 웹사이트는 첫 장점으로 _“Build for every distro: create one app and distribute it to the entire Linux desktop market.”_를 내세우며, 지원 배포판 목록에는 Void Linux, Guix, Alpine처럼 systemd가 아닌 init 시스템을 쓰는 배포판도 포함됨
  • 현재 Flatpak은 사용자가 어떤 init 시스템을 쓰는지 신경 쓰지 않지만, 다음 주요 버전에서는 systemd 의존성이 생길 가능성이 커짐
  • 이 변화가 실제로 도입되면 systemd를 쓰지 않는 배포판에서 Flatpak을 계속 제공할 수 있는지가 핵심 쟁점이 됨

Flatpak Next와 재설계 방향

  • Arian Vovk와 Sebastian Wick은 Linux App Summit에서 Flatpak의 미래를 다룬 발표를 진행함
  • 현재 Flatpak 버전도 계속 개선될 예정이지만, 수십 년 된 설계의 한계를 우회하기가 점점 어려워지고 있음
  • Flatpak Next 또는 Flatpak 2.0으로 불리는 작업은 Flatpak 1.x 이후 쌓인 경험을 반영한 사실상의 재작성에 가까움
  • 새 설계는 Flatpak 초기 설계 이후 자리 잡은 현대적 기술과 아이디어를 활용하는 방향으로 계획됨
  • 발표 내용은 아직 계획 단계이며, 코드가 한 줄도 작성되지 않았기 때문에 향후 몇 년간 작업이 진행되면서 결과가 크게 달라질 수 있음

systemd-appd와 권한 관리 이동

  • Flatpak 개발 방향의 핵심 변화는 권한 관리를 Flatpak 내부가 아니라 서비스 계층으로 옮기는 것임
  • 새 서비스인 systemd-appd는 애플리케이션에 식별자를 부여하고 권한을 저장하며, 시스템의 다른 구성요소가 이 데이터를 조회할 수 있게 함
  • 이 구조는 여러 기능을 가능하게 하며, 특히 하위 샌드박싱(subsandboxing) 이 중요한 기능으로 꼽힘
  • 현재 계획은 이 기능을 현재 Flatpak 버전에 도입하는 것이며, 그 결과 Flatpak에 systemd 의존성이 생기게 됨

비 systemd 배포판을 위한 여지

  • Vovk의 설명에 따르면, systemd를 쓰지 않는 배포판과 사용자를 “매우 배려”하려는 의도가 있었음
  • 예상 가능한 모델은 systemd-logind가 별도 데몬인 elogind로 분리되어, 다른 init 시스템을 쓰는 배포판도 systemd-logind에 의존하는 데스크톱 환경을 사용할 수 있게 된 방식과 유사함
  • Flatpak 개발자들도 systemd-appd에 대해 비슷한 독립 데몬 구현이 가능하도록 현실적인 여지를 최대한 남기려 했던 것으로 보임
  • 이런 접근이 유지됐다면 Flatpak은 systemd를 쓰지 않는 배포판에서도 계속 제공될 가능성이 있었음

논쟁 확산과 개발자 대응 변화

  • Void나 Alpine 같은 배포판 사용자는 Flatpak이 systemd에 강하게 의존할 경우 자신의 시스템에서 더 이상 동작하지 않을 수 있다는 우려를 제기함
  • Flatpak 개발에 기술적으로 관여하지 않은 사람에게 질문이 몰렸고, 그의 답변이 도움이 되지 않거나 모욕적이고 선동적인 경우가 있었음
  • 그가 Flatpak 개발에 관여한다고 오해한 사람이 많아지면서, 진지하고 우호적인 질문과 반 systemd 성향의 격한 반응이 뒤섞여 상황이 악화됨
  • 그 결과 Flatpak 개발자들은 systemd를 쓰지 않는 배포판과 사용자를 배려하는 데 시간을 쓰고 싶지 않다는 반응을 보이게 됨
  • 이 흐름이 이어지면 systemd 의존성은 더 엄격해지고, systemd-appd 기능을 복제하는 독립 데몬 구현도 원래 예상보다 훨씬 어려워질 수 있음

예상되는 결과와 의미

  • 현재 상황에서는 향후 몇 년 안에 Flatpak이 systemd 의존성을 갖게 될 가능성이 높음
  • systemd를 쓰지 않는 배포판에서 systemd-appd 기능을 대체할 독립 데몬을 만들 수 있도록 하는 배려가 빠질 가능성도 있음
  • 그렇게 되면 Flatpak은 더 이상 모든 배포판을 대상으로 하나의 앱을 배포할 수 있다는 배포판 중립성을 내세우기 어려워짐
  • Flatpak은 사용자가 어떤 init 시스템을 쓰든 실제 수요가 있는 도구이기 때문에, 이 변화는 Linux 데스크톱 애플리케이션 배포 범위에 직접적인 영향을 줌

함께 보면 좋은 글 β

▲
GN⁺   [-]
Lobste.rs 의견들
  • systemd를 왜 그렇게 싫어하는지 이해가 안 감. 개인적으로는 다루기 쉬운 API와 합리적인 의존성·충돌 관리를 통해 유용한 기능을 제공한다고 봄
    systemd를 싫어하는 쪽은 “유닉스답지 않다”, “중앙집중적이다”, “systemd-journald 파일 형식이 일반 텍스트가 아니다” 같은 모호한 이유만 대는 경우가 많음
    반대한다면 구체적인 이유와 해결책, 그리고 왜 다른 init 시스템이 더 나은지 말해줬으면 함. 그러면 rc 스크립트가 왜 끔찍하게 지저분한 해킹인지 설명할 수 있음
    • 링크된 Mastodon 논쟁의 상당수는 본질적으로 systemd 반대라기보다 중앙집중화 반대에 가까움. Flatpak이 systemd에 의존하게 되면 다른 init 시스템을 쓰는 Linux 계열은 flatpak 접근성을 잃게 됨
      Linux 철학은 적어도 나에게는 근본적으로 선택에 관한 것이었고, Flatpak이 특정 init 시스템을 요구하면 원하는 결과를 얻기 위해 사용자가 시스템을 구성할 때 선택지가 줄어듦
    • systemd를 잘 쓰고 있지만, Flatpak 같은 경우에는 반발이 이해됨. Flatpak은 본질적으로 “어떤 Linux 배포판에서도 동작하게 해주는 것”에 가까운데, systemd 의존은 그 유용성을 어느 정도 줄임
    • systemd에 대한 손대지 않은 불만은 이 정도임: journald 구현은 별로지만 아이디어 자체는 괜찮고, systemd가 유닛을 관리하는 실제 추상화인 작업 대기열에는 문서화되지 않았거나 찾기 어려운 이상한 경계 사례가 있음
      컨테이너 이미지에 넣기 더 쉬워야 하고, 사용자 systemd가 시스템 인스턴스에 읽기 API 접근을 가져서 최소한 After, Requires 같은 것으로 유닛을 예약할 수 있어야 함
      그래도 HAL 제거 이후 Linux에 일어난 최고의 일이라고 생각하며, Lennart에게 프로젝트에 감사하다고 악수한 적도 있음
    • 실제로 신뢰할 만한 대체 스택을 구현하는 Chimera 같은 쪽은 FUD를 퍼뜨리지 않고 친절하고 겸손함. 반면 온라인 분노 집단은 명시적으로 해결책을 갖고 있지 않고 앞으로도 없을 것임
      이 “반대자들”이 실질적으로 주장하는 것은 해결책 자체가 존재하지 말아야 한다는 쪽에 가까움. Linux의 HOA처럼 굴며, 실제로 탄탄하고 사용 가능하고 경쟁력 있는 시스템이 독점 운영체제를 밀어낼 수 있는 진전을 방해하는 반동 정치에 가깝다고 봄
    • 웹페이지를 제공하거나 GUI 브라우저로 웹페이지를 보여주는 용도의 시스템에서만 쓰인다면 systemd를 싫어하지 않음. VPS에 배포하는 것에 systemd 유닛을 직접 쓰는 것도 괜찮고, SysV init이나 upstart였어도 별 불만 없었을 것임
      하지만 노트북에서는 원하는 것이 다름. 개인 환경을 어떻게 동작시킬지에 대한 생각이 있고, 일반 Linux 사용자가 원하지 않는 편의 기능도 원하며, 명시적으로 요청하지 않은 일은 일어나지 않길 바람. “되게 만드는 수고”보다 “안 되게 만드는 수고”를 훨씬 더 싫어함
      NixOS를 systemd 때문에 떠나게 된 핵심은 계속 커지는 범위와 의견이 강한 기본값이었음. 전원 관리와 로그인 처리가 통합되면서 덮개를 닫으면 무조건 절전되는 식의 동작을 매번 다시 고쳐야 했고, linger 허용 범위 변경은 POSIX가 요구하는 nohup과 screen을 깨뜨렸으며, 더 엄격한 VT 관리는 “한 번 로그인해서 여러 Xorg 인스턴스 실행”이나 “VT 잡기”를 systemd 방식으로 다시 설계하게 만들었음
      결국 최소 init인 sinit과 서비스 감시 없음이 더 낫다고 판단했고, 셸 부트 스크립트를 직접 작성해 일부 시스템 기능은 셸, 일부는 Common Lisp로 구현함. 노트북에서 PostgreSQL 같은 것은 한 번 뜨면 계속 돌고, 멈추면 알아차릴 수 있으며, 재시작으로 충분하면 간단하고, 충분하지 않다면 서비스 감시기도 도와줄 수 없음
      신뢰가 깨진 사례로는 HDD에서 journald가 차가운 캐시 상태에서 로그를 보여주는 데 몇 분을 기다려도 출력이 안 나왔던 일, https://github.com/systemd/systemd/issues/2913 을 직접 겪은 일, nohup을 깨뜨리는 데 거리낌이 없었던 점이 있음
      개발 과정에서도 https://github.com/systemd/systemd/issues/437 에서 “좋은 기본값을 제공하지만, 기본값이 나빠도 배포판이 고치면 된다”처럼 느껴지는 태도와, 안정 API 약속을 꺼리는 http://lists.freedesktop.org/archives/systemd-devel/… 같은 태도가 신뢰를 떨어뜨렸음
      다만 이런 불만은 오래된 것들임. systemd가 어떤 문제를 해결하면서 다른 문제를 만들고, 둘 다 내가 원래 가진 문제가 아니라는 걸 본 뒤 노트북에서는 부트용 셸 스크립트로 옮겼고, 지금은 제자리 유지 비용이 너무 낮아 다시 systemd를 시도할 이유가 없음. VPS에서는 Debian의 익숙한 범위 안에서 systemd를 씀
  • 이 일이 Flatpak 개발자가 아닌 사람이 잘못된 정보로 시작했고, 감정적 반응을 불러일으킨 뒤 원래 스레드가 진행되는 동안 더 강한 표현들이 더해지며 Flatpak 프로젝트와 개발자 평판에 사람들이 몰려든 점이 답답함
    그 결과 실제 Flatpak 개발자들이 감정적으로 영향을 받아 분노한 집단과 거리를 두고 싶어 하게 된 것도 놀랍지 않음
    모두 진정하고 이 일을 더 키우지 않았으면 함. 의심이나 우려가 있다면 실제 유지보수자와 이야기하고, 중간 지점을 찾고 싶다는 지지를 보여주고, 이것이 전체 커뮤니티를 대표하지 않는 특정 개인들의 고립된 사건임을 보여줘야 함
    systemd에 의존한다는 생각도 확정된 것이 아니라 아이디어였던 것처럼, 유지보수자들이 더 다양한 프로젝트 지원을 재고할 가능성도 아직 닫히지 않았다고 봄
  • systemd에서 돌지 않는 시스템도 계속 지원할 수 있을 만큼 사람들이 잘 지냈으면 좋겠음. Flatpak과 다른 컨테이너 방식은 대상 플랫폼에 쉽게 빌드되지 않는 패키지를 사용자가 실행하는 데 도움이 되며, 특정 소프트웨어가 필요할 때 그런 시스템 위에서 Flatpak을 돌릴 수 있으면 좋음
    컨테이너도 비슷한 역할을 하지만, 충분히 특이한 설정에서 x11docker 같은 것을 제대로 동작시키는 건 짜증날 만큼 까다로움
    • 10년 넘게 Void를 만족스럽게 쓰고 있음. init 시스템이나 systemd 통합을 마지막으로 걱정한 게 언제인지 기억도 안 남. Void에 들인 모든 작업에 감사함
    • 노트북에서 Void를 쓰는데, 작업하기 효율적이고 문서도 꽤 잘 되어 있음. 개발자들이 해온 모든 작업에 감사하며, Flatpak의 변화가 너무 큰 부담이 되지 않길 바람
  • “이게 현대 Linux고, systemd만 있다.”
    Linux 커뮤니티는 공동체라기보다 WeWork에 가깝다는 걸 선명하게 떠올리게 함. 주변의 모두가 Red Hat의 존재에 의존하는 월급을 받는 와중에, 누군가는 GNU readline을 공짜로 해킹하고 있는 구조임
    • 글이 이런 부분에서 틀렸다고 보기는 어려움: “광적인 anti-systemd Red Hat 음모론자들(그리고 더 나쁜 부류)을 끌어들인다”는 대목 말임
  • 이 단계에서 단정적으로 “의존하게 될 것”이라고 말하기에는 너무 이르고 추측성이 강해 보임
  • 제목이 글 본문보다 훨씬 단정적인 점이 흥미로움. 많은 댓글이 분명히 제목에만 반응하고 있고, 다행히 전부는 아니지만 이런 현상은 인터넷에서 새롭지 않음
    요즘 lobste.rs에서도 사람들이 제목이나 긴 댓글 속 한 문장에만 반응하는 일을 자주 봐서 걱정됨. 대개 자신이 처음 떠올린, 종종 공격적인 해석 외의 가능성을 거의 허용하지 않음
    글을 읽어보면 Flatpak 2.0 담론에서도 비슷한 일이 있었던 듯함. 다른 init 시스템을 위한 여지를 넣으려 했던 것 같은데, 그 주변 담론이 빠르게 적대적으로 변하면서 사실상 포기한 것으로 보임
  • 대체 init 시스템을 쓰는 입장에서는 정말 답답함. 노트북 하나를 Alpine Linux로 돌리고 있고, glibc에서만 동작하는 소프트웨어를 실행하려고 Flatpak을 써왔음. 이 변화는 그 환경에서 떠나게 만들 것임
    systemd를 싫어하지는 않음. Gentoo 시스템은 모두 systemd 기반임. 다만 systemd가 자유·오픈소스 소프트웨어를 GNU/Linux에 점점 더 의존하게 만드는 방식은 마음에 들지 않음
  • 이건 분명히 좋은 일임
    systemd는 안정적이고 잘 정의된 API를 가진 데몬들로 구성되어 있으니, Flatpak이 의존하게 될 systemd의 어느 부분이든 누군가 노력을 들이면 처음부터 깔끔하게 재구현할 수 있다고 봄
    가능한 최선의 결과임. 파편화는 줄어들고, 특이한 요구사항을 가진 사람들에게는 재구현의 안정적인 목표물이 생김
    • 처음에는 풍자인 줄 알고 읽기 시작했는데 아니었음
      systemd API는 흔히 man 페이지에 모호하게 정의되어 있고, systemd 쪽에서 다른 구현을 기대하지 않기 때문에 양방향으로 안정적이거나 버전 관리되는 것도 아님
      notify 소켓 API의 경우에는 오히려 반대 방향으로만 안정적임. vsock 지원 추가는 libsystemd에 의존하지 않고 구현한 데몬들을 사실상 깨뜨렸음. 이 파손이 잘 알려지지 않은 이유는 vsock이 주로 가상화 경계를 넘는 systemd 간 통신용이었기 때문임. 정상적으로 설계했다면 그 경계에서만 쓰는 확장으로 만들었을 것임
      “데몬들”이라고 하지만 사실상 logind와 systemd가 대부분이고, 이 둘이 전체 API 표면을 노출하기 때문에 조합 가능성은 제한적임. DBus 인터페이스 몇 개, 이제는 varlink, 그리고 단일 라이브러리를 통해 그렇게 함
      systemd를 대체하려면 통째로 대체하면서 내부 모델을 systemd식 API로 노출하도록 어렵게 맞추거나, 먼저 systemd의 API 설계 선택을 풀어내고 플러그 가능한 백엔드를 제공하는 중간 계층을 만들어야 함
      이 문제를 몇 년째 다루고 있음. systemd의 많은 설계 원칙은 타당하다고 보지만, 현재 설계는 대부분의 사람에게 필요 없는 복잡성을 앞쪽에 몰아넣고 있음. 더 모듈화되고 교체 가능한 설계는 가능하며, 분리 가능한 단순 인터페이스 설계도 비교적 쉽게 떠올리거나 기존 것을 재사용할 수 있음
      하지만 systemd API에 의존하기로 선택한 소프트웨어가 문제임. 다른 것과 동작시키려면 libsystemd 전체에 묶인 기능 지원을 분리하는 패치를 upstream에 넣거나, 새 개별 API 지원을 추가해야 하는데 전자는 성공한 적이 없고 후자는 출시 전·소수 API의 유지보수 부담 때문에 받아들여지기 어려움
      아니면 소프트웨어가 쓰는 API만 구현할 수도 있음. 예를 들어 대부분의 API를 구현하지 않는 login1 DBus 서비스를 쓰는 방식임. 하지만 그러면 API의 다른 부분을 대체하려는 다른 구현과 충돌하고, 원래 깨끗한 API, logind/systemd DBus API, varlink용 API까지 세 변형을 구현해야 함
      장기적으로는 전체 systemd나 logind API를 구현하고 뒤에서는 분리된 API로 연결하는 라우터가 해법일 수 있음. 다만 현재 설계에 극심한 중복과 systemd 특화성이 박혀 있어서 제대로 만들기 매우 복잡함
      의도였는지는 모르겠지만, systemd 개발자들의 말을 보면 최소한 의도적으로 신경 쓰지 않은 문제였음. 복잡한 중간 계층을 만들거나 systemd를 다시 쓰지 않고 systemd 대체품을 만드는 건 매우 어렵고, 애플리케이션이 고립된 조각으로 제공 가능한 API 일부에만 의존하더라도 systemd의 한 부분만 깔끔히 대체하기는 사실상 어렵다
    • systemd의 일부를 처음부터 깔끔하게 재구현할 수 있다는 게 지금 실제로도 맞나? 글에서는 elogind를 예로 들고 있음
  • Red Hat이 Linux 생태계에 너무 많은 통제력을 갖는 방식이 마음에 들지 않음
    • 나도 그렇지만, 요즘 Red Hat이 systemd에 얼마나 통제력을 갖고 있는지는 잘 모르겠음
    • 참 양면적임. 통제를 중앙화하는 건 나쁘지만, 사람들에게 돈을 주고 자유·오픈소스 소프트웨어를 만들게 하는 건 좋음. 그리고 그들이 얻는 통제력의 상당 부분은 바로 사람들에게 돈을 주고 자유·오픈소스 소프트웨어를 만들게 하기 때문에 생김
      그래도 Red Hat이 자유 소프트웨어를 받아들인 점은 그 영향력에 대한 우려를 어느 정도 완화해줌. 수년간 인수한 기술들을 보면, 기존에 upstream이 없던 것들에 대해서도 스스로 자유·오픈소스 upstream을 만든 경우가 있음. Dogtag PKI와 389 Directory Server가 특히 떠오름
      전반적으로는 생태계에 대체로 나쁘지 않았고, 해친 것보다 발전시킨 경우가 더 많았다고 봄
  • 이 논쟁에 직접 걸린 건 없지만, Linux 시스템에서 계속 늘어나는 불필요한 복잡성과 추상화에 대한 불안감을 줄여주는 내용은 여기 없음
    Linux가 빠르게 운영체제의 Java가 되어가고 있음. 정말 슬픈 일임
답변달기