Dymaxion.Kim: 10월 2015

2015년 10월 29일 목요일

기계공학용 가벼운 리눅스 배포판

CrunchBang 리눅스가 원래 Ubuntu + Openbox 조합으로 매우 가볍고 빠르면서 편리성도 갖추는데 성공한 이후, 이에 영향을 받은 여러 배포판들이 나온 것 같다.
2009년을 마지막으로 CrunchBang 프로젝트가 중단되었기 때문에 이와 같은 컨셉의 좋은 배포판에 대한 필요성이 더욱 증가하였다.

Debian + OpenBox 조합형 리눅스 배포판

BunsenLabs : https://www.bunsenlabs.org/

BunsenLabs라는 프로젝트는 CrunchBang의 직계 후계 프로젝트로 계속 이어지고 있다.
간단히 말해 그냥 CrunchBang의 업데이트가 계속된다고 봐도 될 듯 하다.
다만 CrunchBang의 마지막 버전은 Ubuntu 대신 Debian 기반으로 전환하였기 때문에, 이것 역시 Debian 기반이다. 이점은 장점이자 약점이기도 하다. 사용목적에 따라 장단점은 달라질 것이다.
일단 설치 자체는 매우 안정적이고 신뢰도가 높다. 설치후 스크립트에 의한 환경 구성 과정이 너무 세심하게 잘 되어 있어서, APM 웹서버 구축하는 것조차도 선택에 따라 설치시에 자동으로 다 이루어진다.
개인용 웹서버와 간단한 데스크탑 정도 목적이라면 Debian 기반 시스템이 좋은 선택일 것이다.
그러나 워크스테이션으로 사용하기에는 Debian 시스템의 보수성 때문에 불편한 점이 많다.
많은 공학용 어플리케이션들이 대부분 Ubuntu 배포판은 기본으로 지원하지만, Debian 배포판은 따로 제공하지 않는 경우가 많기 때문이다. 때문에 Debian에서 억지로 사용하려면 직접 어플리케이션을 빌드해서 사용해야 할 것인데, 이는 시스템 관리에 많은 시간과 노력이 낭비된다는 것을 의미한다.
또한, 하드웨어를 자동으로 잡아주는 호환성 부분이나, 기타 여러가지 편리성 측면에서도 Debian이 아무래도 Ubuntu보다 좀 떨어질 수 밖에 없다. 설치 직후 인식되지 않는 하드웨어 설정 등에 시간이 투입될 확률이 좀 있다.

Ubuntu + OpenBox 조합형 리눅스 배포판

SalentOS : http://www.salentos.it/
Madbox (32bit 버전만 제공) : http://madbox.tuxfamily.org/
GoBang : http://gobanglinux.org
Chromixium : http://chromixium.org

따라서, 편리성과 가벼움(=리소스 절약)을 동시에 달성하기 위해서는 Ubuntu + OpenBox 조합이 최선의 선택이라고 생각된다. 설치하자마자 별다른 설정 없이 그대로 사용을 시작해도 충분한 수준이라고 생각된다.
위에 조사해 본 4가지 배포판 중에서, SalentOS 및 MadBox는 사용을 안해봤다.
MadBox는 32비트 바이너리만 제공하므로 공학해석을 위해 필요한 64비트 버전이 없기 때문에 제외해야 할 것이다.
GoBang은 시험삼아 설치해 봤는데, 설치 요령은 BunsenLabs와 크게 다르지 않으며 매우 가볍기는 하나, 안정성이 좀 떨어진다는 느낌이 든다. VirtualBox 가상머신에서 게스트 확장 설치에 실패했다. 다운되는건 아닌데 내부적으로 충돌이 좀 있어 보인다.
Chromixium은 OpenBox 기반이기는 하나, Tint2 대신 Plank Dock을 기본적으로 사용하기 때문에 훨씬 더 예쁘다. 계속 활발하게 업데이트가 이루어지고 있어서 이제는 매우 안정성이 높아졌다.
편리성을 포기하지 않으면서 동시에 메모리 절약 등 가벼움을 원한다면 현재로서는 가장 좋은 선택이라고 생각된다.
물론 가볍다고는 하지만 GoBang 수준으로 터무니없이 가볍지는 않다. GoBang이나 BunsenLabs의 경우에는 환경설정 대략 해 주고 부팅하면 메모리 사용량이 300~400MB 수준이다. 마우스 클릭시 반응속도는 뭐 말할 필요도 없다. Chromixium은 필요한 환경설정을 대충 해 주고 부팅하면 메모리 사용량이 600~700MB 수준이다. 구글 크롬북을 흉내낸 데스크탑 디자인 때문에 나름대로 산뜻한 느낌을 준다.
내가 이런 가벼운 배포판를 찾는 이유는, 가용한 PC의 메모리가 4~8GB에 불과한 경우가 많기 때문이다. 16GB~32GB 정도의 메모리를 가지고 있다면 고민할 필요가 크게 없다고 생각된다. 그때는 그냥 일반적인 Ubuntu Unity, Mint 같은 것을 사용하는 것이 더 편리하기 때문에 시간낭비를 크게 막아줄 것이다.
유한요소 해석을 할때, 대략 20만개 수준의 엘리먼트를 해석하면 4GB 메모리로도 충분히 커버 가능하다. 그런데 100만개 수준의 엘리먼트를 해석할 경우에는 거의 100% 실패한다. 메모리가 기하급수적으로 소모되기 때문에 메모리 용량은 나름대로 중요한 문제가 된다.
OS에서 기본적으로 점유하는 메모리를 아낄 수 있다면 좀 더 나을 것이고, 또 OS의 환경구성 복잡도가 낮아 단순하다면 더욱 해석에 유리할 것이라고 나름 생각한다.
또한, 리눅스 구성 자체에 재미를 느끼는 오타쿠(?)가 아닌 평범한 기계공학 엔지니어의 경우에는... 리눅스 사용 자체에 거부감을 느끼는 경우가 많다. 컴퓨팅 자체 보다는 설계 해석 행위 자체가 주관심사이기 때문이다. 컴퓨터는 그냥 도구라는 생각이 강하기 때문에, OS 구성하고 셋팅하는데 시간낭비가 없는 것이 좋겠다.
기계공학 엔지니어가 사용할 어플리케이션은 기껏해야 다음 정도다.

유한요소해석 솔버
C,C++,Python 등의 간단한 개발환경
3D CAD 관련 어플리케이션들
간단한 웹서버 운용
SAMBA, SSH, FTP 정도의 유틸리티들
웹브라우저

무거운 배포판은 필요가 없다.

2015년 10월 13일 화요일

Wiki and Jupyter

위키

여러가지 위키를 상당기간 검토하거나 사용해 봤다.
미디어위키. 일단 가장 표준적인 시스템이라는 점에서 보증할 수 있고, 기능이 풍부하며, 확장성 역시 좋다. 그러나 미디어위키 문법은 아주 지저분하고, APM 시스템 기반이라 포터블 하지는 못하다.
깃허브 골룸. DB 의존적이지 않은 대신 Git을 통해 버전관리가 이루어진다. 어차피 DB가 필요한 만큼의 대규모 위키를 운영할 것도 아니므로 이것은 전혀 문제되지 않는다. 또 깃허브 향 마크다운 문법 역시 매력적이다. 설치 방법도 크게 까다롭지는 않다. 그럼에도 불구하고 뭔가 부족하다는 느낌이 든다. 하지만 기본 개념 자체는 아주 좋다.
징고(Jingo). 골룸 비스무레한 것을 node.js와 자바스크립트로 만들어 놓은 것이다. 역시 상당히 좋지만 아직 완성도가 너무 낮다. 겨우 구색만 갖춘 느낌. 그러나 역시 node.js 기반의 소프트웨어는 항상 나를 기쁘게 한다.
티들리위키. 단순무식한게 아주 좋고, 달랑 하나의 파일만으로 포터블성이 극대화된게 아주 천재적이다. 다만 기본 UI가 위키라기 보다는 블로그에 가깝다. 아쉬운 점은, 티들리위키 문법을 사용하고 싶지는 않기 때문에 마크다운 플러그인을 넣어 봤는데 지나치게 허접하다는 점이다.
기타 서비스형 위키로, Torchpad를 사용하고 있는데... 골룸처럼 깃허브향 마크다운 문법 기반이라 너무 좋고, 필요한 확장이 모두 기본적으로 셋팅되어 있을 뿐만 아니라, 그림 삽입 같은 것은 그냥 마우스 드래그만 해 주면 자동적으로 업로드 및 태깅이 되기 때문에 너무 편하다. 단점은 한글 입력시 끝글자가 사라져 버리는 버그가 있고, 깃허브 연동 기능이 아직 제공되지 않는다. 그리고 커뮤니티가 거의 죽어있는 것을 봐서는 곧 망할 것 같은 느낌이 들어 불안하다. 서비스형 위키는 아무래도 내가 통제할 수 없다는 점 때문에 심리적인 불안감을 떨치기 어렵다.

Jupyter

그런데, iPython notebook 즉 Jupyter를 보면, 기본적으로 훌륭하게 마크다운 문법이 지원되는 점을 볼 수 있다.
게다가 한큐에 서버 셋팅까지 되고...
각종 언어 커널만 심어주면 인라인으로 코딩 및 결과까지 보여준다.
그리고 이 모든 걸 전부 다 .ipynb 파일 하나에 싹 다 저장할 수 있다.
게다가 온라인, 오프라인 어느쪽으로든 이건 .html로 렌더링을 쉽게 해 줄 수 있다.
심지어 깃허브에서는 직접 렌더링해서 볼 수 있다.
아무튼 킹왕짱이다.

아이디어

아이디어는 간단하다.
Jupyter를 뜯어고쳐서(?) 골룸 위키 처럼 만들어보면 어떨까?
즉 위키 문서 파일 역할을 .ipynb 파일이 하도록 시스템을 구성해 주고, Jupyter 프론트엔드 쪽에 문서 검색기능 같은 추가 요소를 더 주는 것이다.
그리고 화면 좌측에 트리 같은걸 자동 생성해서 브라우징 할 수 있도록 해 주면 더 좋겠다.
그리고 열람 모드에서는 Jekill 같은 느낌으로 그냥 열람만 할 수 있도록 하고, 편집 모드에서는 Jupyter 네이티브로 편집 가능하도록 해 준다.
그러면 코딩과 문서의 환상적인 조합이 이루어질 뿐만 아니라, 퍼블리싱까지 되는 셈이다.

2015년 10월 1일 목요일

JINGO !!!

개요

깃허브 홈페이지 : https://github.com/claudioc/jingo
한 줄 소개 : node.js로 작성한 Git 기반 위키엔진. 봐줄만한 디자인, 검색기능, 미려한 폰트.

Introduction

Git과 Markdown을 중심으로 한 문서작성체계를 가지고 싶은 사람을 위해 만들어졌음.
복잡하고 과잉기능의 도구에 질려버린 사람에게 좋음.
Github 자체 위키 엔진인 Gollum의 영향을 강하게 받았음.
다만, Gollum 보다는 좀 더 독립실행에 유리하도록 완결성을 주었음.
"Github 없이도 쓸 수 있는 좀 더 강력한 Github 위키"
Jingo = Jingo is not Gollum
데모 홈페이지 : http://jingo.cica.li:6067/wiki/home

Features

데이타베이스 사용하지 않음 : 대신 Git 레포지토리 기능을 활용함
사용자 관리 불필요 : 구글계정,깃허브 계정으로 간단히 로그인하는 기능 지원
완벽한 마크다운 문법 지원 : 깃허브향 마크다운도 지원
Codemirror 또는 Markitup 사용 : 훌륭한 ajax 보여주기 (설정 파일 참조)
전화면 에디터 모드 지원 : 집중력 강화
Gollum 위키에서 만든 문서와 호환
모든 문서에 버전 관리 지원
상이한 버전의 문서간에 비교 기능 지원
모든 문서에 페이지 매기기 기능 지원 : 버전 간에 변화된 부분을 빨리 찾을 수 있음
내용 및 제목 검색 지원
Sidebar, Footer 레이아웃 설정 가능
Gravatar(개인 아바타) 지원
IFRAME 삽입 가능 (예 : 구글 드라이브 문서를 embed할 수 있음)
커스텀 CSS 및 Javascript 적용 가능
문서를 읽고 쓸 때 권한을 줄 수 있는 화이트리스트 지원
빈 페이지 검출 기능 (붉은 색으로 나타남)
Remote로 자동 Push 기능
모바일 대응 (Bootstrap 3.X 기반)
간편한 설정

코드 하일라이트 기능으로, node-syntaxhighlighter를 사용함. 지원하는 언어는 이 페이지 참조.
Code

Installation

node.js 및 npm 설치

우분투 리눅스 14.04 기준. Git이 설치되어 있을 것.

sudo apt-get install nodejs nodejs-legacy npm

Jingo 설치

sudo npm install jingo

Git 설정하기

Git 사용법 참고 : https://backlogtool.com/git-guide/kr/intro/intro1_1.html

mkdir /home/홈폴더/jingo
cd /home/홈폴더/jingo
git init
git config --global user.name "아이디"
git config --global user.email "이메일"

Jingo 기본형 설정파일 만들기

jingo -s > config.yaml

Jingo 로그인 비밀번호 해쉬코드 만들기

jingo -# 비밀번호

위의 명령을 치면 해쉬코드가 나온다. 그걸 긁어서 복사해 둔다.

config.yaml 편집하기

편집기로 config.yaml을 열어서 다음의 내용을 손 봐준다.

---
# Configuration sample file for Jingo (YAML)
application:
  title: Jingo
  repository: '/home/홈폴더/jingo'      <--- Git 저장소로 설정한 디렉토리 절대경로
  docSubdir: ''
  remote: ''
  pushInterval: 30
  secret: change me
  git: git
  skipGitCheck: false
  loggingMode: 1
  pedanticMarkdown: true
  gfmBreaks: true
  staticWhitelist: "/\\.png$/i, /\\.jpg$/i, /\\.gif$/i"
authentication:
  google:
    enabled: false                 <--- Google 로그인은 일단 비활성화 해 두자.
    clientId: replace me with the real value
    clientSecret: replace me with the real value
  github:
    enabled: false                 <--- Github 로그인도 일단 비활성화 해 두자.
    clientId: replace me with the real value
    clientSecret: replace me with the real value
  local:
    enabled: true                 <--- 로컬 로그인만 활성화 해 두자.
    accounts:
      - username: '아이디'                 <--- 아이디
        passwordHash: '해쉬코드'         <--- 아까 만들어서 복사해 둔 해쉬코드를 넣어준다.
        email: '이메일'    <--- 이메일
features:
  markitup: false
  codemirror: true
server:
  hostname: localhost
  port: 6067
  localOnly: false
  baseUrl: ''
authorization:
  anonRead: true
  validMatches: .+
pages:
  index: Home
  title:
    fromFilename: true
    fromContent: false
    asciiOnly: false
    lowercase: false
  itemsPerPage: 10
customizations:
  sidebar: _sidebar.md
  footer: _footer.md
  style: _style.css
  script: _script.js

Jingo 첫 실행

jingo -c /home/홈폴더/jingo/config.yaml

잘 되나? 잘 되면 설정해 둔 아이디와 패스워드로 로그인 한 후, 첫번째 home 문서부터 작성해 보자.

남은 일들

Github와 연동시키기 : 나중에 천천히 하자.
Google 및 Github 계정으로 간편 로그인 기능 설정하기 : 나중에 천천히 하자.
다른 Javascript 스크립트 먹이기 : 나중에 천천히 연구해 보자.
서버에 올려서 서비스하기 : 나중에 천천히 연구해 보자.