Linux 용 데스크탑 앱 훑어보기

요즘은 web 대신 app 으로 나오는게 유행인 것 같기도 하다. 모바일만 그런게 아니고 데스크탑도 약간 그런 것 같은데, 내가 쓰는 툴 중에 자주 쓰는 것 몇 가지도 이런 식.

이 중 두 가지가 내게 익숙한 .deb 1 형식이길래 두 가지를 뜯어봤다. 하나는 slack 이고, 나머지 하나는 WordPress.com 이다.

dpkg-deb -R 명령으로 아카이브된 것을 까보면, 대략 다음과 같은 파일들이 있다:

  • desktop 앱을 위한 파일들 (wpcom.desktop, slack.desktop)
  • node_modules (와 .asar 파일들)
  • elctron
  • libffmpeg.so

특이하게도 slack 쪽엔 cron.d 룰이 있었는데, 여기서 apt 저장소를 설정한다. 이건 좀 이상한듯. 왜 설치 후 스크립트 (postinst) 를 쓰거나, 다른 오픈소스 도구처럼 저장소 자체를 안내하는게 더 좋아보이는데 대체 왜 이럴까. 여담으로, package cloud 란 서비스를 쓰더라. 미리 알았다면 나라도 쓸 것 같이 생겼다 (apt, yum, pypi 저장소랑 몇 가지 더를 지원하는듯)

리눅스 데스트탑이니, GNOME desktop app 형식을 쓴다. 그리고 리눅스 전용으로 만들진 않을테니 electron 을 이용해서 만든다. 자연스럽게 (?) 묶는 것도 electron archive 형식 으로 처리한다.

Atom/Electron 기반의 앱들은 이제 정말 주류가 된 것 같다. MS의 Visual Studio Code나 Facebook 의 nuclide.io 도 그렇고. WordPress 는 PHP를 탈피해서 API 기반 + JavaScript 로 관리자 페이지 다시 만든다고 시작한 Calypso 프로젝트 결과물로 데스크탑 앱을 내놓기 시작했던 것 같다. Slack 쪽도 이번 데스크탑 앱 베타부터 프레임웍을 바꾼 모양…

플랫폼이 파편화되면서 오픈소스 도구나 프로그램들 — 특히 기업이 직접 개발하거나 지원하는 — 쪽이 크로스 플랫폼 라이브러리/프레임웍을 더 많이 쓰다보니 역으로 Mac/linux 데스크탑 환경 쓰는 나같은 사람에겐 더 편한 세상이 되어가는듯.

Update: libffmpeg.so 관련 – @lqez 님 제보로 업데이트 electron 이 chromium에 의존하고, chromium 이 proprietary codec 처리 때문에 libffmpeg 에 의존해서 그렇다 합니다.

 


  1. 데비안 패키지의 파일 형식; 회사에서 해당 형식으로 패키징 할 일이 잦아서 익숙하다. 

node.js 혹은 CPS 단상

지난 주에 둘째 태어나서 병원에 있는 동안 SNS와 블로고스피어를 스쳐지나간 글 중 제일 눈에 띄는 부분이 “CPS와 node.js” 관련된 내용이었다.

iPhone은 정리에는 그다지 좋은 기기라고 못하겠다. 내가 생각하던 문맥을 저장하기엔 내 활용 방법의 문제거나 기기가 부족하거나; 여하튼 기억나는 글들을 여기 정리하자면 (twitter는 정리가 불가능하니 제외),

웹 서버 아키텍처와 프로그래밍 모델의 진화 http://ricanet.com/new/view.php?id=blog/110903 (node.js의 I/O 모델을 점검하기에 좋은 글)

Node.js의 소개글 들에 대한 유감 http://himskim.egloos.com/3810574

이에 대한 홍민희 님의 글 http://blog.dahlia.kr/post/18300740247

그리고 다시 (홍민희 님의) 비동기 I/O 프로그래밍 모델 관련 글 http://blog.dahlia.kr/post/18355002657

 

이에 대한 내 생각을 정리하자면:

1. node.js는 hype이라 생각한다. node.js 광신도(…)들이 말하는 장점은 이미 오래된 얘기고 (이벤트 기반의 비동기 I/O 모델, 단일 이벤트 루프와 그로 인한 싱글 스레드의 단순함), 이런 시도를 하는게 node.js만 있는 것도 아니다. 다만 세상에 JavaScript 프로그래머가 많기 때문에 그렇게 느껴지는 것 뿐이지. 서버 혹은 백엔드 프로그래밍에선 너무 오래된 — (게임) 서버 프로그래밍을 주로 하던 이들 사이엔 이게 왜 이슈가 되는지 궁금해하는 사람들이 나온다 — 이슈라서 말이지.

다음 언어들로도 `흔히’ CPS 스타일의 프로그래밍을 할 수 있다. 그리고 이 언어들 모두에서 node.js에서 `하면 안된다’라고 주장하는 한 이벤트에서 긴 계산을 하는 일도 실행 모델에 따라선 해도 된다. 그리고 이 언어들에선 `흔히 하는 일’에 불과하다.

Go: goroutine 자체가 일종의 CPS 스타일 프로그래밍이다. 그리고 일반적인 이벤트 큐 처럼 쓸 수 있는 channel 개념 역시 존재한다. 그리고 이 두 개념을 최대한 활용해서 만든 언어가 Go다. 자세한 내용은 내 과거 포스팅을 참조하자 (https://rein.kr/blog/archives/tags/go) 개인적으론 이런 류의 I/O 비동기 / 멀티플렉싱을 생각하고 짠다면 Go가 가장 깔끔한 프로그램이 나온다고 생각한다.[1]

C#: C#의 익명 함수 (delegate라고 부르던데) 역시 이런 CPS 스타일로 프로그래밍 할 수 있다. Nexon의 `마비노기 영웅전’과 `마비노기 2’도 이런 개념을 활용해서 서버를 구현했다. 2011년 NDC 세션의 내용을 정리해놓은 것처럼 (https://rein.kr/blog/archives/2696https://rein.kr/blog/archives/2671) 이걸가지고도 JS에서 흔히 하듯이 성공/실패 처리를 cps로 작성한다.

C++: C++11의 lambda 혹은 그 이전의 std::function[2] 을 이용하면 역시 CPS 형태의 코드를 작성할 수 있다. 내가 작성한 게임 서버 라이브러리 역시 이를 이용한 CPS 스타일의 코드가 포함되어 있다.

 

2. node.js가 단일 스레드, 즉 단일 문맥만으로 처리하기 때문에, computation-intensive한 작업은 처리할 수 없다. 그래서 어쩔 수 없이 백그라운드 태스크 큐 등을 써야하고, 이로 인해 생기는 지연 시간(latency) 문제는 극복할 수 없다.
게임 서버에서도 node.js처럼 (혹은 그보다 낫게)

  • 복수의 스레드가 네트워크 이벤트(read/write)를 비동기로 처리하고,
  • 네트워크 이벤트를 서버 메인 스레드(그러니까 논리적으론 단일 스레드 프로그램)로 전달하고,
  • 서버 메인스레드가 내부 로직을 처리해서 다시 네트워크로 보내는

구조를 사용한 서버들이 있다. 다만 이 경우엔 계산 량이 많은 경우 지연 시간이 길어진다. 그것도 게임 상에서 상호 연관이 없어 보이는 부분들 사이에 영향을 주는 형태로 -_-;
게임 서버는 웹과는 좀 다르게 persistent storage에 다 저장하지도 못하고, 각 연결 간에 상호 작용도 많아서 어쩔 수 없이 생기는 문제이긴하지만 맨 첫 글에서 얘기하는 것 처럼 node.js가 `유니크’한 것은 아니다. JavaScript로 서버 프로그래밍을 진행한다는 것은 꽤 참신하지만 말이다.

그리고 서버 메인스레드가 1개가 아니라 복수개 일 수도 있고 — 내가 본 코드에선 이게 주류다 — 걔 중에도 IO 스레드가 full swing을 하돼 non-blocking한 알고리즘을 이용해서 복수의 큐를 사용하고, 블럭킹을 제거한 구현체도 있다.

 

3. 프로그래밍 모델은 CPS는 `쉽게 만들어낼 수 있지만’, 프로그래머에겐 꽤 골치거리라 생각한다. 홍민희 님의 말대로 가장 쉬운 형태는 co-routine일 것이라 생각한다. CPS처럼 이전 문맥에 대해 생각할 필요도 없고, 불필요한 nesting (node.js말하는 거임) 도 필요치 않다. 다만 이 경우에는 언어적인 수준에서 지원하지 않으면 안된다. 불행히도 내가 사용하는 주요 언어인 C/C++의 경우 co-routine을 사용할 수단은 OS fiber수준 정돈데, 이 경우엔 다른 동기화 객체들을 쓸 때, 동기화 단위가 스레드라서 fiber끼리 switching할 때 지옥을 보게 된다. 하지만 node.js 정도의 프로그래밍 모델에선 이게 가장 간편할 것이다. 각 연결 별 문맥끼리 상호작용이 적다면 더더욱 말이다.

  1. 이 언어를 만든 회사가 Google이란 생각을 하면 더 그렇다 []
  2. 혹은 그 이전 구현체인 std::tr1::function, 혹은 이거랑 별반 다를게 없는 boost::function을 생각하면 더 이전부터 []