Wick의 발표에서 Flatpak 프로젝트는 겉보기에는 잘 돌아가는 듯 보이지만 실제로는 활발한 개발이 이뤄지지 않는 상황이라는 점을 강조한 내용 공유, 보안 유지와 간단한 유지보수는 계속되지만 새로운 기능이 거의 추가되지 않는 현상, 많은 기능 제안(Merge Request)이 올라와도 검토하는 이가 없어 답보 상태라는 점은 문제라 생각함, 특히 RHEL 10에서 데스크탑 패키지 제공을 중단하고 Flathub에서 패키지 설치를 권장하면서 Red Hat의 역할이 더욱 중요해졌다고 판단, Red Hat이 Flatpak을 제대로 대체재로 만들고 싶다면 더 많은 자원을 투입해주길 바라는 입장, Flatpak 버전별로 새로운 권한 지원 여부가 달라 backwards compatibility가 필요하다는 Wick의 지적에 공감, 본인이 Flathub에 게임을 배포하면서 오디오와 콘트롤러 권한 문제, --device=input의 미지원 문제, 스피커만 열고 마이크는 차단 같은 세분화된 권한 설정이 불가한 현실을 직접 경험
Red Hat이 처음엔 Firefox와 Thunderbird를 RHEL 10에 Flatpak 전용으로 배포하려다가, 실제로는 GA 출시 후 rpm 패키지도 제공한 사례 언급, Native Messaging 미지원, 중앙 정책 배포 불가, 데스크탑 통합 문제 등 다양한 이유가 복합적으로 작용했음
Flatpak이 처음 시작했을 때 원 개발자를 직접 만나 디자인 철학에 대해 토론했던 경험을 공유, Flatpak은 패키지명에 권한이 묶이고, 인스턴스별 분리가 되지 않는 구조가 문제라 설득하려 했었음, 즉, 동일 Flatpak 앱을 여러 인스턴스로 띄워 각기 다른 권한(예: Documents 하위 특정 디렉토리만 허용)으로 분리 실행이 되지 않음, 이러한 구조는 MS, Apple App Store, macOS도 마찬가지라 세상이 모두 잘못 설계하고 있다고 생각, 예를 들어 LibreOffice 문서에서 RCE(원격 코드 실행)이 일어나더라도 내 다른 문서 접근은 막혀야 하며, 벤더가 보안에 신경쓰지 않아도 Flatpak 샌드박스가 보안을 제공해야 한다고 주장
이런 보안 목적의 복잡성 증가에 비판적 시각, PC는 내 것이기에 인스턴스별 권한, 샌드박스, 파일 공유 제한 등은 불필요하며 '모든 것은 파일'이라는 전통적 개념 유지 원함, 예시로 Thunderbird, Firefox가 /tmp 디렉토리에 접근하지 못해 첨부파일을 저장/다른 앱에서 열기가 극히 불편해지는 샌드박스 환경에 불만, 컴퓨터의 주인이 개발자가 아니라 사용자가 되어야 한다고 주장, 이런 과도한 보안은 생산성 저하로 이어진다고 생각, Useless Machine에 비유
Flatpak 개발진도 이 문제를 이해하고 있었을 가능성을 제기, Flatpak이 기술적으로 완벽한 모델을 택했다면 오히려 앱 개발자, 특히 멀티플랫폼 개발자들에게 너무 큰 진입장벽이 되어 Flatpak 자체가 확산되지 못했을 것이라는 현실론
인스턴스별 권한 모델이 매우 매력적이지만 환경설정(git config, 폰트 폴더 등)에 대해서는 모든 인스턴스가 동일 접근 권한을 갖도록 옵션화하는 하이브리드 방식이 실용적이라고 제안
운영체제 전반을 재설계하여 실행 중인 각 인스턴스에 별도 권한(capabilities) 부여, 디스크 쿼터, 로깅, 프록시, 세밀한 권한 분리 등 다양한 기능을 지원하는 게 바람직하다고 생각, 단순히 Flatpak만의 문제가 아니라고 주장
QubesOS처럼 하이퍼바이저 기반 샌드박싱 등 철저한 분리가 필요한 파워유저, 보안 민감 사용자에겐 인스턴스별 분리가 좋지만, 대부분의 격리작업은 앱 내부에서 이뤄지는 것이 직관적 접근, 웹브라우저 샌드박싱처럼 Flatpak도 nested sandbox 지원이 이상적이지만 현재는 미지원 상태, 코드서명과 샌드박스 연계, UID 네임스페이스 등 꽤 복잡한 문제도 존재함
본인은 Flatpak의 오랜 열성 사용자로서, 혁신적이고 모든 리눅스 배포판에서 최신 앱을 쉽게 쓸 수 있게 해줬지만, 몇 년 간 변화가 없어 점차 관심이 식었다는 경험, 현재는 AUR로 대부분 충족하며 Flatpak 정체 상황이 아쉬움
Flatpak을 사용자로서 쉽다는 점 빼고는 딱히 좋은 경험이 없었음, 테마, 커서, 파일피커, 퍼미션, Drag&Drop 등 여러 통합문제, 기능 사용을 위한 추가 툴 필요, UX가 떨어지는 이상 샌드박싱 등의 보안 혜택은 무의미하다고 생각, 리눅스에서 바이너리 이식성 문제만 없었어도 Flatpak은 필요 없었을 거라는 입장
Fedora+GNOME+Flatpak 조합이 한때 매우 혁신적이라 느꼈지만 최근에는 다시 Arch로 돌아간 경험, Arch 저장소가 훨씬 풍부해졌고 AUR를 거의 쓸 일이 없어짐
여러 패키지를 관리했던 경험자에게 makedeb 사용 경험을 물으며, makedeb는 PKGBUILD 기반이라 이식성이 뛰어나고, 왜 더 많이 안 알려졌는지 의아하다고 언급
Drew DeVault의 ‘배포판이 앱 패키징을 담당해야 한다’는 주장에 100% 동의하진 않으나, 오랜 논의문과 참고 링크 소개, 커뮤니티(배포판)가 사용자를 대표해 패키지를 관리한다는 모델이 올바르다고 보는 시각, Flatpak/Snap/AppImage처럼 배포판 외부에서 패키징하는 모델은 근본적으로 좋지 않다고 주장
이에 반박하며, 앱을 직접 만드는 개발자가 패키지 관리에 가장 적합함, 특히 소스 비공개 소프트웨어의 경우 법적으로 배포 및 패키징 권한이 독점되며, 오픈소스라 해도 핵심팀이 아닌 사람이 패키징에 임의로 개입하는 것은 불필요한 버그, 릴리즈 지연, 새로운 문제를 유발한다고 생각, 빠르고 최신 업데이트, 패키징 변조 없는 순정 소프트웨어 제공을 원함, Flatpak이 너무 많은 역할을 하려는 게 문제라고 보며, 앱스토어 모델 자체에도 회의적, Windows, macOS에서는 앱스토어 없이도 바이너리 배포가 자유롭고, 최소한의 보안은 코드서명 등 OS 레벨에서 제공한다고 주장, 서드파티 패키징 시스템 주도는 불필요
앱 개발자가 직접 배포할 수 있어야 하며, Windows의 간단한 설치 경험을 예로 듦, 유지관리자가 모든 배포판을 지원하는 규모를 갖추기 어렵고 이는 Linux 데스크톱 발전에 걸림돌이라고 봄
여러 배포판에 맞춰 일일이 패키징해야 하는 수고로 인해 오히려 의미가 떨어진다는 지적
세상 소프트웨어를 전부 배포판이 패키징하는 건 비현실적이라는 의견
배포판이 앱 패키징을 잘 못한다는 입장에서, Flatpak 채택이 늘어 기쁨, 개발자가 중간자 없이 자신의 앱을 쉽게 배포할 수 있어야 한다고 생각
Flatpak이 PulseAudio를 계속 이용해 PipeWire 도입에 뒤처지고 있다는 점, PulseAudio는 스피커와 마이크 권한을 통합해 분리 불가, 즉 앱에 소리출력 권한을 주면 자동으로 마이크에도 접근 가능해 보안상 큰 구멍이라는 지적에 공감
윈도우/맥의 디자인 실수나 자유 부족을 조롱하는 리눅스 유저도 자주 보지만, 이런 본질적 디자인 문제 역시 인정해야 한다는 주장, 리눅스 생태계는 책임 소재를 명확히 하지 못한 채 문제를 방치하는 경향이 있다고 생각
VSCode/Codium을 Python 디버깅 목적으로 Flatpak으로 설치했으나, 권한/설정 문제로 디버거 세팅에 오랜 시간이 소요되었고, 결국 Snap 버전으로 설치하니 모든 문제가 해결됨을 경험
Flatpak은 대형 앱(예: Chrome, Chromium) 등 데스크탑 애플리케이션에 적합하지만, 시스템 도구에는 부적합하다고 생각
Emacs Flatpak 버전은 비효율과 좌절만 안겨줬다는 경험
immutable distro에 Flatpak 기반으로 전환하여 사용할 때 잘 맞을 땐 좋은데, 예상외로 많은 부분이 동작하지 않아 기대에 못 미침, 예를 들어 Godot용 외부 툴 실행, 여러 퍼미션 트윅, Flatpak끼리의 상호 연동문제(예: Firefox와 KeepassDX), Godot와 Krita Flatpak의 크래시, 비 Flatpak AppImage/.rpm 등 이질적 환경 등 다양한 불편을 경험, Flatpak의 더욱 많은 혁신을 바란다고 언급
Flatpak으로는 Tailscale처럼 가상 네트워크 인터페이스를 생성하는 앱 패키징이 불가능한 구조, macOS는 API를 통해 네트워크 권한을 세분화해 Tailscale도 Mac App Store에서 샌드박스 앱 형태로 배포 가능함
해당 API 덕분에 Tailscale의 macOS용 샌드박스 앱 배포 가능, 반면 Silverblue, Bluefin 등 Flatpak에 의존하는 "atomic" Linux 배포판에선 이런 종류의 소프트웨어 사용이 힘든 현상
OBS Studio처럼 Flatpak은 데스크탑 대형 앱에 유의미, 시스템 서비스처럼 동작하는 Tailscale은 Flatpak보다 배포판 기본 패키지가 적합하다고 생각, Arch Linux에선 공식 패키지로 존재
Flatpak에서 flatpak-spawn, polkit-exec 등 우회로 가능하나, 이 경우 샌드박스 보호를 거의 포기하게 됨
Linux 최상단에 세밀한 퍼미션 시스템과 패키징까지 한 번에 해결하려는 시도가 지나치게 복잡, Flatpak의 정체나 개발자 소진현상도 이 때문일 수 있다고 의심, 현대 Linux에 근본적인 권한 체계가 없으니 완벽한 퍼미션 설정보다 우선 당면 과제는 소프트웨어 배포, 패키징, 업데이트 체계라는 현실 인식
Tailscale 같은 것은 sysext(시스템 익스텐션)으로 가야 하고 Flatpak은 적합하지 않다는 의견
플랫팍 배포 제안 관련, Java 기반 KmCaster 앱을 개발하며 Flatpak 포팅 요구를 받았지만 두 번의 설치 방법, 다운로드 통계 관리, 서드파티 저장소 신뢰, 신규 패키지 매니저 증가, 저장소 중복 등 추가 부담만 체감, 실질적으로 장점 없음
그럼에도 Flatpak의 긍정적 측면으로 immutable distro에서의 사용 편의, Java 버전 관리 필요성 해소, Flathub 검색 노출, 자동 업데이트 등은 장점이라 언급
오픈소스 유지보수자나 개발자는 아니지만, 수많은 Linux 배포판이 모두 같은 패키지 관리 문제를 안고 있는데 힘을 합쳐 Flatpak의 보완 및 보편화에 집중하지 못한다는 것이 이해가 안간다고 생각
각 배포판마다 배포(Distribution)의 방식 자체가 다르기 때문에 하나로 통일되기 어렵고, 다양한 선택권이 오픈소스 생태계의 장점이라고 생각, 개인적으로는 전통적인 시스템 패키지 매니저가 더 마음에 듦
이런 논리라면 GNOME만 존재해야 하는 셈이고 커뮤니티의 다양성, 의사결정 다양성이 중요하다는 입장
Flatpak이 내게 전혀 쓸모가 없음, 본인이 사용하지 않는 소프트웨어에 기여를 강요받고 싶지 않음
Hacker News 의견