Go! Bbuwoo

Posted 2009/08/20 05:46

ㅎㅎ 정말 정말 무안하기 짝이 없군요. 2년전에 1.3 R2를 릴리즈 하면서 무안하다는 글을 올렸었는데 이젠 R5까지 나와 버렸습니다. :-)

1.3 R5는 kernel 보안 버그 fix하는 검해서 몇몇 드라이버들을 업데이트 하여 installer에 반영한 것이 다 입니다. 특별히 별 내용은 없고, 최신의 벤더 장비들을 지원하기 위함 입니다. (HP의 G6 시리즈들은 HP에서 더이상 2.4 driver를 지원하지 않아서 꽁수로 해 보았는데, 지원 여부는 저도 테스트를 못해봐서 확신이 없습니다.)

1.3 R5에 대한 자세한 내용은 http://annyung.oops.org/?m=update&p=1.3&t=1250715038&n=251 를 참고 하십시오.

어쨌든 안녕 1.x 는 본의 아니게 장수 하는 군요.

정말로 1.x 는 1.3 R5가 마지막 릴리즈 입니다. 정말로 더이상 추가 H/W 지원은 없을 예정이며, 보안버그 업데이트만 지원을 할 예정입니다.

더불어 2.0이 궁금하신 분들을 위하여 한마디 하자면, 언제 나오느냐? 저도 모릅니다. 다만 2.0 작업은 시작 되어서 현재 installer 수정 작업을 진행 중입니다. 빨리 하면 2-3개월 안에 작업이 마무리 가능할 듯 싶으나, 회사가 저를 놀리지 않는 관계로 좀 지연이 많이 되고 있습니다. 올 12월에 릴리즈 하는 것이 목표 입니다.

P.S.
1.3 R5의 code name은 Indongcho 입니다. 아실 분들은 아실 거라고 생각하고 의미는 적지 않겠습니다.

Posted by 김정균

Tag AnNyung, AnNyung LInux, 안녕 리눅스, 안녕리눅스

Response

You can track responses via RSS / ATOM feed

No Trackback
A comment

비밀방문자: 2009/08/21 00:35

Permalink

M/D

Reply

관리자만 볼 수 있는 댓글입니다.

Posted 2009/06/04 18:00

Filed under Tech/Tip & Trick

CVS 에서 주석에 "$Id: $" 와 같이 기록을 해 놓으면, commiter, revision, date 등의 정보가 자동으로 입력이 됩니다. 그래서 현재 내가 checkout 해 놓은 파일의 revision이 어떻게 되는지, 누가 commit 을 했는지 등의 정보를 알 수가 있는데 SVN에서는 어떻게 하는지 궁금했었는데, googling 을 하니 금방 나오는 군요.

home directory 의 ~/.subversion/config 파일에서 다음의 설정을 추가해 줍니다.

[miscellany]

enable-auto-props = yes



[auto-props]

*.java = svn:keywords=Author Date Id Revision;svn:eol-style=native

키워드의 리스트는 다음과 같습니다.

Author, Date, Header, Id, Log, Locker, Name, RCSFile, Revision, Source, State

이 설정을 마치면, commit 을 할 때 id tag 가 자동으로 갱신이 됩니다. 이미 repository에 추가 되어 있는 파일들의 tag 내용을 갱신 시키려면 다음과 같이 하시면 됩니다.

shell> svn up

shell> svn propset svn:keywords "Author Date Id Rev" file_name

shell> svn commit -m "Adding Id and Rev property to all files"

출처: http://ajmoore.blogspot.com/2007/12/enabling-cvs-id-tag-for-svn.html

Posted by 김정균

Tag Id tag, SVN, SVN Id tag

Response

You can track responses via RSS / ATOM feed

No Trackback
No Comment

Posted 2009/04/08 22:27

Filed under Tech/Mozilla

openweb 때문에 요즘 난리다. 어느분이 "가짜 개발자" 논쟁을 불러 일으키며 좀 시끄럽습니다. 그 중에 그 분이 하신 말씀 중에 L10n commiter 를 까는 내용이 좀 있습니다.

흔히들 오픈 소스 프로젝트에 참여한다고 하면 뭔가 대단한 일을 하는 줄 아는 경우가 많은데, 여러 가지 중에서도 번역이 가장 낮은 급의 작업이다. 일정 규모 이상의 오픈 소스 프로젝트들은 대개 기여도가 높고 권위를 인정받는 소수의 개발자들로 이루어진 핵심 그룹이 전반적인 개발 방향을 결정하며, 그 밑에 나머지 대다수 개발자들이 개인적으로 또는 팀을 이루어 개발에 참여한다. 그리고 사이트 관리자나 번역자들이 있어 개발외적인 분야에서 프로젝트에 참여한다. 여기서 중요한 것은 번역자는 개발자가 아니기 때문에 개발에 참여하지 못한다는 점이다. 개발에 참여하지 못하므로 프로젝트에 행사할 수 있는 영향력도 거의 없다(돈이라도 많아서 거액을 후원한다면 모를까). 따라서 개발자가 아니면서 프로젝트 내에서 뭔가 중요한 일을 하는 것처럼 말하는 사람은 한마디로 허풍쟁이다.

일단, 이 내용은 일부 이기 때문에 오해의 소지가 있으니, 심각하게 받아 들이지 마시고, 이 내용을 여기서 말하고자 함이 아니니, 가볍게 넘기시기 바랍니다.

어쨌든 이렇게 L10n 얘기가 나오면서 FF 번역은 윤석찬님 혼자 하고 있는 분위기로 흘러가더군요. 뭐 솔직히 많이 섭섭하더군요. 하긴 실제로 제가 이런일을 한다는 것을 아는 사람은 극소수고.. (심지어는 제가 다니는 회사에서 FF사용하시는 분도.. 제가 한 작업이라는 것을 아시는 분이.. 1분 뿐입니다. T.T)

그러다가 윤석찬님 블러그를 보다가 about:credits 내용이 나왔는데.. 저만 언급이 없더랍니다. 그래서 에이 설마.. 하고 봤는데.. 정말 저만 없습니다. 이거 더 많이 섭섭해 지더군요.

머 3.5 작업은 거의 하지 못했습니다. cvs 에서 mercurial 로 환경이 바뀌면서 적응을 못하고 있고 (mercurial 사용법을 적응 못하는 것이 아니라 번역을 진행하기 위한 시스템이 변경이 되었는데.. 이걸 적응 못하고 있습니다. --;) 또 작년말 부터 갑자기 회사에서 일을 많이 시켜서 손을 대지 못하고 있는 형편이라 왠지 석찬님께 좀 미안한 마음이 있었는데, about:credits를 보니.. 뭐 이제 그만해도 되겠다는 생각이 좀 드네요.

어쩌면 그만두기 위한 자기방어 및 핑계일까요 :-)

그래도 about:credits 에 저만 없다는 것은 충격입니다. T.T 아무래도 영어를 못해서 안끼워주나 봐요.

Posted by 김정균

Tag about:credits, Credits, Firefox, L10N, 번역

Response

You can track responses via RSS / ATOM feed

No Trackback
Comments2

kldstat: 2009/08/22 15:11

Permalink

M/D

Reply

저야 10년전 모질라에 패치 하나 낸 것 때문에 들어 있는데... 요즘에는 어떤 기준으로 들어가는지 모르겠네요. 번역자를 등록하는 정책인지 아닌지 잘 모르겠습니다.
까나리: 2009/05/13 16:17

Permalink

M/D

Reply

FF 사용자로서 애도를 표합니다. ㅋㅋ 힘내셔요~

Posted 2009/02/19 05:12

Filed under Tech/프로그래밍

문서의 Charset 을 detecting 하는 library 로는 IBM 이 지원하는 International Components for Unicode (ICU Project) 의 ICU library 와 Mozilla Browser 에서 이용하는 Universal Chardet library 가 있습니다.

ICU 의 경우에는 charset detect 가 포함된지 꽤 되었음에도 불구하고, php 5.3 부터 기본 포함되는 intl extension 에는 이 기능이 들어가지 않고 있습니다. 그 외에도 pecl 이나 pear 의 icu library 관련 패키지들에도 이상하게 이 부분만 들어가지 않고 있군요.

그리고 좀 더 안습인 것은, Mozilla 의 Universal Chardet 의 경우에는 C#, java, python, ruby (python chardet 을 porting 했음) 등등이 지원하고 있음에도 불구하고, PHP 나 별도의 c/c++ library 로는 제공되지 않고 있습니다.

Mozilla Universal Charset
Nchardet for C#
jchardet for Java
chardet for python
rchardet for ruby (python clone
Encode-Detect-1.01 > Encode::Detect::Detector for perl

mozilla code 에 c++ 로 지원하고 있으니 이걸 포팅하면 되겠지 하고 쉽게 생각을 했는데, xpcom 구조를 알기 전에는 쉽게 뗄 수 있을 놈이 아니더군요.

이렇듯 저렇듯.. 나오기만 2여년을 기다리다가.. 귀찮아서 mod_chardet 이라는 php extension 으로 하나 만들어 보고 말았습니다. 일단 mod_chardet 은 기본은 ICU library 의 Charset detect 기능을 이용하고, 옵션으로 python chardet 이 설치가 되어 있으면 Python C API를 이용하여 python chardet 을 사용할 수 있도록 설계를 했습니다. Mozilla Universal chardet 이 PHP 만 없다는 것도 좀 그렇다는 생각이 들었고..

일단, ICU 와 Universal Chardet 의 성능 비교도 해 볼겸해서 돌려 보았는데, 역시 ICU 보다는 Universal Chardet 이 detect 능력이 좋더군요. 그리고 ICU 에서 detect 할 수 있는 charset 보다 Universal chardet 이 좀 더 많이 지원하는 까닭도 있었고요.

일단, python chardet homepage 에 있는 자료가 오래된 까닭에 다음의 환경에서 해당 자료를 다시 분석해 보았습니다. 테스트 환경으로는 다음과 같습니다.

Python 2.5
Python Chardet 1.0.1
PHP 5.2.6
ICU library 4.0.1

Python Chardet result:
google.cn {'confidence': 0.98999999999999999, 'encoding': 'GB2312'}
yahoo.jp {'confidence': 0.98999999999999999, 'encoding': 'utf-8'}
amazon.co.jp {'confidence': 1, 'encoding': 'SHIFT_JIS'}
pravda.ru {'confidence': 0.93312187961594417, 'encoding': 'windows-1251'}
auction.co.kr {'confidence': 0.56471064895612277, 'encoding': 'ISO-8859-2'}
haaretz.co.il {'confidence': 0.98999999999999999, 'encoding': 'windows-1255'}
www.nectec.or.th {'confidence': 0.77645629965698426, 'encoding': 'TIS-620'}
feedparser.org {'confidence': 0.98999999999999999, 'encoding': 'utf-8'}

python-chardet 1.0.1 의 경우, 홈페이지 자료와는 약간 다른 결과가 나오더군요. 일단 python chardet homepage 의 정보가 변경이 되었을 수도 있고, chardet 이 업데이트 되면서 결과가 달라질 수도 있겠지만, 일단 이 결과에서 auction 이 예전에는 제대로 EUC-KR로 판단이 되었는데, 지금 환경에서는 다른 결과를 보여 주고 있습니다.

다음은 mod_chardet 의 결과 입니다.

PHP mod_chardet result:

google.cn (7121)
    ICU : Encoding -> GB18030 Confidence -> 100
    MOZ : Encoding -> GB2312 Confidence -> 98
yahoo.jp (30367)
    ICU : Encoding -> UTF-8 Confidence -> 100
    MOZ : Encoding -> utf-8 Confidence -> 98
amazon.co.jp (166082)
    ICU : Encoding -> Shift_JIS Confidence -> 100
    MOZ : Encoding -> SHIFT_JIS Confidence -> 100
pravda.ru (97826)
    ICU : Encoding -> ISO-8859-1 Confidence -> 28
    MOZ : Encoding -> windows-1251 Confidence -> 93
auction.co.kr (101330)
    ICU : Encoding -> EUC-KR Confidence -> 100
    MOZ : Encoding -> ISO-8859-2 Confidence -> 56
 haaretz.co.il (174179)
    ICU : Encoding -> ISO-8859-1 Confidence -> 32
    MOZ : Encoding -> windows-1255 Confidence -> 98
 www.nectec.or.th (41527)
    ICU : Encoding -> ISO-8859-1 Confidence -> 37
    MOZ : Encoding -> TIS-620 Confidence -> 77
 feedparser.org (28443)
    ICU : Encoding -> UTF-8 Confidence -> 100
    MOZ : Encoding -> utf-8 Confidence -> 98

 18.33 Sec

보시다 시피, CJK / UTF-8 / ASCII 를 제외한 다른 1byte 권의 언어들에 대해서는 Universal chardet 이 ICU chardet 보다 월등히 detecting 을 잘 하고 있습니다. 다만 안습인 것은, mod_charset 의 Universal chardet 이 Python C API 를 이용해서 python 을 호출하다 보니, ICU 보다 성능이 굉장히 많이 떨어집니다. 실제로 위의 결과를 Universal chadet 체크를 하지 않는다면, 대략 0.04초 정도에 결과가 나옵니디만, Universal chardet detecting 을 시키니 거의 20초 가까운 결과치가 나옵니다.

대략 테스트를 해 보니 문자열이 3K 정도가 넘어가면 Python C API 로 호출한 결과가 상당히 늦어지는 결과를 보이더군요. 대략 1K 이내의 경우에 어느정도 비슷한 속도가 나옵니다.

또한, 짧은 문자열에 대해서도 ICU 보다 Universal chardet 이 성능이 조금 더 좋더군요. 그래도 한글 기준으로 테스트를 했을 때, 한글 10글자 정도는 받아야지 왠만한 confidence 가 나오게 됩니다.

다음의 결과는 web page 에서 html code 를 삭제하고 나온 결과 입니다. 다음의 코드가 사용이 되었습니다.

$buf = preg_replace ('/<[^>]*>/', '', $buf);

보통 웹 페이지의 경우, <>로 쌓여져 있는 코드들은 대부분 ASCII 이기 때문에 확률적 판단을 하는 chardet 에 부정적인 영향을 줄것이라 생각을 하고 한번 시도를 해 보았습니다.

PHP mod_chardet result:

google.cn (2781)
    ICU : Encoding -> GB18030 Confidence -> 100
    MOZ : Encoding -> GB2312 Confidence -> 98
 yahoo.jp (3561)
    ICU : Encoding -> UTF-8 Confidence -> 100
    MOZ : Encoding -> utf-8 Confidence -> 98
 amazon.co.jp (30739)
    ICU : Encoding -> Shift_JIS Confidence -> 100
    MOZ : Encoding -> SHIFT_JIS Confidence -> 100
 pravda.ru (15728)
    ICU : Encoding -> windows-1251 Confidence -> 28
    MOZ : Encoding -> windows-1251 Confidence -> 94
 auction.co.kr (36084)
    ICU : Encoding -> EUC-KR Confidence -> 100
    MOZ : Encoding -> ISO-8859-2 Confidence -> 27
 haaretz.co.il (44570)
    ICU : Encoding -> ISO-8859-8-I Confidence -> 23
    MOZ : Encoding -> windows-1255 Confidence -> 98
 www.nectec.or.th (10425)
    ICU : Encoding -> EUC-JP Confidence -> 64
    MOZ : Encoding -> TIS-620 Confidence -> 76
 feedparser.org (5854)
    ICU : Encoding -> UTF-8 Confidence -> 100
    MOZ : Encoding -> utf-8 Confidence -> 98

 4.86 Sec

이렇게 detecting 을 하니 ICU의 결과가 조금 좋아졌으며 (하지만 오판하는 경우도 생겼군요), 텍스트 양이 줄면서 Python C API를 사용하는 Univiersal chardet 의 성능이 대략 5초 정도로 시간이 절약 되었습니다.

뭐 어쨌든 두가지 기능을 다 지원을 하고, PHP 에서도 Universal chardet 을 지원할 수 있다는 점에 일단은 만족을 하고, posting 과 함께 mod_chardet 을 공개합니다.

그리고 혹시나 단순히 euc-kr / utf-8 만 판단을 해야 한다면, chardet 은 overhead 일 경우가 많습니다. 이럴 경우에는 차라리 pear KSC5601에 있는 is_utf8 method 를 사용하시는 것이 훨씬 경제적/성능적 효과가 좋습니다. 물론 제가 만들어 놓은 것입니다 ^^;

코드는 http://cvs.oops.org/index.php?cvsroot=PHP-Module 에서 받으실 수 있으며, 소스 안의 test.php 를 참조 하시면 사용하시는데 별 무리는 없을 겁니다.

Posted by 김정균

Tag Chardet, ICU, ICU chardet, ICU Charset Detect, KSC-5601, KSC5601, mod_chardet, Mozilla Chardet, PHP Chardet, Python C API, python chardet, Universal Chardet

Response

You can track responses via RSS / ATOM feed

No Trackback
Comments14

상진군

2009/10/05 10:20

« 2021/01 »
일	월	화	수	목	금	토
					1	2
3	4	5	6	7	8	9
10	11	12	13	14	15	16
17	18	19	20	21	22	23
24	25	26	27	28	29	30
31