Gentoo에서 libogg 1.1.4 때문에 이와 관련된 라이브러리들 빌드가 안 되는 문제를 해결하려면 lafilefixer를 설치하고 실행해야 한다. 그런데 신기한 것은 이것을 실행해도 솔직히 안 생기던 la파일이 생기는 것은 아닌데 문제를 일으키던 패키지들이 잘 컴파일되는 이유는 무엇일까?
그리고 Gnome이 rc.conf에 기본 X 세션으로 설정되어 있어도 실행되지 않는 경우 XSESSION 환경 변수를 강제로 설정해서 사용해도 무관한 것 같다. 이렇게 하면 적어도 Gnome은 확실히 뜬다.
요즈음 데비안도 여러 가지로 패키지의 범위도 넓어 지고 쓸만해 진 것 같다.
Pidgin용 네이트온 플러그인은 물론이고 네이트온 자체도 패키지에 추가되었다. 그 뿐이 아니다. 이전엔 꿈도 못 꾸었던 ntfs-3g가 추가되는 등 여러 가지로 편해 졌다. 물론 Skype와 LAME 같은 것들은 라이센스 등의 문제로 추가가 안 되고 있는 것 같지만...
어차피 LAME은 Windows에서도 컴파일해서 써야 하고 Skype는 데비안용 패키지가 제공되니 특별히 걱정하거나 마음에 안 들어할 필요는 없는 것 같다.
생각해 보면 네이트온과 관련된 패키지가 추가되는 등의 상황은 그래도 그 만큼 우리나라 엔지니어들과 리눅스 사용자들이 노력하고 있고 참여하고 있다는 뜻이 아니겠는가? 이런 상황에 감사해야 할 것 같다. 나처럼 별 것 못하는 사람은...
레이니 이야기를 다 읽었다.
느낌은... 쉽게 말해 상당히 철학적이었다. 그리고 나름데로 마법에 대한 이론을 정립하고 이것을 과학적이고 논리적으로 풀어 나가려고 했다는 점에서 참신한 것 같다.
또한 그러면서도 기계 기술과 우리 인간이 편리함에 취하기 쉬운 그런 부분에 대한 경각심을 가지게 하는 것 같다. 나 스스로 기계를 다루는 엔지니어라고 하면서 기계를 사용하지만, 결코 내가 할 수 있는 일을 기계에게 시키는 것이 좋은 것이 아니란 생각이 든다.
물론 속도 측면에서 효율성이 더 좋은건 사실이지만, 나 스스로의 노력으로 속도 문제도 극복할 수 있는 것이 아닐까.
그럼에도 나는 그렇게 생각한다. 엔지니어들이 기계를 만들고 움직이게 하고 프로그램을 코딩하는 것은 정당하다고 그렇게 생각한다. 이것 또한 노력이니까.
우리 LECL의 저장소 공간이 상당히 빨리 줄어 들어 가고 거기다가 남은 용량도 얼마 안 되기에 이번 10월 25일을 작업일로 잡고 공지 올리고 작업을 시작했다.
하는 김에 파워 서플라이의 팬도 좀 볼겸 해서 손을 보기 시작했는데 이게 0시 정각에 시작해서 3시 쯔음에야 끝이 났다. 그렇지만 결국 고치지는 못했다. 뭐 중간에 내부 청소도 좀 하고 그러긴 했지만 너무 시간을 버렸다.
일시적인 방편으로 RAID 0으로 묶기로 하고 백업은 일시적으로 다른 시스템에 네트웍을 통해 하기로 계획했었다. 그래서 기존에 사용하던 데이터 디스크와 백업 디스크를 RAID 하려고 남는 S-ATA/RAID 컨트롤러를 서버에 삽입하고 RAID 0으로 묶는 것을 십여번 시도했으나 계속 실패했다. 정확히 말하면 RAID를 설정하는 도중에 컴퓨터가 멎어 버리는 것이다. 그 뒤로 그 원인을 찾기 위해 별 방법을 다 썼다. 그러다가 "아무래도 안되겠다." 싶어서 Linux의 RAID Transport를 사용해서 구성해 보려고 시도했다.
역시 여기까지도 좋았다. 그런데 그러고 나서 RAID된 볼륨으로 백업한 자료를 다시 복원하는 과정에서 계속 서버쪽에서 오류가 발생하고 서버쪽의 프로세스가 무작위로 죽는 것이었다. 주로 활동이 활발하게 일어나는 프로세스가 그랬다. 나는 이게 메모리 부족이나 RAID를 하기에 적합하지 않은 상황에서 RAID로 묶으려고 해서 발생한 문제인줄 알고 이번엔 어차피 속도는 별로 안 중요하니까 LVM으로 묶자 해서 LVM으로 묶고 실험해 보았다.
그러나 결과는 마찬가지였다. 그래서 RAID로 다시 시도하면서 chunk size를 바꿔 보기도 하고 커널 버전도 바꿔 보고 커널을 컴파일하는 컴파일러 버전도 바꿔 보고 하면서 시도했으나 모두 실패했다. 결국 Linux의 RAID Transport는 일단 포기했다.
그 뒤로 이거 저거 알아 보던 도중에 서버 매인보드에서 제공하는 RAID 기능을 확인하고 이것으로 두 디스크를 묶었다. 그러고 나니 리눅스에서 이것을 다른 디스크로 인식하지는 않지만 md0으로 자동 인식했고 여기에 파티션을 설정하고 운용 시험을 시작했는데 역시나 동기화를 다시 하는 과정에서 오류가 발생하면서 프로세스가 무작위로 죽는 현상이 발생하고 동기화도 중간에 실패했다. 결국 문제점은 OS에 있는 것도 아니고 내가 구성한 RAID 방법의 문제도 아니라는 결론을 얻고 하드웨어적인 문제로 간주하고 하드웨어적인 검사 작업에 들어갔다.
왼만한 것들은 전부 점검시에 문제가 발생하지 않았는데 메모리를 시험하는 과정에서 레드스크린을 띄우면서 시험 프로그램이 죽고 시스템 전체도 멎었다. 그래서 시스템에 설치된 3 개의 메모리를 전부 하나 하나 시험한 결과 2 개는 정상이고 나머지 하나에 문제가 있는 것을 발견했다.
결국 불량 메모리는 제거하고 RAID로 구성한 디스크 전체를 검사하고 FS 검사등을 모두 마친 뒤 다시 자료 복원을 시작했다.
그 뒤로 동기화가 다 될 때 까지 중간 중간 상태를 확인했고 그제서야 정상적으로 동작하는 것을 보았다. 결국! 나는 메모리 오류 하나 때문에 거의 24시간에 가까운 시간을 허비하고 고생이란 고생은 다 한 것이다. 거의 24 시간 동안 밥 두 끼 먹은게 다일 정도로 작업하는 시간동안 쉴 틈 조차 없었다. 잠 잔 시간도 5 시간도 안 되는 시간이었다. 아우... 그래서 그런지 몰라도 온 몸이 뻐근하고 고통스럽다. 어깨와 목은 말할 것도 없고 이러다 보니 머리도 무지 아프다 어휴...
이번에 진짜 엄청 삽질을 한 터라 글로 하나 남겨 놔야 겠다 싶어 이렇게 남겨 둔다.
PS: 이 작업을 하는 동안 옆에서 기다려 주고 도와준 영운이형, 현종이 그리고 손님으로 오셔서 밥도 몇 번 제대로 못 드신 한 분께 정말 죄송하고 그러면서도 감사한 마음이 든다.
GNOME 관련 꾸러미가 뭐 뭐 있나 목록을 보던 중 gnome-blog 라는 녀석을 발견했다. 설명을 보니 BloggerAPI나 MetaWeblog 같은 방식의 BlogAPI를 통해 자신의 블로그에 접속하지 않고 글을 남길 수 있는 프로그램이었다. 일전에도 이쪽에 대해 관심을 가젔으나 딱히 필요성을 못 느끼고 해서 신경을 많이 쓰진 않고 있었다. 그런데 그렇지 않겠는가? 사람이 참 어떻게 보면 간사하다고 떡이 보이면 먹고 싶어지는 법이다. 그래서 그놈을 설치하고 사용해 보려고 했는데 처음부터 잘 되지는 않았다.
처음에 Textcube에서 BlogAPI 플러그인을 켜 주고 GNOME Blog에서 BloggerAPI를 통해 내용 전송 시험을 했는데 아무리 해도 안 되기에 MetaWeblog로 바꿔서 시도했다.
이번에는 다행히 등록 시도한 글이 제대로 올라가서 기뻐하며 이 내용을 한 번 정리해 보자 싶어 이 글을 쓰고 있다.(이것도 물론 GNOME Blog를 통해 등록하는 글이다.)
공통점을 먼저 이야기하자면 둘 다 나름데로 괸찮은 음질의 가상 악기들이란 것이다. 더부러 DXI 및 VST 모드를 지원한다는 점도 같다. Steinberg Hypersonic의 경우는 솔직히 그 자체가 악기라기 보다는 엔진에 가깝고(Gigastudio처럼) 여기에 알맞는 셈플림 컨텐츠를 얹어서 사용하는 형태이다. 또한 Edirol HyperCanvas가 기본적으로 GM+GS에 알맞는 반면 Steinberg Hypersonic은 이런 규격 보다는 다양한 음원 셈플링 데이터에 중점을 두고 있는 듯 하다. 물론 GM 모드를 지원하지만 기본적으로 꺼져 있다. 이렇다 보니 Edirol HyperCanvas가 Steinberg Hypersonic에 비해서 GM이나 GS 규격을 기반으로 작성된 MIDI 파일을 재생하거나 셈플링할 때 상대적으로 깔끔하고 괸찮은 음질을 보인다.(대부분 악기 소리의 현실성 또한 그렇다.)
이제는 세부적인 부분에 대해 알아 보겠다. 우선 Edirol HyperCanvas가 GM 혹은 GS 모드일 때 전반적인 음질이나 악기 소리의 현실성 등이 뛰어나긴 하지만 Steinberg Hypersonic에 비해 Bass 쪽이 좀 덜 받혀 준다는 느낌을 받는 편이고 일부 String 계열(바이올린, 첼로 등)의 경우 Steinberg Hypersonic에 비해 현실성이 좀 떨어진다는 점도 발견되었다. 이에 비해 Steinberg Hypersonic은 GM 이나 GS를 기반으로 하는 MIDI 파일을 재생하거나 셈플링할 경우 Drum 계열을 거의 처리하지 못하는 현상을 보였다. 악기들간의 벨런스도 괸찮고 나름 현실감 있는 악기 셈플들을 담고 있지만 이 부분이 제일 아쉬운 부분이다.(적어도 내 입장에서는...) 마지막으로 관악기를 중심으로 분석해 본 결과 Edirol HyperCanvas가 조금 더 현실감 있는 소리를 구현해 내는 것으로 보였다.
정리하자면 Edirol HyperCanvas가 GM 이나 GS 규격 지원에 있어서는 Steinberg Hypersonic에 비해 상대적으로 뛰어나고 일부 현악기의 소리에 대한 현실감은 좀 떨어지는 편이며 관악기는 비슷하거나 괸찮은 편이고 Bass 쪽은 좀 딸리는 편이다.
위 내용들은 100% 실험을 통해 알게 된 정보들이고 GM 및 GS 규격을 기준으로 하고 있다.
댓글을 달아 주세요
감사합니다 공유 반환 방문을 환영합니다