2015년 11월 29일 일요일

경량 리눅스 신속 설치 레시피




https://github.com/dymaxionkim/UbuntuBang

요기에다가 설치 방법 설명서를 올려 두었습니다.
각종 패키지 깔고 하는건 그냥 쉘스크립트를 Git에서 받아다가 골치 아프지 않게 자동으로 되도록 해 봤어요.
대충 시간을 재보니 수동으로 하나씩 까는 것에 비해서 시간을 1/5~1/10까지 단축해 줍니다.
인터넷 속도가 그럭저럭 나온다면 아마 1~1.5시간 정도면 끝날 수 있을 것 같습니다.

구성은...

Ubuntu Server 14.04 (베이스시스템)
OpenBox (윈도우관리자)
Tint2 (태스크바)
Conky (바탕화면위젯)
PCManFM (탐색기)
다솜입력기 (다국어입력기)
Numix (테마)
Python 툴체인 (Jupyter Notebook 까지)
...

LightDM은 생략해서, 부팅후 텍스트모드에서 로그인한 후에 직접 startx 타이핑 해줘야 됩니다. (개인취향)
뭐 이런 기본적이고 무난한 거고요.
윈도우PC를 주력으로 쓰고, 버츄얼박스로 리눅스 올려서 가볍게 돌리는 경우를 상정해서 구성했습니다.

구버전에서 이런식으로 구축한 레시피가 있었는데 버전도 바뀌고 했으니 함 써서 공유해도 나쁘지 않겠다 싶어서 올려 봅니다.




일단 구성한 후에 X윈도우 진입 직후 메모리 점유율을 보니깐 110MB 정도 됩니다.

그런데 이중에 다국어 입력기가 어떤걸로 하더라도 수십MB 정도의 메모리를 먹더군요.
다솜입력기는 UIM벼루보다 조금 더 메모리를 점유하더군요. --> 오류!  사실은 반대임
대신 한영변환시 Shift+Space 뿐만 아니라 한영키로 모두 쉽게 가능하므로 좋은 듯 합니다.

아무튼 버츄얼박스에 리눅스 올려서 뭔가 하려고 할 때, 우분투 데스크탑이나 민트 같은 걸로 하기엔 너무 자원낭비다 싶을 때 쓰려고 개인적으로 만든 것입니다.  제 경우엔 주로 계산용으로...

 

2015년 11월 8일 일요일

Git for PDM

Git for PDM

구글링 해 보면 이 주제와 관련하여 하나의 제안이 보인다.
간단히 말해 CAD 데이타도 분산 버전 관리 개념을 도입하면 어떠냐는 것이다.
사실 Git을 써 본 설계자라면 자연스럽게 이런 아이디어를 떠올릴 것은 당연한 귀결이다.
과연 이 아이디어가 현실성이 있을까??

기존 상용 PDM의 특징

  • 거의 모든 제품이 중앙집중식 파일관리 개념을 기반으로 하고 있으며, 유연성이 심각하게 떨어진다.
  • 이유는 간단하다. CAD 소프트웨어 개발회사들이 전부 자사의 CAD 제품 안에 고객들을 가둬놓고 돈을 쪽쪽 빨아먹는다는 개념의 비즈니스 모델을 가지고 있기 때문이다.
  • 따라서 산업 표준 호환성이나 데이타 교환의 용이성 등은 심각하게 등한시되어 왔다.

기존 상용 PDM의 문제점

  • 사용자는 모두 온라인으로 연결해서 CAD데이타를 당겨서 써야 한다.
  • 이런 중앙집중식 모델은 네트워크 속도가 받쳐주지 못하면 느려서 도저히 작업 진행이 안 될 지경이다. 특히 그냥 소스코드 따위의 텍스트들도 아니고, 수십~수백 메가바이트 또는 심한 경우 기가바이트 단위의 데이타를 온라인으로 당겨와서 써야 하는데 제대로 속도가 나올리 없다.
  • 다중작업시 권한관리 문제 때문에 역시 설계자의 자유도가 떨어진다.
  • 브랜치를 내는 것이 쉽지 않다. 이는 달리 말해, 하나의 소스 제품이 있을 경우 이에 대해 고객 요구에 따라 커스터마이제이션된 파생 모델을 쉽게 만들기 힘들다는 이야기다.
  • 다양한 파생 모델을 만들어내야 하는 것은 주로 다품종 소량생산 제품을 만들어내야 하는 고부가가치 장비 쪽 업계에서 직면하는 문제다. 이에 대해 기존의 CAD 회사들은 제대로 된 솔루션을 전혀 제시해주지 못하고 있다.
  • 기존 CAD 회사들의 주요 관심사는, 대규모 다국적 기업들 달리말해 큰 돈을 주는 대기업에 주로 촛점이 맞춰져 있었다.
  • 중소기업을 위한 솔루션이라고 구색을 맞춰서 나온 것들이 있기는 하지만, 역시 실제 중소기업 현실에 맞춘 마음에 드는 솔루션을 본 적이 없다.
  • 중소기업의 경우 1명~수명 정도의 소수의 설계 인원만으로 설계작업은 물론 도면 생성 관리 배포 파생제품 설계 생산이관 자료준비 등등 모든 단계를 모두 다 수행해야 한다. 이는 심각한 업무 로드를 강요하게 되는데, 실무자의 업무량을 진짜로 줄여주는 일에 관심을 가진 공급자는 단 한 회사도 없었다고 본다.
  • 특히 중소기업(스타트업,벤쳐등)의 경우, 관리를 위한 관리 보다는 좀 더 유연하게 신제품을 개발하는게 중요하고 또 기존 제품들 즉 레거시 데이타의 구애를 덜 받기 때문에, 중앙집중식 데이타 관리 보다는 분산형이 훨씬 더 필요성이 높다.

diff 문제

  • Git은 기본적으로 텍스트 포멧을 다루는데 최적화되어 있다. 그런데, 대부분의 CAD 데이타는 바이너리 파일이다. 따라서 사용하기에 불리해진다.
  • diff 기능은 고도로 발달되어 있으나 역시 텍스트 이외에는 전혀 쓸모가 없다.
  • 다만, STEP 파일을 보면 기본적으로 텍스트 포멧을 바이너리화 한 것으로 볼 수 있기 때문에 중간에 적절한 필터만 거치게 해 줄 경우 관리가 완전히 불가능한 것만은 아닐 것이다.
  • 또한 CATIA의 Catpart, CREO의 prt 파일 등의 경우 역시 해당 포멧의 구조 중에서 헤더 정도에 해당하는 내용만 파싱해 낼 수 있다면 어느정도 관리가 가능하지 않을까 생각이 들기도 한다.
  • 그럼에도 불구하고, 텍스트 포멧을 다룰때 보다는 훨씬 많은 용량의 저장공간과 관리를 위한 컴퓨팅 파워가 필요할 것이다.
  • 그러나 저장공간의 가격은 매우 저렴해져 있고, 컴퓨팅 파워는 사실 PC 정도 사양만으로도 충분하지 않을까 싶다.

사용자 인터페이스 문제

  • 소프트웨어 개발자가 아닌 기계설계자들을 위한 심플하고 깔끔한 GUI 클라이언트 소프트웨어가 제공될 필요가 있다. 또는 완전히 웹 기반으로 가도 좋지 않나 한다.
  • 인증, 커밋, 브랜치, 머지 등등의 개념을 몰라도 자동적으로 수행되도록 세심하게 개발되어야 할 것이다.

BOM 생성 문제

  • 가장 현실적인 방법은, CAD 종류에 구애받지 않도록 모든 정보를 포기하고 오로지 파일네임만으로 모든 것을 구성하는 것이다.
  • 이것이 성립되려면 파일네임이 유일성을 가지도록 설계단계에서 유의해야 할 필요가 있다. 이는 설계자 교육을 통해 습관하는 것이 충분히 가능하다고 본다.

잠정 결론

  • 아무튼, Git 기반으로 소스코드 관리가 아닌 pdf,dwg,stp 같은 바이너리 파일(도면 포함)을 분산 버전 관리할 수 있도록 솔루션을 구성하고 이를 사업화하는 방법도 꽤 재미있는 아이디어 아닐까 싶다.
  • 한국에서 이게 나올 확률은 0%에 수렴할 것 같아 조금 슬프다.