Vala 언어 소개

Vala 언어는 C# 언어와 문법이 비슷한 객체 지향 언어입니다. Vala 언어로 작성한 소스를 이용해 실행 파일을 직접 만들 수도 있지만 C 소스 코드로 변환할 수도 있는데, 더 정확히 말하면, GObject 프레임워크를 이용하는 순수 GLib 기반 C 언어 코드를 생성한 뒤 이를 다시 C 컴파일를 이용해 실행 파일을 생성합니다. 따라서 이렇게 생성된 C 소스 코드는 이론적으로 GLib 라이브러리가 포팅된 어떤 플랫폼에서든 동작할 수 있고, 실행 속도 역시 C 언어로 작성된 코드와 거의 동일한 성능을 보여 줍니다. 생성된 소스 코드나 라이브러리는 GLib 외의 다른 라이브러리 의존성이 없기 때문에(posix 프로파일을 사용하면 GLib 의존성도 없어짐) 당연히 다른 C 언어에서도 이용할 수 있고, 반대로 C 언어로 개발된 라이브러리를 별다른 바인딩 코드 없이 VAPI 기법을 통해 사용할 수도 있습니다.

요즘 GNOME 프로젝트 개발 흐름을 보면 크게 두 가지 언어, JavaScript와 Vala가 대두되고 있는데, GUI 같은 상위 제어 모듈은 JavaScript로 구현하고, 성능이 중요한 하위 모듈은 C + Vala로 구현한 뒤 이를 하나의 프로그램에서 합쳐서 성능과 개발 효율을 동시에 얻고자 하는 것 같습니다.

사실, GObject 프레임워크가 좋긴 하지만, 여러 고수준 언어에서 사용할 때와는 달리 C 언어에서 사용하려면 어려움이 많아서 비판을 많이 받습니다. Vala 언어는, 말하자면, 이러한 반복되는 코드 재작성(boilerplate code)과 자잘한 코딩을 획기적으로 줄여주면서 C 언어로 GObject 객체 지향 프로그램을 할 수 있도록 도와주는 역할을 하는 겁니다. C++의 복잡함은 싫고, 인터프리터 언어의 느림은 견디기 힘들고… 결국 목마른 사람들이 직접 우물을 판 셈입니다.

그렇다고 Vala 언어는 비단 GTK+ / Clutter 기반 GUI 프로그램을 개발하는데만 사용되지 않고, 서버 데몬[systemd] 같은 콘솔 프로그램 개발에도 사용합니다. 이미 수많은 프로그램이 Vala를 이용해 개발되었는데, C 언어로 개발되었던 기존 프로그램을 Vala 언어로 다시 작성한 것[Cheese]도 눈에 띕니다.

그러나, Vala 언어의 단점이라면, C 언어 부류인 C#과 문법이 비슷하긴 하지만, 무엇보다도 새 언어를 익혀야 한다는 점, 그리고 GLib / GObject 개념에 익숙하지 않을 경우 익히는데 조금 더 시간과 노력이 필요하다는 점입니다. 물론, 오픈 소스 리눅스 개발자 커뮤니티에서 개발되어, 아직은, 그 안에서만 사용하는 마이너 언어라는 한계 때문에, 즉 상용 벤더의 지원이나 Visual Studio, XCode 등과 같은 완벽한 통합 개발 환경도 없기 때문에, 많은 개발자를 끌어당길 매력이 부족한 것도 사실입니다. 하지만 한편으로는, 오픈 소스이기 때문에 오히려 미래가 더 투명한게 아닐까 하는 생각도 듭니다.

아무튼, Vala 언어에 대해 더 관심이 생기는 분은 소개, FAQ, 튜토리얼 문서 등을 한 번 훑어보시길 바랍니다. 샘플 코드도 많고, 튜토리얼도 참 많습니다. 아마 C++ / C# / Java / Python 등과 같은 객체 지향 언어에 익숙한 개발자라면 생각보다 어렵지 않다는 사실을 알게 될 겁니다. 더불어, Vala 컴파일러가 생성한 C 소스 코드를 한 번 확인해 보시면, 객체 지향 개념을 이런 식으로 코딩하고 구현할 수도 있구나 하는, 결국 중요한 건 개발자의 능력이지, 사용하는 언어나 개발도구가 전부가 아니란 것도 느끼게 됩니다.

Posted in Development | Tagged , , | Comments Off

라자냐 코드 (Lasagna Code)

Lasagna
요즘은 예전에 작성한 라자냐 코드(Lasagna Code)의 굴레에서 벗어나기 위해 노력하고 있습니다. 스파게티 코드(Spaghetti Code)가 아닌 라자냐 코드라고? 처음 들어보시는 분을 위해 위키피디어 설명을 날림으로 번역해 보면 다음과 같습니다.

라자냐 코드는 일종의 프로그램 구조인데, 잘 정의되어 분리된 여러 계층(layer)을 가지는 것이 특징입니다. 각각의 코드 계층은 잘 정의된 인터페이스를 통해 아래 계층의 서비스에 접근합니다. 이 용어는 프로그램 구조를 파스타에 비유하는 스파케티 코드와 비교되곤 하는데, 다른 재료(고기, 소스, 채소, 치즈 등)가 각각 파스타 조각으로 분리되어 하나의 접시에 담긴 라자냐의 계층 구조에 기인합니다.

라자냐 코드의 흔한 예 중 하나는 다른 하부 시스템 , 가령 웹 어플리케이션과 비즈니스 로직, 관계형 데이터베이스 사이에 존재하는 인터페이스입니다. 또한 프로그래밍 기법 중에, 프로그램 전체 구조에서 레벨마다 다른 프로그래밍 언어를 사용하는 경우에도 이를 연결하는 계층이 존재하는데 이 역시 라자냐 코드의 일종입니다. 일반적인 클라이언트-서버 응용 프로그램 역시 대부분 잘 정의된 인터페이스를 통해 통신하므로 라자냐 코드라고 할 수 있습니다.

대개 라자냐 코드는 다른 계층간에 인캡슐레이션(encapsulation)을 강요하기 때문에, 문제의 하부 시스템은 잘 정의된 메카니즘(SQL, RPC, FFI 등)을 제외한 다른 통신 수단이 없습니다. 물론, 시스템의 개별적인 레이어는 덜 구조화되어 있거나 엉망으로 조직화되어 있을 수도 있습니다.

위 설명을 보면 라자냐 코드는 전혀 나쁜 것 같지 않은데 도대체 무슨 굴레를 벗어난다고 하는 걸까, 모든 진리가 말하듯이, 과하면 부족함만 못한 법입니다. 너무 많은 계층화는 성능 개선 / 기능 확장 / 유지 보수 디버깅에 오히려 방해가 되어 버리고 맙니다. 예를 들어 GNOME 2 플랫폼에서는 용도별로 개발된 수많은 libgnome* 라이브러리가 존재했지만 GNOME 3 개발 과정에서 대부분 기능을 GLib / GTK+ 라이브러리에 통합한 이유 중 하나도 마찬가지일 겁니다. 여담이지만, 사실 그래서 GTK+는 모든 기능이 종합 선물 셋트처럼 제공되는 QT 애호가들에게 많은 비난을 받아왔었던 것도 사실입니다. 무슨 라이브러리 의존성이 이렇게 많고 복잡한지… 물론 아직도 GTK+ 툴킷 자체는 여전히 기능별 라이브러리에 의존하고 있지만 예전에 비해 정말 많이 정리된 셈입니다.

아무튼, 스스로 만든 라자냐 코드의 굴레 중에서 가장 문제가 되는 부분은, 멀티 플랫폼을 고려하는 것과 더불어 향후 라이브러리 교체시 수고를 덜기 위해 어떤 라이브러리 API를 그대로 사용하지 않고 일종의 확장성있는 랩퍼(wrapper) API를 따로 만들어 사용한 점입니다.  결과적으로, 라이브러리 자체도 계속 업그레이드 되기 때문에 이를 반영해야 하고, 다른 라이브러리로 교체하는 경우도 별로 없고, 성능 개선이나 기능 추가를 위해 끊임없이 랩퍼 API를 추가하면서, 디버깅할 때는 한 동작을 위해 두 세 단계 이상의 계층을 따라 가야하고… 배보다 배꼽이 더 커지는 경우가 발생해 버리는 상황에 이르게 됩니다.

두번째로 문제가 되는 부분은, 기능 하나를 구현할때 구성 모듈을 너무 세분하게 나눈 점입니다. 특히, 수평적이 아닌 수직적으로 기능을 나눌때 적절한 범위를 넘어가버리면, 새 기능 추가시 매우 많은 모듈에 대한 의존성 검사, 부작용 검사 등의 작업이 몇 배나 어렵습니다. 예를 들어 상위 계층에 있는 기능을 하위 계층에서 사용해야 하는 경우가 발생하면 이를 위한 인터페이스를 설계하는데 시간이 더 걸리는 경우도 많습니다. 그냥 간단하게 하나의 모듈로 작성하면 되었을 걸…

과하면 부족함만 못하다… 언제 어떻게 무엇이 될 지 모르는 미래를 위해 미리 고민해서 확장성 있는 구조를 설계하는데 노력하는 것보다, 지금 당장의 요구 사항 수준에서 아무 문제없이 잘 돌아가는, 향후 쉽게 이해하고 확장할 수 있는 간단한 구조의 코드를 작성하는게 맞는 것 같습니다. 게다가 향후 발생할 요구사항을 미리 알 지 못하는데 미리 확장성있게 설계한다는 것 자체가 모순이 아닌가 하는 생각도 들고…

Posted in Development | Tagged , | Comments Off

Sentry24DVR 2.7-1 (2011.06.10) Release

Sentry24DVR 2.7-1 (2011.06.10) version released!

Detail information is below:

Sentry24DVR 2.7-1 (2011.06.10)

Updated:

  • Add support for recent main board chipsets (kernel / system libraries upgraded)
  • Add support for Intel / ATI / NVIDIA video chipsets
  • Add support for USB flash installation
  • Improve network camera video display performance

Note that only RT1640[H] / ODCAP models will be supported since 2.7 version. However, ODCAP models on Intel Sandy Bridge chipsets is not yet supported and it will be available soon.

Sentry24DVR 2.7 installation CD images with OEMs can be downloaded on the following location:

To write the installation ISO image to USB flash on Windows, You will need one of following tools:

You can write the image to USB flash on Linux like following:

# umount /dev/sdX1
# dd if=dvr-2.7-*.iso of=/dev/sdX

/dev/sdX is your USB device detected on the system.

Posted in Development | Tagged , | Comments Off

PCD – Process Control Daemon

아치리눅스를 비롯한 몇몇 리눅스 배포판은 여전히 시스템 부팅 초기화에 필요한 작업, 예를 들어 로컬 파일 시스템을 마운트하거나 웹서버, X서버 같은 시스템 프로그램을 자동으로 실행하기 위해 전통적인 유닉스의 SysV 시스템 구동 스크립트 방식(런레벨, rc.d 스크립트 등) 혹은 비슷한 방식을 이용하고 있습니다. 하지만 오래된 이 방식은 셸 스크립트 기반이라 전반적인 실행 속도가 느릴 뿐 아니라 프로세스간 의존성, 프로세스 종료시 예외처리(예: 자동 재실행) 등과 같은 기능을 지원하지 않아 많은 시스템 관리자 및 개발자의 불만을 산 것도 사실입니다. 특히 최근 몇 년동안 이슈가 되었던 리눅스 부팅 속도 단축을 위해 제일 먼저 처리되어야 하는 걸림돌로 여겨지기도 했습니다. 이런 이유로, 우분투(Ubuntu)는 오래전부터 자체적으로 개발한 Upstart 프로그램으로 이를 교체했고, 페도라(Fedora) 역시 Fedora 15부터 Systemd 프로그램을 이용해 구동 과정을 관리합니다. 즉, 요즘 리눅스 서버 / 데스크탑 시스템에서 시스템 초기 부팅 작업을 위한 솔루션은, 가히 춘추전국시대라고 할 수 있을만큼, 각각을 리눅스 표준으로 정착하려고 노력하는 이들이 있는가 하면, 그냥 옛것이 좋은 것이라고 고수하는 이도 있고, 더 단순하고 본인 입맛에 맞는 시스템을 직접 개발해서 사용하는 이도 있을만큼 다양합니다.

그런데 여담이지만, 아치리눅스 부팅 과정 커스터마이징과 속도를 경험해봐서 그런 건지, 범용 배포판은 어쩔 수 없이 모든 사용자가 만족할 수 있도록 가능한 많은 서비스 프로그램을 기본적으로 설치하고 이를 모두 시작하기 때문에 느려질 수 밖에 없는 건데, 부팅 속도 향상을 위해 시작 프로세스 관리 데몬의 성능과 기능을 개선하는 방향으로만 접근하고 있는 게 아닌가 하는 생각도 듭니다. 물론 다른 고급 기능을 제공한다고 하지만, 어차피 대부분의 기능은 배포판 개발자들만 사용하는 거고… :) 참고로, 이 발표자료만 봐도 부팅 속도와 초기화 프로그램의 능력은 무관한 것 같습니다.

아무튼, 지금까지 설명한 배경이 최근 임베디드 리눅스 컨퍼런스 2011 발표 슬라이드를 읽다가 PCD(Process Control Daemon)라는 프로세스 관리 데몬을 소개하는 내용을 보고 흥미를 가질 수 밖에 없었던 이유입니다. 위에 소개한 최신 프로그램들이 제공하는 기본 기능을 충실히 구현한 것은 물론, 임베디드 시스템을 우선 대상으로 개발했기 때문에 실행파일 크기가 매우 작고 빠르다는 점이 가장 매력적인 장점인 것 같습니다. (자세한 기능은 직접 확인해 보시길… :)

Systemd / Upstart 프로그램은 기능은 강력하지만 임베디드 시스템에 적용하기에는 너무 덩치가 크고 라이브러리 의존성도 무시하지 못할만큼 무겁습니다. 또한 임베디드 시스템은 개발자가 시스템의 모든 프로세스를 통제하고 완벽하게 관리해야 하기 때문에, 시스템에 대해 배포판 개발자와 동등하거나 더 많은 이해를 필요로 하므로 이러한 도구를 이용하면 작업이 수월해질 수 있습니다. 더 나아가, 이 프로그램을 조금 더 응용하면 데스크탑 / 서버용 시스템에서 여러 프로세스로 동작하는 시스템을 개발할 때도 유용하지 않을까 하는 생각도 듭니다.

물론 임베디드 리눅스 개발시 하나의 셸 스크립트 안에서 부팅 과정에 필요한 모든 작업을 처리하는 방식이 무조건 나쁜 건 아닙니다. 다만 복잡도가 더 높은 시스템을 설계할 때는 반드시 이런 프로세스 / 세션 관리 / 예외 처리 프로그램을 사용하거나 알아두면 나중에 참고하는 데 도움이 되지 않을까 생각해 봅니다.

Posted in Development | Tagged , , | Comments Off

Sentry24DVR 2.6-10 / 2.5-12 / 2.4-39 (2011.05.30) Release

Sentry24DVR 2.6-10 / 2.5-12 / 2.4-39 (2011.05.30) version released!

Detail information is below:

Sentry24DVR 2.6-10 (2011.05.30)

Updated:

  • Add support for MEA-NVR OEM

Fixed:

  • PTZ commands sent endlessly to IP camera
  • RTSP IP camera disconnection not detected
  • PTZ button click in web client doesn’t work properly
  • Web client not working in Internet Explore 9
  • System restarts on clicking backward button in backup dialog
  • H.264 video play-back failure in backup viewer

Sentry24DVR 2.5-12 / 2.4-39 (2011.05.30)

Fixed:

  • PTZ button click in web client doesn’t work properly
  • Web client not working in Internet Explore 9

Sentry24DVR 2.6 / 2.5 / 2.4 installation CD images with OEMs can be downloaded on the following location:

Sentry24DVR 2.6 / 2.5 / 2.4 reference manuals and full change log can be browsed on the following page:

 

Posted in Development | Tagged , | Comments Off