MyAlbum   Pet
DirectX   openGL   Java   C/C++   STL   C#   Python   Window   ActiveX   SE & Refactoring   Game   Unicode   googleDesktop   Network   Database   Web   php   asp   asp.net   Library   QT   wxWidget   Something to read  
ToDo
zelon's WebAlbum
Google Tools
Google Naver map
ToRearrange
OpenOffice.org
Eclipse
Check W3 validator
etc Program
e i R f
Anonymous

Contents

1 각종 보안툴
2 ms application verifier
3 gtalk
4 mssql
4.1 데이터베이스 파일의 크기가 너무 클 때
5 CVS
6 Subversion의 장점
7 gimp
8 tclock
9 quickSFV
10 winkey
11 sendmail
11.1 특정 메일 서버에 메일이 가지않을 때
11.2 특정 유저에게 보내는 메일이 특정 유저로 갈 때
11.3 갑자기 메일이 안 가고 /var/spool/mqueue 에 메일이 쌓일 때
11.4 간단한 메일링 리스트 작동시키기
12 etc
12.1 bittorrento

1 각종 보안툴 #


2 ms application verifier #


3 gtalk #


4 mssql #


4.1 데이터베이스 파일의 크기가 너무 클 때 #



--DB log 논리적 Size 축소
BACKUP LOG Target_DB_Name WITH NO_LOG

--DB data 물리적 Size 축소
DBCC SHRINKFILE (1,0)

--DB log 물리적 Size 축소
DBCC SHRINKFILE (2,0)


참고로 위의 dbcc 를 이용해서 log 의 물리적 size 를 축소하기 전에 처음의 backup log with no_log 문을 사용해서 로그를 비워둬야 효과가 크다.

5 CVS #


6 Subversion의 장점 #

  • 커밋 단위가 파일이 아닌 체인지셋입니다. CVS에서라면 여러 개의 파일을 한꺼번에 커밋하더라도 각각의 파일마다 리비전이 별도로 붙습니다. 반면 Subversion에서는 파일별 리비전이 없고 한번 커밋할 때마다 전체 변경 사항에 대해 리비전이 하나씩 증가합니다.

  • CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간. 한 예로 같은 100MB 트리를 업데이트했더니 CVS보다 21배 빨랐습니다.

  • CVS와 매우 유사한 사용법. CVS 사용자라면 누구나 어려움없이 금방 배울 수 있습니다.

  • 파일 이름 변경, 이동, 디렉토리 버전 관리도 지원. CVS는 이것을 지원하지 않습니다.

  • 원자적 커밋. CVS에서는 여럿이 동시 커밋할 때 종종 충돌이 발생하는데 Subversion에서는 더 이상 그런 일이 없어졌습니다.

  • 서버-클라이언트 양방향 모두 차이점만을 전송하므로 네트워크 소통량 최소화.

  • 트리별, 파일별 접근 제어 리스트. 저장소 쓰기 접근을 가진 개발자라도 아무 소스나 수정하지 못하게 조절할 수 있습니다.

  • 저장소/프로젝트별 환경 설정 가능

  • 확장성을 염두에 둔 구조, 깔끔한 소스

  • 커밋 통지 메일 스크립트 기본 제공. CVS에서라면 스크립트를 따로 구해서 써야 하는 번거로움이 있었지만, Subversion은 기본 제공 스크립트를 이용해서 훨씬 손쉽게 설정이 가능합니다.



7 gimp #


8 tclock #


  • http://homepage1.nifty.com/kazubon/


  • 윈도우 2000 이하의 컴퓨터에서 타임 서버와 시간을 동기화시켜 주는 프로그램이다. 게다가 연도(Year), 초(Second)까지 보여준다.


9 quickSFV #


다양한 file verification 을 도와주는 유틸리티.

  • http://www.quicksfv.org

  • 10 winkey #


    윈도우에서 윈도우키의 활용을 더욱 높이는 유틸리티이다. 예를 들어 Win+P 는 프린터. Win+1 은 내 문서 등 다양한 기능을 넣을 수 있다.

  • http://www.copernic.com/winkey/

  • 11 sendmail #


    리눅스에서 메일을 보내는 서비스이다.

    11.1 특정 메일 서버에 메일이 가지않을 때 #



  • 리턴된 메일을 살펴보면, Domain of sender address userid@xxx.xxx.xxx does not exist 이런식으로 나와있을 수 있다. 그렇다면 저 xxx.xxx.xxx 가 실제로 보내는 메일 서버가 맞는지 확인해보고, 틀리거나 이상하다면 고쳐주자.

  • 11.2 특정 유저에게 보내는 메일이 특정 유저로 갈 때 #



    예를 들면 root 에게 보내면 zelon 이라는 유저로 간다. 이 설정은 다음의 파일을 찾아보자
    /etc/aliase
    ~/.forward
    


    11.3 갑자기 메일이 안 가고 /var/spool/mqueue 에 메일이 쌓일 때 #



  • sendmail daemon 을 껐다켜보자

  • 11.4 간단한 메일링 리스트 작동시키기 #



  • /etc/aliase 를 편집한다.
  • allmember:     zelon, zelon@microsoft.com
    everyone:       :include:/var/maillist/everyone.ml
    

    위와 같이 할 경우 allmember 로 보내면 zelon@localhost, zelon@microsoft.com 으로 주소가 날아간다. everyone 으로 할 경우 /var/maillist/everyone.ml 파일을 읽어서 메일을 보낸다. everyone.ml 은 다음과 같은 형식을 가진다.

    someone@some.com
    someone@som.com
    

    • aliase 를 편집한 후 newaliase 명령을 통해 메일 서버에 알린다.

    • 위와 같이 해도 안될 경우, 이미 allmember 와 같은 계정이 있거나, /etc/mail/virtusertable 과 같은 파일에 같은 이름의 메일주소 이름이 존재할 수도 있다.


    12 etc #


    • RAMDiskXP

    12.1 bittorrento #

    저도 C나 C++로 소스가 공개된 된 Bittorrent를 구해보려고 애써봤지만 
    소스가 괜찮으면 성능이 별로고 성능이 좋으면 소스가 별로였습니다. ㅠㅜ 
    
    그래서 이소스 저소스를 보다보니 프로토콜이랑 알고리즘에 대해 좀 
    알게 됐는데 도움이 될까 해서 써봅니다.. 
    
    일단 Bittorrent-이하 토렌트-의 탄생 배경 부터 보면, 사람들이 P2P 공유 
    프로그램을 사용하면서 실제로는 자기가 받을 것만 받고 나눠주지 않는 
    자비롭지 않은 행동을 합니다. 
    
    당나귀가 파일을 쪼개서 받으면서 서로 보내주게 해놨지만, 아시다시피 
    목적은 다운로드지 업로드가 아니기 때문에 업로드 속도제한은 반드시 
    다운로드보다 낮게 (최대한 0kbps에 가깝게 해놓습니다. 
    
    토렌트는 이 짓을 못하게 하려고 파일을 조각조각 나눠서 배포하되 
    아무 것도 없는 다운로더에게는 공짜로 조각을 약간 주고 그 조각을 
    가지고 함께 파일을 공유하고 있는 사람들끼리 교환 하도록 합니다. 
    나에게 많이 업로드 해줄 수록 고맙다고 내 것도 많이 주는거죠. 
    반대로 업로드를 많이 할 수록 다운로드 속도도 빨라지겠죠? 
    이걸 여러명이서 계속 돌아가면서 하고, 그 결과 다운로드 속도가 
    점점 빨라지게 됩니다. 
    
    따라서 자기 자신의 클라이언트를 수정(또는 해킹)해서 업로드 속도를 
    제한해도 업로드 속도가 잘 나와주지 않으면 날 친구로 생각해주지 
    않기 때문에 빨리 받고 싶다면 어쩔 수 없이 업로드를 좀 해줘야 됩니다. 
    
    토렌트가 채용한 파일 공유 방식은 
    
    1. 트랙커 프로그램을 깔면 일종의 웹서버 처럼 작동합니다. 
    2. 완전한 파일에서 만들어낸 metainfo 파일(트랙커 주소 포함)을 만들어서 등록 
    3. 완전한 파일을 가진 자신이 최초 시더(Seeder)가 됩니다. 
    4. 토렌트 파일(metainfo)을 누군가에게 줍니다. (웹배포 등) 
    5. 그 파일을 받은 사람이 토렌트 클라이언트 프로그램으로 트랙커에 접속하고, 
    6. 해당 metainfo를 다운로드 하고 있는 사람으로 등록됩니다. 
    7. 다운로드 하고 있는 사람들은 일정 시간마다 트랙커에서 목록을 갱신받아 서로 통신 합니다. 
    
    트랙커는 metainfo를 가졌지만 그안에 뭐가 들은지 모르는 우편배달부 
    처럼 되는거죠. 
    
    우리나라는 스토리지 사이트나 P2P 프로그램도 많아서 토렌트가 빛을 발하지 
    못했지만 외국에는 토렌트를 통한 파일 공유가 굉장히 활성화되어 있는데... 
    음.. 개인적으로는 우리나라만한 인프라가 없는 외국의 경우 큰 파일 공유에 
    적합하기 때문이라고 생각 됩니다. 
    
    단점을 따지자면... 공식 토렌트 사이트에서 배포하는 클라이언트는 
    자기가 가진 metainfo 파일 목록과 원본 파일의 무결성 확인이라던지 
    이런 개념이 전혀 없는 아주 단순한 다운로더 처럼 생겨서 파일을 
    다운받는 도중에 동료들이 많으면 참 좋지만, 받고난 다음에는 땡이라 
    파일의 공유 수명이 짧다는 문제가 있습니다. 
    
    하지만 공식 클라이언트는 단지 소스 공개 차원이고.. 요즘엔 Azureus, 
    ABC, BitTornado등 위 단점들을 보완한 공개 클라이언트를 많이 쓰지요. 
    이쁘기도 하고.. 
    
    게임 업체에서 토렌트를 파일 배포에 이용하려면 불편한 점으로는.. 
    
    1. 일반적으로 공유되는(동영상, 게임; 파일과 달리 회사 이외에는 
    Seeder를 해줄 사람이 없기 때문에 배포한 모든 파일에 대해 항상 
    Seeding을 하고 있어야 된다는 점.. 
    
    2. 고객들로 부터 걸려오는 전화. "인터넷이 느려졌다. 업로드는 왜하냐?" -> "어떻게 할 수가..." 
    이럴 경우 WoW처럼 프로그램에 업로드 제한 버튼을 넣어서 다운로드까지 느려지게 하는게 
    최선인가요? ㅡ_ㅡ;; 
    
    3. 트랙커 관리 스트레스 
    
    하지만 (특히 서비스 초기에) 많은 유저들을 상대로 고가의 CDN 비용을 
    들이지 않고 훨씬 빠르게 배포할 수 있는 아주 좋은 대안이라고 생각 됩니다. 
    
    ps. 상품 중 하나긴 하지만, 토렌트를 좀 수정해서 CDN서비스 업체도 사용하던데요.