현재 위치

홈 ›› Forums ›› 이슈 ›› 토론, 토의

오픈소스 큰행님들의 snap, flatpak

cogniti3의 이미지
글쓴이: cogniti3 / 작성시간: 토, 2020/05/23 - 2:18오후

(대형 프로젝트, 자본가에게나 해당되는 얘기입니다. 소형프로젝트/개인한테 해당 안 되는 얘기입니다. 열폭할 필요 없습니다. 명예훼손 및 잘못된 내용에 대해 알려주시면 수정하겠습니다. 사용자 편의성 증대라는 공익 관점에서 글을 작성했습니다.)

XIM 이라는 잃어버린 기술(lost technology)이 있습니다. 상업용 유닉스 벤더들이 만들어서 그런지 오픈소스 행님들은 레거시에 오래되고 낡았다는 핑계로 새로 만듭니다. 그 당시(90년대 말, 2000년대 초)는 wayland 가 등장하지 않았던 때고 거의 모든 GUI 어플들이 X 위에서 돌아가던 때입니다.(X 없이 작동하던 svga 어플도 있었습니다.)
XIM 에는 알림 상태(예, 한영 전환) 정보, 조합 문자를 그리기 위한 영역, 클라이언트가 그리느냐, 서버측이 그리느냐 등 여러 스펙들이 있습니다. 트리거 키(단축키) 스펙도 있습니다. 또한 확장할 수 있는 스펙도 있습니다.
XIM 은 현대 시대에 효용성이 떨어지는 건 사실이나 오파츠급 스펙입니다. 스펙을 함 보십쇼.
https://www.x.org/releases/X11R7.6/doc/libX11/specs/XIM/xim.html
XIM 스펙들을 X 기반이 아닌, 통신 기반이 아닌, 투명하게 C API 기반으로 재설계했으면 좋았을텐데 하는 아쉬움이 남습니다.
그 후 입력 API 는 GTK IM, QT IM, 여러 Wayland IM들 등으로 파편화되었습니다.

배포판 파편화의 문제도 심각하여 응용 어플을, 각 배포판에 맞게 라이브러리 버전에 맞게, 패키지 형태(deb, rpm)로 배포하는게 일반적인데,
그런 문제를 해결하고자 snap, flatpak 이 나온거 같은데, snap, flatpak 으로 패키지된 어플은 입력에 문제가 있습니다. GTK 를 예를 들겠습니다. GTK 는 툴킷 라이브러리입니다. GTK 를 사용하여 어플을 만들었다면 GTK 에서 제공하는 GTK IM API 통하여 입력을 할 수 있습니다. GTK IM API 가 입력기에 구현되어 입력기와 연동이 되기 때문에, GTK IM API 를 응용 어플 개발자가 직접 다룰 필요도 없습니다.
GTK 어플을 실행하면 GTK_IM_MODULE 환경 변수를 읽습니다. GTK_IM_MODULE=nimf 라고 되어 있으면
/usr/lib/gtk-3.0/3.0.0/immodules/im-nimf-gtk3.so 라는 파일을 로딩합니다.
GTK 어플에서 입력을 하면 gtk_im_context_filter_keypress(입력값) 함수가 실행되고 im-nimf-gtk3.so 에 gtk_im_context_filter_keypress() 함수가 구현이 되어 있어서, nimf 와 연동이 되는 것입니다.
다른 입력기들도 마찬가지입니다.
그래서 snap, flatpak 패키지로 GTK 어플을 배포한다고 할 때, im-nimf-gtk3.so 입력 모듈을 포함시켜서 배포를 해야 nimf 로 입력할 수 있습니다. 다른 입력기들도, Qt도 마찬가지입니다. 그래서 ibus, fcitx, nimf, uim, hime,.. 등의 입력 모듈을 포함해서 배포해야 입력이 되는거죠. 이 얼마나 뻘짓입니까. 이는 텔레그램도 마찬가지입니다.
아니면 호스트 시스템의 GTK_IM_MODULE 환경 변수를 읽고 호스트 시스템에 있는 .so 를 로딩시킬 수 있도록 해야겠죠. 아마 버전 문제 때문에 곤란할 것 같은데, 이런 방법이 snap, flatpak 에 있는지는 모르겠습니다.
이 문제를 snap, flatpak 의 문제로 보기도 그렇고, 궁극적으로는 통합 입력 API 가 없기 때문에 이러한 문제가 계속 재발하는 것입니다.

그리고 사실 snap, flatpak 이런 게 불필요합니다. 그냥 기존대로 rpm, deb, pacman 패키지로 만들어서 배포하면 되거든요. 라이브러리 버전 때문에 여기선 되고 저기선 안 되고... 그런 문제는 라이브러리 ABI 로 해결하거나 그래도 해결이 어려우면 그냥 정적 링킹해서 배포하면 해결이 됩니다.

안 그래도 패키지 파편화 문제 때문에 불편한데, 패키지 포맷으로 rpm, deb, pacman 에 snap, flatpak 이 더해져도 역설적으로 패키지가 더욱 파편화되었습니다.

대안은 있는가? 당연히 있죠.

GTK 어플에 입력하기 위해서는, XIM 을 통한 방법(GTK 는 XIM 을 지원합니다)과 GTK IM API 를 통한 방법이 있습니다. 그러나 Wayland 가 사용되는 시점에서 XIM 을 계속 쓰자고 주장할 수는 없습니다.
GTK 어플이 GTK IM API 로 입력하는 방법을 보면,
환경변수 GTK_IM_MODULE=nimf 요개 있어야되고,
/usr/lib/gtk-3.0/3.0.0/immodules/im-nimf-gtk3.so 요개 있어야 되죠.
바로 이게 힌트입니다.
그러면,

GTK_IM_MODULE 환경 변수는 GTK 용이니,

COMMON_IM_MODULE=nimf

이렇게 해서 GTK, Qt, snap, flatpak, Wayland 등이 COMMON_IM_MODULE 변수를 읽어서,
변수값에 따라 아래의 입력 모듈을 로딩하는 방법을 생각해볼 수 있습니다.

(가칭)
/usr/lib/common-im/im-nimf.so
/usr/lib/common-im/im-ibus.so
/usr/lib/common-im/im-uim.so
/usr/lib/common-im/im-fcitx.so

GTK_IM_MODULE, QT_IM_MODULE 이런 식으로 GTK, Qt 에 국한시키지 말고,
COMMON_IM_MODULE 라는 방식으로 통합하여
여러 어플용으로 가칭 Common Input Method API 를 만들어서 이를 BSD 계열로 보급하고,
입력 모듈을 여러 어플들이 공통적으로 사용할 수 있게끔 하면 되겠죠. 참 쉽죠~ 잉?

snap, flatpak 얘들도 더 이상 뻘짓 그만하고, 정적 링킹하면 자기네들 효용성이 없다는 것부터 사람들에게 알려줄 필요가 있습니다. 애초 정적 링킹이라는 방법이 존재하는데 왜 이런 뻘짓을 하는지 도무지 이해가 안 되는 사람입니다.

정공법이 더 쉽습니다. 정공법으로 해결합시다.

(대형 프로젝트, 자본가에게나 해당되는 얘기입니다. 소형프로젝트/개인한테 해당 안 되는 얘기입니다. 열폭할 필요 없습니다. 명예훼손 및 잘못된 내용에 대해 알려주시면 수정하겠습니다. 사용자 편의성 증대라는 공익 관점에서 글을 작성했습니다.)

Forums: 
토론, 토의
cogniti3의 이미지

글쓴이: cogniti3 / 작성시간: 토, 2020/05/23 - 11:34오후

snap, flatpak 이 개뻘짓인 이유는, 4kdownloader 를 보면 알 수 있는데,
4kdownloader 의 경우 리눅스용 배포는 이렇게 두 종류로 하고 있습니다.

1. .tar.bz2 의 일반적인 압축 방법을 사용한 배포
2. .deb 파일로 배포

debian/control 에는 libc, libc++ 에만 의존적입니다. 아주 최소한으로만 의존하는거죠.
스태틱 링킹을 하지 않고, Qt 라이브러리 .so 를 같이 배포하고 있습니다.
4kvideodownloader.sh 로 LD_LIBRARY_PATH 를 지정해서 실행시키고 있습니다.
일반적이고 전통적인 방법입니다.

여러 리눅스 배포판에서 의존성 문제 생기지 않게 돌리고자 하는 목표는 tar.bz2 (tar.gz 등의 일반적인 압축 방식) 으로도 매우 쉽게 달성할 수 있는 목표인데... 일반적이고 전통적인 방법을 놔두고,
오픈소스 큰행님들은 snap, flatpak 이라는 더 불편하고 시간을 더 빼앗아가는 방법을 내놓았습니다. 그리고 진짜 단점은, snap, flatpak 으로 패키지하면 성능이 감소되고 기능이 축소되기도 하는데, 이거는 진짜 개뻘짓입니다. 기술 역행입니다.
이렇게 사용자, 개발자들이 골탕을 먹습니다.
이게 왜 나왔겠어요? 오픈소스 큰행님들께서 시장 판도를 새로 짜기 위해서라고 저는 그렇게 생각합니다.
오픈소스 큰행님(빅 브라더)들은 더 이상 혹세무민해서는 안 되겠습니다.
PS. 아래 사이트는 flatpak 의 보안 문제를 지적한 글입니다. 아주 속 시원하게 까주네요 ㅋㅋ
샌드박스는 진짜 구라입니다. 그점은 snap 도 마찬가지입니다.
Flatpak - a security nightmare, The sandbox is a lie, You are NOT getting security updates
https://flatkill.org/

Yi Soo An@Google의 이미지

글쓴이: Yi Soo An@Google / 작성시간: 일, 2020/05/24 - 12:34오후

"그리고 진짜 단점은, snap, flatpak 으로 패키지하면 성능이 감소되고 기능이 축소되기도 하는데" 구체적으로 어떻게 성능이 감소되는지 궁금하네요. (입력기말고 일반적인 관점에서 궁금합니다)

---- 업데이트 ----
오해의 소지가 있어 질문을 구체적으로 적습니다.

"그리고 진짜 단점은, snap, flatpak 으로 패키지하면 성능이 감소되고 기능이 축소되기도 하는데" 구체적으로 "flatpak" 실행시 성능이 어떻게 감소되는지 궁금하네요. (입력기말고 일반적인 관점에서 궁금합니다)

---------------
Happy Hacking!

Anti-Lock의 이미지

글쓴이: Anti-Lock / 작성시간: 일, 2020/05/24 - 12:57오후

샌드박싱 때문에 io라든가 특정api접근등이 제한 될수도 있겠죠. 달리이야기하면 '더 빨라지거나 더 풍부한 기능이 추가되는 가능성보다 그 반대가 되는 가능성이 더 높다' 라고 이해가 됩니다.
(일반론적인 이야기 입니다.snap,flatpak 패키지의 기술적인 내용에 대한 분석은 아닙니다.)

Yi Soo An@Google의 이미지

글쓴이: Yi Soo An@Google / 작성시간: 일, 2020/05/24 - 1:15오후

오해의 소지가 있어 질문을 업데이트했습니다.

snap은 제가 안 써봐서 모르겠고 이런 isolation 툴의 목적이 프로세스가 접근할 수 있는 자원에 대한 제한이라고 할 수 있어서 특정 api를 제한하는 부분에 있어서는 이해가 되고요.
가장 궁금한게 flatpak은 backend를 bubblewrap이라는 sandbox 툴을 이용하는데 이게 VM 같은 가상머신이 아니라 process fork하지만 단지 접근 자원을 제한하는걸로 알고 있어 I/O 관련 퍼포먼스 이슈는 크지는 않을 것이라 생각을 했거든요. 그래서 cogniti님께서 생각하시는 성능 감소가 구체적으로 어떤 부분인지 궁금하다고 질문을 드렸습니다.

---------------
Happy Hacking!

cogniti3의 이미지

글쓴이: cogniti3 / 작성시간: 일, 2020/05/24 - 1:33오후

저도 기술적인 내용은 잘 알지 못합니다. 아래 글을 참고하세요.
https://www.ctrl.blog/entry/firefox-linux-flatpak-snap.html

rururara429의 이미지

글쓴이: rururara429 / 작성시간: 토, 2020/05/30 - 5:45오전

snap은 진짜 우분투라는 이유 하나로 store가 엄청 방대하더라구요.
snap 패키지 거의, 아예 안 써서 몰랐는데 snap store 최근에 한 번 들어가보고 깜놀 했어요.
캐노니컬의 위력이 실감 되더란...

rururara429의 이미지

글쓴이: rururara429 / 작성시간: 토, 2020/05/30 - 5:46오전

elementary OS 팀에서 appcenter를 다른 여러팀과 협업해서 (flathub team 등) flatpak 기반으로 새롭게 개발하고 있더라구요. 펀딩 받고 있는 것 같습니다. https://itsfoss.com/appcenter-for-everyone/

ubuntu 저장소 기반이던 기존 appcenter를 새롭게 모든 리눅스 os를 지원하는 flatpak 기반으로, Android의 Play Store 모델처럼 사용자 결제 환경이 최적화 된 패키지 스토어가 목표인 것 같습니다.

데비안 기본 저장소와 함께 공존해 나가지 않을까요? 위 링크 댓글 토론처럼 서로 장단점이 명확해서...

rururara429의 이미지

글쓴이: rururara429 / 작성시간: 토, 2020/05/30 - 5:39오전

Flatpak 보안 문제는 filesystem=home 샌드박싱 해제 옵션이 개발자 권한으로 너무 쉽게 주어져 있다는 게 문제인거죠?
그럼 flatseal 설치하셔서 ~$ flatpak install flatseal
실행하시면 flatpak 설치된 앱들의 설정 환경을 모두 확인할 수 있는데요.
filesystem=home 열려 있는 앱들을 사용자가 직접 확인하고 간단하게 해제해 줄 수가 있습니다.

rururara429의 이미지

글쓴이: rururara429 / 작성시간: 수, 2020/06/03 - 12:44오후

생각이 바꼈습니다 -_-
그냥 가볍고 작은 프로그램이라면 모를까...
(작고 가벼운 프로그램은 flatpak 괜찮다고 생각합니다.)

audacity를 사용하는데 엄청 저사양 팬리스 랩톱에서 사용을 해보니까
flatpak 버젼은 뭔가 이상하네요.
flatpak 버젼의 버그인지
아니면 flatpak 버젼이 느려서 그런건지는 모르겠습니다. (snap은 더 느리겠죠.)

데비안 기본 저장소 배포판이 역시 최고인 것 같습니다.
apt install 했습니다. 최고네요.

cogniti3의 이미지

글쓴이: cogniti3 / 작성시간: 목, 2020/06/04 - 12:03오후

리눅스쪽은... UFS를 안 쓰고 ext4 를 쓰고, BSD 대신에 GNU 를 퍼뜨리려고 여러 공을 들였죠.
리눅스에서 컴파일하면 `pkg-config --libs glib-2.0 gobject-2.0` 이렇게 두개만 링크해도 의존이 이렇게 많이 걸립니다.

hodong@nimfsoft:/usr/bin$ ldd tian
	linux-vdso.so.1 (0x00007fff57188000)
	libgobject-2.0.so.0 => /lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fa5ec274000)
	libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fa5ec14d000)
	libtian.so.0 => /lib/x86_64-linux-gnu/libtian.so.0 (0x00007fa5ec135000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa5ebf72000)
	libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007fa5ebf66000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa5ebf45000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fa5ebecf000)
	libgio-2.0.so.0 => /lib/x86_64-linux-gnu/libgio-2.0.so.0 (0x00007fa5ebcf7000)
	libgmodule-2.0.so.0 => /lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fa5ebcf1000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa5ebcec000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fa5ec2f6000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa5ebccf000)
	libmount.so.1 => /lib/x86_64-linux-gnu/libmount.so.1 (0x00007fa5ebc72000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fa5ebc45000)
	libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fa5ebc2d000)
	libblkid.so.1 => /lib/x86_64-linux-gnu/libblkid.so.1 (0x00007fa5ebbdc000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fa5ebb4c000)

반면 FreeBSD 에서 컴파일하면, 9개 링크됩니다.

그래서 FreeBSD와 비교할 때, 리눅스가 상대적으로 통합 패키지 제작이 어렵고,
패키지 만들기 위한 debian/control 에

Depends: ${shlibs:Depends}, ${misc:Depends}

이렇게 해놓았고, 이런 걸 관행적으로 사용하기 때문에 더욱 패키지 파편화가 되었던 것입니다.
그 결과 아래의 의존성이 생성이 됩니다.
Depends: libanthy1, libappindicator3-1 (>= 0.2.96), libc6 (>= 2.14), libgcc-s1 (>= 3.0), libglib2.0-0 (>= 2.54), libgtk-3-0 (>= 3.21.4), libgtk2.0-0 (>= 2.18.0), libm17n-0 (>= 1.5.5), libpango-1.0-0 (>= 1.14.0), libqt5core5a (>= 5.12.2), libqt5gui5 (>= 5.9.0~beta) | libqt5gui5-gles (>= 5.9.0~beta), libqt5widgets5 (>= 5.0.2), librime1 (>= 1.5.3), libstdc++6 (>= 4.1.1), libwayland-client0 (>= 1.9.91), libx11-6, libxkbcommon0 (>= 0.5.0), libxklavier16 (>= 5.0), qtbase-abi-5-12-8, dconf-gsettings-backend | gsettings-backend, anthy

저는 소스코드에 저렇게 버전을 걸지 않았는데, debuild 가 패키지 만들면서 지가 갖다붙인겁니다. 저래서 타 배포판, 타 버전에서는 설치가 되지 않는 것이죠. 그거는 debian/control 에 직접 패키지와 버전을 명시해줌으로써 해결할 수 있습니다. 아래처럼요.
이렇게 제작하면 이 경우, 동일한 .deb 패키지 파일을 데비안 10,11, 우분투 19.10, 20.04, 20.10 에서 설치할 수 있습니다.
Depends: libanthy1, libappindicator3-1, libc6, libgcc-s1, libglib2.0-0 (>= 2.46.0), libgtk-3-0 (>= 3.22.0), libgtk2.0-0, libm17n-0 (>= 1.8.0), libpango-1.0-0, libqt5core5a, libqt5gui5 | libqt5gui5-gles, libqt5widgets5, librime1 (>= 1.2.9), libstdc++6, libwayland-client0, libx11-6, libxkbcommon0 (>= 0.5.0), libxklavier16, dconf-gsettings-backend | gsettings-backend, anthy
댓글 첨부 파일: 
첨부파일 크기
Image icon ldd-tian-freebsd.png7.33 KB
김정균의 이미지

글쓴이: 김정균 / 작성시간: 일, 2020/06/07 - 6:40오후

리눅스 쪽은 GNU를 퍼뜨리려고 여러 공을 들인게 아니라, kernel 이 GPL v2 로 배포를 했기 때문에 배포본들은 따라간 것 뿐이죠.

GNU 는 linux kernel 을 GNU/LINUX 라고 부르자고 주장 하지만, 사람들이나 배포본 업데들은 개소리 처럼 들으며 꾸준히 GNU/Linux 라고 하지 않죠. 그냥 선택일 뿐.. 노력이라는 생각은 전혀 들지 않습니다. 그냥 필요에 의해 사용을 하는 거지, GPL 에 무한한 애정을 가지면서 작업 하는 개발자들이 정말 얼마나 될지 궁금하군요.

리눅스쪽은... UFS를 안 쓰고 ext4 를 쓰고, BSD 대신에 GNU 를 퍼뜨리려고 여러 공을 들였죠.
cogniti3의 이미지

글쓴이: cogniti3 / 작성시간: 목, 2020/06/04 - 12:49오후

rpm 의 경우도, 통합 패키지 제작을 할 수 있는 방법이 있습니다.
아직 테스트를 해보지는 않았습니다.
https://rpm.org/user_doc/boolean_dependencies.html

Requires: (libappindicator-gtk3 or libappindicator3)

이런 식으로 하면 될 거 같네요.
libappindicator-gtk3 는 레드햇 계열, libappindicator3 는 오픈수세 계열에서 쓰는 패키지 명칭입니다.
굳이 레드햇(fedora, rhel, centos, epel), 오픈수세(tumbleweed, leap) 별도로 만들지 않아도 될 거 같네요. 다만 위에 말씀드렸듯, 시스템의 기반이 되는 gnu, gcc 라이브러리들에 대한 의존성이 문제가 될 수 있겠네요.

둘러보기