freebsd

py-freebsd 0.9 릴리스

by

지난 2주 정도 출퇴근길 지하철에서 작업한(4호선 만세!) 결과물인 py-freebsd 0.9를 릴리스했습니다. 역시나 아직도 프비 포트가 프리즈 중이기 때문에 포트는 올리지 못했고 그냥 타볼만 올렸네요. =.=;

py-freebsd는 원래 2002년 5월에 그냥 잠시 장난으로 만들어 본 것인데, 파이썬에서 기본적으로 제공되지 않은 FreeBSD 시스템/커널 함수들을 접근하기 위한 모듈입니다. 그동안은 별로 쓰는 사람도 없고.. 저도 그냥 잊고 있었는데, 요새 FreeBSD에서 베이스에 스크립트 언어를 넣자는 토론도 진지하게 올라오고 해서, 점점 파이썬이 인기를 얻고 있는 듯해서 슬그머니.. 다시 업그레이드를 했습니다. 흐흣. 원래는 0.2였지만, 이번에는 1.0을 대비해서 0.9로 바로 올렸습니다.

이번 버전에서는 예전에 벼르고 있었던 기능 2가지를 중점적으로 작업했습니다. 바로 kqueue와 sysctl입니다. kqueue의 경우에는 기존에 devel/py-kqueue에 Doug White가 만들어 놓은 것이 있었지만, 상당히 오래 전에 만들어져서 오랫동안 관리되지 않은 바람에, 현대 파이썬 스타일과는 많이 다르고, kqueue의 막강 기능 중 하나인 udata를 사용하기가 어려운 점이 있었던 것을 개선해서 포함시켰습니다.

그리고, sysctl은 귀찮게 시스템 명령어를 셸 호출해서 쓰던걸 이제 간단하게 데이터 타입 깔끔하게 직접 호출할 수 있도록 만들었습니다. 🙂

으흐흐~ 사실 업그레이드 작업을 처음 시작했을 때에는 pyrex로 하려고 거의 대부분 함수를 pyrex로 다시 썼는데, 아무래도 작업의 특성 상 C 코드나 pyrex 코드나 결국은 1:1 대응이 될 정도로 비슷한데, 사실 pyrex 자체의 제약사항도 있고해서 오히려 C로 그냥 줄줄이 풀어 쓰는게 더 편한 곳이 제법 있어서, 고심 끝에 그냥 일일이 C로 쓰는 것으로 작업을 해버렸습니다. ;; pyrex가 생각보다는 용도가 제한이 많이 되는 것 같네요.. 간단한 래핑이라고 해도 ctypes가 있고.. 복잡한 메모리 할당이나 구조체 작업이 일어나는 것들은 C만큼이나 복잡하고.. 으흐~ 뭐 어쩔 수 없네용;

프리즈가 풀리면 바로 업그레이드! FreeBSD 사용하시는 분들은 FreeBSD FTP에서 미리 받아서 한번 테스트해 주세요. 🙂 4.7이상, 2.3이상을 지원합니다.

py-freebsd, pyrex로 이사~

by

파이썬을 위한 FreeBSD 플랫폼 라이브러리/커널 인터페이스 바인딩인 py-freebsd을 그동안 버려두고 있었다가, 최근에 쓰겠다는 사람이 나타나서 좀 버전업을 해 볼까 해 보고 있습니다. 흐흐 (그동안은 쓰는 사람이 없어서 –;) 몇 년전까지만 해도 별로 신경을 안 썼던 퇴행 검사(regression test) 코드들을 요새는 뭔가 새로 추가하거나 변경만 하면 넣는 분위기가 되어서, 몇몇 개발자들이 인터페이스 테스트 코드를 작성하기는 해야하는데, C로 일일이 스크립팅하려니 귀찮기가 짝이 없어서 파이썬으로 작성할까 생각해보고 있다고 합니다. 🙂

py-freebsd는 원래 완전 쌩노가다 코드로 직접 다 작성되어 있었는데, 제공하는 함수가 30개를 넘고, 상수 200개 정도에 이제 업그레이드하면서 cd(4)나 cam(4)같은 것들을 C 확장 타입으로 만들려고 하니까 이런 중복 작업으로 점철된 노가다 작업에 회의감이 느껴져서 친도가 안 나갔었습니다. 그 뒤로 벌써 거의 3년이 지났는데, 예전에 사람들이 좋다고 칭찬하던 pyrex가 생각나서, “그래 한번 도전해 보는거야!”

우선, py-freebsd에서 가장 간단한 함수인 getosreldate(3)를 해 봤는데. 오우. 단 몇 줄에 되는군요! (다른 데서 봤지만 직접 해보니 새로운 감동이;;;;)

흐흐 물론 SWIG에 비하면 복잡한 방법이기는 하지만, 별도의 파이썬측 모듈을 만들지 않고도 섬세한 리턴값 제어나 입력값 가공이 가능하다는 점은 아주 감동적이라, 아직까지 pyrex로 안 바꾼 것이 참 후회가 되는군요 흐흐.. 그래서 py-freebsd에서 제공하고 있는 대부분의 함수들을 순조롭게 pyrex용으로 바꾸어서 거의 원래 노력형(;;) C 소스에 비해 20%정도의 양으로 줄어버렸습니다~ 🙂

pyrex가 실제 활용하고 있는 사람들에게서 피드백을 많이 받아서 진짜로 필요한 것에 대한 대처가 많은지 의외로 뭔가 하려고 딱 마음을 먹었을 때 막히는 게 없었는데, 꼽아보자면 이런 것들이 있었습니다.

  • C스타일 include가 제공된다: 사실 별 것은 아니지만.. 아무래도 FreeBSD C 라이브러리는 네임스페이스가 그냥 평면 구조이기 때문에, 모듈 안에 여러 단계를 나누기가 애매해서, 하나의 C 모듈 안에 모두 들어가는 것이 좋았는데, C 스타일 include를 제공해 줘서, 소스 길이를 적당히 유지하면서도 대형 모듈을 만들 수 있었습니다.
  • 트릭이 매뉴얼에 언급이 돼 있다;; 예를 들면 플랫폼에 따라서 크기가 일정하지 않은 자료형으로 되어있는 정수형 매크로를 다루기 위해서, cdef extern int를 from header 블럭 안에 써버리면, 사실 타입은 신경 안 쓰기 때문에, 별 문제 없이 넘어간다는 팁 같은 것이 아예 매뉴얼에 써 있어서, pyrex에서 제공해 주는 것만으로는 해결하기가 쉽지 않은 상황들을 어렵지 않게 편법을 이용해서 빠져나갈 수 있었습니다;; py-freebsd에서도 함수로 cdef extern해놓고서는 중간에 C 헤더 파일을 하나 include 해버려서 거기서 매크로로 선언하는 트릭을 하나.. 🙂
  • 사소한 난감함에 대한 배려: FreeBSD의 statfs시스템콜은 struct statfs를 사용하기도 하고, 구현해야하는 파이썬측 함수 이름도 statfs이다보니, 삼중으로 네임 스페이스가 충돌하는데, 이런 경우에 대한 대처가 되어 있었고, 음청나게 많은 enum같은 다른 부분에서도 뭔가 난감하다 싶으면 어렵지 않게 문서에서 해결책을 찾을 수가 있었습니다.
  • 널널하고 친숙한 문법: C 문법과 파이썬 문법을 절묘하게 섞어놔서, 매뉴얼을 안 보고도 대충 이렇게 쓰면 되겠지 하고 쓰면 다 되는게 참 신기할 정도로 잘 만들어 뒀군요. 🙂

한편, py-freebsd의 고유 특징인 것 같기도 하지만, 다른 곳에서도 쓰일 법한 것들인데 고려가 되지 않아서 불편한 것도 제법 있었습니다.

  • 그때 그때 다른 struct 멤버: OS 버전이 올라가면서 빠진 멤버나 버전이 올라가면서 생긴 멤버 같은 것들을 처리해 주기 위해서 C에서의 전처리자로 뽑아주는 것이 뭔가 필요한데, 이런 것을 하기 위한 방법이 딱히 없어서, setup.py에서 struct 정의를 한번 훑어서 그 결과를 pyrex에서 include하는 방식으로 일단은 해결했습니다. –;
  • 엄청나게 많은 상수를 간단하게 정의하기: 커널 API 함수들이다 보니, 특성상 정수형 상수가 엄청나게 많은데, 이런 것도 또 OS 버전에 따라 있기도 하고 없기도 하고, 게다가 그냥 정의하기에는 상수 1개를 정의하기 위해서 3줄씩 써줘야 하기 때문에, 상수 목록을 만들기도 힘들고 관리하기도 힘든 단점이 있어서, 이것도 결국은 간단하게 함수 호출하는 형식으로 pyrex 소스에 적어두면 setup.py에서 컴파일 전에 소스를 스캔해서, 실제 헤더 파일에 있는지 확인해서 있는 것만 cdef extern을 별도의 파일에 넣어서 include하는 방법으로 해결했습니다.. 아주 찝찝하네요 흐~;;
  • 워닝이 너무 많아~: 어차피 generate한 소스이니까 워닝이 좀 나더라도 크게 문제가 되는 것은 없지만.. 그래도 워닝이 너무 많이 나서 참 컴파일하고 있기가 불안하다는 문제는 존재합니다. –;;;;;

몇가지 사소한 난점은 있긴 했지만, 그래도 전반적으로 바꾸고 보니 유지보수도 쉬울 것 같고, 앞으로 새로운 기능을 추가하는 것도 재미있을 것 같아서 굉장히 보람이 있습니다. 🙂 pyrex 좋아!

뽀샤시 NetBSD 컵

by

NetBSD Cup

dakiller6님께서 BSDForum에서 제작하신 컵을 하나 선물 받았습니다. 예쁘네요. ^^ 아주 튼튼해서 한번은 떨어뜨려도 안 깨질 것 같은 데 엄청난 포장에 쌓여서 와서 놀랐습니다. 감사합니다. 🙂

전~~에 FreeBSD Mall에서 샀던 FreeBSD 스테인리스 머그컵은 이제 설거지하다가 다 벗겨져서 원래 FreeBSD 컵인지도 모르게 돼 버렸는데, FreeBSD 새 로고가 나오면 새로운 컵을 하나~~ (-O-)

FreeBSD 베이스에 NLS 지원 등장

by

오늘 드디어 FreeBSD에도
NLS 지원이 들어왔습니다.

리눅스에서 프로그램이 세그폴트 먹으면 “프로그램이 죽었습니다.” 뭐 이런 식으로 나와서 섬뜩하게 만드는데, 이제 FreeBSD에서도 이런 식으로 메시지를 보여줄 수 있는 프레임웍이 갖춰져서, 한국어 번역만 넣으면 strerror에 대한 한국어 메시지를 보여줄 수 있게 되었군요. 🙂 물론 libc외에 일반 프로그램들도 이제 libc에 지원이 들어갔으니 별로 어렵지 않게 한국어 NLS 지원을 넣을 수 있지 않을까 합니다. 그런데, 들어오고 나서 잠시 또 NLS를 뺀 경우에 빌드가 안 되고 뭐 그런 문제가 있어서 임시로 다시 NLS가 빌드에서는 빠졌는데 해결이 되면 곧 들어오겠지요~

이제 FreeBSD 6부터는 “명령 또는 파일이 없습니다.” 에러 메시지를 볼 수 있겠군요. 크크 (자자 번역합시다~ -ㅇ-)

파이썬 curses 툴킷 — Urwid

by

얼마 전에 trac을 깔고 돌아다니다가 trac 홈페이지에서[WWW]urwid라는 파이썬 기반의 curses 툴킷이 나온 것을 알게 되었습니다.:)

curses, slang 바인딩이 있기는 하지만, 그렇게 많이 쓰이고 있지 않고 혹시 쓰일 일이 있더라도 보통은 파이썬에서는 pebrot 처럼 그냥 만들어서 쓰고 그랬었지요. 아무래도 slang이나 curses 바인딩은 파이써닉하게 만들기가 힘들어서였을까요. 이제는 pebrot같은 curses 프로그램을 쉽게 파이썬스러운 코드로 만들 수 있게 되었군요 +_+

0412-urwid.jpg

게다가 한글도 잘 됩니다!. 많은 curses 기반 프로그램들에서 속썩이고 있는 입력창에서의 한글 커서 이동 문제나 입력하는 문제도 모두 해결된 듯이 보입니다. 게다가 예제 소스들을 보면 아주 다들 그냥 간단하게 각 위젯을 인스턴스 목록에만 넣어주면 표시해주고 그래서 curses 생짜 프로그래밍하고는 완전히 달라지는군요. newt안에 들어있는 snack 모듈처럼 생뚱망뚱한 클래스라서 클래스 해제 순서만 바뀌어도 죽거나 그러지도 않구요~

이걸로 간단한 관리 콘솔 프로그램 아주 좋을 것 같습니다. 이히히. dselect같은 UI를 가진 포트 관리툴이나 한번 만들어볼까 생각도 –;

ko_KR.eucKR에서의 Vim 커서 이동 문제

by

올해 초 언젠가 부터 5에서 vim의 커서가 한글 위에서 제대로 안 움직이고, 신택스 하이라이트도 제대로 동작하지 않고 있습니다. 저는 그냥 이것 저것 해 보다가, LC_CTYPE=C로 하면 되는 것을 발견해서 우선 셸 스크립트로 감싸서 쓰고 있었지만.. 얼마전 코드 페스트에서 최준호님도 같은 문제에 고심하고 계신 것을 알고, 같이 옆에서 좀 뒤져 보았더니, 일본 사람들도 같은 문제가 있고 이미 여러가지 해결 방법을 찾고 있었던 것을 찾을 수 있었습니다.

자세히 읽어본 결과, FreeBSD의[FreeBSDMan]mblen함수는 EINVAL (incomplete multibyte sequence)를 발생시킬 때 이전에 들어온 글자를 저장하는 방식으로 되어 있습니다. 즉,[FreeBSDMan]iconv에서 커서를 안 넣은 상태 처럼 다음 바이트를 넣어 주면 진행을 할 수 있는 방법으로 구현되어 있는 상황입니다. 그러나 반면, 리눅스의 구현은 EINVAL이 리턴되는 상황이면 state도 변환되지 않고, 다음 바이트를 입력하는 상태가 아니라 이전 바이트와 다음 바이트를 묶어서 한꺼번에 날려야 하는 구현으로 되어 있습니다. 그런데, vim은 리눅스의 구현을 기준으로 그냥 mblen에 있는 state를 따로 생각하지 않고 항상 1바이트씩 mblen을 하도록 되어 있어서, FreeBSD에서는 state가 계속 왔다갔다 해서 생긴 문제이군용.

이 문제에 대해서, POSIX의[WWW]mblen에 대한 정의는 아무리 곱씹어 읽어보아도, EINVAL을 리턴하는 상황에서 state를 저장해야 할 지 아니면 그냥 무시해야할 지는 해석이 어렵군요. 우흑흑.

일단 이 vim문제를 해결하기 위한 여러가지 방법을 나열해 보자면,

  • FreeBSD mblen함수를 EINVAL을 리턴할 때 state를 저장하지 않도록 한다. (lib/libc/locale/euc.c 의 mbrtowc에서 return -2 위의 state 저장부분 삭제)

  • vim의 mbyte.c에서 mblen으로 다음 글자 계산하는 부분에서 mblen 들어가기 전에 항상 state를 초기화 해준다.

  • vim의 mbyte.c에서 mblen을 읽을 때 항상 MB_CUR_MAX 길이로 줘서, 최대한 길이를 계산할 수 있도록 한다.

각각의 방법 중 하나만 적용해도 되기는 하지만.. 나름대로 다 장단점이 있고, 표준에 완전히 맞는 것이 어느 것인지 매우 혼란스럽군요 -.-;; 그래서 생각한 다른 방법은..

  • vim에 utf-8처럼 euc 인코딩 루틴을 집어 넣어서 mblen 안 쓰게 한다.

흐.. -o- 고치는 방법은 다들 간단한데.. 어느 것이 제대로 된 것인지 알 수가 없어서… (아이고)

FreeSBIE 1.1 릴리스

by

FreeBSD를 기반으로 한 라이브CD 배포본인[WWW]FreeSBIE가 1.1을 릴리스했습니다. 이번 FreeSBIE 1.1은 FreeBSD 5.3을 기반으로 했으며, XFCE와 fluxbox를 지원합니다. 그리고 다른 라이브씨디들과 마찬가지로 이번 1.1부터는 인스톨러를 지원하기 시작했습니다. 그래서 총 4가지 방법을 지원하게 되었습니다.

  • tcsh 셸을 띄움

  • fluxbox를 띄움

  • xfce를 띄움 (불여우와 천둥새를 포함)

  • BSD Installer(dragonfly의 인스톨러입니다.)를 띄움

일단 다운로드! 이번 버전의 용량은 596MB인데, ftp 미러가 상당히 많지만 사실 ftp로는 받을 필요는 별로 없고[WWW]torrent 파일을 제공해 줍니다.[FreshPorts]net/py-bittorrent등의 bittorrent 클라이언트를 깔고 다운로드를 하면 되는데, 저는 350KB/s정도 속도로 꾸준히 받아지더군요. +_+ 역시 차세대 배포 미디어로의 bittorrent는 정말 최상입니다 만세!:)

우선, FreeSBIE로 부팅하면 인상적인것이 splashscreen_bmp.ko를 로딩하는 것이 부팅 과정 중의 상당수를 차지한다는 것인데, 꾸준히 기다려 보면 멋있는 BMP 화면보호기가 나옵니다. –; (역시 라이브 씨디는 뽀대..) 그리고 요즘 논란이 되고 있는 부트로더의 비스티가 컬러로 나옵니다. 므흐흐~

0412-freesbie-urwid.png

부트로더 이후의 화면은 일상적인 FreeBSD 부팅 화면과 매우 비슷하고, 그 다음에 이렇게 자동으로 네트워크 세팅과 하드웨어 드라이브 로드 부분이 나옵니다. 그 다음에는 키보드 맵 선택이 나오고 그 다음에 뭘로 띄울 것인지 물어보는 화면이 나옵니다.

여기서 xfce를 선택하면 상당히 미려해진 xfce를 볼 수 있는데, 기본 세팅이라 테마를 좀 조절했는지 전에 보던 xfce보다 좀 더 예쁘더군요. 흐흐:)

전체 보기

0412-freesbie-xfce.jpg

멋있어요♡ 이제 멋진 GUI 인스톨러만 나오면 되겠어요. 흐흐:)

BSD사용자라면 하나쯤은 꼭 구워두고 키보드 밑에 숨겨둬야할 필수품!

FreeBSD 소원 목록

by

거의 4년동안 개발브랜치였던 5가 이제 스테이블로 갔기에, 이제 슬슬 새로운 소원들이 나오기 시작했습니다. FreeBSD 5의 릴리스 엔지니어인 Scott Long이 앞으로 1년간 FreeBSD 6나 7에 새로 들어왔으면 하는 기능의 목록을 올렸는데 역시나 반응이 뜨겁습니다. +_+ 요즘 내부 개발자 메일링에서는 부트 화면에서 데몬을 없애야 종교적인 거부감을 갖고 있는 사람에게 나쁜 감정을 안 줄 수 있다고 투표도 하고 막 싸우고 있는데.. 그에 비해서 생산적인 토론 같군요.. 흐흐

원래 Scott Long의 의견과 다른 사람들의 80개 정도 되는 답변의 양상을 대충 요약해 보면,

  • 키보드 멀티플렉서: 현재 FreeBSD에서는 동시에 키보드를 1개밖에 쓸 수 없습니다. 따라서, PS/2 키보드를 기본으로 커널에서 설정해 놓았으면 USB키보드는 원격에서 kbdcontrol로 바꿔주지 않으면 못쓰는 난감한 일이 있는데, 키보드 멀티플렉서를 넣어서 여러개의 키보드를 동시에 쓸 수 있도록 하자는 의견입니다. 이 의견에 대해서는 역시나 또 multi-kiosk 환경을 위해서 그냥 여러개를 따로따로 쓸 수도 있게도 해야한다는 답변도 있고.. 이미 들어와 있는데 완성이 안 돼있다는 얘기도 있고.. NetBSD의 wscons를 훔쳐오자는 사람도 있군요. 흐흐. 어떻게 되던 키보드 멀티플렉서는 정말 꼭 있어야 할 기능일 듯 합니다 -o-;

  • 새로운 인스톨러: FreeBSD 인스톨러인 sysinstall은 93년에 처음 나왔을 당시 선풍적인 인기를 끌어, 다른 대부분의 오픈소스 배포본들에게 강한 영향을 주었지만, 현재로써는 FreeBSD 인스톨러의 확장이 어려운 구조나 10년여 쌓인 문제들 때문에, 싹 새로 안 만들고서는 해결되기 어려운 국제화 문제 같은 것들이 난감합니다.

    DragonFlyBSD에서는 1.0부터 새로운 인스톨러를 선보이고 있습니다. 이 인스톨러에서는 sysinstall과 비슷한 curses기반의 환경과, 인스톨러가 웹서버를 띄워서 CGI로 원격의 웹 브라우저에서 설치를 하는 방법을 제공하고 있는데, 많은 사람들이 이에 감동하고 있군요..:)

    여기에 대한 다른 사람들의 의견은 역시나 sysinstall이 최고다 더 뜯어 고치지 마라 이런 말도 있고,DragonFlyBSD의 인스톨러도 국제화 지원 안 하기는 마찬가지 아니냐는 의견도 있고, X 기반의 쌔끈한 GUI 인스톨러도 있으면 좋겠다는 의견도 있습니다. 흐흐;

    아예 인스톨러는 anaconda처럼 스크립트 언어 기반으로 작성되어야 다양한 환경에 맞춰서 쉽게 인스톨러를 고칠 수 있지 않을까 싶군요.

  • PCI Express 지원: FreeBSD는 자체 PCI Express 지원이 아직 없어서 PCI-X 카드를 끼우더라도 호환성 모드로만 동작하게 됩니다. 따라서, 기가비트 네트워크 같은 것에서 많은 불이익을 당할 수가 있는데, Scott는 PCI-X지원을 다음 릴리스에서 꼭 넣었으면 하는 듯 합니다.

  • 저널링 파일 시스템: 그동안 BSD동네에서는 우리도 저널링 하자! 하는 사람들에 대해서 softupdate를 개선하면 저널링 충분히 따라 잡을 수 있다는 사람들에게 완전히 압도돼서 저널링 얘기도 못 꺼내고, JFS, XFS 등으로 포팅한다고 선언한 사람들은 몇년이 지나도 소식도 없고 ReiserFS만 근근히 최근에 나왔죠. Scott은 UFS에 저널링을 넣던지, 아니면 GPL이 아닌 다른 저널링 파일시스템들을 찾아봐서 넣었으면 좋겠다라고 합니다.

  • 클러스터 파일 시스템: 최근에RedHat이 대표적인 SAN업체인 Sistina를 합병하면서 GFS를 다시 오픈소스로 풀었는데, 이런 종류의 소스들을 참조해서 FreeBSD 자체에 클러스터 파일 시스템을 넣자고 하고 있습니다. 이게 들어가게되면 아무래도 야후같은 대형 호스팅 업체들에서 호스팅할 컨텐트들을 일일이 동기화하거나 NFS같은 구리구리한 파일 시스템에서 서비스할 필요가 없어지고, SAN 장비에도 FreeBSD가 본격적으로 도입되겠지용.

    Kris는 맨날 패키지 빌드해서 다른데로 옮겨댕기기 귀찮다. 클러스터 파일 시스템이 지원되면 패키지 빌더들을 모두 묶어버리면 진짜 좋겠다 이런 의견을 올렸고, 다른 사람들은 OpenAFS가 이미 충분히 좋은데 다른 것을 굳이 또 만들 필요가 있겠느냐라고 주장하지만, Garrett은 AFS는 클러스터링에 적합한 컨커런시 모델이 아니라 그냥 분산을 해 줄 뿐이라고 그러는군요.

  • CAM 보완, iSCSI 지원 추가: 현재의 CAM은 너무 parallel-SCSI에 치중되어 있어서, parallel-SCSI에나 통하는 코드들이 CAM에 몰아 들어가 있어서 다른 서브레이어의 버스들이 상대적으로 더러운 방법을 쓰고 있다고 합니다. 그래서, CAM을 좀 중립적이고 깔끔한 소스로 개선하고, iSCSI지원을 별도로 추가하면 좋겠다고 합니다.

Scott의 희망사항들에 덧붙여서 Poul-Henning도 몇가지를 더 올렸는데 이런 것들이 있습니다.

  • 온라인/오프라인 미디어에 더 많은 글을: FreeBSD와 관련된 글을 보다 많은 미디어에 게제해서 좀 더 뜬것처럼 보이자! 이런 .. 흐흐;

  • 학교에서 FreeBSD로 많은 것을: 현재 대부분의 대학 OS 수업은 Linux와 Windows의 구조를 기반으로 되어있습니다. 좀 더 많은 수업에 FreeBSD를 쓸 수 있게 하고, OS와는 큰 관계가 없는 과학/수학 연산 분야에서도 FreeBSD를 많이 쓰도록 하면 좋겠~

  • PR 다루는 사람이 많아지도록: 현재는 PR을 다루는 사람의 수도 아주 적고, 포트가 아니면 그나마 몇달동안 답변이 안 달리는 경우도 많은데 PR에 답해서 어려움을 느끼는 사용자들을 대해 주는 것도 중요!

  • www.freebsd.org 페이지를 좀 더 동적이고 재미있게: 현재 FreeBSD 홈페이지 대문은 몇년째 큰 변화 없이 그냥 릴리스 번호나 올라가고 있는데, 첫 화면에서 최근 변화를 쭈욱 볼 수 있고 좀 더 재미있게 해서 자주 방문할 수 있또록 하자는..

  • BSDcon에 많은 사람들을 참여시킴: 미니 컨퍼런스도 많이 마련하고 해서, 현재 리눅스 유저 그룹들에 비해 압도적으로 적은 컨퍼런스 수를 늘리자 하는 의견입니다.

  • FreeBSD 재단의 연구 지원: FreeBSD 재단에서 연구/코딩의 재정적 지원을 해 줘서 개발자들이 3,6,12개월동안 따로 돈을 안 벌고도 자기가 하고 싶은 분야에 대해서 집중적으로 노력을 쏟을 수 있도록 해 주자는..

Poul-Henning은 사회적인 위시 리스트를 많이 쏟아냈군요. 흐흐. 대체로 그 이후의 의견들은 GUI 인스톨러가 나오면 툴킷은 뭐를 쓸 것이냐, 비디오 카드를 못 잡으면 어떻게 할 것이냐.. FreeSBIE를 기반으로 하면 FreeBSD에서도 쉽게 X띄우고 GUI인스톨러를 띄울 수 있다.. 이런 뻔히 예상되는 전개가 나오고 있습니다. ;;

그래도 이제 5가 릴리스된 덕분에, 이런 희망도 얘기해 보고 좋군요.:)중간에 나온 얘기 중에서는 suspend-to-disk 즉 윈도우 용어로는 hibernate기능도 참 중요해 보입니다. 흐흐.. 저는 아무래도 국제화쪽에서 BSD iconv가 베이스에 들어가는 게 가장 필요해 보입니다. –; 복학하면 꼭 해야징 -ㅇ-;

INDEX는 갔습니다.

by

FreeBSD ports의 구시대 유물 중 가장 어리숙했던
/usr/ports/INDEX가 드디어 포트에서 지워졌습니다.

아..
이제 아련한 asami씨의 소인수분해 놀이,
marcus의”ports freeze baby”도
희미한 Attic에서나 볼 수 있게 되었습니다.

이제 ports에서도 pkgsrc처럼 make index를 하거나
아니면 make fetchindex로 서버에서 자동 빌드된 인덱스를 가져와야 합니다.
오래된 포트 정보를 보여주고,”그래 이건 원래 이런 거야.”하고
야릇한 감정을 느끼던 시절도 이제 옛 이야기가 되었습니다.

있으나 마나 했던 make upgrade도 가고,
슬프도록 이상했던 INDEX도 가고..
이제 portupgrade -a 쳐놓고 넋 놓고 한나절 기다리면
업그레이드 되어있는 말쑥한 포트만 남았습니다.

(아멘 -ㅇ-)

엄청나게 빨라진 그놈 터미날

by

[WWW]크리스나 님의 블로그와[WWW]상구님의 글에서 소개된[FreshPorts]x11/gnometerminal고속 패치를 한 번 적용해 봤습니다. 오랜만에 집 데스크탑을 6-CURRENT로 올리고 산뜻한 기분으로.. 흐흐 무슨 내용인지 내용을 봤더니 ISO-2022와 wcwidth쪽처럼 페이지 렌더링에서 컨텍스트가 필요한 부분을 컨텍스트를 건너띌 수 있도록 패치를 한 다음에, 페이지가 스크롤될 때 렌더링이 아직 덜 된 내용은 쭉쭉 출력한 다음에 스크롤 하는게 아니라 그냥 마구 올려버리는 것이군요.. 그러니까.. 넘어가지만 안 보이는 것도 있는 것!

그래서.. 한번 해 본 결과.. 진짜로 체감 속도가 한 10배가 빨라집니다! jot 10000 정도 돌려가지고는 그냥 씽~ 지나가 버립니다. 흐흐 그놈 터미날도 느리기만 한 것은 아니군! 그동안 뭔가 로그 올라가면 괴로워 하며 기다리던 시절은 지나간 듯 합니다. 그런데, 그렇다고 딱히 진짜 성능이 개선된 것은 아니라서 반응 속도에서는 약간의 향상은 있지만 크게 좋은 편은 아닌 듯 합니다. 스크롤에서만 엄청난 향상을.. 흐흐. 뭐 이정도만 해도 그런대로 만족입니다. -O- 그런데, 옛날에 머드할 때 초당 5~6페이지 올라가는 것 정도는 글자 안 빠지고 거의 다 봤는데 (사실은 메시지를 다 아니까;;) 이거 그놈 터미날로 머드하다가는 누가 때리는 메시지 못 보고 지나가서 낭패 보는 수도 있겠군요..:)

[WWW]현재 포트에 대한 임시 패치를 하나 만들었습니다. 물론, 이게 뭐 별로 정석이 아니라서.. 옵션으로 안 들어가고 그대로 반영되지는 않겠지마는;;