(1) Compiz, Beryl 그리고 오픈소스 방법론

inureyes의 이미지

며칠전 compiz-quinnstorm을 진행시켜오던 compiz.net 커뮤니티에서 정식으로 beryl이란 이름으로 compiz를 fork하였다. 사실 지난 2월의 우분투 포럼에서 운영진의 전폭적인 지지 하에 세를 키워가던 시절부터 개발에 관련하여 이런저런 심상찮은 기운이 오갔었다. 관련해서는 다양한 이야기가 메일링 리스트나 포럼을 통하여 전개되고 있으니 생략.

iXce는 호의적인 fork라고 이야기를 하지만, 속사정을 들여다보면 꼭 그렇지는 않다. compiz를 처음 내놓고 david가 자신의 코드를 마음에 안 들어해서 기초공사부터 다시 시작을 하려고 했던 반면, quinn은 공개되는 코드를 바탕으로 다양한 플러그인부터 시작하여 패치들이 붙여진 패키지를 만들었다. 어느 쪽이 올바른 방향이라고 단정할 수는 없다. 하지만 확실한 것은 두 개발 주체간의 xglx와 compiz에 대한 기본적인 철학이 너무 달랐다는 (X 상에서 compiz가 차지해야 하는 레이어에 대한 의견마저도) 점이다. 사실 이제서야 forking된 것이 이상할 정도로 두 개발의 방향은 달랐다.

재미있게도, forking을 둘러싸고 일어나는 논쟁의 일단에 오픈소스 방법론을 둘러싼 이야기가 있다. compiz에 대한 논의가 이루어져야 하는 곳은 compiz 메일링 리스트임에도 compiz.net 포럼의 영향으로 대부분의 논의가 그 곳에서 이루어지고 있다거나, david에게 전달되는 패치의 내용이 전부 quinnstorm 을 기준으로 이루어지고 있어 소스코드를 원점에서 다시 개편하는 입장에서 도저히 merging할 수 없다거나 하는 등등의 이야기들이다. 오픈소스 프로그램의 원제작자와는 별도로 커뮤니티가 형성되고, 그 커뮤니티와 제작자와의 커뮤니케이션이 사라지면 어떻게 될까? 또는 커뮤니티 자체의 철학이 생겨 원제작자와 상이한 방향을 보게 된다면 어떻게 되는가? beryl은 이러한 의문에 대한 실례를 잘 보여주고 있다. (덧붙여, 사람간의 커뮤니케이션이 집단화된 방향을 형성해 나가는 과정을 지켜보는 과정은 굉장히 흥미롭다.)

이제 compiz 0.2에서 fork한 beryl과, compiz-git에서 이어질 compiz 트리는 계속 다른 방향을 바라보고 나갈 것이다. 어느쪽이 최종적인 승자가 되어 quartz와 aero glass와의 일전을 벌이게 될 지는 모르겠다. 확실한 대답은 그들 각자의 철학을 바탕으로 한 코드들이 해 줄 것이다. :)

p.s.) 이러한 쓰레드가 있다. 포럼이 메일링 리스트를 대체할 수 있는 오픈소스의 커뮤니케이션 수단이 될 수 있는가? 심리적 장벽의 제거와 피드백 스피드를 생각해 보았을 때 긍정적인 생각을 가지고 있다. 동시에, '심리적 장벽의 제거'의 단점 때문에 메일링 리스트로서만 가능한 영역이 아직 있다는 것도 느끼고 있는 중이다.

댓글

hey의 이미지

진입장벽 때문에 오히려 커뮤니티가 정화되는 측면도 있죠. PC 통신 시절의 비공개 소모임이나, 위키가 대중화 되기 전의 노스모크도 그랬고요.

May the F/OSS be with you..



----------------------------
May the F/OSS be with you..


feanor의 이미지

저는 여러가지 이유로 메일링리스트를 포럼보다 선호하는데, 1. 메일링리스트는 메일박스로 날아오지만 포럼은 가서 봐야 하고 (RSS가 있긴 합니다만 지원이 들죽날죽입니다) 2. 메일은 제가 원하는 인터페이스에서 어디에서나 볼 수 있지만 포럼은 포럼 프로그램의 제약을 받으며 3. 가입을 해야 하는 경우 수많은 웹 포럼의 ID와 비밀번호를 도무지 기억할 수 없습니다.

그리고 어찌 보면 당연한 일이지만 아직 메일링리스트쪽이 인프라 면에서 여러 모로 우수합니다. 예를 들어 일반적인 웹 포럼에서 한 달 동안 어느 게시판에 올라온 글을 모두 다운받아 오프라인에서 보려면 어떻게 해야 하나요? 일반적인 메일링리스트라면 mbox 포맷으로 아카이브가 있기 마련입니다.

inureyes의 이미지

참여율 자체를 보면 포럼과 메일링리스트는 비교가 안됩니다. 그리고 웬만한 곳은 가입하지 않아도 글을 다 읽을 수 있지요. 포럼에 비한 메일링의 장점으로는 약한 듯. 요새같은 경우 오프라인에서의 유리함도 그다지 특별하지 않습니다^^

혹시 KLDP 10주년 컨퍼런스 시작 이전에 휴게실에서 뵈신 분 아니신가요? 먼 길 떠나 일찍 도착해서 반쯤 졸면서 맥북프로 켜고 앉아 있었던 옆사람입니다. :)

'Everything looks different on the other side.' -Ian Malcomm

keizie의 이미지

좀 짧아서 감질납니다. -_-;

atie의 이미지

compiz나 beryl 둘 중의 하나가 리눅스쪽의 경쟁자가 될 것이라는 이야기는 아직 이르다고 봅니다. 아직 사용자는 못 본 Glucose가 있죠. zrusin이 몇 달전에 KDE쪽의 composite을 왜 발전 안시키냐고 했을 때 KDE4의 웹코어 작업이 바빠서라는 블로그를 쓴 적이 있었지만, 최근 블로그를 보면 qt4 툴킷 레벨에서 OpenGL 가속 관련 작업을 하는 것을 알 수 있습니다. 그 작업의 결과가 KDE4 어플리케이션에 예제로 적용될 때쯤이면 현재의 compiz나 beryl 이야기는 또다른 이야기가 될 수 있습니다. 그리고, 같은 내용의 작업을 범 gtk쪽 관점에서 하려고 하는 macslow의 agora 프로젝트도 아직 결과는 없지만 리서치 중이라는 이야기도 있고요.

작업의 내용은 벡터 렌더링을 OpenGL 가속으로 하는 것과 컴포넌트를 평면에 그리는 것 외에 동적으로도 조절하는 있는 엔진을 결합해서 툴킷 레벨에서 제공해야 한다는 것으로 요약되는 것 같습니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

keizie의 이미지

http://www.k-3d.org/gtkglext/Main_Page

꽤 예전부터 저런 게 있었던 거 같은데, 어떤 게 다른가요?

그리고 cairo를 기반으로 하는 현재 상황에서는 굳이 OpenGL의 백엔드를 다시 만들 필요가 없는 것 아닌가요?

atie의 이미지

제게 묻는 것은 아니시죠? ^^;; zrusin은 cairo가 좋기는 한데... 하면서 KDE에서는 뭘 새로 만들어야지 하는 글을 본 적이 있습니다. QT 때문일 것이라 추측합니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

ganadist의 이미지

gtkglext는 gdk/gtk에서 glx컨텍스트를 쉽게 다루기 위한 것입니다.

툴킷자체에 OpenGL가속 기능이 포함되는 것이 아니라 툴킷 위에서 OpenGL을 이용해 뭔가를 새로 그릴 때 사용되는 것입니다.

그리고 현재 gdk/gtk에서 cairo는 xlib(/xrender) 백엔드만 사용되고 있습니다. 그리고 gdkx의 Drawing Primitives 는 아직 직접 xlib으로 구현되어 있습니다.(과거api와 호환성을 위해서라고 생각됩니다.)

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

atie의 이미지

오늘자 zrusin 블로그에는 화면의 관점변환을 OpenGL call없이 qt의 새 api로만 하는 예제그림을 올렸군요.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

sangu의 이미지

atie wrote:

compiz나 beryl 둘 중의 하나가 리눅스쪽의 경쟁자가 될 것이라는 이야기는 아직 이르다고 봅니다. 아직 사용자는 못 본 Glucose가 있죠.

Zack Rusin씨가 xorg 메일링 리스트에 올린 메일을 보면 Compiz나 Beryl와 같은 WindowManager가 아니군요.
메일 : Glucose

Quote:

Q: It is what?
A: Acceleration architecture. Nothing more, nothing less.
[...]
Q: Why not XGL?
A: We already have a server. One that works rather well. With AIGLX all this
server is lacking is a nice way of accelerating common rendering primitives.
Glucose is that bridge. Between AIGLX and Glucose we have the complete
solution. Furthermore my plan is to provide a smooth transition for apps that
would like to mix Xrender with GL, with Glucose it's a rather simple thing to
do.

sangu의 이미지

David Reveman씨가 쓴beryl 포크에 대한 메일을 보면 지금까지 알려진 포크를 하게된 여러 기술적 이유들은 사실과 다르고 Quinn Storm씨와 대화한 결과로는 오해한 것이라고 합니다.

atie의 이미지

이 건에 대한 노벨 오디오을 들어보면 David의 포크에 대한 상황 인식은 매우 제한적이라는 것을 느낍니다. 예를 들어 베릴의 사용자 편의성을 위한 소스 코드의 존재는 아예 모르고 있다는 생각이 드는군요. 그렇지만 포크의 주된 이유는 역시 compiz core의 개발 주도권이 누구에게 있느냐가 문제였던 것 같습니다.

두번 들었어도 그놈을 "놈"이라고 하긴 하는군요. 어쩔 수 없는 미국 발음... ;;
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

bigpooh의 이미지

compiz 와 beryl 이 많이 쓰이는게 아니라 metacity 가 많이 쓰일것 같은데요.
기본으로 포함되는 aiglx + metacity 가 그놈 2.18 을 통해 완성 될거라 예측해 봅니다.

sangu의 이미지

bigpooh wrote:

compiz 와 beryl 이 많이 쓰이는게 아니라 metacity 가 많이 쓰일것 같은데요.
기본으로 포함되는 aiglx + metacity 가 그놈 2.18 을 통해 완성 될거라 예측해 봅니다.

현재도 metacity에 gl compositor 기능이 있습니다. 그런데 아직 까지
compiz/Beryl의 plugin을 통해서 제공하는 눈요기 꺼리에 비해서 심하게
떨어지고 metacity에 gl compositor기능을 개발하던 개발자(Fedora
/Redhat 해커)가 현재는 Compiz쪽에 관심을 두고 있더군요.

그리고 Fedora 같은 경우는 곧 발표될 Fedora Core 6에서 Compiz을 기본
OpenGL compositing manager로 사용합니다.

그리고 Compiz도 gnome-window-decorator를 통해서 그놈에서 좀 더 매끄
럽게 사용될 것 같습니다. Fedora rawhide에 Compiz는 아직까지
Metacity 테마를 사용못하지만 git 개발버전에서는 사용 할수 있는 것으로
알고 있습니다.

참고 : Metacity Compositor

atie의 이미지

metacity는 아닌 듯 합니다. 이 메일을 보시죠.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

atie의 이미지

오늘자 zrusin의 블로그에 드디어(?) 불을 지피는 글이 올랐군요. Qt vs Cairo... 역시 초점은 OpenGL 백엔드인 듯 싶습니다. 액면 그대로 글을 믿으면 1년 후에는 지금의 compiz/beryl과는 비교할 수 없이 빠른 composite 데탑이 나온다는 이야기인데... 아쉽게도 테스트는 stencil 버퍼를 쓰는 그래픽카드로 해서 그 때쯤이면 저도 새 랩탑을 하나 사야할 듯 합니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

khris의 이미지

Beryl은 gnome 의존적이지 않습니다. 차후 메이저 릴리즈에서도 DBUS 의존성마저 벗어던질거라는 '비공식 로드맵'이 존재하고요...

KDE를 쓰는 저로써는 Beryl을 계속 이용하게 되지 싶습니다. compiz-git는 어떤가요?

───────────────────────
pacman -S gothick elegant
S-Conscious :: http://ncity.net/~chrishsk/khris/weblog/

───────────────────────
yaourt -S gothick elegant
khris'log

keizie의 이미지

KDE가 이것저것 잘 해놓긴 했습니다만, dbus 정도면 중립적인 거 아닌가요?

마잇의 이미지

KDE4부터는 dcop대신 dbus를 쓴다 합니다.
dcop의 인터페이스가 간단하게 쓰기 좋았는데 dbus도 그런식으로 가능한지 모르겠네요.

--
마잇


--
마잇

atie의 이미지

http://lists.beryl-project.org/pipermail/beryl-dev/

베릴 포럼에서 티격태격하면서 천천히 자리잡아가고 있습니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

atie의 이미지

베릴 1차 로드맵

우분투에서는 beryl과 compiz를 놓고 feisty에 기본 포함되는 창 관리자로 저울질 중이라고 하지만, 어쩐지 업스트림 프로젝트가 배포판의 일정에 맞춰지는 묘한 현상이 생기는군요.

그렇지만 로드맵의 내용은 정확히 현재의 베릴의 문제들을 짚고 있습니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

inureyes의 이미지

우분투 포럼에서 compiz.net이 갈라져 나오고, 이제 beryl-project로 변모해 가는 것을 보면서 beryl에 우분투 사용자층이 굉장히 많을 것은 예측할 수 있는 일이었습니다^^ 출생 때문인지 확실히 우분투 배포판의 스케쥴과 경향성이 비슷하네요 :)

로드맵 자체는 흠잡을 곳이 없네요. 단지 지금의 개발 역량이 스케쥴링을 따라갈 수 있을지는 지켜봐야 하겠습니다.

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

atie의 이미지

제가 그 동안 특정 프로젝트를 이렇게 가깝게 관찰한 적이 없어서인지는 몰라도 베릴 프로젝트는 재미있게 보고 있습니다. 요즘은 compiz.net 초기의 1기라고 할 수 있는 개발자들보다는 2기라고 할 수 있는 현재의 개발자들의 커밋이 주를 이루고 있고 개발자들도 배워가면서 진행이 되는 프로젝트라는 생각도 듭니다. 로드맵의 내용은 5개월 간에 진행이 될 0.2.0을 위한 아이템이라는 생각이고, 별 무리없이 완수될 것으로 저는 봅니다.

벌써부터 궁금한 것은 우분투에 한 달 후면 베타를 벗는 Looking Glass 3D도 Feisty를 겨냥해서 패키지로 들어가게 되면, 베릴 0.3.0(?)을 위한 두 프로젝트의 시너지 효과가 무엇일까 하는 것입니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

ganadist의 이미지

오 LG3D가 벌써 1.0까지 온건가요?

0.4때 몇번 구경하다가 그냥 치웠는데. 함 깔아봐야 겠네요.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

ganadist의 이미지

compiz의 로드맵도 발표되었습니다.

----
데스크탑 프로그래머를 꿈꾸는 임베디드 삽질러

atie의 이미지

그동안 사실상 혼자서 Compiz와의 merge에 머뭇거리던 Beryl의 Quinn이 병합을 하자고 메일링에 본인의 의사를 밝힘으로서 Beryl 프로젝트는 6개월간의 별거 생활을 마치게 될 듯 합니다.

초기의 포럼에서 사용자들의 요청을 적극 반영하던 compiz-quinn의 모습은 꽤 오래전에 온데간데 없어져서 사실상 포럼 중심의 개발은 중단된 지가 오래되었고, trac에 쌓여가는 버그들을 주기적으로 처리하려는 개발자들의 노력도 부족하는 등 최근 한 두달간의 베릴 프로젝트는 0.2.0을 내놓는 것이 꽤 힘든 상태라고 보았습니다.

하지만, Compiz와의 병합은 베릴 프로젝트 내부적으로 Compiz core에 상당하는 기술적 비전을 이끌만한 역량이 없었다는 것이 가장 큰 이유인 듯 싶습니다. 또는 가장 많은 커밋을 하던 플러그인 개발자들이 Compiz core 하나에 두 커뮤니티로 나눠져서 시간을 소비할 이유 (즉, 낭비할 프로그래머 리소스가) 없다고 판단을 하였기에 대다수의 베릴 개발자들이 Compiz와의 병합을 찬성을 하는 편이었습니다.

Beryl측에서 바라는 대로 제 3의 새로운 이름이 될런지 모르겠지만 Beryl과 Compiz는 이제 또다른 이야기의 전개를 위한 시작에 섰습니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

inureyes의 이미지

초기부터 지금까지 쭉 지켜본 입장에서 느껴지는 시사점이 크군요.

언제 한 번 생각을 정리해 볼 기회를 만들어야 겠습니다.

-----
'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

sangu의 이미지

compiz 메인테이너인 David Reveman이 베릴의 코드를 받아 들이냐 겠죠. beryl 에서 자 병합이다라고 해서 해결될 문제는 아닌것 같네요. 예를 들자면 blur plugin(compiz 0.4.0 추가될 예정)같은 경우도 davidr이 beryl코드를 이용하기 보다는 다시 작성했으니까요. 아마 그러한 경우가 많이 발생 할 것 같습니다.

참고 : http://lists.freedesktop.org/archives/compiz/2007-February/001413.html

Quote:

Beryl situation
1. Temporary solutions and workarounds.

Beryl includes temporary solutions and workarounds that paper over
issues in the overall infrastructure. I've been very unwilling to
include such things in compiz as I believe that it hurts the open source
desktop as it hides the real issues and I don't want to do that for my
own projects benefit. Helping other projects by fixing issues where they
should be fixed is how we make the open source desktop unbeatable.
Temporary solutions can be maintained outside the official tree or in
branches for those who need them.

atie의 이미지

Sangu님 이야기처럼 베릴 플러그인들을 Compiz 쪽에서 대거 수용할 가능성은 희박할 듯 합니다. compiz-core에 들어가는 플러그인들과 compiz-extra로 나눠진 플러그인들이 있는 것처럼 베릴의 플러그인들은 사실상 후자에 합쳐지는 것으로 가닥이 잡힐 듯 싶습니다. 그 밖에도 compiz 커뮤니티에서 시작한 screenlets 등도 소스 저장소를 가져야 할 필요도 있고... 관건은 이전의 활력을 찾는 하나의 커뮤니티로 다시 돌아갈 지가 사용자에게는 앞으로 와닿는 문제이겠지요.

어제 노벨 데모에 4개의 다른 배경화면에 각각의 바탕 아이콘 배치를 다르게 한 것을 보면 꼭 용도가 폐기가 된다고 해도 그 간의 실험적인 것들, 예를 들어 wallpaper 플러그인, BDM 등이 쓸모가 없었다고 이야기 할 수는 없겠지요. 마찬가지로 inputzoom, thumbnail 플러그인을 재 작성한다고 해도 그것들이 유용한 아이디어라는 것을 증명은 한 셈이고요. 베릴은 이 점에서는 아직도 필요한 이유였고, 앞으로도 compiz 트리에 4명 이상이 커밋을 한다는 것에 반해 compiz-extra가 있는 이유라 생각을 합니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

atie의 이미지

compiz 포럼과 Beryl 포럼을 하나로 합치기로 한다니 우선은 큰 결정을 순조롭게 한 듯 합니다.
http://lists.freedesktop.org/archives/compiz/2007-April/001809.html

임시 이름이기는 하지만, "Composite Community"로 하는 것에는 꼭 compiz-core의 플러그인에 한정하지 않고 그 이상의 것도 개발하고 참여를 유도하는 의미를 담고 있다고 예상합니다.
----
I paint objects as I think them, not as I see them.
Ubuntu Edgy user / Ubuntu KoreanTeam

----
I paint objects as I think them, not as I see them.
atie's minipage

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.