Unix Programmer가 되려면?

geekforum의 이미지

저는 이것저것 안해 본게 없습니다. 하지만 결국 C로 돌아오더군요. 그래서 윈도 계열보단 유닉스 프로그래머가 되고 싶습니다. 그렇게 하기 위해서는 어떤 순서로 공부하는 것이 좋을까요?

저는 지금 "The C Programming Language"로 C언어를 다시 공부하고 있으며, 앞으로 "Advanced Programming In the Unix Environment", "Unix Network Programming", "The Design of the Unix Operating System" 등등을 읽어 나갈 생각입니다.

FreeBSD,RedHat Linux에서 환경에서 프로그래밍할거구요. 조언좀 부탁드립니다. Unix Programmer가 되기 위해서 나아가야 할 방향을...

익명 사용자의 이미지

대개 리눅스, FreeBSD를 다루는 사람들은 Kernel까지 건들릴정도가 되어야 진정한 무언가를 할 수 있다고 생각하는 경향이 있는 것 같습니다. 그러나 실재로 Kernel을 건드려서 뭔가 의미있는 작업을 하는 사람은 그다지 많지도 않을 것이고, 게다가 그런걸 누가 필요로 하지도 않을 것 같군요.
또 설사 건드렸다 쳐도 그렇게 건드린걸 한명이라도 믿고 사용해주면 대성공일듯 물론 자기 자신은 빼고.

가끔보면 Kernel Level의 함수를 Call하는 것만으로 뿌듯해하는 사람들도 있기는 하덥니디만.

디바이스 드라이버 개발하는 사람은 필수적으로 Kernel Level의 함수가 필요하니 좀 알기는 해야겠지요. 드바이스 드라이브 개발할 필요가 있는 곳은 하드웨어 밴더외에는 없을 것 같군요. Network 장비나 VGA카드, HDD 만드는 회사같은 곳.

그 이외라면 커널과 커널 레벨 함수로 장난 좀 친다고 누가 알아 주지도 않을 것 같군요. 장난은 장난일뿐 아무 것도 아니죠.

"리눅스가 장난감도 아닌데 장난 치지 맙시다."

User level로 가면 뭐 프로그래밍하는게 비슷합니다. 좀 개념이 다르다 싶은게 있기는 한데, Fork와 시그널이죠.

Win32에서는 Fork라는건 없고, CreateThread와 CreateProcess가 있습니다.
CreateProcess를 아주 희안하게 응용하면 Fork처럼 작동하게 만들 수는 있을 가능성은 있습니다. 새로 만든 Process 메모리에다 현재 Process의 메모리를 통채로 그냥 써넣으면 되겠죠. 물론 시스템이 공유하는 객체를 포함하고 있으면 이마저도 불가능합니다.

Win32에서 Thread를 주로 사용했고, Fork라는게 뭔지 모르면, 차차 알게 난 후, Fork가 프로그래밍하기에는 훨씬 더 쉽다는걸 알게 될겁니다. 다만 복제본끼리 뭔가 협력 작업을 할려면 시그널을 보내거나 Data를 Binding 해야하는데 이게 조금 까다롭죠.

Signal을 보내는건 SendMessage 보내는 것과 개념이 같습니다. 다만 Notify 하는건 아무래도 좀 다르죠.

Wni32에서 공유 메모리를 마치 파일 다루듯하는데, Linux에서도 그럴거라는건 안봐도 짐작이가죠. Linux에서는 네트웍도 마치 파일 다루듯 하니까요.

공유 메모리 사용할때는 반드시 동기화를 해야하는데 그렇담 mutext나 semaphore가 필요하겠죠.

고수들에게 이런건 어떻게 사용하냐 라고 물으면, 거의다 대답이 똑갑습니다.

'man 보고 찾아라'

대개 이 말은 자기도 정확히는 잘 모른다라는 반증이긴 하지만, 안다고 치더라도, 대체 어느 세월에 찾나요.

혹시 공유 메모리 이용할 이유가 있어서 사용하게 된다면, 사용중이거나 사용한 후에, 잘 사용하는 법이나 경험담 좀 알려주세요.

저도 아직 사용 못해봤습니다.

혹시 누구중 라이브러리 이름이라도 알면 좀 가르쳐 주세요.

간단한 예제로도 있으면 좋을련만. 예제 하나만 있으면 노력한 해석 능력으로 금새 써먹을 수 있겠는데, ...

익명 사용자의 이미지

이 글 배경에 깔린 논리가 아무리 생각해도 분명히 어디선가 본 듯한 느낌이 들어, 고민을 해봤는데, 오늘 저녁에 소주 한잔 걸치다가 결국 알아내고 말았습니다.

마이크로소프트사에서 줄기차게 밀어붙이고 있는 FUD입니다.

"리눅스 요즘 아무리 치고 올라온다 해봐야 일개 프로그래머에 불과한 너거가 내부 구조를 알면 뭘 알겠냐? 그냥 큰 형님께서 하는대로 API만 익혀서 따라오다보면 자다가도 떡이 생긴다."라는 논지 아닙니까?

이 글 쓰신 분... Identify yourself please.

PS) user level에 가면 프로그램 방법이 똑같다고 하는데, 정말 그런지요? 예륻 들어보시죠. 반례: X 윈도우도 user level에서 돌아가는 응용 프로그램이니까, 그 _빼어난_ 실력을 사용하면 딱 하루만에 이식하시겠군요. 유감스럽게도 Xext 라이브러리에 들어있는 (님 표현대로라고 하면) 신이 내리신 선물인 MIT _Shared Memory_ Extension 때문에 이식을 못한다에 저는 한 표 던지겠습니다.

익명 사용자의 이미지

(위 글 쓴 사람임)

공교롭게도 맥주 한잔 했는데, 이 글을 읽게 되었군요.
안그래도 술한잔하고 글쓰냐는 소리를 듣는판에 진짜 이렇게 되어 버렸네. 오늘은.

FUD가 뭔지??

추측하신 논지는 틀렸음.

이런 것임.
"해봐야 안된다고 말하는게, 아니라 할 줄도 모르면서 아는체 하지 마라."
할 줄 안다는게 고작 저기 아래 어떤 분처럼 kernel print문 정도 사용하고, 나도 커널 좀 만졌다라는 정도죠. 대체 이런게 무슨 가치를 가지는건지.

MIT_Shared Memory_Extension이라. 이게 뭔지 모르지만 이게 "신이 내리신 선물" 이라면 당장 자살하겠음. 신이 내린 선물이 굳이 있다면 그건 인간이 가진 양심일 것임.

프로그램 방법이 똑같다는건 무슨 말인지???? "하는게 비슷하다"라고 말하면 "하는 방법이 똑같은"건가?

이건 컴퓨터 과학의 문제가 아니라 국어 문제군요.

담부턴 술깨고 글쓰기 바람니다.

이렇게 쓴 글 읽고 나면, 분명 혈압 이빠이 오르겠군요.

...

익명 사용자의 이미지

Shared memory 에 mmap() 을 써야 한다는 것을 모르고 계시는 것인가요?

아니면 mmap() 을 써야 한다는 것은 알고 계신데 좋은 예제를 못찾으셔서 그런 예제를 올려주기를 원하시는것인가요?

익명 사용자의 이미지

잘 알면 자랑이라도 해보시지요?

그걸 굳이 꼬깃꼬깃 종이돈 감추듯 그렇게 말을 해야겠습니까?

게다가 오히려 님이 얼마나 아는지 그것도 궁금하군요.

익명 사용자의 이미지

원래 글을 쓰신분은 꽤 많이하신 분 같아 운만 띄워도 쉽게 아실것 같아서, 짧게 썼습니다. 원래 글쓰신 분이 아니신듯 하군요?

프로그래머가 라이브러리 펑션 하나 더 주워들어 놓았다고 뭘 자랑까지 하겠습니까? 구글에 대고 서치 한번 하면 누구나 5분이면 다 알게 될것을...

도움을 드리려고 별 생각없이 쓴 글에 적대적인 반응이 나오니 좀 황당하군요. 인터넷의 익명성 때문일까요...

hackbinkim 앳 3pardata 닷 컴

익명 사용자의 이미지

커널 공부는 무엇에 쓰기 보다는 진짜..

장난에 가깝지만 공부에도 도움이 됩니다 ^^

배워두면 좋고, 재미있고 일반 어플 프로그램 보다 재미 있더군요

그리고 요즘 임베디드다 머다 해서 조금 많이 쓰는거 같은데..

익명 사용자의 이미지

말만 빤지르르하죠.

임베디드에서 커널 건드린다고 해봐야 뭔가 달리 건드리는건 없고, 현재의 덩치큰 커널에서 필요없는 기능을 빼는 작업이 거의 90%입니다.

이런 일을 하더라도 커널을 좀 알기는 알아야하겠지요. 허나 진정 커널로 뭔가 했다고 보기에는 아무래도..

그리고 커널도 쭉 훝어 보다가 숫자 한두개 정도는 대개 그냥 막건드리죠. 뭐 건드려도 탈나는건 아닙니다만 그렇게 건드려서 성능이 더 좋아질지, 문제는 없는지 등등은 아무도 보증해주지 않습니다.

익명 사용자의 이미지

정 반대입니다.
임베디드에서 적어도 커널레벨에서 하는일은 자신에게 필요한 기능을 추가하는 일입니다.
필요없는기능 빼는건 소스 건드릴 필요없이 config면 충분합니다.
그 숫자한두개 바꾸는 일이란것조차도 그렇게 막건드릴수 있는일이 아닙니다.

익명 사용자의 이미지

님은 10%에 소속되신 분이십니다.
10%는 그냥 막연한 추측이고, 그냥 제대로 하시는 분이십니다.
앞으로 더 정진하시기 바랍니다.

익명 사용자의 이미지

커널을 이용해서 무언가를 하기 위해서 꼭 '진정 뭔가 했다고' 볼 일을 해야 하는 것은 아니지 않겠습니까?
그리고 "그렇게 건드려서 성능이 더 좋아질지, 문제는 없는지 등등은 아무도 보증해주지" 않는 것을 일컬어 '장난친다'고 하지 않던가요. 장난 좀 치는 게 무슨 문제가 있겠습니까. 장난치고 싶으면 치고, 싫으면 그만두면 되는 겁니다. 프로그래머로서 이것저것 해보려는 것을 그렇게 비하해 가면서 막으시려는 이유가 무엇인지 모르겠습니다.

익명 사용자의 이미지

안 막습니다.
다만 장난친건 장난으로 끝내라는 겁니다.
그리고 장난은 장난일뿐 그 이상 아무 것도 아닙니다.
장난치 놓고 나선 이건 이렇고 저건 저렇다 라고 말하지 말라는 겁니다.
진지하게 뭔가 하고 나서 아 이건 이렇고 저건 저런거구나 라고 말하는게 진정 필요하겠죠.

그리고 장난만 치는 사람이 대다수라고 추측이 되지만 아닌 사람도 있겠습니다. 그런 분이 굳이 장난치는 사람 두둔할 필요는 없습니다.

익명 사용자의 이미지

정확한 의미를 이해하기 위해서는 질문을 바꿔야겠군요.
"리눅스로 장난치지 맙시다." 라는 말씀은 어떤 의미인지 알고 싶습니다. '장난친다 = 장난치고 다 아는 체한다' 라는 것은 성립하지 않는 게 아닙니까.

처음에는 다들 장난 수준에서 시작하지 않습니까. 리눅스에서도 그걸 권장하는 분위기이고요. 그것이 반드시 필요한 과정이라고 주장할 생각은 없지만 또 굳이 반대하시는 것이 이해가 가지 않아서 그렇습니다.

익명 사용자의 이미지

GEEKFORUM의 댓글달기가 몇개까지 가능한지 갑자기 궁금해졌음.
한계에 도전하실분? 후후...

익명 사용자의 이미지

사실 리눅스는 장난감 맞습니다 ;-)

익명 사용자의 이미지

시스템 관리자가 리눅스를 장난감으로 본다면 그들의 직업적 특성상 이해 할수 있습니다만 프로그래머가 장난감으로 본다면 그냥 철모른다고 해야겠죠.

하룻 강아지 범무서운줄 모른다라는 속담도 있죠.

그리고 단지 커널을 만진다는 그자체가 중요한건 아니죠.

커널 소스 쭉 봐가면서 뭐 버퍼량 설정하는데 가서 숫자 한두개 바꾸는 짓 했다고 커널이 만지기 쉽네, 뭐 알고리즘이 이해하기 쉽네라는 말 하는게 좀 가당찮게 보입니다.

게다가 해보지도 않고 리버스 엔지니어링 하기 쉽네 어렵네 하는 것도 좀 그렇습니다. 물론 소스가 공개되어 있기에 아무래도 리버스 엔지니어링 하기에는 비교적으로 쉽겠죠. 왜냐하면 리스버 엔지니어링에 맞게 커널을 조작한다면 아무래도 작업하는데 도움이 되겠습니다.

윈도우에서도 SoftIce라는 걸 사용하면, 기계어 수준으로 라인 하나하나 실행해가면서 리버스 엔지니어링 할 수 있습니다. 실재로 윈도우 어플리케이션의 Lock을 깨는데 소프트아이스가 아주 큰 일을 담당하고 있죠.

자 만약에 누군가(직장 상사일수도)가 "커널을 고쳐서 지금보다 5%정도 성능을 향상시켜라"라고 대개의 경우는 "어 장난 아닌데", "미쳤나"라는 반응을 보일듯합니다.
그런데 "한번 해보겠습니다"라는 대답이 더 많을지도. 대개는 그런 말을 하지만 실재로 몇달이 지나도 output은 안나오죠.

실재적인 예로서 "파일 시스템을 장악해서 모든 I/O 스트림의 복사복을 특정 컴퓨터로 송신하게 하라"라는 과제는 한번쯤 들어 봤음직한데, 이거 쉬운 일이 아니죠.

뭐 대개 시키는 사람은 말은 잘합니다.

"어디 어디를 건드려서 어떻게 어떻게 해라. 그러면 된다." 라는 식이죠.

막상 이런거 해보시면 알게 되겠습니다만 "장난감"같은 소린 안나올겁니다.

익명 사용자의 이미지

제 앞에 외계인 인형이 하나 있습니다.

제가 이걸 장난감으로 생각하려면 이 인형을 뜯어고쳐서 바비인형으로 만들 수 있어야 하는 겁니까? 그냥 색깔만 고치고 옷만 갈아입히는 수준에서는 장난감으로 생각할 자격도 없는 건가요?

익명 사용자의 이미지

외계인은 외계인이어야 하지 그걸 꼭 굳이 바비로 바꿔야 하겠습니까?

그렇게 꼭 장난쳐야 겠다하면 뭐 말리지 않습니다만,
그런데 바뀌고난 바비 인형이 안봐도 흉칙할거라는건 쉽게 알 수 있죠.

그런 흉칙한 바비 보다는 외계인이 낫습니다.

익명 사용자의 이미지

인형 수준에선 그 정도로 장난감이겠죠...

익명 사용자의 이미지

생각보다 커널을 고치는 것은 어렵지 않습니다.
물론 메모리관리나 프로세서 관리 이런 부분은 어렵겠지만,

그 외의 부분은 천천히 동화책읽듯이 차분한 마음으로 소스를 읽어 가면,
대략 이해가 됩니다.
그리고, 의외로 커널소스를 고침으로서 이득을 보는 경우도 많습니다.
다들 굳이 커널 소스까지 고쳐가며... 라고 생각해서 접근하지 않을 뿐이지,
막상 해보면, 처음에 리눅스를 접해서 APM 설치하던 것과 크게 다르지 않음을
느끼실 겁니다.

물론 커널을 수정해서 사용하면, 새 커널 나올때 마다 패치를 점검해야 하는
골치 아픈 문제도 있지만,그냥 윈도우 바탕화면 색깔 바꾸듯이 자신에 취향에 맞게 고쳐 사용하는 것도 매우 즐거운 일입니다.
(특히 소스를 볼수 없는 프로그램의 리버스 엔지니어링에는 그만입니다.)

익명 사용자의 이미지

커널 고치는거야 초딩도 하죠

HZ 값을 100 에서 한 1000 쯤 해서 내가 리눅스 성능 향상 시켰어(?)

이런말 할수도 있는거구요

쿠쿠

나도 커널 해커다~

익명 사용자의 이미지

실재적인 경험담을 하나 말씀해주시면, 보다더 신뢰성이 있는 글이 될거라는 생각이 드는군요.

구체적으로 커널의 어디를 어떻게 건드렸더니 어떠어떠했다 라는 식으로 말이지요.

지리즈의 이미지

저 같은 경우는
스팩 측정을 위한 산업용 하드웨어 밴치마크(하드드라이브) 프로그램을
돌리는데, 이 놈이 하는 테스트 내용을 알고 싶어서,
IDE관련 부분에 print_k 열심히 삽입했던 것이 기억이 나는군요.

There is no spoon. Neo from the Matrix 1999.

익명 사용자의 이미지

편하게 쓰시려면 Perl을,

깊이 쓰시려면 C를 마스터 해야 합니다.

ToT.

익명 사용자의 이미지

유닉스를 정석대로 배워두면 임베디드 업계에서도 유용하게 써먹을 수 있습니다. 예를 들어 휴대폰, PDA, 기타 가전기기 등등...

익명 사용자의 이미지

정말 시스템 프로그래밍의 대가가 되시려면,
적어도 커널까지는 공부하셔야될것으로 생각됩니다.

익명 사용자의 이미지

제가 권장하는 유닉스 프로그래머로의 접근방법은 다음과 같은 순서입니다.
1) file system처리
APUE(Advanced Programming in the Unix Environment)에서 이 부분에 대한 것을 숙달하시는게 좋을듯하고요. 기본 시스템 호출(system call)인 open/close/read/write/lseek과 ioctl을 잘 사용한다면 좋겠습니다. 부수적으로 몇몇 시스템호출들이 있지만, 이것만 확실하게 알아도 좋지요. 이유는 유닉스가 모든 것을 파일로 보는 관점에서 제작되었기 때문입니다. 파일처리에 능하다는것은 좋은 것입니다.
내부적인 이론은 님이 제시하신 Design of the Unix Operating system에서 아주 훌륭하게 기술하고 있습니다. 특히 버퍼캐시, inode부분의 기술은 여러 유닉스 관련 서적 중에서 타의 추종을 불허한다고 여겨집니다.

2) process
다수개의 프로세스로 구성된 프로그램을 만들어봐야 겠지요. fork(), signal()관련은 기본이겠구요. thread처리까지 갖춘다면 좋겠지요.(사실 저는 thread를 그리 선호하지는 않습니다요)
단연 프로세스동기화(process synchronization) 메커니즘에 속하는 signal처리 부터 다음에 제시한 IPC에 대해 공부하셔야 할것니다.

3) IPC
가장 원초적인 동기화 메커니즘인 signal/wait부터, FIFO, PIPE, 메시지큐, Semaphore, shared memory 그리고 고수준 IPC인 socket레벨 인터페이스를 갖춘다면 좋겠습니다.IPC메카니즘은 Unix Network Programming 6장 정도까지가 좋습니다.

이 3가지가 기본적으로 해봐야 하는것이라고 생각됩니다. 이것을 갖추면 기본은 갖추었다고 감히 얘기할 수 있습니다.
이러한 것을 한 이후에는 유닉스의 용도 및 개발 방법론을 생각해 볼 필요가 있습니다.
유닉스 시스템은 여러 용도로 사용가능하겠지만, 단연 서버시스템이 아닐까? 하는 생각을 가집니다. 서버 시스템 프로그램을 하기위해서는 IPC메커니즘중에서 가장 상위레벨에 있는 socket인터페이스를 면밀하게 해봐야겠지요.
Unix Network programming 2nd edition Volume 1을 보면 소켓인터페이스를 보다 상세하게 소개하고 있습니다. 어찌 보면 자잘한것이 너무 많은 듯도 하지만, 상세히 볼 필요가 있습니다.

여기까지 다 되었다면, 이젠 특정 서버시스템을 들여다 볼때가 된 듯합니다. 훌륭한 예제 서버들이 다양히 있지요. 메일서버, 웹서버등등
이러한 서버들중 하나를 잘 골라서 설치부터 분석까지 해본다면, 다시말해서 하나만 꽉잡으면, 유닉스 시스템 프로그램 고수라는 소리를 들을 수도 있지 않을까? 합니다.

익명 사용자의 이미지

socket이야기를 말씀하셨는데,

IPC의 연장이라고도 볼수 있는 네트워크 프로그래밍도 중요하더군요..
IPC도 네트워크 프로그래밍도 실제로 그 문법자체는 어렵지 않지만,
활용을 위한 구조 설계면으로 들어가면, 정말 공부할 부분이 많습니다.

snowtree_의 이미지

상세한 설명 아주 감사 드립니다.
아래 부분에 "수요가 있나요?" 라고 질문 하신 분이 계신데..
정말 자기가 하고 싶은 일을 하면서 그 일이 자신의
생계유지 수단에도 도움이 된다면 참 좋은 일일 것 같은데요..
혹시 지금 하고 계신 일이 무엇인지 알려주실 수 있는지요 ?
그리고, 유닉스 프로그래머가 필요한 산업군에 대해서도 아시는 것이 있으면
조언 부탁드리겠습니다.

익명 사용자의 이미지

좋은 설명 감사합니다~!! ^.^

익명 사용자의 이미지

리눅스쪽은... O'Reilly 의 Understanding the Linux Kernel(2.4.x용은 아직안나온듯) 과 Linux Device Drivers(2nd Edition은 2.4.x) 도 기본을 공부하기 좋은 책이라 생각합니다..

익명 사용자의 이미지

이건 다른 분들에게 묻고 싶습니다.

수요가 있나요? 제가 볼땐 그런쪽으로

인력을 구하는 곳은 극히 소수인걸로 아는데..

설령 유닉스 프로그래머라 해도 VC++ 다루던

사람이 업무상 맡게 되는 경우가 많지

않은지..?

익명 사용자의 이미지

통신 장비들도 UNIX 개열을 OS로 사용하는 경우가 많습니다.
저는 이동통신 쪽에 있는데 휴대폰 돌아가도록 만들는
네트워크쪽 장비는 대부분 UNIX개열을 사용합니다.

익명 사용자의 이미지

수요가 상당히 있습니다. 유닉스 시스템이 아직도 많이 팔리고 있지 않습니까. 대기업형 SI업체에서 많이 뽑아갑니다. 윈도우즈 프로그래머보다는 좀 더 접근하기가 어려운 것이 문제죠. 유닉스 프로그래머로 성장하려면 대학교 전산관련과를 졸업하는 것이 좋다고 생각합니다.

익명 사용자의 이미지

아직도 금융 전산망쪽은 유닉스 시스템들이 많습니다.

익명 사용자의 이미지

아직도??

대부분이 다 UNIX 아닌가요?

국가 기관의 장비도 다 UNIX 로 돌아가는걸로 알고 있는데?

금융도 워낙 크리티컬하니까 당연히 UNIX죠.

익명 사용자의 이미지

다는 아니더군요. -_-;

물론 DB나 중요부분은 유닉스를 쓰지만,
미들웨어나 웹서버같은 것은 Windows를 쓰는 곳도 많더군요...

익명 사용자의 이미지

금융권(증권,은행,보험 기타..)에서는 메인프래임을 씁니다.

중요한 부분( 계정계 - 실제로 돈에 관한 모든 처리를 담당 )에서는 거의
그렇습니다. 그 외의 조회성, 정보성의 성격에는 부분적으로 유닉스를
도입했습니다.

실제로 컴퓨터의 규격,용량으로 보았을 때,

유닉스는 소형컴퓨터입니다.

그럼 PC 는 무언가요? 마이크로 컴퓨터 .. ㅡ.ㅡ;

돈많이 드는 대용량에서 소용량의 협업으로 가자고 나온 개념이
Downsizing 인데요.. 그 용도로 적합한 게 유닉스죠..

근데, 상당수의 기업들이 다운사이징에 실패....
그 동안 만든 프로그램을 다운사이징에 맞게 고치려니.... 죽을 맛이었겠죠.

결국 다시 메인프래임 + 코볼 + DB2 or H-DB 형태로 가고 있더군요.

근데 어째서 이런 얘기나 나왔을까??

....

당초 주제에서 좀 벗어났네요.. ㅎㅎ.

익명 사용자의 이미지

중요한 부분은 유닉스를 쓰지 않고 메인프레임을 씁니다.

익명 사용자의 이미지

유닉스랑 메인 프레임이랑 차이점이 뭐에요?

위즐의 이미지

왜죠? 돈이 남아돌아서 일까요?

익명 사용자의 이미지

돈이 남아돌아서라기 보다는
메인프레임이 검증된 안정성에서
더 높은 점수를 받기 때문이겠죠.
잘 돌아가는 걸 굳이 위험을 감수해가면서
유닉스로 바꿀 필요가 있을까요?

(신문에 지나가면서 봤는데, 외환은행이
유닉스로 바꾸고 있다는 걸 본 적은 있습니다만..)

bookworm_의 이미지

전문적으로는 아니어도 솔루션을 개발하다가 보면
C 로 만들어진 각종 모듈 & 데몬이 많이 필요하더군요.
--
Bookworm

Bookworm

페이지