TechTV: FreeBSD v. Linux Shootout

그동안 FreeBSD 내부에서 준비가 많았던 TechTV에서의 Linux와의 생방송 대전이 끝났다고 합니다. 방송을 구체적으로 보지는 못했지만, 비교적 성공적이었다는군요. Murray Stokely와 같이 출연한 Matt Olander의 말에 따르면 FreeBSD 설치가 다 끝난 뒤에도 리눅스 측에서는 설치하는 데 35분이 남았다는 표시가 나왔다는.. 크크크 :)

이번 계기로 FreeBSD가 일반인에게도 많이 알려졌으면 좋겠네요. ~_~

방송 안내: http://www.techtv.com/screensavers/print/0,23102,3511343,00.html

(내용 중 FreeBSD 부분 번역)

FreeBSD는 관리하기 쉽고 뜯어고치기 쉽습니다.

FreeBSD는 리눅스를 포함한 대부분의 운영체제들 보다 훨씬 덜 제한적인 라이센스를 갖고 있습니다. 이것은 회사들이 자기 독점적인 수정을 가할 수 있으며, 공개하는 것이 강제적이지 않기 때문에 자기 저작권에 대한 권리를 누릴 수 있게 합니다. 그리고, FreeBSD는 포트 시스템으로 인해 시스템 관리자들에게 가장 관리하기 쉬운 시스템 중의 하나입니다. 포트는 명령 하나로 다운로드와 컴파일, 설치까지 한꺼번에 끝낼 수 있는 9000개의 써드파티 응용 프로그램을 제공해줍니다.

Matt Olander – Offmyserver CTO

FreeBSD는 성숙했고 프로페셔널합니다.

개발자로서, 나는 FreeBSD의 프로정신을 좋아합니다. FreeBSD 코드 베이스는 (리눅스에 비해) 보다 성숙해있으며 프로젝트과 관련한 프로페셔널한 소프트웨어 엔지니어링 문화를 갖고 있습니다. FreeBSD 개발자들 각각에게는 항상 정확하고 버그가 없는 높은 품질의 코드를 생산해내라는 시선의 압력(peer pressure)이 있습니다.

Murray Stokely – FreeBSD Project 릴리즈 엔지니어

오늘의 FreeBSD~*

와와 오늘의 늬우쓰~

  • 드디어 한다한다 하고 여태까지 안 하고 있었던 Java for FreeBSD가 공식적으로 발표되었습니다. 이제 Sun에서 공식적으로 인증받은 자바 플랫폼으로 1.3.1을 쓸 수 있게 되었습니다. 1.4 포팅 작업은 아직 좀 많이 남았기 때문에, 좀 더 기둘려야겠네용. 흐흐. 코드 명이 JRE가 Latte Diablo, JDK가 Caffe Diablo … -O- [WWW]FreeBSD Foundation 웹페이지에서 받을 수 있습니다. (포트 엔트리는 [FreshPort]java/diablo-jre13 [FreshPort]java/diablo-jdk13 입니다.)

  • 4.9 코드 프리즈 시작: 9월 중에 릴리즈될 4.9를 위해 오늘부터 코드 프리즈가 시작되었습니다. 지금부터 -STABLE 트리에 커밋되는 내용은 전부 릴리즈 엔지니어의 허락을 받은 주로 치명적인 보안 패치들입니다. 그래서 지금 -STABLE을 업데이트하시면 이제 4.9-PRERELEASE로.. 흐흐;; 포트 프리즈는 9월 첫째주에 있을 예정입니다. 포트 프리즈 전에 꼭 고쳐야 될 것이 있으면 지금 즉시 알려주세요~ :)

  • sendmail 보안버그: 보안버그의 대명사(–;;) sendmail에서 또 버그가 발표됐습니다. 이번 버그는 DNS 맵을 처리할 때 라운드로빈 테이블을 초기화하지 않아서 쓰레기값을 통해 외부 공격이 유입될 수 있다는 것 같군요. 4.6, 4.7, 4.8, -STABLE, 5.0, 5.1, -CURRENT 트리에 지금 고쳐져 있습니다. 참고: http://www.sendmail.org/dnsmap1.html

msdosfs utf-8 성공!

으히히.. 순전히 mp3를 들으려고 시작한 작업인 msdosfs 유니코드 지원 작업.. 중간에 2 나누기를 안 해서 한참 커널 패닉을 만나서 고생하긴 했지만, 크게 어렵지 않게 성공했습니다! 짠짠~~

프프프.. 주로 Apple쪽의 소스를 그냥 갖다 붙이기를 했기 때문에, 사실 뭐 만든거라고는 함수 2개 밖에 없지만.. ;; 이제 libiconv로 utf-8을 떼내고 msdosfs가 iconv를 쓰도록 한 뒤에, PR을 보내려고 합니다. :)

FreeBSD Dynamic Root

엊그제 블로그에서 언급되었듯이, 예전부터 논의되어 왔던 Dynamic Root가 이제 커밋되었습니다. 흐흐 근데 디폴트는 아니기 때문에 WITH_DYNAMICROOT=yes 를 /etc/make.conf를 넣고 make world를 해주면 Dynamic World로 갑니다. 흐흐 그런데 주의할 점이.. 그냥 마구 했다가는 인스톨하는 도중에 cp나 install같은 바이너리가 동적으로 바뀌어버려서 인스톨이 뻑나면서 시스템 쫑나는 -_- 문제가 생기니까, 최근에 /rescue 생기기 전에 make world하신 분들은 반드시 /usr/src/rescue가서 make install을 먼저 해 주고나서 make installworld를 해야합니당. 에.. 혹시나 벌써 rescue 인스톨하기 전에 installworld해서 이미 쫑난 상태다 싶으신 분들은, 다음 명령으로 우선 응급 처치해 놓으면 그 rescue를 make install할 수 있을 정도로는 됩니다.

예. 이렇게 해서 Dynamic Root를 만들고 나면 이제 다음과 같이 /bin에 있는 것들이 동적으로 나옵니다.

Dynamic Root가 도입되었을 때의 장/단점은..

  • 장점

    • 디스크 용량을 조금 먹는다: 원래 /bin /sbin은 크런치 바이너리가 아니므로 따로따로 static 바이너리라서 엄청나게 먹었습니다. 그런데, 이제 동적 라이브러리로 링크됐기 때문에, libc부분이 공유돼서 줄어들었고, /rescue의 바이너리들도 전부 크런치된 바이너리 라서, 디스크 용량을 전체적으로 훨씬 적게 먹습니다. NO_RESCUE=yes 하면 더 줄일 수 있지만 요것만은 하지 맙시다 =3 =33

    • 플러그인 형태의 공유 라이브러리를 쉽게 쓸 수 있다: nss(dns 캐쉬), pam(Pluggable Authentication Module) 같은 플러그인 형태의 모듈들을 쉽게 쓸 수 있게 됩니다. 그동안 pam같은 경우에는 /bin/login 같은 곳에서 쓸라면 아주 힘들었는데, 이제 pam을 붙일 수 있는 형태로 만들 수 있으니 만세입니당.

    • 휴지통이나 libfsxlat같은 라이브러리를 쓸 수 있다: LD_PRELOAD 흑마법을 기반으로 한 시스템콜 가로채기 라이브러리인 trashcan이나 libfsxlat같은 것들을 이제 /bin /sbin에 있는 녀석들 한테도 쓸 수 있겠죠.

  • 단점

    • 업글 잘못하면 클난다: 리눅스 사용해 보신 분들은 몇 번 겪으셨겠지만, Dynamic Root는 업글 잘못하면 난리가 나서.. 아주 고생을… 그래서 FreeBSD에서는 /rescue에 원래 /bin과 /sbin에 있던 바이너리 전체를 크런치해서 넣어두었습니다.

    • 실행 속도가 느려진다: 공유 라이브러리들을 쓰면 프로그램이 뜰 때마다 리로케이션하느라 힘들어져서, 뜨는 속도가 제법 느려지고, PIC(Position-Independent Code) 생성때문에 최적화에서 불리해져서, 또한 별로 좋은 효과가 들어가지는 않습니다.

흐물~ 뭐.. 5.2에서 너무 많이 바뀌고 있는 것 같아서 좀 불안하긴 하지만, NetBSD도 그랬듯, 뭐 좀 지나면 괜찮아 지겠죠 -ㅁ-;

오늘의 포트질~*

오늘은 엊그제 얘기했던 [FreshPorts]korean/gdick 을 포트에 집어넣었습니다. 흐물.. 이제 프비에서도 쉽게 사전을!

그 외에 잡다구리 주인 없는 포트들 파이썬 버젼 올라가면서 깨진 것들을 고쳤습니다. (자꾸 고치라고 메일 보내서 -.-)

  • [FreshPorts]graphics/py-opengl : tk8.4 지원이 안 들어가 있어서 tk8.3용으로 되어있는 헤더를 이름 바꿔서 써버림. -.-;

  • [FreshPorts]devel/fnorb: Makefile.pre.in에서 @DEFS@ 를 빼야 제대로 컴파일되는 문제.

  • [FreshPorts]biology/pymol: fnorb랑 같은 문제

  • [FreshPorts]devel/pybibliographer: fnorb랑 같은 문제

  • [FreshPorts]math/scigraphica: exec 안에 네스티드 스코프성 변수를 써버리는 바람에 2.3에서는 신택스 에러나서, eval로 바꿔버림.

뿡뿡 =3

오늘의 FreeBSD~!

<에헴>오늘의 간추린 FreeBSD 소식을 말씀드리겠습니다.</에헴> -;;

  • 며칠 전 포트에 dns와 polish 카테고리가 생기고, xfce4 가상 카테고리가 생겼습니다.

  • 드디어 /bin, /sbin을 동적 컴파일을 하는 DYNAMICROOT가 Gordon Tetlow의 작업으로 커밋되었습니다. WITH_DYNAMICROOT=yes를 make.conf에 넣고 make world하면 되는데, 요건 할 얘기는 많지만 내일의 블로그 거리를 남겨두기 위해 자세한 것은 내일;;; _-_

  • 오는 8월 24일 4.9 릴리즈를 위한 -STABLE 트리 Freeze에 들어갑니다. (9월말에 릴리즈 예정)

  • Colin Percival의 새로운 프로젝트로 binup 프로젝트가 교체되었습니다. 그동안 BSDi가 넘어간 이후에 중단되어 있었는데, 이제 앞으로는 혹시나 새로운 Colin의 프로젝트가 성공한다면, 보안성 있고, 빠르고, 적은 대역폭을 사용하는 바이너리 업데이터를 가질 수 있게 될 것입니다. :)

그리고.. 곁다리로 Python 소식 하나… Python 2.3.1이 9월 두째주 쯤에 릴리즈될 예정입니다. 이번 버전의 릴리즈 짜르(Czar)은 마침 9월 첫째주에 휴가인 py2exe와 ctypes로 유명한 Thomas Heller가 맡는 다는군요. 기대가 됩니다.! :D

msdosfs fun

요즘 윈도우 파티션에 들어있는 mp3들을 우찌 잘 들어볼 방법이 없을까. 이런 저런 고민을 하다가, msdosfs.ko를 libiconv.ko를 쓰게 하는 게 아무래도 구조상 무리라서 (현재 libiconv.ko는 CES가 제대로 지원될 수 없는 구조..) msdosfs.ko에 직접 UTF-8패치를 해보려고 시도를 해 봤습니다.

그래서, 이런 저런 닭짓끝에, 기본적인 인코딩/디코딩은 성공했는데.. 두둥.. 웬걸~ 글자가 앞쪽만 잘려서 나오는 겁니다. 으흐.. 이게 무슨 일이냐 해서 보니.. UTF-8 시퀀스가 유니코드 글자 개수만큼 바이트로 잘려서 나오는… 그러니까.. ‘한글’이라는 파일 이름은 ‘\xed\x95\x9c\xea\xb8\x80’ 인데, 이게 앞에 2바이트만 잘려서 ‘\xed\x95’가 되는 것.. 왜 그런지 여러모로 뒤져보니.. 이런! msdosfs.ko가 글자 길이를 그냥 원래 유니코드 시퀀스 길이로 계산해버리는.. 그러니, 사실상 256:256 컨버트가 가능한 ISO-8859 쓰는 녀석들만 msdosfs를 정상적으로 쓸 수 있다는.. 그런 구조로 되어있던 것이었습니다.

그래서, 제대로 계산하게 좀 패치를 했는데(좀 미심쩍은 부분이 있긴 했지만..), 또 웬걸~ 좀 파일 이름만 길어지면 또 뒤가 잘리는.. 그 문제는 이번에는 또 윈도우의 파일 시스템 구조 특성상 13글자 단위로 뒤에서부터 엔트리가 시작돼서.. 긴 파일 이름이 여러 슬롯으로 나뉜다는 것입니다. 그러니.. 결국 파일 이름이 좀 길어지면 13글자 단위로 쪼개서 뒷 블럭부터 변환이 일어나서.. 가변폭 인코딩인 UTF-8로서는 도저히 길이 계산을 할 방법이 없어진다는… 도식적으로 그려보자면 “1234567890123에헤라디여바람분다창문닫아라” 라는 파일이 있다면

  • ATTR_WIN95 엔트리: ‘라’를 들고 있고 WIN_CNT가 2

  • ATTR_WIN95 엔트리: ‘에헤라디여바람분다창문닫아’를 이름으로 들고 있고 WIN_CNT가 1

  • ATTR_WIN95 엔트리: ‘1234567890123’을 이름으로 들고 있고 WIN_CNT가 0

  • 일반 파일 엔트리: ‘123456~1 123’을 이름으로 들고 있음. (짧은 이름이 123456~1.123이 됨)

이렇게 돼서.. 순서대로 파싱하려면 맨 끝에있는 ‘라’가 먼저 나와버리기 때문에, 현재 msdosfs.ko처럼 ATTR_WIN95 엔트리를 처리하면서 변환까지 같이 하는 구조에서는 가변폭 인코딩을 처리할 방법이 전혀 없습니다. 그래서 궁리를 좀 해보니, WIN95 길이의 최대길이인 256글자를 스택에 들고 있으면서 거기에 버퍼링을 해 뒀다가 그걸 한꺼번에 전체를 인코딩하는 방법 밖에는 없겠다 싶었습니다. 그래서 좀 찾아보니.. 으허허 역시 Apple Darwin에서는 벌써 그런 방법으로 고쳐놓았더군요. 그래서 결국은 FreeBSD의 win2unixfn 함수가 없어지고 getunicodefn이 msdosfs_conv에 들어가서, msdosfs_vnops에서는 win2unixfn으로 일일이 엔트리마다 변환해서 dp->d_name에 직접 쓰는 것이 아니라, getunicodefn으로 각 엔트리별 유니코드 스트링을 스택에 버퍼한 다음에 그걸 사용하는 것으로 되어있었습니다. 그런데, Darwin은 원래 파일시스템이 유니코드 기반이라 변환이 필요없지만, FreeBSD는 8bit byte sequence형태이므로 변환할 필요가 있기 때문에 Darwin것 그대로 수용은 불가능했지만, 그래도 뭔가 좀 빌려 쓰면 될 것 같네요.

음.. 그래서.. 결론은? 에.. 며칠 삽질 더 해야겠다는.. 크크;;

이렇게 하고 나면 뭐 거의 libiconv.ko에도 바로 붙을 수 있는 수준 –;;;;;

ko_KR.CP949 등록!

“쀍”과 “햏”같은 글자를 쓰기 위한, 필요악 인코딩인 CP949(CodePage 949)를 기반으로 한 한국어 인코딩이 FreeBSD에 추가되었습니다. (이 블로그는 UTF-8을 쓰기 때문에 그렇게 나쁜 편은 아닙니다 히히~)

그냥 터미날같은 데서 적당한 프로그램들을 쓰면, 이제 확장완성형 글자들도 특별히 깨져서 나오지는 않을 것입니다. 완전하지 못한 점이 하나 있다면, 아직 FreeBSD가 multibyte collation을 지원하지 않아서 collation에 대한 고려가 전혀 되어있지 않다보니, 한글 정렬이 제대로 안 될 것입니다.

그리고, screen에서는 원래 한국어를 쓸 수 있는 인코딩이 euc-kr과 UTF-8밖에 없어서, CP949패치를 따로 해서 넣으려고 하고 있습니다.

[WWW]CVSWEB

ktrace(1)를 이용한 자동 plist 생성

포트를 만들거나 업글할 때 가장 귀찮은 과정 중의 하나인 plist를 자동으로 만드는 방법은 [WWW]mtree기반으로 된 것이 있었지만, 뭔가 다른 프리픽스로 한 번 깔아보는 게 대략 귀찮은 관계로.. [FreeBSDMan]ktrace 를 이용한 방법을 한 번 생각해 봤습니다. 흐흐흐.. open 시스템 콜을 모두 추적해서 O_WRONLY나 O_CREAT로 열린 녀석들 목록을 자동으로 plist로 만들어주는 것인데, 대충 만들어 본 소스는..

흐흐.. 그런데, 대충 만들고 나서 보니, 속도가 너무 느리고 (좀만 대형 포트로 가면 엄청난 양의 kdump가 나와버려서 그것 파싱하는데 십분이 넘게 걸립니다 –;) mtree기반의 녀석에게 특별한 장점이 없다는 결론이.. 흐흐흐… (그리고, 위 구현에서는 디렉토리를 인스톨 도중에 mv 해 버린다던지 하는 것에 대해서 무방비 –;)

그래서, 이 녀석을 좀 변모시켜서 plistlint 정도의 이름으로 인스톨하면서 plist에 없는 프로그램 건드리지는 않나, 빼먹은 파일 없나, /tmp에 이상한 파일 남기지 않나 등등을 검사하는 걸로 만들어 볼 까 합니당. 크크

4-STABLE의 PAE 지원

FreeBSD의 물리적 주소 범위를 4GB이상으로 넓히는 Jake Burkholder의 PAE 옵션이 Luoqi Chen의 포팅 작업으로 4.x에 성공적으로 포팅돼서 그동안 많은 테스트가 있었는데, 이제 이번 주 금요일에 PAE가 4에 임포트가 된다고 합니다. PAE를 사용하는 드라이버같은 것들이 따로 아직 많은 편은 아니기 때문에 직접적인 영향은 없으리라 생각되지만, 그래도 안정적인 시스템 운용이 필요한 분들은 다음 주까지는 좀 미루시는 것이 좋겠군요. :)

PAE가 들어오면 이제 FreeBSD 4에서도 4GB이상의 메모리를 쓸 수 있고, 2테라 이상의 단일 스토리지를 쓸 수 있게 됩니다. :) 그리고, 이것을 포함한 다음 릴리즈는 9월 예정인 FreeBSD 4.9! ~.~