바이너리로 배포되는 낡은 프로그램들의 실행성에 있어서 그누/리눅스와 윈도간의 차이점

popuri의 이미지

바이너리로 배포되는 낡은 프로그램들의 실행성에 있어서 그누/리눅스와 윈도간의 차이점

제목이 다소 깁니다만, 문득 의문이 들어서 토론에 올려봅니다.

윈도의 경우 XP, 혹은 9x때 만들어진 바이너리도 최신에 가까운 윈도(7이나 8)에 설치하여 사용 가능한 반면에, 리눅스커널을 사용한 OS들(GNU를 포함)은 그게 잘 안되는 경우가 많다고 느낍니다.
예를들어서 그누/리눅스들의 경우 꽤 예전 (사실상 아시아눅스 전용으로 만들어지긴 했지만) 한컴소프트 한글워드프로세서 같은 경우 최근 배포판들 위에서는 제대로 설치도 안되고 사용하기 힘듭니다.
시간이 크게 많이 지나지 않은 바이너리들도 단지 커널버전이 변경되거나 배포판의 버전이 변경된것 만으로 보통은 제대로 작동하지 않습니다.
하지만 윈도의 경우 비슷한 시기에 발매된 윈도용 한글은 지금 윈도에 설치해도 보통은 제대로 설치가 되고, 충분히 쓸만합니다.
KOEI의 역사 게임같은 것들(윈도 9x때 게임)은 몇몇 경우를 제외하고는 윈도7에서도 잘 돌아갑니다.

위와 같은 것들을 생각했을때, 윈도는 유독 낡은 프로그램에 강하다고 느껴집니다.
10년, 20년전 바이너리가 아직도 제대로 작동될 정도니까 말입니다.
다르게 말하면 리눅스 배포판들은 유독 레거시에 약합니다. 의존관계는 깨지기 쉽고, 보통은 관리도 힘듭니다.
apt-get과 같은 패키지 관리시스템이 의존관계를 관리하고 있긴 하지만, 조금이라도 레거시한 프로그램을 사용하려고 하면 apt-get의 관리를 벗어나버립니다.
오죽하면 ubuntu의 의미가 I can't configure Debian 이라고 하겠습니까 :P (물론 ubuntu도 레거시 프로그램들에 대해서는 약하긴 마찬가지입니다)
약간 빗겨나가긴 하지만, 맥도 레거시에 약하긴 하지만 그누/리눅스만큼은 아닙니다. 맥이 레거시에 약한건 아키텍쳐를 한번 바꾼 것에서 오는것이 강하다고 생각합니다.(게다가 snow leopard 이후에는 레거시를 위한 에뮬레이터인 로제타스톤을 없애버린 것도 레거시에 약해진 이유라 봅니다)

이 차이점은 도대체 어디에서 오는걸까요?
윈도가 의존라이브러리들을 dll 형태로 프로그램 내부에 보통 저장해놓고 쓰는데 비해서 그누/리눅스는 공유라이브러리로 만들어서 사용하기 때문에 라이브러리 업데이트에 개별 소프트웨어가 따라가지 못해서 그런걸까요?(사실 이점에 있어서는 .app 으로 관리되는 맥의 어플리케이션도 그런듯 합니다)
윈도에서는 소프트웨어를 구입하거나 도입하는 방식이 보통은 인터넷이나 CD롬으로 설치마법사를 실행시켜서 실행아이콘이나 exe 파일을 도입하는 형태였지만, 그누/리눅스 배포판들은 apt-get 이나 yum, portage(는 소스 설치이니 앞의 두개과 다를것 같긴 하지만)과 같은 중앙저장소에서 OS에 커스터마이즈 된것을 내려받는 형태라서 그런걸까요?
일단 그누/리눅스에서 작동하는 바이너리도 동적라이브러리를 사용해서 프로그램 폴더에 넣어놓고 사용하는 방식으로도 사용할수는 있겠습니다만, 그것마저도 보통은 /usr/local 에 넣고 환경변수 PATH를 설정해서 쓰거나, /usr/local/bin 등에 심볼릭링크를 만들어서 쓰거나 하는게 주류입니다(맥도 비슷).
보통 그런 과정은 일반적인 사용자에게는 무리입니다. 일반사용자에게 터미널을 열어서 cd target_program ; sudo ./install.sh 을 타이핑 하게 하는건 가혹한 일이고, .deb 를 더블클릭해서 실행시켰을때 의존성패키지 리스트를 보여주는것은 다른 의미에서 가혹합니다.

결론적으로 제가 생각하는 그누/리눅스와 윈도의 낡은 바이너리에 대한 실행성차이는 UNIX 철학(한가지 프로그램은 한가지 일에 특화되도록 하는것)이 그 근원이라 생각합니다.
그누/리눅스에서 프로그램이란 OS의 일부로 작고 효율적이면서 동시에 프로그램들간에 유기적으로 연결된 것이지만, 윈도에서 프로그램이란 비교적 간단히 OS와 분리되는 객체처럼 느껴집니다.
따라서 윈도에서는 OS에 대하여 바이너리의 수명이 비교적 긴편(OS의 변화가 있더라도 내부의 바이너리가 OS에 의존하는 부분이 적으므로)이고, 그누/리눅스는 그렇지 않기에 바이너리의 수명은 태생적으로 짧아질수 밖에 없는듯 합니다. 맥은 그 중간정도고요.

---------
이하, 지극히 GNU에 치우친 부연입니다.
---------

이상적인 GNU의 철학에서 생각한다면 바이너리의 수명이 짧은건 사실 크게 문제가 안되긴 합니다.
소스가 남아있고 gcc만 제대로 들어가있고 표준라이브러리들이 제대로 지원되기만 한다면 언제든지 소스컴파일해서 최신상태로 유지시킬수 있을테니까요.
물론 OS 자체의 창관리자나 GUI 이벤트콜 등이 달라지는 것에서 오는 호환성의 문제는 있을수 있지만, 이건 윈도도 가지고 있는 문제이고 GUI를 사용하는 이상 피할수 없는 문제일겁니다. 그러므로 그런 GUI 관련 함수들은 충분히 미래를 내다본 설계를 할 필요가 있습니다만, 이건 지금 논의하고 있는 문제와는 좀 거리가 있는 다른 문제입니다.(범용적이지 않은 다른 개별 라이브러리들에게 충분히 미래를 내다본 설계를 해라고 하는건 권장사항은 될수 있지만 반강제적으로 말하기엔 힘들다고 생각합니다)

다만 바이너리의 수명이 짧은것은 실제로 바이너리만으로 배포되는 독점프로그램들에 있어서는 엄청나게 큰 문제입니다.
그누/리눅스에서 가동되는 게임이 적은 이유는 GPL과 같은 소스공개를 강제하는 라이브러리나 프로그램들에 의한 (관점에 따라서는...?) 문제와 더불어 바이너리의 수명이 짧을수 밖에 없는 그누/리눅스의 태생적 문제와도 직결되어 있다고 생각합니다.
미래에 GNU가 일반화되어 프로그램을 만드는 회사나 개인이 소스를 공개하는것이 일반화되는 문화가 정착된다고 가정한다면 이상적으로는 프로그램 소스는 커뮤니티에 의해 관리되어 레거시는 언제나 유지보수되어 최신으로 업데이트 될수 있겠지만, 이건 사실 유토피아에 가깝다고 느껴질 정도의 미래상이라 지금의 사회가 점진적으로 실현 가능할지 다소 의문입니다.(적어도 그런 미래가 가능하기 위해서는 지금보다 더 많은 사람들이 프로그램 언어를 다룰수 있고 그걸 취미로 가지는 사회가 와야 할겁니다)

게다가 소스가 공개된 프로그램들도 유닉스계열에서는 의존성지옥이 기다리고 있습니다.
패키지관리자를 쓸수 없는 개인이 컴파일하는 소스는 의존성을 하나하나 체크해야합니다.
이것을 해결하기 위해서 autoconf 나 makefile 등의 훌륭한 툴이 나온거겠지만, 그 툴들은 너무 geek 합니다. 일반적인 사용자는 손이 닿질 않는 영역입니다.
조금 더 고수준(프로그램 계층적인 의미에서)의 프로그램이 있다면... macport나 homebrew 같은걸 들수 있을지도 모르겠습니다.
그것들은 소스컴파일을 하면서 동시에 의존성도 해결해주는 프로그램이니까요. 하지만 아직 geek 합니다...

결국 바이너리수명을 늘리는건 이상적인 GNU가 일반화된 사회가 아닌 현 사회에 있어서는 선택이 아닌 필수가 됩니다.
사용자가 원하는건 아이콘을 클릭했을때 실행되는 혹은 설치되고 실행되는 프로그램입니다. 그리고 윈도는 이래저래 그걸 10, 20년간은 잘 해오고 있는편이고요.
그누/리눅스가 현실적으로 윈도 데스크탑의 대안이 되기 위해서는 UNIX의 철학을 적어도 end user가 사용하는 GUI 어플리케이션에 대해서는 잠깐 접어둬야할 - 어쩌면 현재의 맥처럼 되어야할 - 지도 모른다는겁니다.

그외에 앞에서 잠깐 언급한 OS자체가 제공하는 라이브러리 등의 레거시 대응에 대해서는 조금 부연이 필요할지도 모르겠습니다.
그누/리눅스는 윈도와 같이 다양한 하드웨어 위에서 작동된다는 것은 같습니다.
하지만 윈도같이 통제된 개발환경(적어도 윈도는 '배포판'은 없죠)이 없다는게 또 다른 바이너리 수명을 줄이는데 기여하고 있습니다.
이것은 OS의 다양성을 늘려주지만, 동시에 end user 에게는 단기적으로는 독입니다.
그누/리눅스도 레거시를 좀더 잘 지원해주는 de-facto 배포판이 있다면(우분투...?) 모르겠습니다만, 저는 그런 배포판은 잘 못본것 같습니다. 물론 애초에 그누/리눅스에서 쓰는 프로그램들 자체가 윈도에서 볼수 있는 레거시의 형태로 사용되는게 거의 없다는 점도 있습니다.
굳이 들자면 서버로 사용되는 리눅스에서 안정성을 위해서 레거시한 프로그램을 쓰거나 그래픽 드라이버를 예전 하드웨어에 맞춰서 레거시한걸 쓰거나... 하지만 이것들도 윈도에서 말하는 낡은 바이너리와는 좀 다른 느낌입니다.

----------

처음으로 돌아가서, 여러분은 바이너리로 배포되는 낡은 프로그램의 실행성에 있어서 그누/리눅스와 윈도간의 차이점에 대해 어떻게 생각하십니까?

36311의 이미지

바이너리의 독점을 버리려고 하는 곳이 GNU 아니었나요?

* 포럼 주제와 무관한 신변잡기를 반복해서 올리지 맙시다.
* 질문 게시판 만이라도 익명 글쓰기를 막아야 한다고 생각합니다.

popuri의 이미지

GNU의 철학이 담긴 GPL은 소스독점이 불가능하도록 설계되어 있지 않나요?
바이너리를 독점한다는 의미를 잘 모르겠습니다.

그리고 하나의 컴파일된 바이너리의 실행성(수명)과 소스독점은 관련되어있긴 하지만 GNU 하에서는 독립적인 문제라고 봅니다.
소스가 자유소프트웨어라면 결국 바이너리 실행성의 문제는 레거시한 라이브러리들이나 지원(결국 하위호환)을 마구넣은 상태로 OS를 만들건지 말건지의 문제니까요.

꽉 찬것은 텅 빈것과 다를게 없다.

popuri의 이미지

에전 KLDP 글 중에서 하위호환에 대한 글이 있어서 링크 해봅니다.

https://kldp.org/node/74937

꽉 찬것은 텅 빈것과 다를게 없다.

dymaxion의 이미지

저도 리눅스에서 어떤 어플을 받아다 깔았는데 라이브러리 버전이 안맞다는 둥 하면서 실행 안 될 때 짜증이 화악 솟아 오르더라고요. (@,.@);;;
대표적으로 한컴뷰어 리눅스 버전, 3D CAD DraftSight 같은 녀석들이 이랬어요.
패키지 제작자의 배려가 부족하다고 느껴지더라고요.

개인적으로 이상적으로 생각하는건 이런 형태인데요...

(1) 리눅스 시스템 관련 부분이나 유틸리티 종류는 기존대로 시스템 라이브러리에 의존하도록 구성한다.
(2) 독립적인 업무 또는 게임용 어플리케이션은 가급적 시스템 라이브러리에 의존하지 않도록 패키징해서 제공한다.

(2)번 형태를 조금 부연하자면,

SageMath 라는 수학계산용 패키지를 내 컴퓨터에 설치할 때,
이 패키지는 그냥 나의 Home 디렉토리에 압축만 풀어넣으면 끝입니다.
시스템에 의존하는 부분이 없더라고요.
전부 자기 안에 다 들어 있습니다.
참고로 이 패키지는 수학관련된 각종 패키지 100여종 이상을 다 모아놓은 건데요...
Python 위주로 되어 있는데 심지어 자기 전용 파이썬2.7까지 스스로 가지고 있어요.
당연히 필요한 Pythin 라이브러리들도 전부 이미 들어 있고요.
그래서 시스템의 Python이 어떻게 설정되어 있는지 등에 전혀 관계가 없는거죠.
사용자는 그냥 압축 풀고 실행만 시키면 되도록 되어 있어요.
시스템 설정 뭐 건드려줘야 되고 의존성 따지고 이런데 신경 안써도 되고요.

물론 이런 전략을 취할 경우 댓가가 따르죠.
용량이 더 커지고, 시스템 자원이 중복되고,
안에 패키징된 많은 종류의 라이브러리들의 라이센스 조건을 일일이 다 확인해서 문제없는 것만 선별해야 되고 등등.

그런데 하드디스크 용량가지고 걱정하는 시대도 아닌데다가
라이센스야 뭐 오픈소스 패키지일 경우에는 별 문제되는 경우는 없어 보이더라고요.
소스를 감추고 사업하려고 하니깐 문제가 되는거지....

하지만 그래도 그게 사용자 입장에서 제일 편하긴 하더라고요...
업데이트는 그냥 새로 받아다가 덮어서 풀어주면 되고요.
자동으로 버전 체크하면서 알아서 버전업 해 주면 더 좋지만...

이런 식의 패키지라면, 애플보다 못할 것도 없죠 뭐.
시스템 유틸리티가 아니고, 사무용이나 게임용 어플이라면 이쪽 방향이 더 편한 것 같아요.

======================================
Mechanical Engineer
DymaxionKim.github.io
======================================

popuri의 이미지

'컴퓨터로 일을 한다' 라고 한다면 꽤 많은 경우 레거시를 고려할수밖에 없지요.
그래서 그 싫고 짜증나는 윈도를 욕하면서 쓸수밖에 없게 되는거고요.

컴퓨터를 단순히 '사용'하는 사용자에게 좀더 친절하게 와닿는건 역시 시스템 업데이트에 따라서 변하기 쉬운 의존성 라이브러리들을 하나의 프로그램이 전부 품고 있는 형태가 지금 상황으로는 맞을듯 합니다.
물론 그런식으로 거대한 프로그램의 반대편에 서있는 각각이 의존관계를 가지는 모듈형 프로그램들로 설계되는 자유소프트웨어와 중앙관리되는(저장소관리되는) 소프트웨어들만으로도 대부분의 작업은 가능하고, 실제로 그누/리눅스의 형태는 그게 더 바람직하다는 점을 생각해본다면 앞으로는 그런 형태로 점점 가야겠습니다만, 그건 한컴워드같은 사유소프트웨어가 자유소프트웨어화 되지 않는한 불가능한 일이겠죠.

왜 그렇게 FSF가 자유소프트웨어가 적어도 자유소프트웨어 기반의 OS에 있어서는 '대안'이 아닌 '유일한 방법'이라고 말하는지는 바로 이런 문제때문이 아닐까 하고 생각해봅니다.

sage는 자유소프트치고는 다소 예외적이려나요.
윈도에서 sage를 사용하려면 native하게는 불가능하고, 가상데스크탑하에서 설치해야하는것도 있고요.
사실 sage는 python + numpy + sympy + scipy + matplotlib + ... etc 을 해놓은 frontend 일 뿐이라는 면이 강해서 GNU/Linux + sage 에디션에 가깝다고 생각이 드는 면도 있지요.

꽉 찬것은 텅 빈것과 다를게 없다.