예전에 dasom 개발하면서 많은 글을 작성했었는데 당시 drupal 로 홈페이지를 사용했었는데 drupal 관리를 못해서 데이터를 다 날려먹었습니다. 복구가 안 되요. 그래서 그 때부터 그냥 블로거에 글쓰고 있는 겁니다. 블로거는 구글에서 관리를 하는거니 제가 손댈 필요가 없어서 좋긴 하네요.
그건 그렇고 입력기 이야기를 하고자 합니다.
예전에 다솜 개발 전부터 다솜 개발 후까지 계속 시리즈로 글을 썼었는데 글이 다 날아가서 아쉽네요.
다솜 입력기 개발 동기는 끝글자 버그 잡다가 2014년 12월, 2015년 1월 쯤 ibus 버그임이 판명되어
https://kldp.org/node/150790
https://github.com/ibus/ibus/issues/1282
ibus 고쳐쓰려다가 ibus 구조상 고치는 것보다 새로 만드는게 더 낫다라고 판단하여 새로 만들게 된게 dasom 입력기입니다. dasom 입력기의 이름을 nimf 로 변경하여 현재에 이르고 있습니다.
이런 얘기하기 좀 거시기한데, ibus 는 근본적으로 설계가 잘못 되었습니다.
그래서 버그가 많습니다. 해결도 안 되고요. 중복 코드도 정말 많고, 키입력을 가로챌 수 있는 보안 이슈도 있었습니다. ibus 입력기가 어떻게 리눅스 배포판에 널리 탑재되었는지 의문이 들 정도입니다. ibus 한글 입력 버그는 2018년 현재까지 해결되지 않은 상태인 것 같습니다. 입력기로써는 심각한 버그죠.
https://github.com/ibus/ibus/issues/1980
https://github.com/libhangul/ibus-hangul/issues/42
그리고, ibus 의 키값을 가로챌 수 있는 보안 문제를,
제가 2015년 1월 경에 인지하고 있었습니다.
https://kldp.org/comment/609821#comment-609821
이 문제가 fcitx 개발자님에 의해 2017년 10월 보고가 되고
https://github.com/ibus/ibus/issues/1955
2018년 1월에 해결되었네요. ibus 탄생 시점이 2008년일 걸 감안할 때 이러한 심각한 버그가 해결되는데 9년이나 걸렸네요. 그 9년 동안 루트 패스워드 노출되지 않았다고 장담할 수 있습니까?
nimf 도 마찬가지로 2017.02.19 버전부터 보안 문제가 있었는데;;; 2018.07.02 에서 해결되었습니다. 소켓 파일 소유자 id 와 클라이언트 소유자 id 가 같은지를 체크함으로써 해결하였습니다. 진작에 그렇게 했어야 했는데;;;;; 1년 반 걸렸죠... 하지만, 제가 인지하자마자 하루 내에 고쳤습니다. ibus 보다는 키값을 빼돌리기가 어려운 버그입니다.
https://gitlab.com/hodong/nimf/issues/107
오늘 우연히 ibus 생각이 나서 검색해봤습니다.
2018년 아직까지도 삽질 중이네요.
ibus 는 비동기 방식의 입력기라 해결이 안 됩니다.
그 문제를 해결하려면 동기식으로 바꿔야 하는데, 동기식 설계가 매우 어렵습니다. 잘못하면 컴퓨터가 먹통될 수 있기 때문입니다. 입력기를 새로 만드는 것보다 어렵습니다.
Hangul preedit is moved with mouse click #1980
https://github.com/ibus/ibus/issues/1980
한글과 스페이스 순서가 바뀌는 문제 #42
https://github.com/libhangul/ibus-hangul/issues/42
그래서 나온게 dasom (현재 nimf) 입력기입니다. nimf 입력기는 버그가 거의 없고 매우 안정적으로 잘 작동합니다. 툭하면 죽는 ibus 와는 기술적으로 차원이 다른 입력기입니다.
과거 절 욕하고 원망하시는 분들도 계셨었는데... 정작 욕 먹어야 할 프로젝트는 ibus 아닙니까?
개인 프로젝트인 nimf 프로젝트보다 관리가 안 되어 10여년간 매우 심각한 버그 해결도 안 되지 않습니까?
그동안 억울해서 하소연 해봅니다.
ibus 로 아직도 삽질 중인 분들도 계시는데... 응용 프로그램을 ibus 의 비동기 방식에 뜯어 고칠 수는 없습니다. 그거는 문제 해결도 되지 않고 해결이 더욱 어려워지게 되고 또 다른 버그가 생겨납니다.
ibus 는 비동기 방식의 입력기이고, 응용 프로그램에서 요구하는 방식은 동기식 방식입니다.
정확하게 구현한게 바로 nimf 입니다. 타 입력기들은 버그가 많은데 nimf 는 버그가 거의 없습니다. 원래 입력기라는게 버그가 많을 수가 없는 물건입니다. 입력기가 버그가 많고 그걸 수년 동안 해결할 수 없다면 설계에 근본적으로 문제가 있다는 것입니다.
왜냐고요? 사용자분들 키 입력하면 그 키값을 입력기에 전달하고 입력기는 그 키값들을 변환하여 응용 프로그램에 돌려 줍니다. 기본 원리가 이렇게 간단합니다. 변환 엔진을 제외하면 입력기는 투명한 존재입니다. 그래서 입력기는 버그가 거의 없어야 정상입니다.
입력기라고 다 똑같은 입력기가 아닙니다.
nimf 는 과거에는 나온 적 없는 혁신적인 입력기 프레임워크입니다.
이제 우리는 꿈의 입력기 nimf 로 나아가야 합니다.
개발자님은 님프 개발하면서 스트레스를 많이 받으신 것 같은데, 님프를 쓰는 저는 님프를 쓰면 쓸 수록 스트레스가 주네요.
답글삭제개인적으로 느끼건데 일본어/중국어/한국어같이 완성식(?) 비슷한 문자를 쓰는 곳은 뭔가 좀 다른 입력기들이 이상하게 작동하는 게 심했다는...
입력기 기술이 퇴보하여 오히려 XIM 으로 입력하던 90년대가 더 편했었어요. nimf 가 있으니 그나마 다행이죠. nimf 애용 감사드립니다.
삭제fcitx, ibux 등 외산(?) 입력기들은 그다지 맘에 들지 않습니다. 사소한데서 불편합니다. 그 사람들이 한글을 잘 이해하는 사람들이 아니라 그런 가봐요.
답글삭제님프는 한국 사람이 한글을 입력하는데 있어 프로그램이 어떻게 해야 하는지 정말 잘 알고 만들었습니다. 예전엔 나비가 그런 면에서 좋았고 그리고 지금은 님프가 정말 맘에 듭니다. 나름 개발일 하면서 리눅스를 주력으로 쓰는데, 님프가 없으면 끔찍합니다.
ibus, fcitx 는 근본적으로 설계가 잘못되었습니다. 그래서 끝글자 버그가 나는 거고, 주 개발자가 외국인이다보니 신경을 잘 못 쓰는거고.. 만약 nimf 가 리눅스 기본 입력기로 설치되면 외국인들 똑같은 소리할 거에요 ㅎㅎㅎㅎ
삭제그런데 nimf 는 설계에만 6개월이 걸렸습니다. 뼈대, 기초공사가 잘 되어 있어서 기능 추가, 버그 패치 이런게 손쉽게 됩니다. 현재 풀 동기화 방식으로 작동하지만, 설계가 매우 잘 되어 있어서, 향후 구글 보이스 입력기가 필요하다면 그에 맞는 비동기 함수를 추가하기도 쉽습니다.
타 입력기는 DBUS 로 구현한 비동기 통신에 동기식 함수를 넣는 거는 소켓으로 하는 것보다 더 복잡한 방법입니다.
소켓 통신을 하면 코드도 간단하고 빠르고 가벼운데 도대체 왜 DBUS 로.. 그것도 비동기로 설계했는지 이해불가 입니다.
저는 정공법을 택했습니다. 책에 나온데로 소켓으로 IPC를 했고, 설계 초기에 동기화 통신으로 함수 콜하는 것과 디스패쳐 설계에 어려웠지만, 잘못된 걸 알면서 쉬운 길로 가려는 편법(DBUS, 비동기 통신)은 하지 않았습니다. 그 결과 ibus 구조에서는 한글 끝글자 버그를 고치는 것이 입력기를 새로 만드는 것보다 어렵게 되버려 10여년 동안 해결이 되지 않는 것이죠. nimf 애용에 감사드립니다.
답글삭제