몇 년 만의 가전 제품 교체

결혼한지도 이제 거의 10년이라(…) 작년 – 올해 사이에 가전 제품들을 몇몇 교체하게 되었다. 작년에 교체한 건 전부 생활 가전이었지만 올해는 다르다 올해는 (???).

이번 주에는 의도치않게(?) 모니터 중 한 대와 PC용 스피커 교체. 교체한 것에 대한 간단한 리뷰.

우선 집에서 Dell U2408 과 Dell U2410 을 각각 아내와 내가 썼는데, U2408 쪽을 LG 27UD88 로 교체.
교체하면서 느낀 점을 두서 없이 정리하면,

  • 역시 고해상도 모니터를 써야한다.
  • 현 세대 모니터들은 대부분(?) 베젤이 얇고 16:9 이 경우가 많아서, 책상 위 공간 차지하는 부분에선 Dell U2408 랑 거의 비슷함. (약간 좌우로 더 쓰는 정도?) 지금은 좌우로 좀 긴 책상을 컴퓨터 사용하는 용도로 아내와 같이 쓰는데, 다른 모니터를 1~2년 후에 27″ 혹은 28″ 로 바꿔도 딱히 더 책상이 좁아지진 않겠다 싶음. 베젤 얇은 것처럼 앞/뒤 두께도 얇아서 좀 더 시원한 것 같기도하고…
  • 사기 전에 매장에 전시품이 없어서(…) 스펙만 확인하고 샀는데, 이게 틸트, 높이 조절은 되는데 설치하고 보니 바닥판 부분이 (수평방향으로) 회전이 안됨 -_-; 이거 좀 난감하다. 보는 방향 바꾸려면 몸을 일으켜서 모니터를 들어서 틀어야 한다.
  • 이것도 베젤 얇은 탓의 연장인 것 같은데, 전원 어댑터가 따로 있다. 이거 알았으면 이 모니터 안 사고 다른 거 샀을 듯 (전원 어댑터 별개인거 개빡침)
  • 본체 – 모니터 간 USB port 연결을 USB-C로 하는데, 구성품 중에 USB-C to USB-A 가 있어서 (C to C도 있음) 그걸로 연결; 다만 기본 길이가 짧다. 모니터 옆에 본체를 두는게 아니면 연결하기 곤란할 수도 있음. 이건 1.5m 정도는 해줘야 하지 않을까
  • HDMI 와 Display Port 케이블도 좀 짧은 느낌. 아슬아슬 하게 끼웠다.
  • 요즘 모니터라 HDMI가 두 개라서 그 부분은 잘 써먹었다. 닌텐도 스윗치가 HDMI 출력을 쓰는데 U2408 쪽에는 HDMI가 없다 (DP는 있음). 그래서 부득이하게 출력을 내 모니터로 돌려서 플레이하고 그랬음 -_-;; 이건 이제 해소. 그리고 사운드 출력 선도 (본체 혹은 닌텐도) — (HDMI) — (모니터) — 3.5 ϕ 연결 — 스피커 쪽 line-in 으로 처리해서 선이 하나 줄었다. (이전에는 line-in 을 닌텐도 할 때마다 수동으로 바꿔 낌)
  • 전원 어댑터에서 전원 공급받는 부분 바로 위에 3.5 ϕ 출력이 있다. 그래서 thermal noise 가 출력에 꽤 낀다; 이건 며칠 뒤에 구입한 스피커랑 연결할 때 문제가 좀 되었음.
  • …모니터 자체 리뷰는 아니지만 Windows 10 현재 버전은 Hi-DPI지원이 꽤 멀쩡해진듯. 7 때의 그 괴로운 상태는 벗어난 것 같다.

그리고 13년째 사용한 Creative GigaWorks G500 스피커도 폐기하기로 하고, Bose Companion 20 을 구입. 아무리 생각해도 아파트에서 우퍼는 무리인 것 같고, 발치에 걷어차이는 것도 매우 괴로워서, 우퍼 없이 가기로.

  • 매장에서 청음은 해보고 (큰 기대는 안하고) 샀는데, 집에 와서 들어보니 생각 외로 유닛 크기 작은 것에 비해서 소리가 해상도가 꽤 높고 볼륨도 커서 놀랐음. (사실 직전에 사운드 바도 청음해서 그런 것 같긴함)
  • 곶통스럽게도 이것도 전원 유닛이 별도다. (전원선 – 어댑터 – 우측 스피커로 들어가는 구조) 모니터 때와 마찬가지로 이 부분은 매장에서는 안 보여서 그냥 넘어갔다. ㅠㅠㅠㅠㅠㅠ; 이전 스피커는 우퍼 유닛이 아주 커서 그 내부에 전원부가 있어서 어댑터는 따로 없었다.
  • 대체 파워 코드는 왜 각 지역별 코드를 다 포함하는가. (전원 코드가 4갠가 5개 들어있음)
  • 기본 포함한 3.5 ϕ 케이블이 왜 이렇게 노이즈를 잘 전달하는진 모르겠지만 라인-인에 넣지 않은 쪽을 손에 쥐기만 해도 스피커 쪽에 노이즈가 와장창; 그래서인지 엘지 모니터 쪽을 이걸로 연결하면 아주 그냥 혼파망.
  • 그래서 다른 PC쪽을 그 케이블로 연결하고, 새 모니터와 스피커 사이는 다른 케이블로 연결하니 노이즈가 거의 안 끼더라. (최대 볼륨 근처에서나 희미하게 들림) 일단은 이 셋업을 한동안 유지하기로…

…역시 새 물건을 써야 삶이 편하네요. 수동으로 오디오 케이블 바꿔끼기 너무나도 고통스러웠었다. 이젠 더 안해도 되겠지만.
하지만 전원 어댑터가 늘어서 이 꼴보기 싫은걸 수납할 선반을 주문함.
내일 배송 예정이라 뜨는데, 제발 로켓 배송 힘을 내 줘(…).

Linux 게임 서버 성능 평가 (eBPF + BCC)

어제 발표에 썼던 슬라이드.
어제 발표에 와주신 분들 감사합니다.

Linux 커널의 내장 트레이싱 기능인 eBPF 와 이를 위한 BCC 툴킷을 써서 동작 중인 프로세스를 분석해서 성능 문제를 찾는 방법을 설명했다.
머지 않은 미래에 안드로이드 성능 측정도 이걸로 할 수 있을 듯하니, 서버 뿐만 아니라 안드로이드 기기에서 개발하는 분들도 한 번 보시라.

eBFP +BCC 는 간단히 요약하면, python (혹은 go, lua) 으로 통계 처리 및 초기화, 몇줄 안되는 C코드로 커널 내부에서 후킹/통계 수집을 하고, 수집할 수 있는 범위가 넓어서 (커널 함수부터 유저 함수까지) 성능 분석 / 디버깅 쪽에 유용한 툴이다.
최신 커널이 필요하긴 하지만 재시작/빌드없이 측정할 수 있다는 점에서 매우 매력적인 툴이다.

그리고 예제로는 C++ HTTP API 서버를 만들었다. 하재승 군이 만든 Crow 와 이것의 사촌쯤될 데이터베이스 래퍼 CrowDB 를 썼다. 내가 쓴건 아직 비공개 버전.
덕분에 C++ 1y 로 매우 편안하게 짰다.

iPhone 배터리 교체

지난 설에 양가 방문하고 나니 도저히 이대로는 못 버티겠다 싶어서, 3월 초에 배터리 교체를 받았다. 사용 중인 아이폰 6S는 특정 시기 생산품에 대해서 무상 교체를 하는데, 그 대상이라 공짜로 교체 받긴 했다.

가장 가까운 서비스 센터가 판교 일렉트로 마트 안에 있어서 휴일에 판교역에 갔다와야 했다. Orz.

배터리 교체는 생각보다 얼마 안걸렸고 — 대략 20분 내외? — 잠시 대기 줄에서 기다린 시간이 한 15분 정도였던듯. 근데 이건 문열자 마자 뛰어가서 그렇고, 실제로는 이보다야 더 걸리겠지.

교체하고나니 배터리가 좀 더 오래 가기는 하는데, 체감 상으로 더 컸던 부분은 트위터 실행 속도가 빨라졌다 정도? 배터리 충전량 줄면 성능 줄이는게 생각보다 더 컸던 듯 싶다.

코코넛 배터리에도 이제 충전 잔량이 크게 나온다 신난다(?).

Screen Shot 2018-03-17 at 09.27.39

리뷰: 콘클라베

로버트 해리스 의 장편 소설. 흔히 팩션 이라고 말하는 장르의 소설이다. 내가 본 상당 수의 팩션은 로버트 해리스 작인듯 – 이니그마, 당신들의 조국, 고스트 라이터, 아크엔젤, 어느 물리학자의 비행 등등. 덤으로 키케로 3부작 (이 이름이 맞나?) 도 있고.

제목에서 바로 알 수 있듯이, “교황 선종” – “새 교황 선출” 까지의 짧은 기간을 배경으로 한 소설이다.
직전 몇 대 교황 실명이 나오긴하지만 소설 자체는 정말로 픽션. 배경과 이전 교황이름만 현실에서 가져왔다.

콘클라베 관해서는 뉴스 단신에 나온 정도만 알고 있었는데 — 투표 결과 선출하지 못하면 검은 연기, 선출하면 흰 연기가 난다 정도? — 여러모로 궁금증을 충족시켜주는 스토리라인이었다.
읽다보면, 내가 왜 종교가 없는지도 되새김질 좀 하고, 현실 의 천주교회가 끌고가고 있는 추문들도 한 번 들춰보고. 그리고 로버트 해리스 소설의 결말들을 그다지 맘에들어하지 않는데 – 이니그마 정도만 맘에 들었음 – 이건 꽤 괜찮았다.

다만 이거 전자책으로 나오는 줄 모르고 종이책 나오자마자 사서 책장 공간이 처치 곤란 Orz.

Jenkins 2.x DSL 적용기

설 직전에 사용 중인 jenkins 서버가 버전이 올라갔다. 그리고 악몽(?)의 시작…

대략,

  • 플랫폼 별 병렬 빌드를 위해 사용하던 buildflow 플러그인 결과물이 사라지는 현상
  • 프로젝트 설정에서 buildflow 스크립트를 확인하거나 편집할 수 없는 현상

이 생겼다.

근데 최악의 문제는 아니었던게, 결과물이 보이지만 않고 서버 머신의 디스크에는 남아있더란; 비슷하게, buildflow 스크립트도 display: none 로 처리하고 있어서 스타일 수정하고나니 보이긴하더라.

Jenkins wiki에서는 새 DSL인 pipeline plugin으로 넘어가라고 한다. 그래서 이전 작업을 시작;

  • Buildflow 의 병렬 빌드에 해당하는 parallel 태스크는 있다.
  • Parameter 넘기는게 미묘하게 다르긴한데 — 어차피 groovy 이긴 함 — 약간의 삽질 후에는 성공
  • Artifact 복사해올 때 이전에는 buildflow toolbox 를 썼는데, “Copy Artifact Plugin” 을 설치하고야 처리할 수 있었다.
  • Gerrit trigger 메뉴가 없어서 당황; Gerrit trigger 를 클릭하고, 추가로 뜨는 gerrit 주소 설정을 추가하고 나서야 동작한다.
  • Artifact archive 관련해서, 패턴 매칭에 실패하면 오류 처리한다. [이건 이미 해결된 이슈로 있더라. 오류 처리 끄는 플래그가 있음](https://issues.jenkins-ci.org/browse/JENKINS-38005)
  • Downstream 프로젝트들을 빌드 성공 후 트리거해야하는데, 트리거하고 종료하는게 없어서 ?! 했는데, build job 패러미터로 wait: false 를 주면 되긴하더라.

이렇게 작업일 1일+를 날리면서 느낀 좋은 점을 요약해보자면.

  • 새 DSL 로 모든 플러그인 / 작업 기능을 내보내고 있어서 설정 백업이나 신규 버전으로의 이전 작업은 어느 정도 편하게 할 수 있을 듯 하다.
  • 심지어, DSL 을 Jenkinsfile 이란 이름으로 저장소에 포함하는 것도 가능하다.
  • 새로운 선언형 (declarative) 와 기존의 스크립트스러운 빌드 방식을 모두 포함한다.
  • 이 기반으로 작성하면 기존보다 훨씬 나은 시각화를 제공한다.

물론 좋기만 할리가.

  • 새 DSL은 만들었는데, jenkins 없이 이걸 시험해볼 방법은 없다. 다만 replay 기능을 쓰면 점진적으로 문제를 찾는건 가능하다. 빌드 시간이 길다면야 이걸로 나아지는게 많지 않긴 한데;
  • 선언형과 절차형 모두 지원하는데, 양쪽을 동시에 쓰면 애로사항이 꽃핀다. 특히나 모르고 문서 뒤지던 초기에 이 차이를 모르고 튀어나오는 groovy / JVM exception 에 많이 당함.
  • Jenkins 2.x + pipeline 으로 넘어가면 과거로 돌아갈 수 없다. 아주 간단한 예로, 설정 파일을 **XML 1.1** 로 바꾼다. …대체 왜? 1.1 쓰는거 처음 봄. 다운그레이드했다가 잠시 지옥을 봤다.

여하튼; 새 DSL 부터 쓰는 사람은 꽤 편할지도? 나는 크게 당했지만.

Docker 로 Linux 없이 Linux 개발하기

지난 달 말 — 이미 10월 말인 것 같지만 다 기분탓 — 발표에 썼던 슬라이드.

Windows + VisualStudio / macOS + Nuclide 환경에서 내부에 같이 띄운 docker container에 접근해서 C++ 프로그래밍을 디버깅 하는 내용을 다뤘다. 기록 차원에서 블로그 글로도 남긴다.

리뷰: “코스믹코믹: 빅뱅을 발견한 사람들”

cosmiccomic

대략파인만이나로지코믹스같은 느낌의 책이다. 로지코믹스 때는 좀 덜했는데, 이 책과 파인만은 내용이 좀 비어있는 기분. (아래 사진이 두 책)

feynman-logicomics

그리고 전자책으로 구매했는데 폰으로 보기엔 좀 불편해서 결국 데스크탑으로 옮겨서 봄 — 종이책 살걸 ㅠㅠ.

개략적인 얼개는 빅뱅이론의 나오기까지의 이론적/실험적 증거를 찾아가는 여러 사람의 얘기를 좀 가볍게 다룬다. 예를 들어

같은 얘기를 모아서 빅뱅 이론이 성립되어간 과정을 이론/실험적 증거로 얘기한다. 잘 읽히고 내용도 꽤 흥미롭다.

근데 전개를 단편적인 에피소드 나열에 의존하는 거 + 너무 짧고 얕게 쓴 건 좀 불만이다. 여러모로 미묘한 책. 로지코믹스에는 만족하고 + 파인만 책에는 만족하지 못했다면 비추. (파인만 책 보다도 내용이 없어…)

Docker + C++ IDE 개발환경 꾸려보기

Windows / macOS 용 docker를 이용하면 VM을 따로 띄우지 않아도 로컬 환경을 리눅스 개발 환경처럼 쓸 수 있다.
전에도 한 얘기지만, 툴은 가능하면 해당 OS 용의 GUI 도구를 활용하고 싶은게 내 심정.

그래서 (?) 요즘 나오는 좋을 툴들을 써서 Windows / macOS를 쓰는 기기에서 docker + linux 개발환경을 해당 OS 용 IDE 로 개발하게 꾸려보았다. (컴파일은 linux 컨테이너, 디버거 UI는 호스트 OS의 IDE를 쓴단 소리)

Windows

Widows 의 VisualStudio 확장 기능으로 linux  개발을 지원하는 Visual C++ Tools for Linux 라는게 있다. 지난 2016-09-06 에 업데이트.

이걸 써서 같은 컴퓨터에 띄운 docker 컨테이너에 접근하면, 디버거까지 붙여서 돌려볼 수 있다.
하재승 군의 crow 예제 하나를 디버거 붙여보면 잘 돈다.

vs-debugging

다만 고칠게 좀 많다:

  • Docker for Windows 의 volume 설정이 좀 이상한 것
  • 권한을 추가로 주지 않으면 잘 안 도는 것 (디버깅)
  • 빌드/디버깅/빌드 결과물을 한땀한땀 입력해야하는 것 (…)

macOS

macOS 용으론 Facebook 의 Nuclide 가 있다. 여기서도 crow 예제를 돌려보았다.mac-nuclide-io

macOS 에 띄운 docker 컨테이너에서 프로세스를 띄우고, lldb (GDB가 아니라…) 를 띄워 디버깅하는게 가능하다. 다만 의존성 걸린게 많아서 내가 만들어본 역대 최대 크기 (1.1 GiB) 짜리 docker 이미지가 나오더라; 용량은 차치하고, Docker for macOS 쪽이 volume 지원같은게 낫긴하지만 이쪽도 문제는 한 바가지긴 하다.

  • 설정을 한땀한땀 넣어야한다. (VS 쪽보다 아주 약간 편함)
  • 깔아야하는게 한 가득 (atom, nuclide, npm, clang, llvm, lldb, … 그리고 clang, llvm, lldb 에 대한 python 래퍼)
  • 테스트 한다고 썼던 ubuntu 16.04 에선 라이브러리 내의 경로가 잘못 박힌게 많아서 고쳐써야할 부분도 많다 (ubuntu 14.04 쪽도 크게 다르지 않으리라 생각)

이런 내용을 포함해서 이번 주 수요일 (2016-09-28) 에 넥슨 코리아 지하에서 기술 세미나를 합니다. 궁금하신 분은 와서 보시길.

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. 데비안 패키지의 파일 형식; 회사에서 해당 형식으로 패키징 할 일이 잦아서 익숙하다. 

Interop Madness

클라이언트 서버간 암호화  관련해서 개념 증명 + 몇 가지 성능 측정을 해야해서 몇 가지 언어 + 플랫폼에서 libsodium 1 을 호출해봤다. 그 와중에 겪은 일 정리.

C++

이쪽은 평범한 C/C++ 인터페이스니 문제 없이 끝.

Python

위에서 구현한 부분을 클라이언트 쪽 구현을 (빨리) 만들어서 테스트하는 작업을 했다.

여기서부터 문제가 생기기 시작. Ubuntu 16.04 (xenial) 이 제공하는 libsodium 래퍼가 python-nacl 2 인데, 써보니 내가 쓰려는 함수가 여럿 없다. 특히 crypto_stream* 류 함수가 없더라. 그래서 다른 래퍼가 있나하고 PyPI 에서 몇 가지 써보고는 빠른 포기.

이제 cffi 를 쓸 타이밍. C 코드로 정의한 함수를 변환해서 만든  .py 파일로 동적 라이브러리 (.so, .dll, .dylib) 에서 가져오는 방식을 썼다. 3 예~전에 ctypes 로 로딩할 때 괴로웠던 부분이 확실히 줄어들었다. ABI 대신 API 수준에서 접근하는 차이는 정말 컸다. cdata의 buffer 인터페이스도 쓸만했다.

cffi 로 libsodium 에서 필요한 함수들을 가져다 쓰기 시작한 이후로는 금방 일이 정리.

…하지만 이 시점에선 어떤 비참한 미래가 기다리는지 모르고 있었다. (?)

C#

(나로써는) 슬프게도, 클라이언트 쪽 구현 중 하나는 C#으로 해야한다. (Unity3d + mono) 게다가 이건 여러 플랫폼을 지원해야 한다:

  • Unity Editor: Windows, MacOS
  • Android: 다행히도 ARMv7만. Unity가 ARMv6는 지원하지 않는다 (?)
  • iOS: 기기 + 시뮬레이터에서 모두 돌아야 한다.

Windows는 (내가) 당장 쓸 머신이 없어서 일단 미뤄두고, 나머지에 대해서 잘 도는지 시험하기 시작. 꼬박 2일 걸린 것 같다 — 생각해보니 절반은 C++ 기반인 cocos2d 랑 같이 처리하는 것 때문이었던 것 같기도?

우선 각 플랫폼 별로 크로스 빌드를 시도…해야하나 했는데, libsoidum 저장소에 플랫폼 별 빌드 스크립트가 있다. 4 iOS/Android 쪽에 내가 쓰려던 함수 중 몇 개가 빠져서 컴파일 플래그를 조금 고친 것 말고는 별 일 없이 진행. 그리고 Unity 에서 (native) 동적 라이브러리를 어떻게 가져가나 고민했는데 경험 많은 동료분이 설명해주셔서 매우 간단한게 통과.

대략,

  • DllImport 로  C에 있는 함수들을 CLR 쪽에 노출하고
  • C# 코드로 이 함수들을 래핑하고
  • 다시 이 함수들을 써서 실제 개발자가 쓸 고수준 API로 바꾸자

라는 방향으로 진행했다. 에디터(=랩탑 위)에서 잘 도는걸 보고 android  기기에 올리기 시작. 왠걸, 초기화 (=sodium_init()) 은 성공했고 몇몇 초기화도 했는데, 그 이후에 호출하는 함수에서 크래시 (SIGSEGV).  (당연하게도) 콜 스택은 native code에서 죽는 것.

원인을 추측하기 시작:

  • C 함수 원형을 잘못보고 옮겼는지 확인 시작. C는 타입 무시하고 심볼 이름만 보니 내가 잘못 옮겼다면 크래시할 수도 있으니 우선 여길 의심하고 C 함수 원형과 하나씩 대조. 별 이상 없어 보였다 (불행의 단초)
  • 크로스 컴파일을 잘못했는가 확인: 생각해보니 C/C++ 로 올렸을 때는 잘 돌았다 (…)

…대략 정신이 멍해져오는데 다시 함수 원형을 보다가 불현듯 깨달은 사실:

C 쪽의 size_t 를 C#의 ulong 으로 지정했는데 Unity + ARMv7 은 32bit ABI를 쓰니 uint 여야하는 것. Orz.

그래서 이걸 iOS / Android 플래그로 ulong / uint 처리하게 했다가, iOS도 아직 32bit인게 남아있는 걸 보고는 (iPhone 5 및 그 이전 + iPhone 5C) UIntPtr 로 처리하고 강제 캐스팅하게 수정해서 마무리했다. 그러고나니 잘 돌더라.

 

3줄 요약

  • ABI 맞추기는 삽질이다. 어떻게든 API 수준으로 해결할 수 있는 법을 찾자 — python의 cffi 처럼. 아니면 기계적으로 처리할 방법을 찾아야?
  • (부득이하게) ABI를 맞춰야 한다면 가능한 arch 목록을 잘 확인하자. C/C++에서 편했던 platform dependent type들이 대재앙
  • 여러 플랫폼 지원하는 라이브러리는 정말 인생에 도움이 된다. 잘 쓰고나면 널리 알려줍시다 (?)

 


  1. libsodium 페이지. 현 시점에 적합한 대칭키 암호화 + AEAD, ECC 함수들, system random source 를 래핑한 함수, side channel 공격을 피하는 비교, 해시, … 등등을 제공하는 잘 만든 라이브러리. 인터페이스도 보고 바로 쓰는게 그다지 어렵지 않다. 
  2. GitHub 저장소. libsodium 이 fork(?)한 NaCl 을 래핑한 것 같은 이름이지만 libsodium 을 래핑한다. 
  3. API 수준에서, 소스 코드 밖에서 정의 부분을 참고해서 작성했다. 
  4. 저장소의 dist-build 디렉터리 의 스크립트들이 이에 해당한다.