(4) 하위 호환성 (Legacy)

inureyes의 이미지

이번 글은 TT 1.1 완료되면 써 보고 싶었다. 그러나 현실은 냉혹해서, 스케쥴대로 모든게 되는 것은 아니다. TT 1.1과 관련하여 상위 호환성(하위 호환성이 아니다)에 대한 여러 생각을 하게 되었다. 상위 호환성에 대해서는 다음에 이야기해 보고 (다음으로 미룬게 몇갠가 도대체 ㅠ_ㅠ 번호는 이제 4인데...) 이번에는 예전에 적었던 하위 호환성에 대한 글을 좀 다듬어 재탕으로 올려본다.

레거시라... 공간적으로도, 시간적으로도 존재하는 그 무엇.


컴퓨터는 무언가의 희생없이
호환성을 얻을수 없다
무언가를 얻기위해선
대등한 대가가 필요하다
그게 컴퓨터 업계의 레거시의 법칙
그시절 우리들은
그것이 세계의 진실이라고 믿고있었다.

- 강철의 코딩술사 中 -

처음 컴퓨터를 만나던 1990년 당시에는 컴퓨터의 과거가 컴퓨터의 현재에 어떤 식으로 영향을 미치고 있는지 전혀 몰랐었다. 오랜 시간이 지난 지금, 이제야 알게된 과거로부터의 발목잡기에 대하여 몇가지 적어보고자 한다.

우선, 언어의 다양성을 보자. 대학의 컴퓨터 공학과에서 배우던 언어의 개수를 한 번 세어보자. 저급언어부터 세어보면,
MASM
Gcc, Turbo-C, MS Visual C
Fortran, Pascal, Java, MATLAB
LISP
가 된다. 이 목록을 보며 시간과 공간에 관한 두 가지 이야기를 할 수 있다.

*

MASM이야 CPU를 구워 만들어야 하는 3학년을 위하여 준비된 과정이니 논외로 치자. 지금 와서 컴파일러도 제대로 안나오는 Fortran이나 Pascal은 왜 배워야 하는 것일까? 대답은 의외로 간단하다. "지금도 그 언어가 쓰이고 있기 때문" 이다. 특히 물리학 분야에서는 더욱. (저 두 언어는 전산물리에서 데굴데굴 굴러가면서 배우게 된다.)

오래된 프로그램들은 Fortran이나 Pascal로 작성되어 있다. 그러한 프로그램들을 C로 고쳐주는 프로그램이 있으면 좋겠지만 불행히도 그러한 프로그램은 없다. 오래된 물리학자나 컴퓨터공학자들은 여전히 Fortran을 선호한다. 20년 전의 프로그램들을 이해하기 위해서 위의 두 언어는 전혀 필요가 없어 보이는데도 배워야 한다. 단지 에전의 프로그램들이 존재하고, 아직까지도 작동하기 때문이다.

이러한 문제가 위의 경우처럼 학문적인 경우에만 머물러 있으면 문제가 크지 않을텐데, 사실은 그렇지가 않다. 1990년대 말, 수많은 기업들은 Fortran과 Pascal을 할 줄 아는 프로그래머들을 찾아 온 세계를 헤매고 다녔다. Y2K 문제를 해결해야 하는데 소스코드를 이해할 수 있는 사람들이 별로 남아있지 않기 때문이다. 이러한 이유때문에, 컴퓨터를 공학이든 과학이든 사용하려는 사람들은 결국 컴퓨터계의 라틴어인 저 두 언어를 배우게 된다. EQUIVALENCE(A,AB,AC) 의 명령어는 세 변수가 같은 변수임을 의미한다. 왜 있을까? 프로그램 입력을 위한 천공카드에 구멍을 잘못 뚫는 경우에 다시 뚫기 힘드니까 존재한다.

NASA에서는 70년대 띄운 위성들의 데이터를 해석할 수가 없어 문제가 되었다. 당시의 데이터가 어떤 컴퓨터 구조에서 어떤 형식의 데이터로 저장되어 있는지 알 수 없기 때문이다. 게다가 이제는 테이프를 읽을 리더도 구하기가 힘들다. 만약 집에 8비트 애플 컴퓨터의 '벽돌깨기' 테이프가 있다면 어디에서 재생할 수 있을까? 5.25인치 드라이브도 이젠 찾기 힘들다. 테이프를 마지막으로 사용한 것이 90년이었으니 이제 15년밖에 되지 않았다. 5.25인치는? 최근에는 3.5인치 플로피디스크 드라이브도 찾아보기 힘들다. 표준 PC 사양에서 제외되었기 때문이다.

*

다음의 문제는 위의 경우처럼 빨리 변해가는 시간 때문에 발생하는 문제가 아니라 공간적인 영역, 실제 보이지는 않지만 기업간에 존재하는 영역의 차이로 발생한다. 'C라고 다같은 C인가?'

네가지의 C를 사용했다. 프로그래머들이 모두 그렇듯이 프로그램을 하나 작성하면서 많은 모듈들을 만들게 되었다. 그 중 유용한 모듈들은 당연히 다른 프로그램을 작성할 때에도 사용한다. 처음에는 별다른 문제가 없었다. C를 바탕으로 작성한 프로그램들이니 코드가 호환된다고 생각해 왔고, 대부분의 경우 그렇게 작동을 해 왔기 때문이다.

문제는 2001년 말부터 본격적으로 터지기 시작했다. 메모리를 직접 다루는 루틴이 많아지면 많아질수록 모듈들은 충돌했다. VC가 Unix의 gcc보다 메모리 부분에서의 에러를 컴파일러 단계에서 처리해 주는 경우가 많기 때문이다. 또한 메모리 참조의 경우, 메모리 참조를 하는 포인터가 가리키는 양이 차이나는 경우도 발생했다. 또한 라이브러리 문제도 있다. Itoa와 atoi는 대부분의 프로그래머들이 알지만, itoa는 VC에만 존재하는 명령어이다. (MSDN에 보면 itoa64라든지 하는 희한한 명령어들도 존재한다.) 이런 문제는 복잡한 문제이지만 정말 간단한 예들도 있다. 특정 경우에는 For문에서 쓰이는 명령어들 중 i++를 처리하는 방법이 C마다 다르다. 결국 하나의 C 프로그램이 작동하기 위해서는 ANSI C 규격을 지켰음에도 운영체제에서 원활하게 돌기 위해서는 수정을 해야 하는 것이다.

위의 예는 간단한 경우이다. 회사마다 컴파일러에서 오류 처리하는 법이 다를 수도 있고, 오류를 가지고 있을 수도 있기 때문이다. 그런데 같은 컴파일러에서 문제가 되는 경우도 있다. 2001년 말이었다. 텔넷 BBS 서버 프로그램 하나를 새 리눅스 머신에서 컴파일하는데 동작하지 않는 것이다. 왜냐? gcc 버전이 올랐기 때문이다.

컴파일러도 결국에는 프로그램이다. 컴파일러가 오류를 가지고 있을 가능성도 있다. 그럼 오류가 발생하면 일반적으로는 gcc처럼 컴파일러를 수정하면 되지 않을까? 문제가 바로 위에 있다. 오류를 수정하고 라이브러리를 개선하는데에는 레거시가 문제가 된다. 이에 대한 대처는 다양하다. '죽어도 레거시 버그라도 레거시'를 주장하는 쪽이 있는가 하면, '절대 완벽'을 주장하는 쪽도 있다. 그리고 지금까지는 전자가 항상 후자를 이겨왔다. 컴퓨터를 사용하는 것은 사람이니까.

소프트웨어의 레거시를 이야기했는데, 하드웨어에 비하면 소프트웨어의 레거시는 양반이다. 지금의 개인용 컴퓨터 구조는 '이름도 거룩하사 IBM PC' 가 나온 이후로 커다란 변화를 겪은 적이 없다. 초창기의 기괴했던 보드 구조들 -예를 들자면, 마더보드가 따로 존재하지 않고 CPU조차 ISA 버스에 카드 형식으로 꽂히고 컨트롤러도 카드 형식으로 연결되는- 을 제외하면, AT 구조 이후로 하드웨어 구조의 레거시는 근 20년동안 그대로 유지되어 왔다.

예가 있다. 윈도우 95가 나와 Plug and play가 가능하게 되어도 실상 장치수는 15개의 IRQ (interrupt queue) 수로 제한되었다. 왜 15개인가? 8비트 시절의 버스 구조 컨트롤러의 레거시를 위해 당시의 8비트 컨트롤러를 그대로 유지해 왔기 때문이고, 결국 x86이 올라가면서 1비트를 희생해서 똑같은 8비트 컨트롤러를 직렬연결하는 방식으로 사용했기 때문이다. 결국 ACPI 가 나와서 다중 장치들을 하나의 IRQ에 할당하는 방식을 사용하기 시작했지만 윈도우 2000이 나오기 이전에는 제대로 지원하는 운영체제조차 없었고, 결국 2002년에 와서야 APIC가 나오게 된다. IDE는 구조의 불안정성과 속도의 문제에도 불구하고 LBA의 개념과 PIO, 디스크 컨트롤러에의 DMA의 도입을 거쳐 UDMA까지 '안 망하고' 이어져온다. 성능때문일까? 농담이겠지. 모두 레거시 때문이다. CPU 아키텍처 이야기는 입만 아프니 생략.

*

Sony사의 Play Station 2가 처음 세상에 나왔을 때 내세운 장점이 두 가지였다. 하나는 DVD video 재생 지원, 나머지 하나는 PS1에의 레거시 지원이었다. PS1의 레거시를 보장하기 위하여 소니는 무리수를 두었다. PS1의 CPU를 PS2에 내장하는 방식으로 (컨트롤러 칩으로 사용한다는 명목으로) 레거시를 보장한 것이다. 결과는 성공적이었다. 전자는 가전제품으로서의 보급을, 후자는 게임기로서의 보급을 가져왔다. MS는 Visual Studio.net을 출시하면서 예전의 이상한 처리 루틴들도 그대로 (혹은 어쩔수 없이) 가져왔다. 덕분에 PS2는 동시대의 기종 중 최악의 입력장치를 -10년동안 변화가 없는- 가지게 되었고, MS는 엄청나게 복잡해서 가끔 에러를 에러라 말하지 못하는 컴파일러를 가지게 되었다.

한때의 신기술이 어느순간 족쇄로 변하는 모습은 역사에 언제나 존재해왔다. 단지 지금은 그 변화의 속도가 너무 빨라서 레거시를 유지하는 것이 엄청난 장점이 되기 때문에 유지될 뿐이다. 다행인 것은, 예전에는 발전의 속도가 느렸고 발전이 압도적이었기 때문에 우리는 옆에 촛대가 달린 전구를 쓰지 않아도 되고, 마구용품이 앞에 달린 자동차를 타지 않아도 된다는 점이다.

얼마전에도 기숙사 공용 컴의 AGP와 PCI와 ISA의 IRQ 충돌을 해결하고 온 상황에선 촛대달린 전구는 충분히 있을법한 일로 여겨진다. =_= 안타깝지만.

댓글

cppig1995의 이미지

옛날에 C FAQs에서 읽었던게 생각나서 말씀드리자면,
Pascal -> C와 FORTRAN -> C 모두 존재합니다 (완벽하진 않지만요).
http://cinsk.org/cfaqs/html/node22.html#SECTION002260000000000000000 참고하세요.

PS. 좋은 자료 번역해 주신 cinsk님께 항상 감사드립니다^^

Real programmers /* don't */ comment their code.
If it was hard to write, it should be /* hard to */ read.

inureyes의 이미지

가능은 하지만, 역사가 좀 흐른 학문들(예를 들어 물리학)에선 쉽게 인정을 해주질 않습니다. FORTRAN이 아직 쓰이는 이유는 단순히 코드의 레거시 문제 말고도, 라이브러리가 오랜 세월동안 검증을 받았다는 이유도 있거든요. :) 변환시에 제대로 변환되었다는 것을 주장하려면 그것 또한 연구 주제가 될 정도입니다.

(실제로 IMSL등을 들여다보면 마지막 수정일자가 1972년인 라이브러리들도 있습니다^^)

물론, 최근에 부상한 학문들의 경우에는 라이브러리들이 C로 개발된 것들도 꽤 있습니다. CERN의 ROOT나, GNU를 따르는 GSL이 대표적입니다.

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

warpdory의 이미지

Pascal 또는 Fortran -> C 로 바꿔주는 자동화 툴은 몇가지 존재합니다만 ...
여태까지 '제대로' 되는 걸 그다지 본 기억이 없습니다. 차라리 기존의 포트란 또는 파스칼 소스를 쭉 .. 프린터로 뽑아놓고, 그것을 다시 C 언어로 사람이 번역하는 게 더 '제대로' 돌아갈 겁니다. 물론, 속도는 자동화 툴보다는 무지하게 느려지겠지요.

포트란 교재에 있는 내용 정도를 C 로 바꾸는 거야 별다른 문제가 없겠지만, 정작 필요한 것들(제가 예전에 했던 경우라면 소숫점 이하 32 자리 정도의 정밀도 ...)은 처음 의도와는 다르게 완전히 다른 결과를 보여주는 것이 많았기 때문입니다.

물론, 윗분께서 말씀하신대로, 요새 나오는 라이브러리 같은 것은 C 로 나오는 경우도 많고, 요새 전산 물리학 등을 전공하는 사람들은 처음부터 C 로 공부하는 경우가 많기 때문에 C 로 많은 부분 옮겨가고는 있습니다만 ...
말 그대로 Legacy 코드는 그 양도 무지하게 많을 뿐더러, 지금 잘 돌아가고 있는 걸 굳이 시간 들여가며 C 로 바꿀 필요성을 거의 느끼지 못하기 때문입니다. 누가 C 로 잘 돌아가게 바꿔준다면 C 로 된 코드를 쓰겠지만, 굳이 그런 일을 하는 경우는 거의 없습니다.

물론, 저도 처음에 포트란 77 을 공부할 땐 무지하게 욕하면서 (C 의 포인터 공부할 때 나왔던 욕 이상으로...) 배웠었지요. 그리고, 아마 제가 짰던 코드를 들여다 보고 있을 후배들은 제 욕을 하고 있을 겁니다. 사실, 지금 제가 봐도 뭐라고 짠 건지 모르겠어요 -_-

---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.
http://akpil.egloos.com


---------
귓가에 햇살을 받으며 석양까지 행복한 여행을...
웃으며 떠나갔던 것처럼 미소를 띠고 돌아와 마침내 평안하기를...
- 엘프의 인사, 드래곤 라자, 이영도

즐겁게 놀아보자.

inureyes의 이미지

아.. 마지막 문단이 너무 와 닿습니다^^;

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

feanor의 이미지

두 가지 지적하겠습니다.

1. Fortran에 EQUIVALENT라는 명령어는 없습니다. EQUIVALENCE입니다.
2. 천공카드 이야기는 거짓말 같네요. EQUIVALENCE의 원래 목적은 메모리 절약입니다. 그 외에 C의 union 형과 비슷한 용도로도 사용됩니다.

inureyes의 이미지

옙 수정하였습니다. 하도 오래되어서 가물가물하네요^^

천공카드 이야기는 맞을겁니다. FORTRAN의 초창기부터 지원했던 명령이고, 지금은 컴파일러 구현 단계에서의 여러 문제로 권장하지 않는다고 배웠습니다. 50,60년대에 FORTRAN 컴파일러 관련한 일을 하신 노교수님께 들었습니다. :)

(포트란이 세계 최고의 언어라고 주장하시는 것만 빼면 참 좋으셨는데...)

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

palsuet의 이미지

포트란이 컴파일러도 제대로 안나온다는 말씀은 오해인 것 같습니다. 여전히 많은 회사들이 포트란 컴파일러를 만들고 있습니다. 인텔의 경우만 해도 윈도우, 리눅스, Mac OS X 용의 포트란 컴파일러를 제공하고 있고 썬, IBM 등에서도 찾아볼 수 있습니다. 저도 인텔의 포트란 컴파일러를 사용하고 있습니다. MS에서는 안나오긴 합니다만...
--
feel the gravity

feel the gravity

inureyes의 이미지

옙- 제가 설명 없이 써서 오해가 생겼습니다. 저도 속도 문제로 인텔 포트란 컴파일러를 사용하고 있습니다. :)

위에서 컴파일러가 제대로 안 나온다는 이야기는 사실 f90이 확립된지 시간이 흘렀음에도 아직까지도 그 규격을 완전히 지원하는 컴파일러가 등장하고 있지 않다는 이야기였습니다. (지금은 f95까지 나왔죠)

워낙 오랫동안 규격에 변화가 없었기 때문이기도 하고, 다르게 보면 그렇게 변한 f90이나 f95를 사용하느니 그냥 c나 파이썬으로 갈아타는 것이 낫다고들 생각하고 있기 때문인듯 합니다. 그런 의미에서 위의 표현을 쓴 것인데, 말하고자 하는 바를 위해 쓱쓱 쓰다보니 굉장히 뛰어넘은 느낌이 있네요. 다음부터는 주의 하겠습니다^^

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

죠커의 이미지

저는 과연 레거시 만의 문제일까라고 가끔 생각을 합니다. IA32 아키텍쳐만 해도 옛날이나 지금이나 비난하는 사람은 넘쳐납니다만 예전이나 지금이나 그만큼 만만하고 경제적이고 적절한 성능을 제공하는 아키텍쳐는 찾기 힘들다고 생각합니다. 이전이나 지금이나 더 만만하고 경제적이고 적절한 성능을 제공하는 솔루션은 환상에서만 찾을 수 있는게 아닌가 합니다. 잘난 RISC 칩 중에 펜티엄 듀얼 코어를 상대할만한 녀석이 있을까요. 이론적인 가능성을 규모의 경제가 압도했습니다. 지금 RISC 칩을 새로운 기술로 만든다고 하더라도 발매 시기에 나올 펜티엄 시리즈 보다 효과적이긴 힘들 것입니다. 그때 나오는 펜티엄 시리즈는 지금 사람들이 인식하는 한계보다 더 강력한 결과를 보여줄 것입니다. 물론 레거시를 고려하지 않았다면 이상적으로는 발전할 가능성이 있었을 것입니다. 하지만 그 이상이 현실이 되는 일은 매우 드물 것입니다.

그리고 플스 2가 플스 1의 코어를 I/O칩에 내장하였지만 그 것이 컨트롤러가 그대로 유지된 것의 원인이라고는 생각하지 않습니다. I/O칩에 의해서 외부 인터페이스가 결정된다면 8255로 만들어진 제품은 모두 동일한 외부 인터페이스를 가지고 있었을 것입니다. 어느 정도 정책적인 면이 강하게 적용한 것이라 생각합니다.

- CN의 낙서장 / HanIRC:#CN

inureyes의 이미지

PS1과의 레거시를 위해서 PS1의 코어를 I/O 칩으로 내장했고, PS1 게임 조작의 호환성을 위해서 컨트롤러를 못 바꿨죠^^ 어느쪽이든 PS1 레거시의 영향을 받았습니다. :) 그런데 PS3까지 올 줄은 몰랐습니다 윽;

IA32가 계속 쓰이는 것도 결국 레거시의 문제이고, IA64가 완전히 시장 실패를 경험한 것도 레거시를 무시했기 때문이라고 생각합니다. 아마 CN님이 말씀하시는 레거시와 제가 설명하는 레거시의 범위가 차이가 나는 것 같습니다^^

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

죠커의 이미지

레거시의 의미의 차이가 나는지는 모르겠습니다만 PS의 콘트롤러와 관련해서 얘기를 하겠습니다. PS1의 코어를 I/O칩에 내장한 것과는 별개로 PS2의 I/O는 PS1에 비해 확장되어 있습니다. PS1에서 만들기 힘들었던 주변기기도 PS2에서는 등장하기도 했습니다. 제 생각엔 PS의 콘트롤러가 저급한 것은 어느 정도 정책적인 면이 강한게 아닌가 생각합니다.

저는 IA32가 계속 쓰이는 이유 중의 하나가 성능이 경제적이다고 생각합니다. 이 강력함은 이론적인 강력함과일치하지는 않습니다. 인텔 호환 아키텍쳐만큼의 성능을 가진 다른 하드웨어를 일반인이 구하는 것은 힘이 듭니다. 보급의 측면도 있겠고 규모의 경제도 있겠지요. 일반인들이 다른 하드웨어 정보에 어둡다는 정보의 측면도 있을 것입니다.

물론 기존 제품들이 계속 쓰이는 이유 중 가장 강력한게 호환성이겠습니다. 거기에 대해 이견은 없습니다. 하지만 그 이외의 이유들도 무시할 수 없다고 생각합니다.

- CN의 낙서장 / HanIRC:#CN

마잇의 이미지

하드웨어의 예를 주로 드셔서 좀 다른 얘기가 되겠지만 소프트웨어쪽을 이야기를 해보겠습니다.

이전 버전은 이전 버전대로 지원하고 새 버전은 새 버전대로 새로운 기법과, 자료 형태, 이러저러한 새로운 시도들 하려는 것은 일종의 환상이 아닌가 합니다. 양립할 수 없는 것을 제한된 자원안에서 추구하려다 보니 여기저기 삐걱거리기 마련이라는 생각입니다.

그것이 가능하다 하더라도 그만한 투자 가치가 있는지도 심각히 생각해봐야 한다고 생각합니다. 그것을 가능하게 하면서 가지게 되는 피해를 사용자들이 원하고 있는지도요.

어쨌든 가장 자연스러운 것은 쓰던 것은 그대로 쓰게 두고 새로운 것은 새롭게 쓸 수 있으면 된다고 생각합니다. 하지만 새버전을 판매해야 되는 입장이 되면 이렇게 못하게 되죠.

문제는 항상 여기에서 생기는 것 같습니다. 구버전 사용자를 신버전 구매자로 끌어들여야 하니 무리해서라도 하위 호환을 제공하려고 하죠. 갈아탈 이유가 없는 사용자들에게 유혹의 손짓도 해야하고 진보된 성능과 새로운 기능을 원하는 사용자들도 끌어들여야 하는데 이게 쉬운일만은 아니겠지요.

이렇게 하다 양쪽으로부터 많은 원성을 사거나, 결국 망해버린 소프트웨어들을 많이 봤습니다. 죽도 밥도 안된거죠.

리눅스와 자유 소프트웨어를 접하기 전까지는 솔직히 기업들의 수익 때문에 이런 부분을 어쩔수 없다고 생각했었는데 이제는 생각이 바뀌었습니다.

2.4 커널하고 아파치1.3으로 잘 사용하고 있으면 2.6과 아파치2에 눈돌리지 않아도 됩니다. 새로운 것이 실패작이라고 느껴지고 다른 사용자들도 그렇게 느낀다면 현재에 머무를 수 있는 자유로움을 누릴 수 있습니다. 외부의 압력을 받지 않습니다.

KDE 4를 개발하는데 3.x에서 돌던 프로그램들이 다 돌게 해야 하느냐? 글쎄요. 저는 그렇게 중요하다고 생각하지 않습니다. 그게 중요하다면 그냥 3.x를 사용하면 됩니다. 4에서는 4만의 무엇을 보고 싶은 거지요. 뭐 그렇다고 쌩판 다르게 만들지는 않겠지만요.

하지만 중요하게 생각하는분도 있을 겁니다.

그래서 요지는 이겁니다. 레거시 지원이 중요할 때도 있고 이것을 포기하고 새로운 것에 더 집중해야 할 때도 있을 겁니다. 문제는 누가 그것을 결정 하느냐 같습니다. 벤더냐, 우리들이냐.

어느 만큼 레거시를 생각하고 지원해야 하는지의 경계선을 사용자와 개발자 공동체가 스스로 결정해 갈 수 있기 때문에 좋다고 생각합니다.

이런 점을 생각할 때 마다 자유라는 말의 포함된 의미를 몸으로 깨닫게 됩니다. 그리고 그 자유가 기술적으로 우월한 것을 만들어 가는데도 아주 효과가 탁월한 것 같습니다.

--
마잇


--
마잇

inureyes의 이미지

예전에 그 이야기로 친구와 토론을 한 적이 있었습니다. 소프트웨어의 레거시 지원에서 유저들이 떨어져 나가지 않는 마지노선이 어디인가? 라는 주제로 밤을 샌 기억이 나네요.

말씀하신 부분에서 생기는 문제라면, 실제 유저와 오픈소스 개발자들간의 시각차 때문에 너무 쉽게 레거시를 포기하는 경우랄까요? 벤더는 쉽게 포기 못하는 반면, 자유 소프트웨어의 경우에는 너무 쉽게 포기하는 경향이 있습니다. 대신 기술의 전환이나 진보는 빠르지만 말이죠 :)

언제나 적절한 균형선을 찾는 것이 참 힘듭니다^^

'Everything looks different on the other side.' -Ian Malcomm

'Everything looks different on the other side.' -Ian Malcomm

마잇의 이미지

자유 소프트웨어의 장점이 그럴때 특히 빛을 발하는 것 같습니다.

레거시를 포기했다고 하더라도 아직 원하는 사용자층만 두터우면 따로 계속 이어나갈 수 있다는 점이 그점인데요. 페도라 레거시 프로젝트 같은 것을 보면서 그런 생각을 했습니다.

레드햇은 중단할 수 밖에 없지만 공동체는 계속해나갈 수 있는 그런 자유가 좋은 것 같습니다.

--
마잇


--
마잇

kalstein의 이미지

캐쉬의 역할이 큰걸로 알고있습니당...
예전에 캐쉬가 비리비리할땐 서버영역은 거의 못건들였죠. 그러다가...캐쉬의 성능이 비약적으로 좋아지면서 점점 서버시장마저 잠식해 가고있죠.

RISC의 장점은 모든걸 레지스터에 저장하고, 그에따라 인스트럭션이 간단해지는것에 있는데...인스트럭션이야 뭐 x86내부에서 MicroOp로 바꿔버리니까 ㅡ.ㅡ;; 의미없어지고...
예전에 RISC가 CISC보다 빨랐던 이유가...레지스터의 개수가 압도적으로 많아서였는데...
요즘 x86들은 레지스터의 속도만큼 빠른 엄청난 크기의 캐쉬메모리를 가지고 있죠...그러니 속도에선 별 차이 안나고, 엄청 찍어대니까 싸지고. 어쨌든 CPU는 점점 x86이 점령해나가고 있네요...;;


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.