computer

약 20분 전부터 뭔가 인터넷 대란 현상이 일어나고 있습니다.
한국에서 구글의 서비스들이 대부분 접속이 안 되기 시작하더니,
몇분 전부터는 미국과 영국에서도 구글에 접속이 안 되고 있군요.
그리고 국내 포탈들도 다들 백본이 가득차서 긴급하게 대책을
강구하고 있는 듯 합니다. 뭔가 타이머가 맞혀져 있던 웜의 대량
공격일까요. 아니면, 중국의 김치 사장들이 고용한? -_-;;
IRC에서 물어보니 다른 나라에서도 대체로 다들 같은 문제가 있는
듯 하니 중국에서 하는 건 아닌 것 같군요~ 무슨 문제인지 무지
궁금하당.. 으흐흐~ 곧 뭔가 뉴스가 뜨겠지요.. @.@

하여간.. 옆에 adsense가 안 떠서 화면이 멈춰 있는 문제 때문에
임시로 adsense를 꺼 뒀습니다. 삽질하고 있을 구글 시스템관리자들
화이팅! -O-

yser님의 다음 질문에 대한 답변입니다.

퍼키님이 내부에서 쓴다는 코딩 정책을 읽어 봤습니다.
퍼키님은 스페이스 신봉자이신 듯 한데, 처음 소스 짤 때부터 스페이스로 하셨나요? 저는 요즘 탭으로 하던 버릇을 소프트 탭=공백 치환으로 바꿔야 할까 고민 중입니다. kldp 의 논쟁이나 다른 데서 비교하는 걸 봐도 결국은 취향 문제 아닌가 하는데 장단점이야 다 있는지라 어느 하나가 절대적으로 우세하다고는 못하겠더군요.

답

제가 쓴 그 코딩 정책은 회사에서 쓰는 것이기 때문에, 개인적인 선호와 전혀 상관이 없는 것은 아니지만 그대로 반영하는 것은 아닙니다. 그리고 한 프로젝트에 대한 것이기 때문에 C 코드나 Win32 API를 쓰는 C++코드, 본셸 코드 같은 것은 명시하지 않았구요. 그냥 그런 것도 쓴 적이 있더라.. 정도로 보시면 되겠습니다.

들여쓰기를 할 때 탭을 쓰느냐 스페이스를 쓰느냐에 대한 제 의견은 “환경에 가장 맞는 것을 써야 한다”는 것입니다. POSIX 환경에서 주로 편집이 이뤄지고 셸에서 많은 작업이 있어야 하는 경우에는 당연히 탭의 크기는 8이기 때문에, 인덴트를 스페이스로 합니다. 주의하실 점은 탭 크기와 인덴트 크기는 의미가 다르다는 것입니다. 탭 크기는 ‘\t’ 아스키 문자의 화면 표시상의 크기를 뜻하는 것이고, 인덴트 크기는 들여쓰는 단위를 뜻하지요. 따라서, 8칸씩 띄어서 쓰기에는 너무 크기 때문에 보통 4칸 들여쓰기를 하기 위해서는 스페이스를 쓰는 방법 밖에 없습니다. ts=8 sts=4 noet 즉, 인덴트는 4칸으로 하면서 가급적이면 탭을 쓰기는 쓰는 방법도 영 안 쓰이는 방법은 아니지만, 이런 경우에는 정규식으로 소스코드 치환하기가 매우 까다로워지기 때문에, 가급적이면 탭 크기와 인덴트 크기가 다를 때는 스페이스로 풀어쓰는 것이 좋겠습니다.

반면에, 대부분의 사용자들이 쓰는 편집기가 탭 크기를 4로 쓰고 있는 MSVS같은 IDE를 기반으로 하는 환경에서는 탭이 4이고, 스마트 백스페이스같은 기능이 지원되지 않기 때문에 탭 1개로 들여쓰기를 하며 4칸으로 쓰는 것이 좋습니다. MSVS에서 물론 탭을 스페이스로 풀어쓰기를 지원하기는 하지만, 해당 설정이 프로젝트에 저장되는 게 아니라, 설치된 컴퓨터의 레지스트리에 저장되기 때문에, 해당 기능을 설정하지 않은 개발자들과 혼선이 빚어질 수도 있기 때문이죠.

그리고, 만약 자기가 새로 만든 프로젝트가 아니라, 기존에 있는 프로젝트에 참여하는 것이라면, 당연히 그 프로젝트에서 원래 쓰고 있는 스타일을 따라가는 것이 맞습니다. 명시적으로 프로젝트에서 쓰는 스타일을 문서화를 한 경우라면 가장 좋겠지만, 문서가 없더라도, 남의 소스를 고칠 때는 비슷한 다른 부분을 찾아서 누가 만든 것인지 구분이 안 갈 정도로 같은 스타일로 맞춰 주는 것이 좋습니다. 구분이 확연히 간다면, 해당 부분에서 나중에 문제가 발생하게 되면 다른 사람들은 그 코드가 자기 코드가 아니라는 생각이 먼저 들게되고, 그쪽 코드 문제가 아니더라도, 분노 게이지가 꽉 차서 결국은 버그는 안 잡고 버그 트래커에서 싸움질만 하게 되겠죠. 누구 코드인지 구분을 못 하게 돼버리면 모든 소스는 공동 재산과 같은 성격을 띄게 돼서, 너의 버그가 나의 버그이고 나의 버그도 너의 버그이고.. 이런 상태가 돼서, 모두가 생산적으로 일할 수 있게 됩니다. 🙂 (굳이 svn blame 같은 기능 써가면서 추적해서 욕하는 사람을 만나면 잘 기억해 뒀다가 다음에는 같이 프로젝트를 안 하도록 잘 피해 보세요.)

결론적으로, 제가 쓰는 스타일은 이렇습니다. (vim 명령어로..)

• C 코드 (POSIX): ts=8 sts=8 sw=8 noet
• C 코드 (Windows): ts=4 sts=4 sw=4 noet
• 파이썬 코드: ts=8 sts=4 sw=4 et
• 본셸 코드: ts=8 sts=2 sw=2 noet
• awk 코드: 들여써야 할 정도로 긴 코드는 안 짬. 🙂

토끼군과 퍼즐릿님의 활약으로 이제 국내에서도 꽤 뿌리를 내린
난해한 프로그래밍 언어계에 이제 마이크로소프트도 손을 내밀었습니다. 이름은 “요다”. 헬로월드는 이렇게 쓴다는 군요.

(args of string many are they) Main is what they seek yet return they do not.

Brace you must
     Written it is, the Console. “Hello World”

일반적인 오픈소스 프로젝트는 아무래도 여가시간에 자발적으로 참가하는만큼 프로젝트 진행 방향에 있어서 기업 프로젝트에서와 같이 “데드라인 엄수”, “최저 생산가”, “최고의 속도”, “가장 완벽한 인터페이스”가 아니라, 그저 “개발자의 재미”가 최고의 가치로 작용합니다. 완벽한 UI를 만들면 재미있는 개발자들은 완벽한 UI를 만들고, 표준을 완벽하게 엄수하는 것으로 재미를 느끼는 개발자들은 표준을 어기는 코드가 있으면 길이길이 날뛰면서 표준에 맞게 고쳐서 패치를 내겠지요. (토끼군처럼 남이 못 알아보도록 짜는 것에 재미를 느낄 수도 있고.. =3=3) 재미가 오픈소스 프로젝트의 가장 큰 요소인 것은 너무나 당연함에도 불구하고, 그동안 정부의 오픈소스 정책이나, 오픈소스를 추종하는 사용자들, 체계적인 체제를 갖추지 않은 오픈소스 프로젝트 들에서는 많이 간과되어 왔습니다.

최근 《재미와 소프트웨어 개발》이라는 논문이 나왔습니다. 이 논문에서는 주로 오픈소스 프로젝트들을 예를 들어서, 개발자들에게 개발의 재미를 주는 요소들과, 프로젝트 생산성, 창의성의 관계에 대해서 살펴보고 있습니다. 작업의 명료성, 재미, 충동, 주의, 집중 등이 프로젝트 결과에 영향을 주는 요소로 재미있게 분석되어 있습니다. 🙂

Haskell로 구현된 Perl6 프로젝트인 pugs 개발자가 쓴 O’Reilly 기사에서 얘기하고 있는 pugs의 -Ofun 성공 비결은 이렇게 요약하고 있습니다. (각 조건의 설명은 원문을 참조하세요.)

• -Ofun을 프로젝트 최우선 최적화 조건으로 삼아라.
• 현대적인 분산형 버전 컨트롤 시스템을 사용하라.
• 커밋이 허용되는 개발자들을 최대한 늘리고 커밋을 쉽게 하는 무정부주의를 지향하라.
• 빌드가 깨지거나 개발을 방해하는 데드락을 피하라.
• 커미터 권한을 많은 다양한 사람들에게 주어라.
• 돌아가는 코드가 아이디어보다 낫다.
• 끈끈하고 도움을 주는 개발자 커뮤니티를 만들자. (예: 신규 개발자들에게 멘터링을 해주는 방식)
• 흥미와 배움은 전염된다.

기업이 투자하는 것이 아니라면, 오픈소스 프로젝트가 성공하기 위해서는 리더들은 무엇이 개발자들에게 개발 동기를 유발하는가를 고려하여 그 점들을 자극할 수 있는 무언가를 충분히 재공해 줘야할 듯 합니다. 주변의 예만 보더라도, FreeBSD의 버그 트래킹 시스템인 GNATS는 웹에서 접근할 수 있는 개발자 리소스가 제한되어 있기에, 버그 트래킹 시스템에 접근하려면 ssh로 중앙 서버에 접속해야하고, 그 과정이 미미하지만 동기 요소를 떨어뜨리는 요소로 작용하게 마련입니다. 그래서 FreeBSD 버그 트래킹 시스템에서는 유난히 오래된 버그들이 많고 개발자들이 할당만 해놓고 거들떠보지도 않는 경우가 많습니다. 또한, 코드를 직접 커밋해서 다른 사람들이 리뷰할 수 있는 경우와, 최근 CVS로 업데이트한 다음에, diff를 떠서, 복잡하게 버그 트래킹 시스템에 올린 다음에, 커미터에게 리뷰를 받아서 다시 또 설명을 한 다음에 결국 한참 있다가 커밋되는 것과는 피드백의 시간에 있어서 동기 유발에 큰 차이를 보이겠지요.

그나저나, 저 오라일리 글의 “bus error” 표현은 아주 재미있군요. 이히히히~

Worse yet, a “bus error” (a key person being hit by a bus) may stall the project for good.

주변의 C모님이 서버가 상당수 뚫려서 복구하느라 고생하는 것을
옆에서 보고 있다가, 요새 sshd에 대한 공격이 굉장히 유행한다는
소리를 들었습니다.
그래서, 오픈룩 서버에서도 로그를 검사해 본 결과,

lucy(perky):/var/log% (cat auth.log && bzcat auth.log.*) | awk '{print $1" "$2}'|uniq -c|sort -r
3461 Sep 24
2794 Sep 25
2385 Sep 13
1604 Sep 18
1198 Sep 24
 936 Sep 13
 844 Sep 15
 667 Sep 16

요새 같은 IP에서 초 단위로 유저를 계속 바꿔가면서 자동으로 공격하는 경우가 많이 생기고 있습니다. 아무래도, 사용자를 계속 바꿔가면서 시도하는 걸로 봐서는, 사용자로 전환이 일어난 이후에 발생하는 버그를 노린 것이거나, 취약한 패스워드를 그냥 찔러 보는 것 같네요. 하여간, 뚫린 분의 말씀으로는, sshd가 honeypot 데몬으로 교체돼버리기 때문에, 사용자가 다음부터 접속하더라도 완전 바보짓을 하게 돼서 결국은 콘솔로 가서 뒤엎고 복구하는 수 밖에 없다고 합니다. 으흐흐..

공격이 하루에 수천건이 들어오니,
sshd 버전 최신 버전인가 꼭 확인하고, 사용자 패스워드 간단한 것 안 쓰는지 보고, 1111, 7777 같은 것 쓰는 사람들 계정은 다 정지시켜
버려서 괜히 고생하지 말도록 합시다~

K모 사이트에서 글을 읽다가 저자에게 당장 소스를 내놓지 않으면 오픈 소스가 아니라고 주장하는 글을 보고서는 상당히 무서워서 오픈소스와 크게 관련 없는 일반인들이 다들 오픈소스가 그런 줄 알 것 같아서, OSI의 오픈소스 정의에 따른 퀴즈를 하나 만들어 봤습니다. (잘못된 것이 있으면 알려주세요. 🙂

다음 중 (일반적으로) 오픈소스에서 금지되는 것은 무엇일까요? (답은 1개)

1. 오픈소스 소프트웨어 libxyz의 저작권을 갖고 있는 저자가 소스를 약간 고쳐서 회사 내부 프로그램에 넣은 다음 소스를 공개하지 않았다.
2. 굉장히 유용한 오픈소스 소프트웨어인 sleep을 누가 이름만 살짝 바꿔서 dontsleep이라고 릴리스 했는데, 소스 안은 실수로 안 바꿨는지 원래 라이선스가 들어있었다.
3. 일본의 어느 대학 연구소가 유전자 변형에 대한 극도의 알레르기가 있는 Eugene Dollison씨가 만든 오픈소스 소프트웨어 libmolly를 이용해서 획기적인 유전자 변형 연구를 해서 팝콘이 나는 옥수수 나무를 만들었다.
4. 오픈소스 소프트웨어인 prettyplot는 굉장히 아름다운 그래프를 그리기 위해서 대부분의 나라에서 특허로 등록된 기술을 사용하고 있어서, 저자가 README파일에 “이 프로그램을 진짜로 쓰려거든 특허는 별도 구매하시오”라고 써 놓았다.
5. 오픈소스 소프트웨어로 사이트를 만들어서 운영하고 있는데, 방문자가 오픈소스이니까 소스를 달라고 했는데 남자라서 기분이 나빠서 씹어버렸다.
6. 반국가 테러집단인 mujabi단이 오픈소스 OS와 컴파일러, 수학 라이브러리 등을 이용해서 정교한 대륙간미사일을 만들어서 미국을 공격했다.
7. 자바가 재배포를 제한한다는 점에서 썬에 반감을 갖고 있는 Mooney Lunar씨는 CLI 소프트웨어 하나를 오픈소스로 개발하면서 자바와 같이 배포하지 말라고 썼다.
8. 태양계 전체를 구글어쓰처럼 보여주는 대단한 오픈소스 소프트웨어가 나왔는데, 1980GB나 되면서도 느리디 느린 FTP로만 배포해서, 답답했던 사용자 한명이 Bittorrent로 자신의 배포 사이트를 구축해버렸다.
9. 외계인이 지구를 침공하려고 만든 우주선에 지구에서 개발된 오픈소스 소프트웨어를 몇 개 가져다가 사용하였다.
10. MS사를 매우 미워하는 개발자 Mike Row씨는 자기가 만든 오픈소스 소프트웨어를 MS에서 못 받아가게 웹서버에서 IP로 막아두고, 접근하면 웹에 “MS 메롱”이라고 표시하게 해 두었는데, MS에서 그 프로그램을 다른 경로로 둘러서 입수해서 사용하였다.
11. 화면에 오리가 돌아다니다가 마우스로 눌러주면 “꽥꽥!”하는 오픈소스 프로그램을 보고서는, 심혈을 기울여 소스를 분석해서 그 오리와 비슷하게 “꽥꽥!”하는 독점 소프트웨어를 만들어서 팔았다.

답을 보여주세요

(이 글은 public domain으로 저작권 표시 없이도 어떤 목적으로든 자유롭게 쓰실 수 있습니다.)