RHEL과 CentOS이야기는 리눅스쓰시는분들이라면 잘 아실겁니다.

RHEL은 전세계에서 가장 인기있는 대규모 서버용 배포판이고 안정성도 충분히 검증되어왔습니다. 그리고 그 안정성을 바탕으로 기술지원등의 수익을 벌고 있습니다.
그리고 대한민국한정으로 리눅스로 밥벌어먹을때 익혀야할 필수 배포판입니다.(우분투는 대한민국에서 아쉽게도 이쪽에서 크게 힘을 못 씁니다)

그리고 CentOS는 이 RHEL과의 호환성을 보장하고 무료로 배포된 배포판이기에 RHEL쓰다가 CentOS로 바꿔도 쓰던거 그대로 쓸 수있을 정도로 RHEL과 호환성이 좋기에 굳이 기술지원이 필요없다면 개인차원에서도 RHEL공부용으로 쓰기 좋은 배포판이었습니다. 그리고 국내에선 네이버나 카카오같은 자체개발능력이 있는곳에선 CentOS를 주력으로 쓰고있었지요.

그러다 CentOS를 직접 레드햇이 인수하게 되는데 이때까진 그래도 괜찮았습니다. 호환성을 무기로 점유율을 늘린건데 호환성이 더 좋아지면 더 좋아졌지 개판이 될거라고는 생각못했으니까요.

하지만 레드햇은 CentOS의 목을 쳐버리고 말았습니다.
기존 CentOS의 지원기간을 줄이고 이후에는 CentOS Stream이라는 개발버전만 남기기로 했습니다.

CentOS Stream은 RHEL과 호환되지 않습니다. RHEL은 안정성이 검증된 특정버전을 꾸준하게 보안업데이트만 하면서 지원해주는것이 특징인데 CentOS Stream은 말그대로 Debian unstable마냥 굴러가거든요.
Debian unstable과 stable이 일부 라이브러리에서 서로 충돌나는것처럼 CentOS Stream과 RHEL은 충돌납니다.

이후 CentOS의 후신을 자처하며 Rocky가 등장했고 Oracle도 CentOS에서 넘어올 수있도록 스크립트까지 배포하며 열심이었는데 레드햇은 이 Rocky도 마음에 안들었는지 유료 구독자 이외에는 자신들의 소스접근을 차단하기에 이르렀습니다. (호환성을 얻기위해선 소스를 알아야겠지요. 이걸 못 하게 막은겁니다.)

레드햇이 리눅스 개발커뮤니티에서 끼치는 영향을 생각하면 이건 상당히 위험한 행보입니다. 당장 RHEL의 점유율에는 영향이 없겠지만 (아니, 오히려 RHEL의 점유율은 올라갔습니다) 이미 개발자들에게 찍혀버렸고 CentOS로 RHEL관리법을 배우던 학생들도 사라져버렸습니다.

보통 CentOS로 공부하던 사람들이 현장에서 RHEL을 쓰는 방식으로 점유율이 높아진건데 이들이 사라지고 말았으니 이후 미래는 조금 위험해지지 않았나 싶습니다.

P.S RHEL의 소규모버전은 무료로 풀었다고 합니다. 학교등의 소규모 서버는 이걸로 한다고쳐도 규모있는 중견기업은 어떻게 해야할까요? RHEL을 구독해야할까요?

대부분은 관심없는거 압니다. 하지만 eu에게 뚜드려맞은 이유중 하나가 바로 webkit입니다.

webkit은 애플이 만드는 웹브라우저 엔진입니다
KDE에서 쓰던 KHTML을 잘 개량해서 쓸만하게 만들었고 대부분 크롬이긴했지만 한때는 웹브라우저 엔진 점유율 1위에 빛나던 물건입니다.

하지만 Webkit2를 애플이 발표하면서 크롬을  만들던 구글과 분쟁이 생겼고 구글이 기존의 Webkit을 포크해서 Blink로 바꾸게 되었습니다.
그리고 이름을 바꾸면서 기존에 크롬이 쓰던 Webkit1이 Blink가 되고 애플이 새로만든 Webkit2가 Webkit이 되었습니다.

즉, 지금의 Webkit은 사실 Webkit2고 과거의 영광을 가진 Webkit은 Blink인것이지요.

그리고 MS도 Webkit대신 Blink를 선택했고 현재대세는 애플의 Webkit이 아닌 기존Webkit을 계승한 Blink가 되었습니다.

하지만 애플은 이게 마음에 안들었는지 자사플랫폼(iOS)에선 Webkit(정확히는 Webkit2기반의 Webkit)사용을 강제했습니다. 그래서 Gecko엔진을 가진 Mozilla재단조차 iOS용 Firefox조차 Webkit으로 만들어야했습니다.

여기까진 십분이해 할 수 있습니다. 자사 라이브러리쓰게 할 수 있지요. 하지만 같은 Webkit이라도 Safari와 다른브라우저간의 레이아웃이 상당히 다릅니다. 성능도 당연히 다르고요. Safari외의 다른 브라우저를 못 쓰게하는건지 성능차이가 심하게 납니다.

심지어 웹 개발자들 말에 의하면 Chrome에 맞춰서 만들고 firerox로 접속해보면 딱히 건들곳이 없는데 iOS로 접속하면 다 깨지고 난리부르스라 그냥 Webkit용으로 따로 만드는게 낫다고 할정도입니다.

크롬과 파이어폭스는 엔진이 다름에도 서로 차이가 없지만 웹킷은 "어쩌라고"를 시전하는것이지요. 혼자 유아독존입니다.

그리고 최근 EU에서 애플을 Webkit에대해 반독점법 위반으로고소했습니다. 이미 라이트닝고수하다가 처맞은 전적이 있기에 이번에도 또 처맞을거 같은데 만약 이대로 된다면 Webkit의 점유율이 또 폭락하겠지요. iOS사용자들도 크롬을 선호하니까요.

Blink에 비해 특출난게 없고 Gecko보다 불안정하니 결국 트라이던트처럼 버려지고 Blink기반 사파리가 나올지도 모르겠습니다.

모르는 분들은 모릅니다
VKD3D vs. DXVK

사실 이 둘은 경쟁관계라고 볼 수 있습니다
VKD3D는 Wine환경에서 D3D를 Vulkan으로 돌리기위해 만들어진 라이브러리이고 DXVK는 DirectX환경에서 D3D를 Vulkan으로 돌리기위한 라이브러리입니다

이렇게보면 둘이 직접경쟁하는것 같지 않을겁니다. 하지만 이 둘은 경쟁중입니다. 바로 SteamDeck에서 구동하는 방식이지요.

저 위에 문구에서 D3D를 Vulkan으로라는 문구가 겹치는것이 보일겁니다. 사실 이게 이 둘의 핵심입니다만 구동방식이 약간 다릅니다.

DXVK는 DirectX환경. 즉, 윈도우환경을 전제로 합니다. 그런데 Wine은 윈도우와 호환되는 환경이기에 Wine에서도 구동이 이루어졌습니다.
VKD3D는 Wine환경에서 구동이 전제이고 실제 윈도우에서 구동되는건 신경쓰지 않았습니다.

그럼 SteamDeck에선 어떨까요? 당연히 SteamDeck은 네이티브 리눅스용이 아니면 Proton으로 구동되고 이는 사실 게임에 최적화된 Wine입니다. 그러다보니 DXVK나 VKD3D를 쓰게 되었고 둘이서 성능에 관해 경쟁하게 되었습니다.

써본결과 둘 다 성능차이는 크게 없지만 특정게임에 한해 DXVK가 더 낫기도하고 VKD3D가 더 낫기도하고 그렇습니다. 이는 D3D11을 Vulkan으로 구동하냐와 D3D12를 Vulkan으로 구동하냐의 차이입니다. D3D12를 잘쓰는곳은 VKD3D가 훨씬 성능이 좋지만 D3D12보다 D3D11이 더 괜찮은 게임은 DXVK가 더 나은 상황입니다.

그리고 계속 SteamDeck이라고 하고 있지만 일반PC리눅스의 스팀도 동일한 방식을 쓰고 있으니 같은 방식 차이가 생길거라는 생각을 할 수가 있습니다.

밸브의 선택은
DirectX11은 DXVK
DirectX12는 VKD3D로 잡은것 같습니다만 모르지요. 나중엔 어떻게 될지...

참고로 DXVK는 윈도우환경을 전제로 했기에 DirectX11에서 느린게임(라데온이 보통 그렇습니다)을 Vulkan으로 구동해서 빠르게 구동할 수 있지만 VKD3D는 윈도우에서 구동을 보장하고 있지 않습니다. 이쪽은 애초에 리눅스나 유닉스에서 돌리는것으로 만든 Wine팀 작품이니까요.